{"id":5734,"date":"2025-05-10T12:30:00","date_gmt":"2025-05-10T11:30:00","guid":{"rendered":"https:\/\/www.marshflattsfarm.org.uk\/wordpress\/?page_id=5734"},"modified":"2026-02-04T11:20:06","modified_gmt":"2026-02-04T11:20:06","slug":"opnsense-miscellaneous-hints-and-tips","status":"publish","type":"page","link":"https:\/\/www.marshflattsfarm.org.uk\/wordpress\/?page_id=5734","title":{"rendered":"OPNsense – Miscellaneous Hints and Tips"},"content":{"rendered":"\n

Ping not working from WAN interface<\/h2>\n\n\n\n

This seemed really strange; in a test configuration, where the “WAN” connection for OPNsense was in fact an existing (but not OPNsense) packet-filtering firewall, the WAN interface was happily being allocated an IP address by DHCP but it wasn’t possible to get a ‘ping’ response from the next-hop Gateway. Looking at the packets on the network, it was clear the ICMP packets were indeed being sent – and responded to – but these replies were never being seen by the ‘ping’ command. As a consequence of ‘ping’ not working, the status monitoring on the WAN interface was failing, considering it to be always ‘down’ – and so not routing any traffic to it.<\/p>\n\n\n\n

The solution came via this Reddit post<\/a>, which says:<\/p>\n\n\n\n

\n

Check firewall > settings > advanced. Change the “reply-to on wan rules” to the opposite.<\/p>\n<\/blockquote>\n\n\n\n

This is referring to the “Disable reply-to on WAN rules” tick-box, for which the additional help text says:<\/p>\n\n\n\n

\n

With Multi-WAN you generally want to ensure traffic leaves the same interface it arrives on, hence reply-to is added automatically by default. When using bridging, you must disable this behaviour if the WAN gateway IP is different from the gateway IP of the hosts behind the bridged interface.<\/p>\n<\/blockquote>\n\n\n\n

The OPNsense manual page for this setting is here<\/a>. It’s not clear how Bridging is related to this – there is<\/strong> a Bridge interface for one of the LAN VLANs; maybe the Tunable configuration settings required for that Bridge change the behaviour for the WAN interface too?<\/p>\n\n\n\n

From some further reading, it seems the problem only manifests itself when the next-hop gateway is itself a packet-filtering firewall, so it might not be an issue in a more realistic deployment scenario.<\/p>\n\n\n\n

There’s an in-depth discussion in this OPNsense Community posts: Reply-to on WAN by default is bogus<\/a><\/p>\n\n\n\n

possible DNS-rebind attack detected:<\/h2>\n\n\n\n

Admittedly it’s a slightly unusual deployment scenario to have one DNS server running in the Outbuildings, referencing another<\/em> DNS server running in the House – where both the House and the Outbuildings are using RFC1918 ‘private’ IP address ranges. One consequence of this deployment pattern is that the Outbuildings DNS server treats the receipt of an RFC1918 IP address from its upstream DNS server as a “possible DNS-rebind attack<\/em>” – because dnsmasq is configured (by OPNsense) with stop-dns-rebind<\/code> in its configuration file.<\/p>\n\n\n\n

There’s certainly a requirement for the Outbuildings’ DNS server to return IP addresses for hostnames such as unifi<\/code> (so UniFi network equipment knows where to find its Controller) which trigger the ‘rebind attack’ error if the response comes from the House’s DNS server.<\/p>\n\n\n\n

One option is to add a duplicate, local entry for unifi<\/code> to the Outbuildings’ DNS server, since that avoids triggering the error (because the entry is ‘local’) – but it means maintaining a duplicate entry on both DNS servers.<\/p>\n\n\n\n

Another option is to use the rebind-domain-ok=\/unifi\/<\/code> dnsmasq configuration syntax to specify domain names which should be permitted RFC1918 addresses. Since this construct is not supported by OPNsense’s GUI for dnsmasq, such configuration lines need adding to a custom .conf<\/code> file placed in directory \/usr\/local\/etc\/dnsmasq.conf.d\/<\/code> While this works OK it’s a bit of a pain to have to maintain entries for all hosts in the House.<\/p>\n\n\n\n

A third option is to not<\/strong> to specify stop-dns-rebind<\/code> in the dnsmasq configuration file (and hence turn off rebind checking completely, for the Outbuildings’ DNS server) – but this line is automatically added to the main dnsmasq.conf<\/code> file by OPNsense and there is no GUI option to remove it. It appears that the same result can be achieved by adding the following in a custom .conf<\/code> file – which effectively says that ‘all hosts’ are rebind-domain-ok<\/code>:<\/p>\n\n\n\n

rebind-domain-ok=<\/code><\/pre>\n\n\n\n
A related point is that none of the DHCP host address reservations should have the ‘Local’ box ticked, since doing so declares the specified Domain will only be served by the local DNS server – and never forwarded upstream.<\/p>\n\n\n\n
In the end, the all-round better solution turned out to be to centralise DHCP and DNS on the House firewall, using DHCP Relay settings on the local VLANs in the Outbuildings. A side-effect of this is that the DHCP leases returned by the House’s DHCP server automatically reference the House’s DNS server, so there’s only one DNS server that ever returns RFC1918 addresses.<\/p>\n\n\n\n
TCP Session Timeout<\/h2>\n\n\n\n
Kept noticing packets tripping the “Default deny \/ state violation rule” when on inspection they belonged to legitimate traffic – so they were clearly failing on the ‘state’ element of the check.<\/p>\n\n\n\n
There’s an Advanced Setting for the Firewall of “Firewall Optimization” which is “Normal” by default; changing this to “Conservative” seems to be helping to avoid this traffic being blocked unnecessarily.<\/p>\n\n\n\n
Checklist for Adding an Extra VLAN<\/h2>\n\n\n\n
Adding a new VLAN isn’t difficult but there are quite a few steps required, some of which must be performed in a specific order.<\/p>\n\n\n\n
The first step is to allocate the configuration settings for the new VLAN, notably:<\/p>\n\n\n\n