Restrict inbound traffic on site-to-site VPN using VPN filter while allowing all outbound traffic

[mitchen]

I want to set up a site-to-site IPSEC VPN between 2 locations, where I am the administrator for Site A's Cisco ASA firewalls and Site B is a 3rd party company:

Site A: 10.10.10.0/24

Site B: 192.168.20.0/24

From Site A's Cisco ASA firewall, I want to be able to block anything inbound from Site B (that hasn't been initiated from Site A) and I want to allow ALL outbound traffic from Site A to Site B (and leave it to Site B to decide if there is any specific traffic they want to block)

How can I achieve this with a VPN filter at Site A?

(Note: using "no sysopt connection permit-vpn" and interface ACLs isn't an option due to the large number of VPNs already in use so I'd like to be able to do this using VPN filters)

Thanks.

[Rahul Govindan]

VPN Filters are usually bidirectional, so I don't believe you can achieve unidirectional blocking using that. There is an open enhancement bug to fix this:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCsf99428

I would suggest trying to translate your 10.10.10.0/24 network to a single ip address (PAT) when going outbound to 192.168.20.0/24. You would also have to change your source proxy network to that ip address (crypto ACL) on both ends of the tunnel. This way, they cannot initiate traffic towards you unless their is a connection and xlate built when you initiate outbound connection.

[mitchen]

Hi Rahul,

thanks - that's what i thought.  Will have to have a re-think about how we achieve this then!

[mitchen]

@Rahul Govindan

If possible, could you be able to elaborate on your suggested workaround a little more? I'm struggling to work out exactly how to do it? Thanks.

[Rahul Govindan]

Sorry for the late reply. There are 2 parts to the solution I mentioned:

1) NAT all traffic from your local vpn network to the remote vpn network to a single ip address. The rule would look like:
nat (inside, outside) source dynamic <local-subnet-object> <nat-ip> destination <remote-subnet-object> <remote-subnet-object> no-proxyarp route-lookup.

This basically translates local subnet to nat-ip when going to remote-subnet.

2) Since NAT takes place before VPN, the VPN crypto ACL match now has to match between the nat-ip and remote subnet, instead of the local-subnet and remote subnet. You have to change this on both ends.

Since the NAT above is dynamic, the remote site cannot initiate traffic to the nat-ip and get into your network. Only traffic initiated from you will be able to get to the other side successfully.

Hope this is more clearer.

[mitchen]

@Rahul Govindan Thanks very much - makes sense.