ASA Guest Network With Limited Inside Access

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.

ASA Guest DMZ Active Sync

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.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in CCIE Security, CCNA Security, Certification, Security, Technology and tagged , , . Bookmark the permalink.

7 Responses to ASA Guest Network With Limited Inside Access

  1. TonyM says:

    This is exactly what I am trying to accomplish for a small client of mine. One question though, what is the need for the deny statement?
    Thank you.

    • Paul Stewart says:

      The reason for the deny statement is to restrict inbound connectivity from the DMZ. In my example, I used a 192.168.1.10 address for the inside server. The acl for inbound on DMZ was called “DMZ_access_in”. Without an ACL, no traffic can flow from the DMZ to inside. If I created an ACL that permitted the traffic to the required host, that would be permitted. However, all else is denied. If I omitted the deny entry and followed it with a “permit ip any any”, all traffic would be permitted. This would include traffic to the internet (which I wanted), and traffic to the rest of the inside of my network (which I didn’t want). Therefore, I inserted the deny between the two permit rules that denied traffic to any of my internal networks. HTH.

  2. Zarr says:

    What about when you wish to use VPN client? DNS name vpn.corporate.net points to the outside interface on the ASA. Does same NAT trick work – destination is simply translated to the guest interface’s address?

    • Paul Stewart says:

      I don’t think that will work. The NAT won’t work properly for traffic destined to the interface of the ASA. Therefore, you need to think through the options. You could have a different DNS server or something that services that area of the network. The ASA also has this alias command that could manipulate the DNS reply. Unfortunately, this command has been removed from later versions. The third option would be to build a guest and non-guest wireless network. The non-guest could have the more appropriate controls and offer the more sophisticated services natively. I wish I had a better answer for you.

  3. quan2mst8 says:

    I did this five years ago and it is still our preferred method for building Guest networks (wired), for wireless we use GRE and VRFs to deliver the VLAN to WLCs for authentication and then push them through the ASA for internet access.

    The primary problem that I have seen with this in a production network is browser versions and PKI for https. It seems that some browsers take an inordinate amount of time to render the full authentication prompt.

    Have you noticed this? Did you resolve it? (I think it may have to do with PKI verification attempts but it hasn’t been that much of a show stopper.)

  4. Patrick says:

    Thank you for this Example. Is there a way to use a different IP for the Consumer Wireless/DMZ (that we have from our ISP IP Block) ?
    Or is it easier to just do a static route form the second WAN IP to VLAN3 ?
    How can we do this ?
    Thanks for any help.

    • Paul Stewart, CCIE 26009 (Security) says:

      You could modify the existing NAT rules to only include inside sources. Then create a NAT rule that only matches the Guest IPs. On the NAT rules that match the Guest IPs, use the alternate address or addresses.

Leave a Reply