02-12-2016 05:51 PM
We are currently trying to terminate a VPN tunnel at a 5505 across a Fortigate 60d. We have succeeded in establishing a transparent tunnel from the 5505 to a remote client.
Unfortunately we cannot ping anything on the inside vlan from a VPN connected client except for the inside interface of the ASA. However, from the ASA command line interface, every device on the inside vlan can be pinged. The main goal is to be able to manage multiple devices on the inside network remotely.
The ports being forwarded in the Fortigate are UDP 4500, UDP 10000, UDP 500, IP protocol 50 and 51, UDP 443, and TCP 443.
We are about out of ideas as to why this isn't performing as expected. Attached is the 5505 configuration. Please let me know if you see anything wrong with the configuration.
02-13-2016 04:20 PM
Hello,
I see that you configured a nonat ACL but you didn't configure the no nat itself, I will assume that 172.22.16.0/24 is the remote network if not then correct the access list with the correct remote network.
access-list nonat extended permit ip 172.22.6.0 255.255.255.0 172.22.16.0 255.255.255.0
you need to configure the no nat like this:
nat (inside) 0 access-list nonat
Regards, please rate!.
02-15-2016 09:44 AM
Thank you for your response Diego. I configured the no nat and am still not able to ping the LAN from the remote network.
02-15-2016 01:41 PM
try running a packet tracer to confirm that you are hitting the nat exemption:
packet-tracer input inside icmp 172.22.6.5 8 0 172.22.16.7 de
02-15-2016 01:57 PM
02-15-2016 02:10 PM
Hello,
Ok so we know the nat is not an issue this has something to do with the ACL most likely the one you applied to the outside interface
access-group ping in interface outside access-group ping out interface outside
Can you remove it from the config:
no access-group ping out interface outside
no access-group ping in interface outside
and configure another ACL don't specify icmp type just do icmp any any:
access-list test extended permit icmp any any
apply it to the outside interface inbound direction:
access-group test in interface outside
try the packet tracer again.
02-15-2016 03:23 PM
Thank you Diego. The packet-tracer shows that those packets aren't being dropped anymore. I still cannot ping devices on the LAN from my remote client's command prompt. When I tried to trace the packets over the outside interface, I got ipsec-spoof drop reason. Does this indicate that my encryption out of the 5505 is not being performed?
02-15-2016 04:09 PM
If the packet tracer from inside to outside is working then it should work backwards the packet tracer is not the best way to simulate traffic from outside to the inside when it's coming from a VPN tunnel. What I will suggest next if the SA is up with this traffic and you see the tunnel up take captures on the ASA to see if the traffic is really getting to the inside interface to isolate the issue.
capture capin interface inside match ip 172.22.6.0 255.255.255.0 172.22.16.0 255.255.255.0
send ping and then do a "show capture capin" if you see the request and not the replay is an internal routing issue if you don't see the traffic on the ASA there's a problem in the remote device that is not sending the traffic correctly
02-15-2016 04:33 PM
Thank you Diego. I was able to see the requests and not the reply. Looking at my VPN client statistics, under route details, I see only a secure route to the LAN (172.22.6.0) and nothing to the VPN subnet (172.22.16.0). I have implemented ASAs in the past that work fine with only this secured route, however I wasn't trying to perform NAT-T. Is this a route I need to define explicitly for this application?
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: