Messages

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.

Active le logging pour les règles par défaut (Firewall: Settings: Advanced).
Regarde le log live quand tu démarres le client mail.

Si le pare-feu est le souci, tu devrais voir du rouge.
Les ports pour le courriel sont standard (SMTP = 25, IMAP = 143, various for POP). Ça dépend du service que tu utilises.

Si tu ne sais pas créer la règle pour compenser, partage une copie d'écran du traffic bloqué (tu peux filtrer le log live).

Ping and tracert should work FROM a IPv4 host in LANDMZ because of this:

Code Select Expand

AB Protocol     Source     Port Destination Port Description
A  IPv4 ICMP    LANDMZ net *    *           *    Allow ICMP to OPNsense 
At least, it should go through the FW.
There's not enough info in this thread to infer what 192.168.11.1 maps to.

Then I was saying that this makes sense (option A):

Code Select Expand

AB Protocol     Source     Port Destination Port Description
...
B  IPv4+6 *     LANDMZ net *    RFC1918     *    Block LANDMZ to internal  # Explicit block of inter-VLAN
A  IPv4+6 *     LANDMZ net *    *           *    Allow access to everything

This is an alternative (option B):

Code Select Expand

AB Protocol     Source     Port Destination Port Description
...
A  IPv4+6 *     LANDMZ net *    !RFC1918    *    Allow access to everything except local networks

One big difference is that when it is followed by this:

Code Select Expand

AB Protocol     Source     Port Destination Port Description
...
A  IPv4 *       LANDMZ net *    FLUX_IPs    *    Allow to admin PC only    # Isn't the Block RFC1918 rule getting in the way?   
Assuming FLUX_IPs is a subset of RFC1918 (give the admin PC description), option A will prevent that rule from going into effect while option B won't.
If that rule was higher up (before the block), it would also work.

So one part of my comments was about some redundancy (block 1918, allow !1918), another was about an unreachable rule (block 1918, allow IPin1918).

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...

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?

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.

The diagram is reasonable. You don't need to assign a member NIC to the "LAN" bridge if you only plan to connect VMs.
meyergru has a Proxmox + OPN post in the tutorials. The 2nd post is about a data center use case (1 NIC).
Feel free to continue to use the USB NIC but you don't have to. You can also adapt as appropriate.

Make that Proxmox bridge VLAN aware. All you have to do for the Linux Mint VM is to specify a VLAN tag = 50 in the network device passed to the VM.

Wrt to your issue:
By default, WAN does not allow access to the GUI (no FW rules).
But if it's the only interface, anti-lockout applies to it.
When you're adding another interface, anti-lockout "moves" to that...

Add a FW rule to WAN to allow GUI access.

Define "a lot".
What is resource consumption like? Which processes consume?

When I feel like I should verify what I'm about to post, I run such tests on my secondary virtualized OPN.

I can't believe how badly I misread that original post.

Both the "WAN" and the "LAN" side of OPN get IP via DHCP from your home router???
That's an invalid setup. You can't have overlapping subnets across interfaces.
OPN's LAN should have its distinct range, statically assigned.

I won't comment on the OpenWRT VM for now.

With NAT on OPN, the ISP-router LAN is flat (all traffic coming for hosts in that subnet).
The main downside is that you lose visibility into the OPN LAN hosts. That's a feature at the edge router!

If you disable NAT on OPN, you end up propagating traffic with sources in OPN LAN into the ISP-router LAN.
You need to route that traffic back there:
* Internal-GW pointing to OPN WAN IP.
* static route OPN-LAN -> Internal-GW
You might be able to take care of that if your ISP router allows you to specify static routes.

Again, such traffic should go between peers directly.
One possibility is that one of them is misconfigured (e.g. /32 netmask) so that it sends everything to the gateway.

Another possibility is that the 2 peers are connected to different members of the bridge.
A properly configured bridge should not perform any filtering at the member level for this reason.
Connections between peers is regular switching and typically not subject to filtering (which is expected at the interface level).
That's what the tunables in the bridging guide are all about.

That looks like incomplete instructions for that software.
Why don't you post on their forum? Oh wait, there's been 1 post year to date.
And that software has apparently not been updated in over 5 years. Are you sure you want to use that?

Apparently, you can add tftp to OPN to get a PXE server: https://gist.github.com/azhang/d8304d8dd4b4c165b67ab57ae7e1ede0

Or maybe use the info in that page to infer how you need to input data in DHCP options.
The layout on the tftp server has to be standard...

Also, I suspect outbound traffic to the current DNS router is bouncing off of the ISP router, unless reply-to has been disabled (FW advanced settings).

If you disable NAT on OPN, even if it's just for the ISP router LAN only, you'll have to route reply traffic back to OPN WAN, which is essentially choice a.
You might as well disable NAT completely at that point... Most of the work involved ends up being on the edge router (ISP router).

Check the alias in Firewall: Diagnostics: Aliases.
There are validation rules on their content.

Yep. I'm aware. Although when I first read it, I was pretty green with OPN (and greener with virtualization) and missed the part about vmbr1 being internal only...
I later set up a 1 NIC virtualized OPN at home with physical machines on its LAN and still didn't understand how this datacenter use case worked.
Then I realized my mistake...