Possible NAT Issue?
First of all, I don't know if this is really a NAT issue but, I'm thinking that it might be. Lol.
I am using pfSense 2.2.6 in an enterprise environment. Filtering unnecessary websites that are accessible by the employees is one of the main concern by our management which at the same time has a pretty tight budget for our IT Infrastructure. We've implemented SquidGuard to filter downloads and websites, it gets the job done but only for non encrypted sites. I'm using OpenDNS for encrypted websites (HTTPS).
I have the following interface assignments with its IP Addresses; WAN (Public IP c/o ISP), INTERNAL (10.100.100.1/30), DMZ (10.100.100.5/30), PUBLICWIFI (172.18.100.1/24). We also have 30 Static Public IP addresses which we can use. Let's just assume that I am using the following Public IP Addresses; WAN (126.96.36.199, Outbound NAT for INTERNAL), Mail Server under DMZ (188.8.131.52, 1:1 NAT), Internal Servers Network under INTERNAL (184.108.40.206, Outbound NAT), PUBLICWIFI (220.127.116.11, Outbound NAT) .
What I need to do is to filter unnecessary websites for our INTERNAL Network and leave the PUBLICWIFI network untouched. I have no problem implementing this with SquidGuard, as I've selected the INTERNAL interface only under squid proxy. However, I am encountering an issue when it comes with my OpenDNS, we are under the free subscription of OpenDNS we can only input 1 public IP. We've set in the OpenDNS the IP configured in our WAN 18.104.22.168. Our PUBLICWIFI is configured to use 22.214.171.124 using Outbound NAT. OpenDNS is working and is filtering unnecessary websites in our INTERNAL network as it should be. However, OpenDNS is also filtering websites in our PUBLICWIFI network.
I have confirmed that my Outbound NAT configurations are working by going to ipchicken.com, devices from INTERNAL are displaying 126.96.36.199, and devices from PUBLICWIFI are displaying 188.8.131.52. I am only forcing the use of OpenDNS to INTERNAL Interface by using a port forward rule. So, filtering unnecessary websites in our PUBLICWIFI network by OpenDNS can be eliminated by using different DNS server. But, when I am using different DNS Servers configured via DHCP Server in the PUBLICWIFI interface, I am unable to access our own mail server situated under our DMZ, "DNS Rebind Attack" message is appearing.
I think I am wrong with this but, I am suspecting that the reason why the web filtering of OpenDNS is still working in our PUBLICWIFI interface is due to a NAT issue. My Outbound Rule is configured as follow, Interface is set to my WAN (184.108.40.206), Source is set to 172.18.100.0/24, NAT Address is set to 220.127.116.11. I am thinking that my PUBLICWIFI is still NATing to my WAN 18.104.22.168, and my WAN will NAT into 22.214.171.124, hence a possible Double NAT issue and OpenDNS is still detecting 126.96.36.199 that's why web filtering is still working on PUBLICWIFI. Attached is the Outbound NAT config for your reference.
I hope someone could enlighten me on this one. And, I also hope someone could provide a possible solution in using different DNS server for my PUBLICWIFI and yet still able to access our corporate mail server without generating a possible DNS Rebind Attack.
Thank You! ;D ;D
Thought you stated that when you go to ipchicket from your public wifi it shows the correct public IP.
My guess would be as it is suppose to do pfsense is caching the entries it gets from opendns on the filtered sites. opendns does not respond with nx on something that is filtered it responds with a different IP for that record pointing to their block page right.
So lets say your looking for blockeddomain.com that on the public resolves to 188.8.131.52, but this is filtered in opendns to resolve to 184.108.40.206. Now when someone from your public wifi asks pfsense for blockeddomain its say hey sure I have a cached entry for that 220.127.116.11
Are you using the forwarder or resolver? I assume the forwarder if your forwarding to opendns, you could maybe use the resolver for your public wifi users and have overrides in it for the local stuff you need them to resolve.