Solved: Cisco ASA L2L Filter

exonetinf1nity · ‎10-09-2009

Greetings, i want to manage/monitor a customer network remotely using a L2L VPN between two Cisco ASA's.

I want to allow specific traffic originating from our network (ICMP, SSH, SNMP) to be allowed onto the customer network but dont want the customer to have any visbility of our network.

I have created the L2L VPN and applied the a VPN filter on the customer firewall, all is well and we can only using ICMP, SSH and SNMP between our site and the customer site.

However the customer also has visibility of our network using the same protocols.

This is the VPN filter on the customer firewall.

access-list cust_mgmt extended permit udp object-group remoteMgmtHosts allsites-inside 255.255.0.0 eq snmp

access-list cust_mgmt extended permit icmp object-group remoteMgmtHosts allsites-inside 255.255.0.0

access-list cust_mgmt extended permit tcp object-group remoteMgmtHosts allsites-inside 255.255.0.0 eq ssh

access-list cust_mgmt extended deny ip allsites-inside 255.255.0.0 object-group remoteMgmtHosts

remoteMgmtHosts = Our management hosts

I have added the deny ip any to our management hosts at the end but it doesnt appear to be working.

However if i put a VPN filter on our firewall denying traffic from the customer network when applying this filter i am unable to use SSH, SNMP or ICMP, i was working on the principal that traffic originating from our network would be permitted back through the firewall on the return path.

Any suggestions would be much appreciated.

Regards

Patrick0711 · ‎10-09-2009

With your above VPN-filter applied to the client side, the client should only be able to communicate back to the remote side via ICMP.

You need to think about VPN-filter rules bi-directionally. Example:

access-list cust_mgmt extended permit tcp object-group remoteMgmtHosts allsites-inside 255.255.0.0 eq ssh

This is saying:

The remoteMgmtHosts object group can originate traffic on ANY source port to allsites-inside subnet on TCP port 22

OR

The allsites-inside subnet can source traffic on TCP port 22 to the remoteMgmtHosts object group on any destination TCP port.

Lets say you wanted to filter return traffic to ONLY allow TCP port 80 requests from the client. You would apply the following rule on the client side:

access-list cust_mgmt extended permit tcp object-group remoteMgmtHosts eq 80 allsites-inside 255.255.0.0

This being said, you can understand why the ICMP traffic would be bi-directional.

The following line is also not necessary:

access-list cust_mgmt extended deny ip allsites-inside 255.255.0.0 object-group remoteMgmtHosts

All traffic that is not permitted in the vpn-filter access-lists is denied.

If configured correctly, the filter only needs to be applied to one side.

Hope this helped. Let me know if you have any questions.

View solution in original post

Patrick0711 · ‎10-09-2009

With your above VPN-filter applied to the client side, the client should only be able to communicate back to the remote side via ICMP.

You need to think about VPN-filter rules bi-directionally. Example:

access-list cust_mgmt extended permit tcp object-group remoteMgmtHosts allsites-inside 255.255.0.0 eq ssh

This is saying:

The remoteMgmtHosts object group can originate traffic on ANY source port to allsites-inside subnet on TCP port 22

OR

The allsites-inside subnet can source traffic on TCP port 22 to the remoteMgmtHosts object group on any destination TCP port.

Lets say you wanted to filter return traffic to ONLY allow TCP port 80 requests from the client. You would apply the following rule on the client side:

access-list cust_mgmt extended permit tcp object-group remoteMgmtHosts eq 80 allsites-inside 255.255.0.0

This being said, you can understand why the ICMP traffic would be bi-directional.

The following line is also not necessary:

access-list cust_mgmt extended deny ip allsites-inside 255.255.0.0 object-group remoteMgmtHosts

All traffic that is not permitted in the vpn-filter access-lists is denied.

If configured correctly, the filter only needs to be applied to one side.

Hope this helped. Let me know if you have any questions.

exonetinf1nity · ‎10-09-2009

Thank you for your time Patrick, that makes perfect sense indeed, im happy with ICMP traffic being allowed as the only hosts visible on our side are an NMS station and a dedicated support network.

My main concern was the customer being able to have visibility of our network and vice versa as well as mitigating any risk of virus outbreaks etc

Regards

Mark Rigby