VLANs and Tomato Wifi
-
@parry Why does akismet flag 3 edits of my post as spam ?
-
There is nothing cached in pfSense. It's handing you a lease in the 192.168.3.X subnet correctly and will be passing the interface IP as DNS (192.168.3.1). That us the default setting. It is your client that is choosing to ignore that.
Did you try a different test client yet?Whilst it is technically possible to have Unbound handle requests from different clients in different ways that is not how it's intended to be used in pfSense. It will handle all requests in the same way unless you add a bunch of custom options there.
You can add a reject rule on the VLAN3 interface with source VLAN3net and destination 'This firewall'. Put it above the pass rule and it will prevent clients accessing the pfSense gui. BUT be sure to put a pass rule above that allowing VLAN3 clients to access Unbound at the VLAN3 address on port 53 if they are using that for DNS.
Steve
-
@stephenw10 I have not had a chance to try out a different client yet - but will do so with a Win 7 an OS X 10.11 and a ubuntu client. I had not seen the "This Firewall" idea which initially I thought was an alias. But I see that it is a macro supplied by pfsense. I found this thread explanatory and full of vituperation ;) https://forum.netgate.com/topic/117527/this-firewall-self-what-does-it-do
-
Yes, it's important to use that because it includes every IP on the firewall and the webgui listens on all of them. So otherwise clients in VLAN3 might be able to hit the public WAN IP and reach the gui for example.
Steve
-
@parry said in VLANs and Tomato Wifi:
How do I set different DNS options with the DNS resolver when it appears to not be associated with any DHCP range or VLAN ?
No, I defined the DNS servers in the dhcp options.
But I also created an ACL(?) in unbound to refuse non local in this example.
So external dns will be answered by google.
And because there is a rule to force all external traffic through a vpn, also the dns is done through that vpn. :)
-
@Bob-Dig I have to smile Bob-Dig because the plethora of options makes my brain hurt. You also provide valuable insight, so thanks for that too ! The screenshots above are particularly useful. Now if we could only resolve the politics in the US as easily as you guys help me, we would be on a winner ;)
-
@parry Ah, now I finally understand where the problem with the Wifi OS X client lies. If I manually enter a DNS server like 192.168.1.1 for the VLAN which is on subnet 192.168.3.x it remains, irrespective of the fact that I have set a DHCP address from the 192.168.3.1 DHCP server.
However..... if I remove that server it immediately populates with 192.168.3.1 for the DNS server. So the reason I was not accessing the DNS server but still able to ping any address is the fact that the DNS server was set to 192.168.1.1. I thought that it was a mistake that set the xxx.1.1 address for a 192.168.3.x subnet. BUT that is not so. The moment you enter a DNS address manually into the setting it remains.
So what happened is that I started with a LAN on 192.168.1.1 as the DNS and gateway IP and entered the 192.168.1.1 address into the Wifi OS X client. When I added the vlan on 192.168.3.x subnet, the client had the 192.168.1.1 DNS address and I simply did not look at it.
What really drove me bonkers was the fact that with ethernet VLANs I had no problem. The reason is that the DNS servers were added automatically to those vlans. I used a trunked ethernet cable from pfsense containing a number of vlans all of which I could connect to and get a DNS address on my mac client.
But when I tried to get a DNS resolution on the Wifi access point connected to the 192.168.3.x subnet I could never get that address. All because I had manually entered a DNS address into the wifi setting and then used the wifi client to connect to the vlan. This little thing has been causing pain for many weeks.
I promised I would provide information about other operating system. Using the Windows 7 client without a DNS server identified the client connects to both the 192.168.3.x subnet and the 192.168.1.x subnet. Adding the DNS server 192.168.1.1 to the LAN Wifi client and then using the client for the 192,168,3,x subnet removes the DNS server setting and provides a DNS address.
Nett - once you set a DNS server in the OS X Yosemite (10.10.5) client that remains. In Windows 7 it seems that the DNS server from the previous setting is removed. I will provide the same analysis for the Ubuntu and OS X 11 (El Capitan) clients. Nett: the fact that the DNS server on the OS X client remains a set irrespective of which WiFi network it connects to is the reason I could not get a DNS address, Such as small thing but such a problem, Thanks again !
-
@parry Windows 7 uses the DNS server that is entered, but changes it if I select a different subnet. Debian 8 (OK I know that is ancient) also looks for the DNS server irrespective of what is set. It seems that OS X will search for a DNS server if you dont enter one manually and in fact if you remove the one installed manually it will find the DNS server appropriate to your network. BUT if you enter a DNS server manually into the WiFi client it appears to hang around.
-
Yeah, that would explain what you're seeing.
That seems like unexpected behaviour unless perhaps you move the access point from the LAN to VLAN3? In that case the SSID and MAC of the access point would remain the same so it might see the connection as the same.
The MAC of the DHCP server would change though which would cause Windows to see it as a different network.Steve
-
@parry For the future - just leave the DNS in Tomato set to 0.0.0.0 which it uses as a default. The DHCP server in pfsense provides the access to DNS
