Security

Subject line is pretty clear, basically I'm able to hit our internal intranet homepage and sub-pages on the guest network I have configured. auth-guest role configured to block all private IP space. When the client does a DNS lookup on our internal home page (sharepoint), the query goes out to OpenDNS (208.67.220.220). the query response returned is 67.215.65.132. That IP I understand to be the standard response from OpenDNS when the host name cannot be resolved, so working as expected!

Packet capture shows the DNS query/response, however, it also shows all subsequent comm to our internal webpage as traffic to/from 67.215.65.132. To the controller, this looks like legitimate traffic to allow since I am not blocking that IP address, but I have no idea why traffic originating from my internal web page( on a 10.x.x.x network) would be returned to the client looking like it came from 67.215.x.x. So basically, on an Internet only wlan, I can browse our internal sharepoint farm over http all day.

Has anyone run into this issue when using a public DNS for their guest wireless networks?

Thanks in advance

Greg

What firewall policies do you have assigned to authenticated guests on that WLAN?  Is "auth-guest" the role that users get when they are fully authenticated, or when they just associate?  if it is for post authentication, what rules  (firewall policies) are applied in the "auth-guest" role?

Associated guests (pre-auth) receive guest-logon role. Nothing is returned except the captive portal. Firewall rules as follows:

clearpass-portal (http(s) src-nats to portal page)

captiveportal (default settings)

guest-logon-access (allow dhcp, allow DNS to OpenDNS)

deny-internal (deny all private IP space)

Once authenticated to clearpass, users receieve auth-guest role. firewall rules as follows

cplogout (dst-nat to 8081 for controller)

guest-logon-access

allow-websense (for http block page, guest users are filtered through content gateway)

deny-internal (deny all private IP space)

auth-guest-access (permit http(s) to any)

drop-and-log (default)

-GR

If you can get on the commandline, please type "show rights auth-guest" so it can show the firewall policies and the order.  Paste in the output if you can.  I am wondering what the guest-logon-access piece of the role does.

Sure no prob

(Aruba3200-US) #show rights jhhc-auth-guest Derived Role = 'jhhc-auth-guest' Up BW:No Limit Down BW:No Limit L2TP Pool = default-l2tp-pool PPTP Pool = default-pptp-pool Periodic reauthentication: Disabled ACL Number = 59/0 Max Sessions = 128 access-list List ---------------- Position Name Location -------- ---- -------- 1 cplogout 2 guest-logon-access 3 allow-websense 4 deny-internal 5 auth-guest-access 6 drop-and-log cplogout -------- Priority Source Destination Service Action TimeRange Log Expired Queue TOS 8021P Blacklist Mirror DisScan ClassifyMedia IPv4/6 -------- ------ ----------- ------- ------ --------- --- ------- ----- --- ----- --------- ------ ------- ------------- ------ 1 user controller svc-https dst-nat 8081 Low 4 guest-logon-access ------------------ Priority Source Destination Service Action TimeRange Log Expired Queue TOS 8021P Blacklist Mirror DisScan ClassifyMedia IPv4/6 -------- ------ ----------- ------- ------ --------- --- ------- ----- --- ----- --------- ------ ------- ------------- ------ 1 user any udp 68 deny Low 4 2 any any svc-dhcp permit Low 4 3 any OpenDNS svc-dns src-nat Low 4 allow-websense -------------- Priority Source Destination Service Action TimeRange Log Expired Qu eue TOS 8021P Blacklist Mirror DisScan ClassifyMedia IPv4/6 -------- ------ ----------- ------- ------ --------- --- ------- -- --- --- ----- --------- ------ ------- ------------- ------ 1 user websense-block tcp 15871 permit Lo w 4 deny-internal ------------- Priority Source Destination Service Action TimeRange Log Exp ired Queue TOS 8021P Blacklist Mirror DisScan ClassifyMedia IPv4/6 -------- ------ ----------- ------- ------ --------- --- --- ---- ----- --- ----- --------- ------ ------- ------------- ------ 1 any 10.0.0.0 255.0.0.0 any deny Yes Low 4 2 any 192.168.0.0 255.255.0.0 any deny Yes Low 4 3 any 172.16.0.0 255.255.240.0 any deny Yes Low 4 auth-guest-access ----------------- Priority Source Destination Service Action TimeRange Log Expired Qu eue TOS 8021P Blacklist Mirror DisScan ClassifyMedia IPv4/6 -------- ------ ----------- ------- ------ --------- --- ------- -- --- --- ----- --------- ------ ------- ------------- ------ 1 user any svc-http permit Guest Access Lo w 4 2 user any svc-https permit Guest Access Lo w 4 drop-and-log ------------ Priority Source Destination Service Action TimeRange Log Expired Queue TOS 8021P Blacklist Mirror DisScan ClassifyMedia IPv4/6 -------- ------ ----------- ------- ------ --------- --- ------- ----- --- ----- --------- ------ ------- ------------- ------ 1 user any any deny Yes Low 4 Expired Policies (due to time constraints) = 0

