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.
Jul 10 07:42:42 | authmgr[1528]: <124006> <WARN> |authmgr| {171} TCP srcip=10.83.0.254 srcport=49523 dstip=67.215.65.132 dstport=80, action=permit, role=jhhc-auth-guest, policy=guest-logon-access |
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.
Jul 10 07:46:23 | authmgr[1528]: <124006> <WARN> |authmgr| {397} TCP srcip=10.83.0.254 srcport=49548 dstip=67.215.65.132 dstport=445, action=permit, role=jhhc-auth-guest, policy=guest-logon-access |
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.
Jul 10 07:57:11 | authmgr[1528]: <124006> <WARN> |authmgr| {846} TCP srcip=10.83.0.254 srcport=49563 dstip=67.215.65.132 dstport=3389, action=permit, role=jhhc-auth-guest, policy=guest-logon-access |
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