04-12-2017 08:04 AM
Hi,
I have recently set up a site to site IPSec VPN between two Cisco ASAs. However, I have only been seeing one way traffic on both ASAs - one added complication is that one of the endpoints sits one hop away from the ASA (see attached diagram).
When I ping from 10.1.0.2 to 10.2.0.2, I am seeing traffic counters on both ASAs VPN monitors increase, but only one way, there is no return traffic.
When I ping from 10.2.0.2 to 10.1.0.2, I do not see any traffic counters increase on either ASA.
I am able to ping from 10.2.0.2 to 172.22.100.30 (and back).
I am struggling to understand how traffic is not being passed over the VPN from the ASA 5512 back to the ASA 5505 as the configurations are near identical.
Please let me know if there is any more iformation I can provide.
-Gareth
04-13-2017 12:07 PM
I have had experiences with one way traffic for a site to site VPN. Sometimes it reflects an issue with configurations that do not match, sometimes it reflects an issue with NAT/noNAT/identity NAT on one side or the other, sometimes it reflects an issue where the hosts on one side do not have correct routing information about the network on the other side.
HTH
Rick
04-18-2017 02:28 AM
Hi Rick,
After a bit of troubleshooting, I've made some changes to the NAT configuration on the 5512, but am still seeing the same issue.
The NAT configuration on both reflects the following:
NAT (Inside,Outside) source static PRENAT_IP PRENAT_IP destination static POSTNAT_IP POSTNAT_IP route-lookup
I have not configured any routes on either device as it looks like these have been automatically added by the cryptomap:
5512
S 10.1.0.0 255.255.255.0 [1/0] via <Public_IP>, Internet
5505
S 172.22.100.28 255.255.255.252 [1/0] via 192.168.10.254, outside
S 10.2.0.0 255.255.255.0 [1/0] via 192.168.10.254, outside
Thanks,
Gareth
04-17-2017 04:55 AM
i recommend you to debug the ASA5512 .
Initiate continuous ping from 10.2.0.2 to 10.1.0.2
# loggin on
#loggin con 7
#debug crypto ipsec 127
& also # debug icmp trace
for more please share the both configuration ASA.
Regards,
Mani
04-18-2017 02:21 AM
04-19-2017 02:01 PM
Gareth
Thank you for posting the configs. On the 5505 could you reverse the order of these nat statements
nat (Inside,outside) source dynamic any interface
nat (Inside,outside) source static NETWORK_OBJ_10.1.0.0_24 NETWORK_OBJ_10.1.0.0_24 destination static DM_INLINE_NETWORK_1 DM_INLINE_NETWORK_1 route-lookup
so that the ASA sees the static nat before the dynamic one?
HTH
Rick
04-20-2017 12:37 AM
Hi Rick,
I've changed the NAT orders so the static NAT statements are at the top on both firewalls, but am still experienceing the same issue.
When I run a packet trace on the 5512, I am seeing the traffic marked as to be encrypted, but is dropped by a configured ACL rule. I have also tried prepending this rule with an Any-Any, but to no effect.
Thanks,
Gareth
04-20-2017 07:22 AM
I've captured some debug logs whilst pinging from either end of the tunnel:
5505:
6 | Apr 20 2017 | 13:33:01 | 302020 | 10.1.0.1 | 10072 | 172.22.100.29 | 0 | Built outbound ICMP connection for faddr 172.22.100.29/0 gaddr 10.1.0.1/10072 laddr 10.1.0.1/10072 |
6 | Apr 20 2017 | 13:33:11 | 302021 | 172.22.100.29 | 0 | 10.1.0.1 | 10072 | Teardown ICMP connection for faddr 172.22.100.29/0 gaddr 10.1.0.1/10072 laddr 10.1.0.1/10072 |
6 | Apr 20 2017 | 13:33:14 | 302020 | 10.1.0.1 | 5768 | 172.22.100.30 | 0 | Built outbound ICMP connection for faddr 172.22.100.30/0 gaddr 10.1.0.1/5768 laddr 10.1.0.1/5768 |
6 | Apr 20 2017 | 13:33:24 | 302021 | 172.22.100.30 | 0 | 10.1.0.1 | 5768 | Teardown ICMP connection for faddr 172.22.100.30/0 gaddr 10.1.0.1/5768 laddr 10.1.0.1/5768 |
5512:
6 | Apr 20 2017 | 16:03:12 | 110003 | Ifc | 10.1.0.1 | 0 | Routing failed to locate next hop for icmp from NP Identity Ifc:172.22.100.30/0 to CUST-TEST-VPN:10.1.0.1/0 |
6 | Apr 20 2017 | 16:02:58 | 110003 | Ifc | 10.1.0.2 | 0 | Routing failed to locate next hop for icmp from NP Identity Ifc:172.22.100.30/0 to CUST-TEST-VPN:10.1.0.2/0 |
Thanks,
Gareth
04-20-2017 09:37 AM
Gareth
The messages that you post from the 5512 are puzzling. They seem to indicate a problem routing. Would you post the output of show route from the 5512?
HTH
Rick
04-20-2017 09:44 AM
Show route:
Gateway of last resort is <Public IP next hop> to network 0.0.0.0
S* 0.0.0.0 0.0.0.0 [1/0] via <Public IP next hop>, Internet
S 10.0.0.0 255.0.0.0 [1/0] via 172.22.100.17, MZ_VRF
S 10.1.0.0 255.255.255.0 [1/0] via <Public IP next hop>, Internet
S 172.15.0.0 255.255.0.0 [1/0] via 172.22.100.17, MZ_VRF
S 172.16.0.0 255.240.0.0 [1/0] via 172.22.100.17, MZ_VRF
C 172.22.5.0 255.255.255.0 is directly connected, MGMT
L 172.22.5.254 255.255.255.255 is directly connected, MGMT
C 172.22.100.16 255.255.255.252 is directly connected, MZ_VRF
L 172.22.100.18 255.255.255.255 is directly connected, MZ_VRF
C 172.22.100.28 255.255.255.252 is directly connected, CUST-TEST-VPN
L 172.22.100.30 255.255.255.255 is directly connected, CUST-TEST-VPN
C 172.22.125.0 255.255.255.0 is directly connected, BR-25
L 172.22.125.254 255.255.255.255 is directly connected, BR-25
C 172.22.127.0 255.255.255.0 is directly connected, BR-27
L 172.22.127.254 255.255.255.255 is directly connected, BR-27
C 172.22.130.0 255.255.255.0 is directly connected, CLL-IT
L 172.22.130.254 255.255.255.255 is directly connected, CLL-IT
C 172.24.25.0 255.255.255.0 is directly connected, BRIDGE-25
L 172.24.25.254 255.255.255.255 is directly connected, BRIDGE-25
C <Public IP subnet> 255.255.255.224 is directly connected, Internet
L <Public IP self> 255.255.255.255 is directly connected, Internet
S 192.168.0.0 255.255.0.0 [1/0] via 172.22.100.17, MZ_VRF
Show asp table routing:
route table timestamp: 205
in 255.255.255.255 255.255.255.255 identity
in 172.22.100.30 255.255.255.255 identity
in <Public IP self> 255.255.255.255 identity
in 172.22.100.28 255.255.255.252 CUST-TEST-VPN
in <Public IP subnet> 255.255.255.224 Internet
in 10.1.0.0 255.255.255.0 via <Public IP next hop>, Internet
in 0.0.0.0 0.0.0.0 via <Public IP next hop>, Internet
out 255.255.255.255 255.255.255.255 CUST-TEST-VPN
out 172.22.100.30 255.255.255.255 CUST-TEST-VPN
out 172.22.100.28 255.255.255.252 CUST-TEST-VPN
out 224.0.0.0 240.0.0.0 CUST-TEST-VPN
out 255.255.255.255 255.255.255.255 Internet
out <Public IP self> 255.255.255.255 Internet
out <Public IP subnet> 255.255.255.224 Internet
out 10.1.0.0 255.255.255.0 via <Public IP next hop>, Internet
out 224.0.0.0 240.0.0.0 Internet
out 0.0.0.0 0.0.0.0 via <Public IP next hop>, Internet
out 0.0.0.0 0.0.0.0 via 0.0.0.0, identity
out :: :: via 0.0.0.0, identity
Thanks,
Gareth
04-24-2017 12:00 PM
Gareth
I notice that on the 5512 the access list used for the crypto map includes the log parameter. Would you remove that parameter from the access list and tell us whether the behavior changes.
HTH
Rick
04-25-2017 01:07 AM
Hi Rick,
I've now removed the logging paramaters on both 5505 and 5512 cryptomaps, but am still seeing the unidirectional traffic on both.
Thanks,
Gareth
04-24-2017 01:37 PM
Hello,
Could you please attach output of packet-tracer from both the ASA. There are no hits on crypto map policy encaps or decaps, so looks like the crypto map is not being used as of now.
Also, please attach output of show route from both ASA.
On ASA 5512, you have an object-group named 'DM_INLINE_NETWORK_1' used in crypto access-list but I dont see it defined in running-config, please cross check.
It should rather be 'DM_INLINE_NETWORK_2'
Regards,
AJ
04-25-2017 01:05 AM
Hi Ajay,
The objects 'DM_INLINE_NETWORK_1' and 'DM_INLINE_NETWORK_2' are both present in the running config on the ASA 5512 and both contain the same network objects. It looks like I accidentaly removed the object group when trimming my config before posting - apologies.
5505 show route:
Gateway of last resort is 192.168.10.254 to network 0.0.0.0
C 192.168.15.0 255.255.255.0 is directly connected, MGMT
C 192.168.10.0 255.255.255.0 is directly connected, outside
S 172.22.100.28 255.255.255.252 [1/0] via 192.168.10.254, outside
C 10.1.0.0 255.255.255.0 is directly connected, Inside
S* 0.0.0.0 0.0.0.0 [1/0] via 192.168.10.254, outside
5512 show route:
Gateway of last resort is <Public IP next hop> to network 0.0.0.0
S* 0.0.0.0 0.0.0.0 [1/0] via <Public IP next hop>, Internet
S 10.0.0.0 255.0.0.0 [1/0] via 172.22.100.17, MZ_VRF
S 10.1.0.0 255.255.255.0 [1/0] via <Public IP next hop>, Internet
S 172.15.0.0 255.255.0.0 [1/0] via 172.22.100.17, MZ_VRF
S 172.16.0.0 255.240.0.0 [1/0] via 172.22.100.17, MZ_VRF
C 172.22.5.0 255.255.255.0 is directly connected, MGMT
L 172.22.5.254 255.255.255.255 is directly connected, MGMT
C 172.22.100.16 255.255.255.252 is directly connected, MZ_VRF
L 172.22.100.18 255.255.255.255 is directly connected, MZ_VRF
C 172.22.100.28 255.255.255.252 is directly connected, CUST-TEST-VPN
L 172.22.100.30 255.255.255.255 is directly connected, CUST-TEST-VPN
C 172.22.125.0 255.255.255.0 is directly connected, BR-25
L 172.22.125.254 255.255.255.255 is directly connected, BR-25
C 172.22.127.0 255.255.255.0 is directly connected, BR-27
L 172.22.127.254 255.255.255.255 is directly connected, BR-27
C 172.22.130.0 255.255.255.0 is directly connected, CLL-IT
L 172.22.130.254 255.255.255.255 is directly connected, CLL-IT
C 172.24.25.0 255.255.255.0 is directly connected, BRIDGE-25
L 172.24.25.254 255.255.255.255 is directly connected, BRIDGE-25
C <Public IP subnet> 255.255.255.224 is directly connected, Internet
L <Public IP self> 255.255.255.255 is directly connected, Internet
S 192.168.0.0 255.255.0.0 [1/0] via 172.22.100.17, MZ_VRF
Thanks,
Gareth
04-25-2017 05:05 AM
Please attach output of packet-tracer from each ASA.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide