Restart of service Wireguard leads to incorrect firewall rules
-
I restarted Wireguard in an attempt to restore a tunnel that did not establish itself automatically. After doing that the routing did not work as before the restart. I have configured firewall rules to route some type of traffic from one LAN onto a VPN group. After the Wireguard restart this traffic was sent to the default gateway, not the VPN group. The following log entries seems to confirm something goes wrong:
May 20 09:19:20 php-fpm 382 /rc.filter_configure_sync: An error occurred while trying to find the interface got 10.67.19.58 . The rule has not been added. May 20 09:19:20 php-fpm 382 /rc.filter_configure_sync: An error occurred while trying to find the interface got 10.68.57.144 . The rule has not been added. May 20 09:19:20 php-fpm 382 /rc.filter_configure_sync: An error occurred while trying to find the interface got 10.67.19.58 . The rule has not been added. May 20 09:19:20 php-fpm 382 /rc.filter_configure_sync: An error occurred while trying to find the interface got 10.65.139.210 . The rule has not been added. May 20 09:19:20 php-fpm 382 /rc.filter_configure_sync: An error occurred while trying to find the interface got 10.67.198.131 . The rule has not been added. May 20 09:19:20 php-fpm 382 /rc.filter_configure_sync: An error occurred while trying to find the interface got 10.65.173.208 . The rule has not been added.The 10.* addresses are for the Wireguard VPNs.
I have not noticed this behaviour is earlier pfSense releases.
-
@pst this is a setting you can set in pfsense. If a gateway you are sending a rule to is not available you can have pfsense just skip the rule, or you can have it just use the default gateway.
https://docs.netgate.com/pfsense/en/latest/config/advanced-misc.html#skip-rules-when-gateway-is-down
-
@johnpoz I already had that option ticked (don't know why though) but I had not added the firewall reject rule as per the documentation.
However, after adding the reject rule none of the gateways come up. The reason is most likely because I have gateway monitoring enabled, and dpinger does not get a response to the pings as the gateway is not up (get caught by the reject rule), so we end up locked... catch-22.
I was hoping to use gateway monitoring to detect failure on one gateway in the gateway group to trigger a switch to a tier 2 gateway. But perhaps that is never going to work?
