lan 2 lan vpn tunnels

[carl_townshend]

Hi all, can anyone tell me if stateful inspection still applies on vpn tunnels on my asa? and also when creating an access list for the site to site tunnel, how do I know which direction the access list is in?

[satish_zanjurne]

Hi,

1.I think it still applies , because the tunnel in encrypted connection between sites & hosts on both sides still needs to be statefully inspected to allows sessions between them

2.For site to site tunnel the access-list will define interesting traffic from this site to peer site , in outward direction.

HTH..rate if helpful..

[carl_townshend]

ok, thanks

regarding the access list, how would I configure the access list to be inbound from the peer to my site? I cannot see this option on the gui interface.

hope you can help

[jkeeffe]

In the ASA documentation, it specifically states the when an ACL is applied to a VPN-filter, the first entry in the ACL always represents the remote end, regardless of whether the remote end is the source or destination of the traffic.

This caused me to hold off on deploying my ASA-5540s as a VPN head-end because of the difficulty in troubleshoot this weird way of doing ACLs would cause. You'd never know by looking at the ACL, what is the source or the destination of a particular connection.

Refer to this Cisco document:

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00808c9a87.shtml

I hear that the ASA code, as far as the VPN subsystem ins concerned, is being completely re-written and one of the changes will be NOT doing the ACL's this way. On all other Cisco devices, the first entry in an ACL refers to the source.

If I am wrong here, please someone correct me.

[elden]

Interesting post.

We struggled with setting up 3 new L2L tunnels recently on an ASA5520 using vpn-filters and we've experienced the same. We banged our heads (and 3 TAC engineer's + their escalation) against the wall trying to understand the vpn-filter ACL logic flow.

We think we now understand the anti-logic of TCP connections, but are still puzzled at the workings of ICMP vpn-filters. If we are pinging from a host on our local network to a host on the far-end of the tunnel, one would think you would have to allow icmp "echo" from our network and icmp "echo-reply" returning from the far-end. The only way it worked was to allow both icmp "echo" and icmp "echo-reply" from the far-end to us in order for us to successfully ping.

Any update on your comment on the code re-write?