Firewall blocks DNS requests by LAN clients to unbound
-
Hi,
I'm new to pfSense and still figuring out the bits and pieces, especially the firewall part. Now I'm seeing some traffic being blocked and wondering why that is.
Here is an example from the log of the firewall blocking DNS traffic to the LAN interface:
Jan 20 23:02:39 LAN Default deny rule IPv6 (1000000105) [fe80::7af8:45ff:feb2:baa2]:2492 [2a02:8086:a3a8:46dc:d4:14ff:af30:bd00]:53 UDPThe source address is my mobile phone, the destination address is the IPv6 address of the LAN interface of the pfSense machine. Why would this kind of traffic be blocked? Why does the rule "Default allow LAN IPv6 to any" not match here?
Thanks!
P.S.: I should also mention that it's not like all DNS requests are blocked. I can query unbound from my desktop from example over the IPv6 address. It only seems to happen from time to time or with some clients only - hard to tell.
-
https://doc.pfsense.org/index.php/Why_do_my_logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection
-
Not the case here Grimson..
That is from a link local address fe80 to global address 2a02:8086, owned Virgin Media Ireland Limited.
Why would the client query like that? If going to talk to your global address, it should come from its global address not its link local address.
-
Please note that I changed a few bits of the IPv6 address before posting. So, my ISP is a different one. Nevertheless, the log still shows the Global Unicast Address of the LAN interface of the pfSense box where Unbound is running. It's also the same IPv6 address that the DHCPv6 server advertises to the clients to use for DNS6.
As for why does the client use it's Link-Local address as a source when sending a DNS query to a global address that is on the same local network: I don't really know. But it doesn't seem unusual to me. On other networks that have deployed IPv6 internally, I have seen traffic coming from any IPv6 address assigned to an interface as long as there is a route for the destination address on that interface (when source and destination are on the same network segment). So, from my experience, this can Link-Local to a GUA, ULA to GUA and GUA to ULA. I don't know whether this is buggy behavior by clients or conforming to the specs (I'm in no way a network expert), but it seems to happen in practice.
Now, back to the firewall rules. Would that mean that the rule "Default allow LAN IPv6 to any" doesn't include FE80::/1 addresses? Or just blocks Link-Local to GUA?
Thanks!
-
You can look at the actual rule with..
pfctl -vvsr
I did a grep for the actual LAN default any any rule - and it parses the lan net to the global address network on the lan - I am for sure not that well versed for specs of link local to global address rules in general. But I would think a client wanting to talk to a global should use its global address.. Not the link local.
I can tell you by grepping the actual rules for anything that has fe80 in it - I do not see any pass rules that would allow such traffic..
Do you have your dns listening on the linklocal that would create such rules?? So I do not have mine listing on local, let me change that and then check the rules… But currently mine show only these for fe80 allow rules
@23(1000000110) pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type echoreq keep state
@24(1000000110) pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routersol keep state
@25(1000000110) pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routeradv keep state
@26(1000000110) pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbrsol keep state
@27(1000000110) pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbradv keep state
@28(1000000111) pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type echoreq keep state
@29(1000000111) pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type routersol keep state
@30(1000000111) pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type routeradv keep state
@31(1000000111) pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type neighbrsol keep state
@32(1000000111) pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type neighbradv keep state
@33(1000000112) pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type echoreq keep state
@34(1000000112) pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routersol keep state
@35(1000000112) pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routeradv keep state
@36(1000000112) pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbrsol keep state
@37(1000000112) pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbradv keep stateSetting unbound to listen on link local - doesn't auto create any rules for that.. Maybe that is something that should be allowed in the rules when you allow any any ipv6 that the link local address space also needs to be allowed? Have to check in redmine if anyone else has brought that up.. Also have to look if such traffic is normal?
I found this - that seems to be related to the behavior of sending to global from link local..
https://redmine.pfsense.org/issues/6826
DNS forwarder is sending packets with link-local IPv6 source address to global unicast addressedit: OK I found this that states from cmb that link local is not included in the default lan rules..
https://forum.pfsense.org/index.php?topic=108804.0
"LAN net does not include link local by design"So if you want to allow such traffic, not sure if even clients do try and talk to global - per that freebsd redmine posting if its good practice. But if you want to allow such traffic for your local dns, then you should prob change your source from lan net to any, or include fe80 space a source to talk to your dns, etc.
-
Thanks.
I have not changed the listening address for unbound (yet), so it is set to the default "All" at the moment. In the DHCPv6 server configuration, I left the DNS fields blank, which then by default announces the interface's IPv6 address to the clients if the DNS service is enabled. On the client's I can see that the announced DNS6 server address is the GUA of the LAN interface of the pfSence machine. So, this all seems fine.
I looked at the output of pfctl -vvsr as suggested and it actually contains a line that looks like it should allow this traffic:
@76(1000002655) pass in quick on bridge0 inet6 proto udp from fe80::/10 to 2a02:8086:a3a8:46dc:d4:14ff:af30:bd00 port = dhcpv6-client keep state label "allow access to DHCPv6 server" [ Evaluations: 6005 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: pid 51700 State Creations: 0 ]I haven't set up this rule, so I assume it gets created automatically. But why doesn't it match here?
EDIT: Sorry, I misread the rule. It says DHCPv6 not DNS. So, it's not supposed to match here. But that leaves the question: Why would traffic to the DHCPv6 server from Link-Local to GUA be allowed by default but not to the DNS server?
Also note, I use a bridge interface (bridge0) as my LAN interface. As suggested elsewhere here on the forum, I set the tunables net.link.bridge.pfil_bridge=1 and net.link.bridge.pfil_member=0, so the firewall applies the LAN rules to the bridge interface.
Regarding whether such traffic conforms to standards: I briefly looked at RFC 6724 mentioned in the bug report you referenced. Basically, the client should select the source address for the traffic according to scope of the destination and a global address should be preferred when connecting to a global destination address. Nevertheless, prefixes can be assigned with different precedence levels, so it's possible that link-local is preferred over a gloabal address as the source.
-
"Why would traffic to the DHCPv6 server from Link-Local to GUA be allowed by default but not to the DNS server?"
Because that is how it gets its address ;)
" so it's possible that link-local is preferred over a gloabal address as the source."
But that is not normally going to work… the only time that would work is if the Global is actually on the local network... So wanting to talk to a global address it would be best to use a global address would it not..
Here is the thing if you want to allow it just adjust the rules as I stated. But it seems clear out of the box pfsense default rules do not account for link local address to be talking to the global address of dns server running on pfsense.
-
" so it's possible that link-local is preferred over a gloabal address as the source."
But that is not normally going to work… the only time that would work is if the Global is actually on the local network... So wanting to talk to a global address it would be best to use a global address would it not..
Sure. But if this behavior is not against standards and seen in practice, I'd assume it should be allowed by default. Because it will just cause unnecessary delays with clients waiting for a response.
And just to be clear, I didn't manually configure the routes or so (neither on the client nor on the server). Nor is it some kind of exotic device or OS (in the example above it's a Google smartphone running the latest Android release and I can see at least one different device in the logs with the same behavior).
Here is the thing if you want to allow it just adjust the rules as I stated. But it seems clear out of the box pfsense default rules do not account for link local address to be talking to the global address of dns server running on pfsense.
Yep, thanks. I added a rule now that allows and logs this kind of access to the DNS server (logging, because I'd like to see how often that actually happens and if it's specific to certain clients/operating systems). I'm just surprised at this point that I seem to be the first one to stumble over this.
-
I would be curious how often this does cause delays… I would look to the vast ipv6 deployment in the corp world where firewalls are common ;) Oh wait - we are still years and years and years away from that since in the corp world there is like zero reason to deploy ipv6 in a manner where users devices like desktops, laptops, tablets or phones would even get IPv6 on the corp network to try this out ;)
Corp deployment of ipv6 is really a nonstarter because there is zero advantages to using it, and only downsides..
So where you mostly see ipv6 deployment is on isp home user connections, and what do the vast majority of them use - some soho off the shelf router that does really zero firewall rules outbound, etc. Or filtering of any sort of traffic from talking to anything listening on the routers local interfaces.
I just not see how link-local talking to global would ever be something that should be deployed... Like saying hey I want my ipv4 link local 168.254 address to talk to my rfc1918 address.. Guess what that doesn't work either in pfsense.. Since lan network is the networks that are actually configured on the interface..
I would be curious to what devices are doing this... Seems borked to me..
-
So, I've monitored this for some time now and it seems only certain Android clients behave this way (i.e. using their link-local address to send queries to the global address of the DNS server). But it doesn't happen too often (only a handful requests per device and day). So, it's probably safe to stay with the defaults and block this traffic unless one prefers cleaner log messages.
-
I would be curious to reach out to the android community on why… Since it seems borked to attempt such communications..