ugh that's ugly. I attached a txt file as well for easier reading. Thank you again.

-GR

Attachment(s)

output.txt   5 KB 1 version

Is there a reason why you are source-natting DNS traffic?

That might not be your issue, but that is the only thing that stands out.

What is the default gateway for this guest network?

The original idea was to src-nat all traffic coming out of the guest network to keep it isolated. We wound up defining the guest network on the core switch so permitting this traffic instead would work. I'll give it a shot.

The default gateway for the guest network is the core. We also were going back and forth on this, the advantages of using the controller as the gateway over the core. It was suggested we use the core for routing rather than the controller. All traffic I believe is tunneled back to the controller from the AP for inspetion before it is forwarded on to the gateway defined on the core is it not?

I will get back to you on the src-nat change to permit.

-GR

I take that back, I willnot be able to test the src-nat vs. the permit until another issue I am having is resolved. Every day, sometime in the afternoon, I wind up hitting some kind of configured session limit (on controller) from my laptop on the guest network only, where I can no longer browse to the captive portal while connected to the guest SSID. Working with TAC on that one, but I'll be able to test tomorrow morning, that tends to be the time everything wakes up and starts working again!

-GR

Tested permitting DNS traffic to OpenDNS rather than src-nat, no change in result. Still able to resolve our internal sharepoint intranet page.

I changed the OpenDNS alias to include the IP 67.215.65.132 and kept the change to permit the traffic instead of src-nat. Also logged all comm with that alias destination set. Here is what I saw.

A pcap again shows the dns query for my company's internal home page with 67.215.65.132 returned as the response. all port 80 traffic destined to that IP from then on logs as the following in the controller and returns the home page content.

What is interesting, since I am permitting all traffic to the OpenDNS alias which includes the 67.x.x.x address, I am logging permits to all ports destined for that address. So I tried connecting one of my network shares but since openDNS cannot resolve my internal file server host name, the same 67.x.x.x IP address is returned. It looks like this in the controller, notice port 445 for SMB over TCP.

The difference here is, I am not able to map the drive. A similar test using RDP to an internal server, port 3389 is permitted in the controller logs, but unable to resolve the host.

So in every case I am unable to resolve the private IP space, but it only seems to impact port 80 traffic. So, long story short, I tested blocking the 67.x.x.x IP address, which effectively blocked the guest network from our internal home page, however I think this is a band aid for something else at work here. Not to mention it creates an unnecessary amount of traffic generated from my client machine trying to figure out how to get to the 67.x.x.x address it's being told to resolve by OpenDNS.

Any other ideas?

-GR

How are you resolving intranet?  Are you just typing it into a browser or are you specifically using nslookup to the Open DNS server?  Using nslookup will rule out other, hidden resolution methods not related to DNS.  Is it possible that the device you are testing it with has a different way of resolving?

It's set as the home page in the browser. An nslookup using OpenDNS returns the IP 67.215.65.132.

Checked hosts file, don't have it hard coded anywhere. I don't have any indication from the controller traffic logs or a local pcap that I am communicating directly with our intranet. I would think if the source IP was anything in the private network space, the controller would see it and drop it based ont he policies I have created. I guess my concern is that there is definitely something else at play here and perhaps our intranet isn't the only thing slipping through the cracks.

I checked our web proxy server, and it is definitely logging traffic to the intranet server from the wireless client. All I can figure is somewhere in between the request for 67.215.65.132 and the web page displaying, something is resolving the destination for the content from the home page, but by the time it gets back to the controller, it translates it back to 67.215.65.132.

Need to do some digging on the web proxy but still not sure why (if that is the culprit) the 67.x.x.x address is still returned as the destination.

-GR

We have confirmed it was in fact the proxy that is delivering the internal content. Still need to work with TAC on why the proxy device would be set to do this and how we can prevent it.

Basically, our theory right now is, the web request is going out for an internal host with that bogus IP 67.215.65.132 which would return a destination unreacheable...if it ever got there. But, before it does, the proxy is intercepting the traffic, doing a dns lookup on behalf of the guest client on our internal DNS servers (which the wireless client does not have access to) and delivering all the content of the originally requested web page.....kiiiiind of a problem. The controller never saw the originating IP address, only looked like 67.215.65.132 traffic.

We confirmed this by browsing to multiple fully qualified web sites on our internal network from our "Internet Only" guest network only to find that yes we could in fact get to each and every one of them. Permitted on the controller as 67.215.65.132, when each and every web server actually lived in the 10.x network.

Moral of the story, CHECK YOUR PROXY!!! Thanks guys for taking a look and apologies if I wasted anyones time.

-GR