The traffic permitted by the VPN-filter is statefully inspected and return traffic is allowed back. But still the VPN-filter doesn't work as typically expected as the filter doesn't have a direction.
Example (192.168.1.1 is a remote IP, 10.10.10.10 is the local server):
access-list VPN-FILTER permit tcp host 192.168.1.1 host 10.10.10.10 eq 80
The remote host can reach the local server and return-packets are allowed through statefull inspection. As there is the implicit "deny any" at the end, no other traffic (regardless of direction) is allowed.
Now you want that the internal server is allowed to RDP to the remote server. Now it gets awkward and the ACL looks like the following:
access-list VPN-FILTER permit tcp host 192.168.1.1 host 10.10.10.10 eq 80
access-list VPN-FILTER permit tcp host 192.168.1.1 eq 3389 host 10.10.10.10
The ACL gets clearer when realizing that the syntax is not
access-list ACL-NAME permit/deny SOURCE DESTINATION
it is for the VPN-filter
access-list ACL-NAME permit/deny REMOTE LOCAL
And if the local server want's to RDP to the remote system, the port tcp/3389 is used on the remote system.
One implication of this is that you can't configure that you can ping the other side, but they can't ping you. As there is no source/destination-type, an ICMP-ACE is always applied in both directions.
How to get out of this situation?
- Wait until Cisco implements filter with direction. But I'm not sue when/if that will happen
- Use the old style "no sysopt connection permit-vpn" and control the access with interface ACLs.
- Use a router for site-to-site-VPNs where you can apply ACLs per direction to the VPN-tunnel.
