AnyConnect NAT and packet filtering

[janiax]

Dear Cisco Community,

I have several things that I would like to clarify with you regarding AnyConnect SSL VPNs.
First is packet filtering and the other is NAT.

The ASA we use is basically a pure VPN gateway. There is no other traffic than tunnels.
We use a public IP address on the Outside segment, to which SSL VPN users and IPsec tunnels connect to.

As I said, the users on the inside segment does not use the ASA for regular Internet access, it is used as a VPN gateway, therefore there is no need for NAT from Inside to Outside. However, there are several static twice NAT rules that apply to the SSL and to IPsec tunnels, and the rules are pretty wide like (Inside,Outside) 10.0.0.0 /8 to 10.16.26.0 /24.
Is there any need for that? Why would I want to configure NAT in this case? I believe do not need that, since the ASA is not used as an Internet gateway, so there is no need to translate Inside users in any way.

And now the filtering. I have only few ACL rules on the Outside interface. I also think there is no need for them to be there, it could be even deny any any, since sysopt permit-vpn is enabled. However, when I run packet tracer for an established TCP connection in the SSL tunnel, AnyConnect host (Outside) - 10.10.10.15, server (inside) 192.168.1.10, the packet tracer tells me that the flow is denied, even though the connection is established. Does the packet tracer reflect the fact, that the traffic flow is supposed to be in the SSL tunnel, or does it just look at the ACL, relizes that there is no allow rule and drops it?

I have inherited this configuration, tehrefore I have no idea why someone set this up this way.

Many thanks.

[Rahul Govindan · Accepted solution]

You do not need a NAT if you do not have any other conflicting NAT statements. Prior ASA versions had a feature called NAT-control that required some sort of NAT for all traffic flowing through the Firewall. This was removed in 8.4. So if this config was migrated from a prior release and had rules in place to satisfy NAT control feature, this might be why these rules exist on the ASA.

You do not need outside ACL's allowing traffic if you have the sysopt permit-vpn enabled (default). Packet tracer by default does not consider outside-->inside traffic as VPN. So the drop is expected. In ASA release 9.9, there is a new feature on the packet-tracer to "Treat a simulated packet as an IPsec/SSL decrypted packet". This should be able to show you the right results for VPN traffic traversing inbound. 

https://www.cisco.com/c/en/us/td/docs/security/asa/asa99/release/notes/asarn99.html

[janiax]

Many thanks, Rahul!