Firewall pass-all rules not firing

[devl_ish]

Good call from Patrick. I was time pressed and forgot to mention that one.
It's always sane to do this on an internal OPN. Without it, traffic is bouncing off of the edge router LAN GW...

FWIW, the anti-lockout rule is primarily a port forward rule (with associated FW rule).
What you see on that screen is the associated rule.
On WAN, all you need is one rule to allow HTTPS (you don't really the HTTP one is you disable the HTTP->HTTPS redirect or type the full https:// when you access the GUI.
Note that the rule won't fire if the anti-lockout rule are currently on that interface because PF rules take precedence over FW rules.

How about showing the WAN rule you added?

WRT the anti-lockout - even if the port forward takes precedence over the firewall, one of these should still have triggered a pass and prevented a default-deny, right?

WAN Rules (though its working now after adding in another interface):

Going back to the vmbr2 bridge (LAN side of OPN).
A bridge is a switch.
If the member is a physical NIC, it's like a physical port on the switch.
When you assign the bridge to a VM, you get a virtual port on the switch.

The traffic on the bridge is going to be dependent on the interface(s) you assign on the OPN side:
* Assign an interface to vtnet5 directly and traffic is not tagged
* Assign an interface to a vlan device parented to vtnet5 and traffic is tagged

When you have vmbr2 passed to the VM with a VLAN tag, it will only be exposed to traffic from the VLAN (BUT the traffic received by the VM is untagged, as with a regular access port on a switch). You don't have to do any VLAN config within the VM.

If you connected a machine to NIC3:
When the OPN LAN interface is assigned to a vlan device, traffic is tagged (and ignore by that machine unless its NIC is configured appropriately).
When the OPN LAN interface is assigned to vtnet5 directly (no VLAN), traffic is not tagged and should flow freely.

Thanks for that - I have the VLAN working, I think - I have the VM tag the traffic and the bridge VLAN-aware but untagged as I intend for the interface to handle more than one VLAN.

That said now that the firewall is working I still have no luck getting a port forward to work. I'm trying to forward TCP port 21 (now 192.168.50.67 with the new OPNSense VM) on the WAN IP to port 22 on the Linux VM (still 10.2.1.54 and can ping 10.2.1.54 so its live).



I can see where the incoming connection from my laptop (now 192.168.50.212) is being passed to port 21, but no corresponding rdr or any other traffic showing port 22.
Edited: My error, I mistyped the ssh connection command of all things. I can now see when the inbound connection from laptop hits the firewall port 23, when it redirects to 10.2.1.54:22, and outbound from 10:2.1.54:22 back to originating IP as below. Unfortunately, still have an ssh timeout.

Where might I look to see where the roadblock is?

[devl_ish]

Ok, what the actual hell.

I deleted the VLAN and brought up a bridge to a physical port for testing - no change in behaviour.
Then I added the VM VLAN back in, reasoning that I could just run the management interface through a VM in the interim.

Didn't need pfctl -d. Yes, for some reason it now works as soon as the next interface was added. I have no explanation for this. pfctl -e tells me the firewall is definitely already back up.

I'll need to understand eventually but for now I'm going to work on that port forward test.

Slight correction to prevent confusion.

[devl_ish]

Delving further into things, I've taken a look at the routes status table and have a question about it - what does "link#n" mean? I've had a google around and can't find an explanation.



To my newbie mind communication would go like this:

Laptop ssh client -> home router gateway (192.168.50.1) -> Opnsense WAN (now 192.168.50.67) port 23 -(NAT)-> interface 10.2.1.1 -> destination sshd (10.2.1.54 port 22)

...and then the response travels that path in reverse. In that case where along that line might it be misconfigured?

Edit: found https://unix.stackexchange.com/questions/110642/what-does-link1-mean which says under FreeBSD this is the interface in the sequence shown by ifconfig. The routes shown seem to be directing the right subnets to the right interfaces so as far as I can tell that's not causing lost communication.

Does log line:

Code Select Expand

    ServersandNAS        2025-06-04T15:52:55    192.168.50.10:44122    10.2.1.54:22    tcp
...imply that communication from the laptop is being directed to the right place IP and port, but there is no route configured for it to use to get there?

[EricPerl]

Please attach screenshots using preview or reply (vs. quick reply).
As of now, your 3rd party links are hit and miss...

The 2nd "manual anti-lockout" should be sufficient. As is, you won't see stuff in the logs because logging is not enabled on it.
Nothing should end with a default deny with these rules. More don't have logging and some of them don't have description (makes troubleshooting harder).

In the PF rule, I'd use "WAN Address" and add a description.

Given the live view logs, traffic passed through the FW (in on WAN, out on ServerAndNAS).
The next step is to do a packet capture to see if anything is coming from the ssh server.
It's in interface diagnostics. Capture the WAN and LAN side for port 22 (it would be easier if the WAN port was also the standard 22).

More tomorrow. It's late...

[devl_ish]

Please attach screenshots using preview or reply (vs. quick reply).
As of now, your 3rd party links are hit and miss...

Apologies, they were showing up well in Preview - swapping image host.

Port forward currently:


Route Status:


Log:

The 2nd "manual anti-lockout" should be sufficient. As is, you won't see stuff in the logs because logging is not enabled on it.
Nothing should end with a default deny with these rules. More don't have logging and some of them don't have description (makes troubleshooting harder).

I agree - and am still at a loss to explain how the denies happened. Nevertheless its working now after I added in the VLAN, even if I don't understand why that is. I'm concerned that the behaviour will return on the final build or when I add in other VLANs/interfaces.

In the PF rule, I'd use "WAN Address" and add a description.

Thanks - done, screenshot above. No change.

Given the live view logs, traffic passed through the FW (in on WAN, out on ServerAndNAS).
The next step is to do a packet capture to see if anything is coming from the ssh server.
It's in interface diagnostics. Capture the WAN and LAN side for port 22 (it would be easier if the WAN port was also the standard 22).

I started by changing the port forward to "WAN Address" and changing the port forward to 22 -> 22 and confirming that firewalls are down on both proxmox and the linux VM.

Packet capture analysis with Wireshark (hey, new skill...):

Laptop 192.168.50.1, destination port 22, WAN interface


Laptop 192.168.50.1, destination port 22, VLAN interface



I reinstated the "This Firewall" destination port forward and opened an SSH connection from another VM on 10.2.1.0/24 to 10.2.1.1 to see what the traffic is supposed to look like:

10.2.1.54, port 22, VLAN interface:


As far as I can understand the firewall isn't blocking anything, but any requests from 192.168.50.10 are being stopped somewhere or don't have a route.

More tomorrow. It's late...

I really appreciate your efforts on this, I can't imagine you have a lot of time on your hands and I'm grateful for your patience on the bits I've badly explained or missed out. Thank you!

[EricPerl]

FYI, 'WAN Address' is the IP assigned to the WAN interface likely via DHCP.
'This Firewall' is the collection of IPs assigned to all interfaces.
Using 'This Firewall' makes sense for FW rules where an IP associated with the FW might do.
It makes less sense on a port forward on a single interface where only one of the IPs is relevant.

It looks to me like no traffic is coming back from the Linux VM.
Have you confirmed outbound network connectivity from that VM (IP, ping, DNS, light browsing) as a way to establish some baseline on network connectivity?
Have you confirmed that you can connect to it from its LAN? Or even just from OPN?

Is sshd even installed and running?

Code Select Expand

systemctl status sshd

Edit:
That last screenshot is ssh into OPN? It looks rather healthy.

[devl_ish]

FYI, 'WAN Address' is the IP assigned to the WAN interface likely via DHCP.
'This Firewall' is the collection of IPs assigned to all interfaces.
Using 'This Firewall' makes sense for FW rules where an IP associated with the FW might do.
It makes less sense on a port forward on a single interface where only one of the IPs is relevant.

Thanks for that, I had assumed that's how it worked so was using it interchangeably for testing, but you're right, I should have used "WAN Address" in the first instant and carried it through.

It looks to me like no traffic is coming back from the Linux VM.
Have you confirmed outbound network connectivity from that VM (IP, ping, DNS, light browsing) as a way to establish some baseline on network connectivity?
Have you confirmed that you can connect to it from its LAN? Or even just from OPN?

Is sshd even installed and running?

Code Select Expand

systemctl status sshd

Edit:
That last screenshot is ssh into OPN? It looks rather healthy.

Yup, the last screenshot is ssh from another Linux VM on the same VLAN 60 (10.2.1.48 from memory, I've taken it down now) which I used to successfully test whether a "This Firewall" port forward would allow it to ssh to 10.2.1.1 and have its traffic forwarded to 10.2.1.54 (the test VM with sshd running). Worked fine.

10.2.1.54 is able to:

• ping 10.2.1.1, and
• ping 8.8.8.8 when I have an Outbound NAT rule enabled, and
• ping the laptop (192.168.50.10) on the VLAN50 interface
• ssh to another offsite server when I have an Outbound NAT rule enabled

ufw confirmed down on this machine as well, and the offsite server has its ssh on a non-standard port.

...and just in the middle of typing that I found the problem.

The linux VM was also bridged to vmbr0, a bridge on proxmox, and had an IP of 192.168.50.30 on that interface. It was not a fresh VM and I had that up to enable updating and installing openssh-server from memory.

When I SSH'd from the laptop to the firewall (192.168.50.67) it correctly NAT'd to 10.2.1.54, but when 10.2.1.54 replied it logically routed back through the other interface (or didn't reply at all, who knows).

I deactivated the interface to vmbr0 and it worked :-)

Many thanks for your help! I'm still keen to know why the rules in the original post didn't fire, but as I can no longer replicate that behaviour I'll have to make that a problem for later.

As the original question remains, do I still (and how) mark this thread as solved?