The ASA appliance is a very popular choice for the branch office environment. It provides flexible security and is a good termination point for a VPN connection back to a headquarter location. One challenge that technicians often run into is the inability to manage the ASA across the VPN. While some may choose to connect to the outside interface, this creates some additional challenges. This article looks at a couple of commands that allows VPN based communications to and from the ASA’s inside interface.
In this article we will examine a VPN connection to an ASA Appliance. We will use the inside interface of the ASA as a termination point for management traffic that transits the VPN. Use cases for this is include ssh, snmp and radius for centralized authentication.
This article assumes an already configured VPN between the two locations. The starting configuration used is as follows.
hostname R1 ! crypto isakmp policy 10 authentication pre-share group 2 crypto isakmp key cisco address 126.96.36.199 ! crypto ipsec transform-set myset esp-des esp-sha-hmac mode tunnel ! crypto map mymap 10 ipsec-isakmp set peer 188.8.131.52 set transform-set myset match address vpn ! interface Loopback1 desc Emulate LAN ip address 192.168.1.1 255.255.255.0 interface GigabitEthernet0/1 ip address 184.108.40.206 255.255.255.0 crypto map mymap ip route 0.0.0.0 0.0.0.0 220.127.116.11 ! ip access-list extended vpn permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 !
hostname ASA1 interface Ethernet0/0 nameif outside security-level 0 ip address 18.104.22.168 255.255.255.0 ! interface Ethernet0/1 nameif inside security-level 100 ip address 192.168.2.1 255.255.255.0 object network obj_any subnet 0.0.0.0 0.0.0.0 object network obj-192.168.2.0 subnet 192.168.2.0 255.255.255.0 object network obj-192.168.1.0 subnet 192.168.1.0 255.255.255.0 nat (inside,any) source static obj-192.168.2.0 obj-192.168.2.0 destination static obj-192.168.1.0 obj-192.168.1.0 ! object network obj_any nat (inside,outside) dynamic interface route outside 0.0.0.0 0.0.0.0 22.214.171.124 access-list VPN extended permit ip 192.168.2.0 255.255.255.0 192.168.1.0 255.255.255.0 crypto ipsec ikev1 transform-set myset esp-des esp-sha-hmac crypto map mymap 10 match address VPN crypto map mymap 10 set peer 126.96.36.199 crypto map mymap 10 set ikev1 transform-set myset crypto map mymap 10 set reverse-route crypto map mymap interface outside crypto ikev1 enable outside crypto ikev1 policy 10 authentication pre-share encryption des hash sha group 2 lifetime 86400 tunnel-group 188.8.131.52 type ipsec-l2l tunnel-group 184.108.40.206 ipsec-attributes ikev1 pre-shared-key cisco
At this point the VPN is fully functional. However the internal address of the ASA cannot be reached through the tunnel. This can be verified by initiating traffic from the inside of the router. Here, the IP address of Loopback1 is used to simulate traffic that will be encrypted and tunnelled over the VPN.
R1#ping 192.168.2.1 source 192.168.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds: Packet sent with a source address of 192.168.1.1 ..... Success rate is 0 percent (0/5) R1#
To resolve this issue, it is necessary to issue two commands. These commands are the magic that enable management access and force a routing table lookup for the return traffic.
ASA1(config)#management-access inside ASA1(config)#nat (inside,any) source static obj-192.168.2.0 obj-192.168.2.0 destination static obj-192.168.1.0 obj-192.168.1.0 route-lookup
Notice that the second command is basically adding the “route-lookup” parameter to the previously configured nat statement.
Returning to R1, it is now possible to ping the inside interface of the ASA over the VPN.
R1#ping 192.168.2.1 source 192.168.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds: Packet sent with a source address of 192.168.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms R1#
It is also possible to test this from the ASA itself. To do so, the ping command must identify the interface as “inside” (the management interface).
ASA1(config)# ping inside 192.168.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds: !!!!
It is also possible to allow vty traffic across the VPN.
ASA1(config)# ssh 192.168.1.0 255.255.255.0 inside ASA1(config)# telnet 192.168.1.0 255.255.255.0 inside
R1 Testing Telnet
R1#telnet 192.168.2.1 /source-interface loopback 1 Trying 192.168.2.1 ... Open User Access Verification Password: Type help or '?' for a list of available commands. ASA1>
R1 Testing SSH
R1(config)#ip ssh source-interface loopback 1 R1(config)#do ssh -l asa 192.168.2.1 Password: Type help or '?' for a list of available commands. ASA1>
Other management protocols can be enabled by associating them with the inside interface.
ASA1(config)#snmp-server host inside ? configure mode commands/options: Hostname or A.B.C.D IP address of SNMP notification host ASA1(config)#aaa-server RAD protocol radius ASA1(config)#aaa-server RAD (inside) host 192.168.1.100
While it may not initially seem possible, this method of using a VPN for management traffic can simplify various operational functions. It is worth noting that this article was written around ASA 8.4(7). Some of the earlier versions of 8.4 didn’t have the “route-lookup” parameter and didn’t behave as expected. Versions 8.2 and prior functioned without the need to use the “route-lookup” option in the nat command.
Disclaimer: Configuration is meant as an example only. A proper configuration should be assessed to ensure that it meets the security policies and needs of the organization for which it is being deployed.