Bug Reports

ICMP messages have the IP address of the gateway reporting the error, which may be in any of the private networks. This is legal.

The same holds for IGMP and DHCP.

That is, the DHCP server of your ISP may legally have a private IP (10/8, 172.16/12, and 192.168/16) while serving public IPs (whatever has been assigned to your ISP).

Likewise, a border router IGMP may also broadcast in the 224.0.0.0/24 range from a private IP.

Checking the "Block private networks" box on the WAN webGUI Interface page will result in a set of rules that will break some RFCs.

For example, given LAN in the 10/8 range, an optional interface in the 192.168/16 range and a STATIC WAN configuration on interface sis0, m0n0wall will create the following rules:

@8 block in log quick on sis0 from 10.0.0.0/8 to any
@9 block in log quick on sis0 from 192.168.179.0/24 to any

@10 block in log quick on sis0 proto udp from any port = bootps to 10.0.0.0/8 port = bootpc
@11 pass in quick on sis0 proto udp from any port = bootps to any port = bootpc

@14 block in log quick on sis0 from 127.0.0.0/8 to any
@15 block in log quick on sis0 from 172.16.0.0/12 to any
@16 block in log quick on sis0 from 192.168.0.0/16 to any

Rules 8 to 11 limit traffic on the WAN for IPs used internally. Rules 10 and 11 refers to DHCP traffic: in this example, the DHCP server and Relay are not enabled on the LAN, while the DHCP Server is enabled on the optional interface.

Obviously, rules 14 to 16 limit the rest of the private IP space although the loopback interface is not part of RFC 1918.

When the "Block private networks" box on the WAN webGUI Interface page is not checked, rules 8 to 11 above are still generated while rules 14 to 16 are not. In this case, packets with a source address of 127.0.0.1 will be accepted which may cause unwanted results on the m0n0wall gateway.

In either case, rules 8 to 11 have precedence over any rule that can be defined on the WAN tab of the Firewall Rules webGUI page.

So, RFCs are broken wheter the box on the WAN interface is checked or not.

Finally, traffic on the WAN interface _from_ 224.0.0.0/3 (Reserved, limited broadcasts, and multicasts) should be blocked in extremely hostile environments ;-)

As a suggestion, it would be nice if the rule for the WAN traffic could be moved immediately after the first few rules required to speed things up or cleansing really unwanted traffic, such as

@1 pass in quick on lo0 all
@2 block in log quick from any to any with short
@3 block in log quick from any to any with ipopts
@4 block in log quick on sis0 all head 200

This would allow a level of control on source IPs viewed from the WAN interface that is not required in any of the other interface. For example, a destination unreachable or source-quench ICMP message may be transmitted to an application inside the perimeter even if the source IP is represented anywhere in the topology of the gateway.

Perhaps the "Block private networks" option would be easier to manage in this configuration. In the current situation, an ISP that is agressively using private IPs to manage its network will fill the Firewall logs with entries from the RFC 1918 range that are perfectly valid.

Regards,

Serge Caron