ASA 8.3 VPN access-rules

[BigG@servebase]

Hi, I've recently purchased an ASA 5520 to use as a VPN gateway for multiple site to site VPN tunnells. I've upgraded to version 8.3 and set up a lab environment. I have set up a simple VPN with a general permit ip rule to stert with and everything works fine. I am having trouble tightenign up the access now, if I change the access on the ASA to ICMP I can ping both ways, if I add tcp I can telnet from a workstation on the other end of the VPN, but if I change the tcp to telnet I cannot connect. the other end on the VPN is a cisco 2620XM and I match the access lists for each of the changes. I also don't quite get the direction in the ASA access list, it seems that if I want to permit tcp access from the remote host to the host behind the ASA I have to have the host behind the ASA as the source, it seems backwards??? Can any one shed any light on this? much appreciated.

[Jennifer Halim]

Are you configuring VPN-filter ACL?

VPN-filter is predominantly meant to be for remote access vpn filtering policy, so the direction of the ACL would be from remote end towards the local LAN.

If you are using the VPN-filter for L2L VPN tunnel, I would suggest the following:

- To allow/block traffic from remote towards local LAN, use the VPN-filter feature

- To allow/block traffic from local LAN towards remote LAN, use the ACL on your LAN (inside) interface.

[BigG@servebase]

Hi, thanks. What I've now done is permit ip local ----> remote any on the the VPN ACL's and then put more grandular ACE's in the ACL's on the interfaces. this works well for me as the VPN can be brought up for any reason but access to my servers is tied down to the specific ports I need.

[Jennifer Halim]

Can you please share your ACL and advise which ACE is not working?
And also who is trying to initiate connection towards which side? eg: remote is trying to telnet to local LAN, etc.

[BigG@servebase]

I think you mis understood my previous reply. I actually have it working now by making an ip any on the VPN acl as follows;

access-list outside_b2b_vpn_1_cryptomap extended permit ip object prod_lan object remotesite1_1918NET

and the applying port specific access lists to my interfaces as follows;

Providing access in from the WAN interface with the "outside_b2b_access_in" ACL

access-list outside_b2b_vpn_access_in extended permit icmp object-group vpn_remote_hosts object LBIP_1918 object-group icmp_permitted
access-list outside_b2b_vpn_access_in extended permit tcp object-group vpn_remote_hosts object LBIP_1918 eq telnet

Provide access out the LAN interface with the "inside_cp_link_access_out" ACL

access-list inside_cp_link_access_out extended permit icmp object-group vpn_remote_hosts object LBIP_1918 object-group icmp_permitted
access-list inside_cp_link_access_out extended permit tcp object-group vpn_remote_hosts object LBIP_1918 eq telnet

This works.

[Jennifer Halim · Accepted solution]

Yes, you are supposed to only configure "IP" for your crypto ACL (ACL applied to your crypto map), and crypto ACL supposed to mirror image on each peer, hence when you change it to specific TCP/UDP ports, it doesn't mirror image to the other side/peer anymore.

I thought you are using ACL applied to "vpn-filter".

But from the previous post, you actually configure ACL on each interfaces.

The above are 3 different ACL that you applied differently (crypto ACL --> apply to crypto map, vpn ACL --> apply to vpn-filter, and your normal interface ACL).

[BigG@servebase]

Thanks Jennifer, it all makes sense now.

On another point, do you have any recommendations on monitoring traffic in the CLI. This firewall will be a very busy VPN gateway with approximately 300 site to site VPN tunnels so I'm looking for any info regarding filtering log output or possibly traffic capture to make future troubleshooting easier. You can imagine the log output once this is in production would be a nightmare if I cannot filter out only the detail I need. Any suggestions would be great.

[Jennifer Halim]

A few "show" output if you would like to check on specific peer:

show cry isa sa | i

show cry ipsec sa peer

show vpn-sessiondb detail l2l

The "show vpn-sessiondb" command can be more specific, please find the following command for your reference:

http://www.cisco.com/en/US/docs/security/asa/asa82/command/reference/s7.html#wp1306284

Good tip, use the packet tracer feature, and it would go through each packet flow, and will tell you where the problem is exactly.

Hope that helps.