DMZ interface DNS rule seems to be failing at random??
I have 3 interfaces.. LAN/WAN/DMZ (actually, I have a 4th management interface as well).
I have created rules to allow DNS to/from the LAN and the DMZ. For some reason, The DMZ system occasionally stops being able to access the internet (can't browse to www.google.com for example). When I check the log files, it shows traffic to PORT 53 being blocked… I verify the rule still exists to permit port 53 traffic and it does.
What is really weird is that if I use "quick rule" to create another rule allowing the system to access DNS, the system is then able to connect for a while, but eventually starts dropping again. Any ideas what may be causing this? The LAN rule works perfect. The interface for the DMZ is a separate nic from the onboard one used for the LAN. I don't think the problem is with the nic.
Any assistance is appreciated!
biggsy last edited by
You shouldn't need a rule to allow DNS from your LAN.
Did you allow both TCP and UDP 53 through the DMZ interface?
Not TCP and UDP, just UDP… is that the problem?
biggsy last edited by
It's one possibility.
From what I've seen in various places, DNS can fall back to TCP/53 under some circumstances. Can't hurt to try it.
Another oddity.. It seems that if I use the IP (and not an alias) for the rule, the DNS rule doesn't stop working. I have to wait a bit to confirm.
Any rule for DNS needs to allow both udp and tcp, since dns will move to tcp if over 512 bytes
it should be noted that failure to support TCP (or the blocking of DNS over TCP at the network layer) may result in resolution failure and/or application-level timeouts.
In the absence of EDNS0 (Extension Mechanisms for DNS 0) (see below), the normal behaviour of any DNS server needing to send a UDP response that would exceed the 512-byte limit is for the server to truncate the response so that it fits within that limit and then set the TC flag in the response header. When the client receives such a response, it takes the TC flag as an indication that it should retry over TCP instead.
So how exactly is pfsense resolve this alias for your dns? I would have to assume if the pfsense box fails to resolve the alias, then that rule would fail. Why can you not just use the IP for your name server? Name servers IP don't normally tend to change all that often ;)