1

Ok... I'm having a really strange IPSec issue (at least strange to me :-) ). I have a Sonicwall Pro 2040 connected to an ASA 5510. When the traffic initiated from the Sonicwall side of the network, it works fine... but if it originated from the ASA side, no dice. For instance, icmp echo from PC-A on the sonicwall gets received by PC-B on the ASA. PC-B responds with an icmp reply and PC-A receives it. If PC-B sends an echo request to PC-A, it never even traverses the IPSec tunnel (verified by no ESP traffic being generated across the wire). A wireshark on PC-B shows the EXACT SAME source IP and MAC on the icmp echo request as the icmp echo reply... any ideas as to what could cause this behavior? :(

Additional note: if I clear the isakmp on the ASA and try to ping from PC-B to PC-A, it doesn't attempt to bring the tunnel up... it doesn't seem to realize that this traffic is destined for the sonicwall network, even though when I send replies back it works fine.

Another note: I ran a packet capture on the ASA using the same exact ACL as the IPsec tunnel and it matched the icmp request packets from PC-B... so for some reason it's just not trying to send them across the tunnel even though it matches.

Dan
  • 1,278
  • 18
  • 27

1 Answers1

1

Aha... apparently because I was hairpinning on the internal interface (testing before I ship it out to a remote site) and the default route was out the external interface, I needed to put a static route on there to route the VPN traffic back to the internal interface and then it would send it across the tunnel. I noticed this when I was using packet-tracer and it mentioned flows... I guess a flow created by a VPN connection inbound can take precedence over static routes... good to know :-)

Dan
  • 1,278
  • 18
  • 27