Several months ago, I published an article called Using an ASA to Establish a Guest Network. While this article covered the simple concept of using a DMZ interface to create a simple Guest Network, it did not address one issue that often arises. This is the need to access public facing servers that are located on the “inside” interface. This article addresses the issue for ASA’s running 8.2, as well as the newer syntax found in 8.3 and 8.4.
I know, the first question is (and should be), “Why would anyone have public facing servers on the “inside” interface?” Let’s ignore the philosophical and security discussion for the moment and just address the function. The solution demonstrated in this article will function with other DMZ interfaces exactly the same as it does with the internal interface. Therefore, these concepts are relevant for accessing a public facing server on another DMZ interface as well.
One of the cases that this may be more relevant is in an organization that decides to establish a guest network, then finds that mobile devices on the guest network cannot access their Exchange Active Sync environment. Again, this diagram shows a very small organization that is using a single Exchange server on the inside network. From the outside, it appears as 192.0.2.10. The clients connect to mail.foo.com.
Challenge–Establish a Guest Network Using an ASA. The guests should have full Internet access AND be able to use their active sync clients to access the Exchange server. Exchange Active-Sync utilizes an SSL connection over port 443.
Note: In the lab it is easier to test with telnet. Therefore, all configuration examples for this article will use port 23 (telnet). However, if you are trying to achieve the above challenge in your network, port 443 can be substituted as applicable to meet the requirement.
For demonstration purposes, a base configuration will be used. The base configuration will be very similar to completed configuration from the article I wrote a few months ago that only addressed outbound access for the Guest users. The ASA model used is an ASA5505, so the L3 interfaces are actually represented as VLANs. This base configuration will also be a good starting point to more clearly define the problem. The first base configuration addresses the ASA configuration in 8.2 and earlier releases. The later version is below. Feel free to skip over the examples that are not relevant to ASA versions that you support.
ASA 8.2 and Earlier Base Configuration
//Inside Interface interface Vlan1 nameif inside security-level 100 ip address 192.168.1.1 255.255.255.0 ! //Outside Interface interface Vlan2 no forward interface Vlan3 nameif outside security-level 0 ip address 192.0.2.10 255.255.255.0 ! //Guest Network Interface interface Vlan3 nameif DMZ security-level 50 ip address 192.168.2.1 255.255.255.0 //Attaching L3 Interfaces to Physical Interfaces interface Ethernet0/0 switchport access vlan 2 ! interface Ethernet0/1 switchport access vlan 3 ! //Ethernet 0/2 is attached to vlan 1 (not shown because it is the default) interface Ethernet0/2 ! //Dynamic PAT Configuration global (outside) 1 interface nat (inside) 1 0.0.0.0 0.0.0.0 nat (DMZ) 1 0.0.0.0 0.0.0.0 //Static PAT configuration for Active Sync (represented by telnet) static (inside,outside) tcp interface telnet 192.168.1.10 telnet netmask 255.255.255.255 //Required access-list/access-group access-list outside_access_in extended permit tcp any host 192.0.2.10 eq telnet access-group outside_access_in in interface outside //default route route outside 0.0.0.0 0.0.0.0 192.0.2.1 1
ASA 8.3 and Later Base Configuration
//Layer 3 Interface Configuration interface Vlan1 nameif inside security-level 100 ip address 192.168.1.1 255.255.255.0 ! interface Vlan2 no forward interface Vlan3 nameif outside security-level 0 ip address 192.0.2.10 255.255.255.0 ! interface Vlan3 nameif DMZ security-level 50 ip address 192.168.2.1 255.255.255.0 //Physical Port VLAN Memberships interface Ethernet0/0 switchport access vlan 2 ! interface Ethernet0/1 switchport access vlan 3 ! //Ethernet 0/2 is attached to vlan 1 (not shown because it is the default) interface Ethernet0/2 ! //NAT Configuration Items // Object Groups object network inside subnet 0.0.0.0 0.0.0.0 object network DMZ subnet 0.0.0.0 0.0.0.0 object network ExchangeSvr host 192.168.1.10 // Dynamic PAT for inside and DMZ (Guest Network) object network inside nat (inside,outside) dynamic interface object network DMZ nat (DMZ,outside) dynamic interface // Static PAT for Exchange server (from outside) object network ExchangeSvr nat (inside,outside) static interface service tcp telnet telnet //Access-list (notice the REAL IP address) access-list outside_access_in extended permit tcp any host 192.168.1.10 eq telnet //Access-list attached to outside access-group outside_access_in in interface outside route outside 0.0.0.0 0.0.0.0 192.0.2.1 1
At this point, the Guest Network hosts and inside hosts have access to the Internet. The Internet should be able to telnet to 192.0.2.10 (mail.foo.com). Our testing will utilize the hostname and depend on an Internet based DNS server. This is similar to how I’d expect a typical “active sync” client to be configured.
Testing Base Configuration
Inside Server to Internet
ExchangeSrv#ping 192.0.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.0.2.1, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 1/3/4 ms ExchangeSrv#
Guest Network to Internet
GuestHost#ping 192.0.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.0.2.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Internet to Telnet (would be https for Active Sync)
Internet#telnet mail.foo.com 23 Trying mail.foo.com (192.0.2.10)... Open User Access Verification Password: ExchangeSrv>exit [Connection to mail.foo.com closed by foreign host]
So what’s the problem? The problem, as demonstrated below, is that users in the Guest Network can’t telnet to mail.foo.com. Again we are simply using telnet to demonstrate the more common need of allowing mobile devices to access https for Exchange Active Sync.
The Problem
GuestHost#telnet mail.foo.com 23 //using dns server at 192.0.2.1 to obtain IP of mail.foo.com Translating "mail.foo.com"...domain server (192.0.2.1) [OK] Trying (192.0.2.10)... % Connection timed out; remote host not responding GuestHost#
If this were an iPhone or an iPad using Active Sync, the user would not be able to access his or her corporate email. There are two basic ways to solve this. The first is to manipulate the DNS replies. The second is to make the public IP address usable in the same manner out in the DMZ area.
To implement the latter solution only requires us to go back and think about how the ASA works. How do we go from a less secure to a more secure interface? The answer to this question is implementing the appropriate “static” NAT configuration and an ACL. Guest Network users are trying to reach the public IP address (192.0.2.10) and we know there is a private address of 192.168.1.10. Therefore, this is the information required to configure the ASA to allow the traffic.
Resolving the Issue for ASA 8.2 and prior
//create the static to NAT 192.168.1.10 -> 192.0.2.10 ciscoasa(config)# static (inside,DMZ) tcp 192.0.2.10 23 192.168.1.10 23 //create an acl that meets the following requirments //allows only the desired traffic to the inside //denies all other inbound traffic //allows internet destined traffic ciscoasa(config)# access-list DMZ_access_in extended permit tcp any host 192.0.2.10 eq 23 ciscoasa(config)# access-list DMZ_access_in extended deny ip any 192.168.1.0 255.255.255.0 ciscoasa(config)# access-list DMZ_access_in extended permit ip any any //apply the acl to the DMZ interface ciscoasa(config)# access-group DMZ_access_in in interface DMZ ciscoasa(config)#
Resolving the Issue for ASA 8.3 and Later
//create the static to NAT 192.168.1.10 -> 192.0.2.10 //the new syntax requires multiple steps (below) //define another host object we could share the original one //by using "ANY" for the interface specification, but we are using //the interface IP which forces us create a second NAT construct object network ExchangeSvr2 host 192.168.1.10 //create a NAT construct for the DMZ object network ExchangeSvr2 nat (inside,DMZ) static 192.0.2.10 service tcp telnet telnet //create the ACL to be applied to the DMZ //should permit only the required traffic //Note the REAL ip address access-list DMZ_access_in extended permit tcp any host 192.168.1.10 eq telnet access-list DMZ_access_in extended deny ip any 192.168.1.0 255.255.255.0 access-list DMZ_access_in extended permit ip any any //attach the ACL to the DMZ interface access-group DMZ_access_in in interface DMZ
Final Testing
At this point, it should succeed. To test, the telnet will be attempted again from the Guest Host.
GuestHost#telnet mail.foo.com 23 Translating "mail.foo.com"...domain server (192.0.2.1) [OK] Trying (192.0.2.10)... Open User Access Verification Password: ExchangeSrv>exit [Connection to mail.foo.com closed by foreign host]
This now seems to work. While demonstrating this with Telnet and discussing the use case for Exchange Active Sync, these same concepts can be used with any other protocol. Additionally, an internal server exposed to the world is not generally a recommended practice, it works well for demonstration. The concepts remain the same for hosts on other interfaces as well.
