Not reproducible

I am receiving complaints from our ISP that there is an open recursive DNS resolver on the external address of the firewall. This has to be considered a bug as the DNS only is supposed to reply to requests from clients on it's own network. That is, the relay should not reply to requests to the outside address, only from clients on the inside. I have tested different versions of Monowall and they are all behaving the same way, when you turn on DNS forwarding Monowall starts to reply on the external (WAN) interface as well as on the correct inside (LAN) interface.

As this behavior is considered unacceptable by many ISP's it should be considered a bug or it should at the very least be a feature that can be turned off. Using a firewall rule to block port 53 is not an acceptable solution as that also would make it impossible to run DNS servers on the inside of the firewall.

Anders

m0n0wall 1.33 in the default configuration does not reply to DNS queries on its WAN interface. What do your WAN firewall rules look like?

As I have several DNS servers on the inside that has to be able to communicate with upstream servers I have port 53 open and NAT'ed to the primary DNS on the inside.

As I have several DNS servers on the inside that has to be able to communicate with upstream servers I have port 53 open and NAT'ed to the primary DNS on the inside.

There should be no need for that - m0n0wall uses stateful packet filtering, so when your internal DNS servers send queries to upstream DNS servers (and you allow those queries on the corresponding LAN/optional interface), then the replies will automatically be let through, even if there's no rule for that on WAN.

As I have several DNS servers on the inside that has to be able to communicate with upstream servers I have port 53 open and NAT'ed to the primary DNS on the inside.

There should be no need for that - m0n0wall uses stateful packet filtering, so when your internal DNS servers send queries to upstream DNS servers (and you allow those queries on the corresponding LAN/optional interface), then the replies will automatically be let through, even if there's no rule for that on WAN.

Yes, that would be true if it wasn't for the fact that the DNS on the inside is the primary DNS for the whole domain. There is a bit of traffic in both directions between it and the secondary DNS that is located outside the firewall. It is queried for updates on a regular basis from the secondary DNS and since it also is authoritative for the domains it hosts other DNS'es needs to be able to query it too.

Yes, that would be true if it wasn't for the fact that the DNS on the inside is the primary DNS for the whole domain. There is a bit of traffic in both directions between it and the secondary DNS that is located outside the firewall. It is queried for updates on a regular basis from the secondary DNS and since it also is authoritative for the domains it hosts other DNS'es needs to be able to query it too.

I see. So I take it you have multiple public IP addresses? Can you please post all the relevant NAT and WAN firewall rules so we can figure out what's going wrong?

Yes, that would be true if it wasn't for the fact that the DNS on the inside is the primary DNS for the whole domain. There is a bit of traffic in both directions between it and the secondary DNS that is located outside the firewall. It is queried for updates on a regular basis from the secondary DNS and since it also is authoritative for the domains it hosts other DNS'es needs to be able to query it too.

I see. So I take it you have multiple public IP addresses? Can you please post all the relevant NAT and WAN firewall rules so we can figure out what's going wrong?

Yes, that's right. There are three external public addresses, 193.11.112.144, 193.11.112.145 and 193.11.112.146. The last address is also the address of the physical WAN interface. On the inside there are a number of servers, all on a private 192.168.1.XYZ network. The first two addresses are NAT'ed 1:1 to  corresponding servers on the inside and the last address is NAT'ed to several servers on the inside. The rules of interest are the following:

NAT:
WAN TCP/UDP 53 (DNS)  192.168.1.4 53 (DNS)

WAN:
TCP/UDP * * 192.168.1.4 53 (DNS) NAT


The problem is not with the rules however but rather with the way dnsmasq binds to the different interfaces. By making the following change I was able to get the desired behavior and I would recommend that it is added to the mainstream release.

In the function services_dnsmasq_configure() in /etc/inc/services.inc I added this just before the dnsmasq binary is executed.

/* determine WAN interface name */
$wanif = get_real_wan_interface();
/* remove WAN interface from bindings */
$args .= " --except-interface={$wanif}";

It makes sure that you still can use DNS forwarding on the inside and any OPT interfaces but that dnsmasq never replies to requests on the WAN interface.

So the IP address that attracted open resolver complaints was 193.11.112.146? I still don't see how dnsmasq could ever even receive a query from the Internet given your NAT and firewall rules... Anything else about your setup that I should know?

While we can add the fix you suggested, I'd rather get to the bottom of this issue, since it should easily be possible to control this using just firewall rules alone. Also, who knows - someone might actually want the DNS forwarder to be accessible to certain IP addresses via the WAN interface.

So the IP address that attracted open resolver complaints was 193.11.112.146? I still don't see how dnsmasq could ever even receive a query from the Internet given your NAT and firewall rules... Anything else about your setup that I should know?

While we can add the fix you suggested, I'd rather get to the bottom of this issue, since it should easily be possible to control this using just firewall rules alone. Also, who knows - someone might actually want the DNS forwarder to be accessible to certain IP addresses via the WAN interface.

There is nothing special about the way I have Monowall setup so I am pretty sure that it isn't a config issue.

Well, the fix definitely solved the problem so the culprit seems to be dnsmasq and the way it binds to the interfaces. Though it might point to a problem with the way pf works my guess is that dnsmasq somehow manages to bind to the interface at a lower level bypassing the packet filter.

Perhaps it would be a good idea to add the option to bind to all interfaces on the config page for DNS forwarding but to leave that out by default?

I noticed that this has been brought to the surface before in a posting that was moved to the Bogus bug list.
http://forum.m0n0.ch/index.php/topic,904.0.html
However, the underlying problem was not resolved so this is definitely something that needs to be addressed.

Well, the fix definitely solved the problem so the culprit seems to be dnsmasq and the way it binds to the interfaces. Though it might point to a problem with the way pf works my guess is that dnsmasq somehow manages to bind to the interface at a lower level bypassing the packet filter.

I'll give it a try tomorrow, as there should definitely be no way for queries from the Internet to get to the DNS forwarder if there isn't an explicit WAN firewall rule to allow it.

I noticed that this has been brought to the surface before in a posting that was moved to the Bogus bug list.
http://forum.m0n0.ch/index.php/topic,904.0.html
However, the underlying problem was not resolved so this is definitely something that needs to be addressed.

That post was moved to bogus because it claimed that the DNS forwarder was accessible from WAN in the default configuration, which is not the case. The simple fact that Dnsmasq listens on all interfaces (as evidenced by netstat etc.) doesn't constitute a problem in my opinion; we just need to be certain that it only actually gets queries from the Internet if the user has explicitly configured the firewall rules that way. Why this didn't work in your case I don't know, but I hope I'll find out

I tried to reproduce this today (m0n0wall 1.33, default configuration with two additional WAN IP addresses via proxy ARP, inbound NAT and 1:1 in place as per your description), but it was not possible to access the DNS forwarder from WAN. Only when I removed the port 53 NAT rule and added a firewall rule as follows did I get a response:

TCP/UDP    *    *    WAN address    53 (DNS)

Would it be possible for you to send me your (sanitized/anonymized if necessary) config.xml (to mk@neon1.net)? I'd very much like to reproduce this...