Messages

Hi Franco

I'm still experiencing this issue in production as well as my homelab.

As I'm rebooting more often in my homelab, I'm having to manually restart dhcpd/DNS services to take into consideration wireguard

My new workaround script is: https://gist.github.com/Westie/5557cffd927dd32de93255e5ac4a22e0

As an aside, when booting the firewall VM I've noticed in the serial console that DHCP, DNS services etc seem to set up before Wireguard/other VPN services have been set up.

May this might be related to the issues I'm experiencing?

[Contents of /usr/local/etc/rc.syshook.d/start/99-reload-rules:]

Another post!

A friend and I had come up with a suggestion independently and almost at exactly the same time, to use syshooks to resolve the issue.

Contents of /usr/local/etc/rc.syshook.d/start/99-reload-rules:

Code Select Expand


#!/bin/sh

sh -c "(sleep 60 && /usr/local/etc/rc.filter_configure) > /dev/null" &


Whilst I could probably get away with reducing the timer down to 30 seconds, I kept it at a minute because honestly... if things were to go wrong, 30 seconds would be the least of my issues.

I've just reverted the patch and can confirm that the same diff is obtained.

Thank you for responding quickly by the way @franco, I appreciate the help

[Proof of patch being applied:]

Patch appears to not help.

Proof of patch being applied:
root@meerkat-firewall:~ # cat /usr/local/www/interfaces_assign.php | grep interface_bring_down | wc -l
       0


Diff of debug file after manual reapply
root@meerkat-firewall:~ # diff /tmp/rules.debug.1 /tmp/rules.debug
85a86,87
> nat on vtnet0 inet from (wg0:network) to any port 500 -> (vtnet0:0) static-port # Automatic outbound rule
> nat on vtnet0 inet from (wg1:network) to any port 500 -> (vtnet0:0) static-port # Automatic outbound rule
89a92,93
> nat on vtnet0 inet from (wg0:network) to any -> (vtnet0:0) port 1024:65535 # Automatic outbound rule
> nat on vtnet0 inet from (wg1:network) to any -> (vtnet0:0) port 1024:65535 # Automatic outbound rule
102a107,110
> rdr on wg0 inet proto {tcp udp} from {any} to {(self)} port {80} -> $traefik port 80
> nat on wg0 inet proto {tcp udp} from (wg0:network) to $traefik port {80} -> (wg0) port 1024:65535
> rdr on wg1 inet proto {tcp udp} from {any} to {(self)} port {80} -> $traefik port 80
> nat on wg1 inet proto {tcp udp} from (wg1:network) to $traefik port {80} -> (wg1) port 1024:65535


There are numerous additional instances of what's been flagged up in 102a107,110 however I've removed them for clarity.

[Dear lurkers:]

Dear lurkers: I have a workaround here.

Hi all

Unfortunately I've not been able to find any sort of logs that will assist with this issue, however I'll describe the issue in its entirety in the hope that someone can help with regards to how to diagnose this issue.

This is something that came to light when upgrading to the latest community version from 23.1 - at time of this post, it is 23.7.9.

As far as I can tell, everything appeared to be working when I had performed checks post-install of 23.7, however I wouldn't trust that.

So, issue:

• Firewall VM is booted
• Wireguard is booted
• WG user can connect to WG server, and can access OPNsense admin UI
• WG user can access any IPs that are declared/routed through Wireguard
• WG user cannot access any IPs that are routed to the firewall itself, other than the port of admin UI/admin SSH
• Any attempt by WG user to access IPs routed through the firewall are met with a connection timeout
• Any attempt by WG user to access IPs do appear in logs (filter=dst_ip, filter=dst_port), and they are not blocked.
• NOTE: I didn't check whether or not any responses to the originating IP address were logged nor blocked.
• WG user proceeds to "Firewall" > "Aliases" page within admin UI
• WG user proceeds to click "Apply" at the bottom of the page
• WG user is now able to access IPs local to the Firewall

I'm confused. How should I go about this, other than adding a script to perhaps re-apply firewall rules soon after boot?

Note: all other routing works as intended, I appear to just have problems being routed through the firewall between the firewall booting, and me manually re-applying rules.