A lot of Cisco ASA administrators run into issues when trying to access the ASA itself over a Remote-Access VPN or Site-to-Site VPN tunnel due to the odd traffic path and in this article, we take a look at some of the fixes you might need to apply to make this all work.
Introduction
Accessing an ASA via a Remote-Access VPN (using AnyConnect, now renamed to Cisco Secure Client) or through a Site-to-site VPN tunnel usually causes a head-ache because it goes against the basic traffic rules set up for regular data traffic, and you might need to apply some extra configuration to get it all working.
The premise is that the ASA administrator wants to connect to the ASA’s inside IP address using SSH or ASDM.
Below, I have compiled the most common settings that are needed for this traffic flow to be established. While the topology below is based on the use-case of a Network Administrator needing management access to the ASA firewall using Cisco Secure Client/AnyConnect), a lot of the tips in this article will work for the Site-to-site VPN tunnel scenario as well.
Designate “management” Interface
Designate a “management” interface. While the ASA can still be accessed via IP addresses belonging to interfaces other than the one specified, this command specifies which interface can be accessed through other interfaces and via VPN (Remote-Access and Site-to-site VPN tunnels), which would be considered traffic coming in from the “outside” interface and hitting the “inside” interface.
management-access inside
The command above also affects some traffic that is originated from the firewall itself and needs to enter VPN tunnels to get where it needs to go (for instance, an ASA at a branch office sending Syslog messages via a Site-to-site tunnel to headquarters where the Syslog server/collector is hosted).
Permit VPN IP Pool network(s) to access ASA management
Access to the ASA’s various management protocols requires you to specify which protocols should be allowed from which IP network (or a single host).
You will need to add the IP network(s) of your VPN IP address pool(s) to this configuration and since we have designated the “inside” interface for management-access, this is the interface we need to refer to in this configuration, even though the management traffic technically is coming in from the “outside” interface facing the Internet.
ssh 192.168.99.0 255.255.255.0 inside
http 192.168.99.0 255.255.255.0 inside
Configure NAT for VPN to ASA traffic with “route lookup”
Depending on how your routing table is set up, you might need to add the “route-lookup” keyword to your NAT statement that prevents your Remote Access VPN traffic from being translated when communicating with the Inside networks, including the ASA’s inside IP address. This type of NAT is called Twice-NAT or Identity-NAT (self-to-self NAT, essentially telling the ASA to not translate this traffic).
The “route-lookup” parameter is added because it forces the ASA to look in the routing table for the egress interface, instead of just basing it off which interfaces are mentioned in the NAT rule itself. When a user is connected to the ASA via Remote Access VPN, a /32 static route for that user’s particular IP address in the VPN IP Pool is added automatically to the routing table, with a next-hop interface of “outside”.
Management traffic like SSH/ASDM coming in from a Remote Access VPN session or a Site-2-Site VPN tunnel destined for another interface (the “inside” interface”) of the ASA and then having the return traffic go back in the tunnel again can be confusing for the ASA’s routing logic. This is where the “route-lookup” parameter can come in handy.
An example of this configuration can be seen below.
object network VPN-IP-POOL
subnet 192.168.99.0 255.255.255.0
object network INSIDE
subnet 10.0.0.0 255.0.0.0
nat (inside,outside) source static INSIDE-NETS INSIDE-NETS destination static VPN-POOL VPN-POOL route-lookup
Enable traffic to enter and exit the same interface
Somewhat connected to the routing logic above, you may need to enable the feature that allows for traffic to come in on one interface and exit out the same interface. By default, this type of traffic flow is denied.
same-security-traffic permit intra-interface
VPN Split-Tunnel Networks ACL must include ASA
If you are using the Split-Tunnel feature to only tunnel in certain IP networks/hosts for Remote-Access VPN users, make sure that the ASA’s inside IP address is included in this Access List so that ASA management traffic is sent inside the VPN tunnel, and not outside it.
VPN Access Control List must include ASA
In addition to having to include the ASA’s inside IP address in the potential Split-Tunnel ACL, make sure that SSH/HTTPS (for ASDM) is permitted towards the ASA’s inside IP address in the VPN ACL that is controlling which traffic is allowed to pass through. Just because you have the route from the Split-Tunnel ACL doesn’t mean the management traffic itself towards those IP networks/hosts is allowed.