VLANs and Tomato Wifi
-
Thanks Steve.
I have attached the rules and the Tomato VLAN settings.
The mystery is why the Ethernet VLANs work but the Wifi bridge connected to the VLAN does notOne thing that has bothered me for a long time is that in Tomato the default gateway is set to the LAN IP address on the pfsense box. What do the bridges connected to the Wifi VLAN use as a gateway ? [0_1604367664063_CurrentLAN rules.pdf](Uploading 100%) CurrentLAN rules.pdf.zip
-
@stephenw10 I also added the DNS resolver settings to the attached pdf which has to be zipped to upload it. As I understand it, I am not providing the resolver with any DNS address- it is supposed to connect to root DNS servers. https://docs.netgate.com/pfsense/en/latest/services/dns/resolver.html
If I issue a dig server_address from an ssh session on the pfsense firewall I get this
dig yahoo.com
; <<>> DiG 9.14.12 <<>> yahoo.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5151
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;yahoo.com. IN A;; ANSWER SECTION:
yahoo.com. 1800 IN A 74.6.143.25
yahoo.com. 1800 IN A 74.6.231.20
yahoo.com. 1800 IN A 98.137.11.163
yahoo.com. 1800 IN A 74.6.143.26
yahoo.com. 1800 IN A 74.6.231.21
yahoo.com. 1800 IN A 98.137.11.164;; Query time: 215 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Nov 02 20:52:44 EST 2020
;; MSG SIZE rcvd: 134 -
Since moving the firewall rule that blocks access to the LAN subnet allow clients to resolve it seems almost certain they are trying to use the LAN IP for DNS.
Since you have the dhcp server on VLAN3 in pfSense set to hand out it's own interface IP it seem likely the Tomato router is handing out the LAN IP to clients.
When you connect a client on VLAN3 via wifi do you actually see it in the dhcp status in pfSense?
Does that client get an IP in the correct subnet? What DNS server is it passed by the dhcp server?
Steve
-
@stephenw10
Thank you again Stephen. The ip address I received on this client when I attached to the VLAN3 based Wifi access point was 192.168.3.11 which in the subnet that the dhcp server provides for this VLAN in pfsense. In addition, I could see the device in the DHCP lease list with the name of this laptop.
I notice that the time of this lease is 14:49 whereas my time zone is set to EST. I presume that if I reboot this will resolve itself and is not a cause for these issues.
As for your last question regarding the DNS server, I am frankly not sure. The Tomato router DNS only provides for one DNS ip address setting which I set to the LAN gateway. The DNS resolver does not mention an IP address so if you could dumb down your question for me that would help me answer it ;) Thanks again,
-
The lease it shows there in your screenshot is in the LAN subnet right?
When it's connected to wifi via the VLAN it get's a lease in the 192.168.3.X subnet? From pfSense?
Check the client network settings when it's connected via the VLAN, what DNS server(s) is it showing?
Steve
-
Sorry Steve, I copied and pasted without seeing the pasted image. When one finished posting there is only a link visible. So here again is the lease for the VLAN
dig yahoo.com does not resolve because the client does not see a dns server. But when I ping 1.1.1.1 with this VLAN Wifi connection I get a response
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1:
icmp_seq=0 ttl=59 time=12.594 ms.
Clearly the VLAN does not see the DNS server but it can reach outside the VLAN. The client shows the LAN gateway as a the DNS server.
The client's DNS IP address can be changed, but the default is the LAN gateway. How does the DNS resolver connect to requests for name resolution from the LAN and VLAN ?By the way is there some method of editing posts once they are posted so even if I screw up I can correct the error ? Thank you for bothering to spend the time on this.
-
Yes you can edit you post from three dots menu.
Ok, it looks like either your client is set to not pull a DNS server via dhcp or something else is handing that to it.
Previously you showed the DHCP server config for the vlan3 interface and it did not have any dns servers specified. If you don't set any pfSense will use the interface address there so it will be handing out 192.168.3.1 there which clients should be able to access.
Steve
-
@stephenw10 Much obliged to you for your response Steve. Here's what I don't understand. The DNS resolver is supposed to access root DNS servers whose IP is not revealed (but see https://securitytrails.com/blog/dns-root-servers) but it is the OS X mac client that determines which DNS server to use. It appears that the DNS server chosen comes from the DHCP address, It seems that then my case all the local and VLAN interfaces are selected for the DNS resolver viz
. I have blocked VLAN 3 access to the LAN and that was blocking DNS access. When I used the original WiFi client to connect via dhcp to vlan3, the DNS server registered with the client (OS x --> Preferences --Network --> Wifi --> advanced--> DNS was from the LAN - namely 192.168.1.1
Looking at the Wifi client on my OS X device, once it has acquired a DNS address it wont change even though it is supposed to capture it from the DHCP server. For example I saw that after the WiFi client connected to the LAN network and used 192.168.1.1 as the DNS address. Even though it had no difficulty acquiring a 192.168.3.x address from the Wifi access point attached to vlan3 in my tomato router, it set192.168.1.1 as the DNS server. I could not get a name resolved with this setting. However it is possible to manually change the DNS setting to 192.168.3.1 which was able to resolve a name. But I dont want to ask users on my guest network to start setting DNS addresses. In addition it is not possible to assign a VLAN tag to a Wifi client through the GUI. But what is the IP address of the DNS resolver ? None is given, rather than provide an ip address tp connect to, the resolver shows the various network and outgoing network interfaces
I guessed that I should use 192.168.3.1 for vlan3 and 192.168.1.1 for the LAN
So far (a) The OS X wifi client can access any dhcp address but once it has registered itself with a specific DNS ip address only manual changes allow it to be changed
(b) If an additional Wifi client is added and connected to the vlan3 wifi access point it will find the correct DNS ip address
(c) This means that if a user comes from their own home to mine and tries to access the WiFi network, the DNS server setting in their client may likely not be updated.
(d) To access different wifi networks will require the setup of separate wificlients none of which can have a vlan ID assigned.That means it is possible to separate Wifi users only by IP address not by vlan tag (I think). I am not sure of the consequences of this of whether one can separate a vlan tag from a subnet. One important goal is to restrict access to the pfsense firewall to all except to a management vlan (currently it is on the LAN) and to isolate the vlans from each other (which I assume can be accomplished with firewall rules). I would appreciate any insights you may be able to provide about (a) The effective difference of using subnets vs lan tags [can one run a vlan between different subnets ?] (b) Clarifying what IP address I need to tell each vlan to address for a DNS service using DNS Resolver. Is it the one that comes mysteriously with the DHCP address (c) Most importantly reviewing the conclusion derived above.
Thanks again
-
I don't get any of your problems. Make a vlan, configure dhcp for it and define the dns server in there, if you don't want pfSense doing the dns.
If you just have dns questions, than this has probably nothing to do with vlans.In the above example, I had defined 8.8.8.8 as the DNS Server for the dhcp-clients, so they don't have to touch pfSense at all.
On an other interface, I had configured the dns Resolver to refuse nonlocal. On that interface I defined pfSense and google dns to be the dns servers in dhcp. All done in the gui.
-
Try testing with a different client. the behaviour you're seeing with that OSX device just looks broken. pfSense will be handing 192.168.3.1 (the interface IP) to clients to use for DNS via DHCP and your client looks to be ignoring it.
Unbound, the DNS resolver listens on all interfaces by default, that means all IP addresses on the firewall.
If you don't specify a DNS server IP the DHCP server on each interface will pass the interface IP for DNS. That will work fine with any standard dhcp client.Steve
-
@Bob-Dig Thakns Bob-Dig. I did not know that you could assign different DNS servers on different VLANS. If I look at the DNS resolver it looks like once it is assigned to the appropriate internal and outgoing vlans thats it.
How do I set different DNS options with the DNS resolver when it appears to not be associated with any DHCP range or VLAN ?
Could you please help me understand where on this page do I tell DNS resolver to forward the DNS requests to 1.1.1.1 for VLAN A and to use the DNS Resolver root DNS servers for the LAN ?
It appears to be monolithic. That is, once you set the option and use DNS resolver that is the DNS server for all interfaces.
Or does the DNS resolver know which VLAN I am working with and so its settings change with the VLAN ? I also get that you can set a DNS server address in the DHCP settings, but that's not what I was trying to do I am trying to use the root DNS servers directly.
My problem stems from the fact that OS X seems to cache the DNS server for the WiFi settings and it is not clear, without flushing dns how long it is cached.
So when I connected to the 192.168.3.x vlan with the pfsense dhcp servers, the DNS server was associated with 192.168.1.1.
That explains (as @stephenw10 pointed out) that this was a problem with my Wifi client. After running dscacheutil -flushcache the nameserver associated with the LAN and VLAN3 that appears in the OS X client is the correct one.
In the past connecting to VLAN3 over wifi gave me an IP address but what I did not look at was the DNS server it was using. Well it was using 192.168.1.1 for a vlan running the 192.168.3.0 subnet.
I had blocked vlan3 from accessing the LAN network so when my local device was calling for a name resolution from vlan3 it was being forwarded to the LAN address. So I could ping any IP address outside the firewall, but could not resolve it. I also think that there is some kind of caching of addresses and settings in pfsense, my wifi router and my client that complicates the issue further. But I am not about to try to figure out this combinatorial problem. For others going down this path I would say they should follow your approach if they want to use specific ip addresses. If they want to use the DNS resolver then they should use the ip address for their VLAN to access the resolver (that may need to be made clear in the documentation) as the DNS server. Finally how do I prevent users from accesing the firewall from a vlan ? For example I can get to the firewall from 192.168.3.1 when my intent was to only have the LAN access the firewall ?
Thanks again to @stephenw10 and yourself for your thoughts.
-
@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