Should router on a stick work?

[dragon2611]

i3-6100T USFF machine 8gb ram, ~300Mbit connection.

Wan is a VLAN on em0
Lan is native
Various other VLANs.

Opnsense 21.7.7

Having Zenarmor installed even running in passive mode seemed to cause some weridness like connections hanging or being slow to establish.

Not sure if it's underpowered hardware or it gets upset at seeing the WAN vlans as well.

Only way to split the WAN and LAN interfaces would be to add a USB3 NIC.

[chemlud]

Wan is a VLAN on em0
Lan is native
Various other VLANs.

Opnsense 21.7.7

Does that mean to mix tagged and untagged traffic on the same physical interface? Don't do that on BSD...

[lilsense]

Wan is a VLAN on em0
Lan is native
Various other VLANs.

Opnsense 21.7.7

Does that mean to mix tagged and untagged traffic on the same physical interface? Don't do that on BSD...

He stated Native which is a std dot1q feature. This should work without an issue. I am not sure how to set a Native vlan in OPNSense.

[Patrick M. Hausen]

You don't set a native VLAN. Just don't assign an interface to the physical ports and only use tagged VLANs.
On the connected switch set the native to an unused one - I use 1001 ...

OPNsense although a firewall is essentially a Unix host and not a switch. So you have to live with the FreeBSD network stack. Using a native VLAN will lead to all sorts of trouble. Don't do it.

Not sure if Zenarmor on VLANs is supported at all. Suricata officially isn't for IPS mode - only IDS works.

HTH,
Patrick

[lilsense]

I presume your statement to be incorrect, since I work with Juniper JunOS which is based on FreeBSD and it does support all the features.

[sy]

Hi,

@dragon2611 can you send a bug report from the upper right corner of Sensei GUI?

[Patrick M. Hausen]

I presume your statement to be incorrect, since I work with Juniper JunOS which is based on FreeBSD and it does support all the features.

Juniper is based on FreeBSD but they have their own proprietary forwarding plane. Otherwise anyone could build a product  that is feature and performance comparable with Juniper by just installing FreeBSD.

Also their later variants of JunOS are based on Linux.

If you don't want to take my word for it, ask Kristof Provost, one of the main FreeBSD networking developers. I have been exchanging messages back and forth with him while designing our network infrastructure for an entire data centre running on FreeBSD and I do claim to know the FreeBSD network stack from an operations point of view really well.

[dragon2611]

Does that mean to mix tagged and untagged traffic on the same physical interface? Don't do that on BSD...

Oh, wasn't aware that causes an issue 

[dragon2611]

Hi,

@dragon2611 can you send a bug report from the upper right corner of Sensei GUI?

I think it might actually have been down to broken IPv6 that was being annoyingly intermittent, Turns out I had more than one V6 gateway and they had the same metric

[lilsense]

I presume your statement to be incorrect, since I work with Juniper JunOS which is based on FreeBSD and it does support all the features.

Juniper is based on FreeBSD but they have their own proprietary forwarding plane. Otherwise anyone could build a product  that is feature and performance comparable with Juniper by just installing FreeBSD.

Also their later variants of JunOS are based on Linux.

If you don't want to take my word for it, ask Kristof Provost, one of the main FreeBSD networking developers. I have been exchanging messages back and forth with him while designing our network infrastructure for an entire data centre running on FreeBSD and I do claim to know the FreeBSD network stack from an operations point of view really well.

Thanks for that... Currently, the later version of the JunOS is running on a linux KVM in FreeBSD. I have heard they are planning to move to linux kernel, but I have not seen a product running it. The current QFX runs FreeBSD as well.

One thing to note is that I do not understand that FreeBSD is not supporting the full spec IEEE 802.1Q which allows native vlan to be identified as anything but vlan1.

[Patrick M. Hausen]

It does. But things like pf might get confused. Which is the point of OPNsense 

And if you want to use if_bridge - which is frequently the case in the TrueNAS environment, not so much over here - then making the physical/native a member of a bridge interface results in tagged VLANs not working at all. You cannot have VLANs on a bridge member in FreeBSD.

So it's discouraged - that's all.

And VLAN 1 is allowed as native, default state for e.g. Cisco. I guess the reasoning being not to lock yourself out of the management plane, which is also VLAN 1 by default.

At work I simply don't want a customer with a trunk port to be able to throw untagged packets at my management plane, so I set the native VLAN to 1001 on every trunk and do not use that VLAN anywhere.

Whoever is responsible for that part of the spec deserves to be shot. Most network professionals I work with agree with me on that. A trunk is a trunk and carries only tagged frames. Period.

So I might have a strong opinion on that topic, but in general it helps to hammer that point home at people with little to no experience, because the "native VLAN" is a frequent source of all kinds of problems.

Kind regards
Patrick

[lilsense]

And VLAN 1 is allowed as native, default state for e.g. Cisco. I guess the reasoning being not to lock yourself out of the management plane, which is also VLAN 1 by default.

At work I simply don't want a customer with a trunk port to be able to throw untagged packets at my management plane, so I set the native VLAN to 1001 on every trunk and do not use that VLAN anywhere.

Right, so the question is how do you set the native VLAN to 1001 in OPNSense rather than VLAN 1.

[Patrick M. Hausen]

Simply run VLAN 1 tagged and don't assign an IP address to the untagged parent interface. No need to mess with "native" at all. FreeBSD is a host in that regard, not a router or switch.

On OPNsense: in Interfaces > Assignments don't assign anything to e.g. igb0. Create a separate VLAN with igb0 as parent for every single firewall interface --> no untagged use of igb0 ever.