Messages

This is explained here: https://docs.opnsense.org/manual/firewall.html

See "processing order".

BTW: This is the german part of the forum...

It does not matter which way you go, that is a matter of preference. However, assuming that you have a VM host that runs several VM guests which attach to different VLANs, the physical connection that the VM host needs to have a "trunk" access, i.e. all VLANs are accessible, Since many VM guests must attach to the same VLAN, they are usually connected using a logical bridge on the VM host, which in turn connects to a VLAN.

By choosing which host bridge a VM guest connects to you essentially define which VLAN ist is connected to.

Bridging is one type of VM networking which resembles a "switch" in the real world.


Not meaning to be rude, but the questions you ask make me wonder if you really want to start with an advanced networking concept like VLANs without having some basics? If you do not want to read some books about networking, I can recommend NetworkChuck's Youtube channel, which has hands-on examples for many networking concepts you may need along the way.

I think it is easier to build knowledge up from the ground than to start at something exotic and trying to "drill down" to every piece of the puzzle, i.e. instead of being able completing a task building up from existing knowledge, one finds again something that needs to be understood first. The latter way, you will end up in following many branching roots without ever finishing anything before new uncharted territory becomes visible.

VMs are very easy to use with VLANs - and they cannot choose to which one they are connected.
You simply setup VLANs, connect the VM host as trunk and create bridges for every VLAN, many of which do not even have an IP address on the VM host itself.

Then, you assign VM guest interfaces to the appropriate bridge.

I helps it you have console access in your VM solution, so that you can check if anything in the networking goes wrong - otherwise you cannot see much. I prefer Proxmox. If you create a lab for testing only, you can also put OpnSense into a VM.

That sounds strange - the manufacturer says that the hardware is verified to run with OpnSense and you say it works under Proxmox (so no hardware defect).

Did you try under Proxmox first and restored a backup of your OpnSense settings from that installation under your bare-metal OpnSense install? In that case, the interface names do not match. You would have to re-assign the logical interfaces to physical ones via the console menu.

Normally, there is nothing to worry about with these systems - the I225 ports are detected automagically.

You can do both (or either): on a WLAN, you usually have a 1:1 mapping of WLAN <-> VLAN and secure WLAN access via passwords. If switchports are physically accessible, you have a problem.

Therefore, in a company situation, you usually have important VLANs (like server VLAN) in a closed area like an infrastructure closet - the switch is located there, as well, such that you can only physically access certain ports. But even then, exposed ports in offices are secured by 802.1x or at least by allowing only specific MACs.

The former is used with intelligent clients than can be provisioned with certificates (like PCs), the latter for dumb devices like printers or VoIP phones. Because a MAC can be spoofed, you could have a PC pose as a printer using its MAC (which is commonly visible on a label) - therefore, printers are often on a separate VLAN which has limited access.

As you can see by now, VLANs are a means to separate a network into zones of different sensitivity, but as you said, this works only if you can control this separation - either by separating them on a WLAN level or by making sure that no illicit devices can access privileged ethernet ports. Nowadays, there is also a third kind of networks, i.e. virtual networks. For example, when you have a virtual backup machine for a friend that is accessible from WAN, you want that to be on a separate VLAN (demilitarized zone) that has no access to your LAN.

Following that, you probably have the following VLANs:

- LAN, for your PCs and servers
- IoT (for devices you cannot fully trust, because they might "phone home" and thus introduce security risks)
- Guest (to give friends or neighbors internet access without compromising your own networks)
- DMZ

Between those, you will have limited routing or a firewall which allows access from LAN to all, but little else.
There may be exceptions, like you might allow printing from Guest to printers in IoT. Also, IoT devices can probably access a media share on your LAN (like for your TV to play videos). Guest and DMZ probably also use port isolation, so that devices cannot talk among another.

That is not how VLANs work. You are mixing up different logical layers. Simply put, you cannot control which VLAN a client is on by assigning it an IP address that is associated with a VLAN - that is too late.

Essentially, VLANs are a form of complete separation via different "rails", either by having a network client select its rail itself by static configuration if a physical switch port carries multiple VLANs ("trunk port") or by assigning the switch port to a specific VLAN in the first place. Those decicions are static and take place before DHCP kicks in.

DHCP is handled on a specific VLAN already, so logically, you have one DHCP instance for every VLAN. Theoretically, you could assign every VLAN the same IP range, but those are completely separate networks. The main reason not to do this is that normally, you want to route between the VLAN networks.

The only way to dynamically select a VLAN for a client is using 802.1x or MAC-based VLAN assigment on the switch itself. In that case, the switch can dynamically assign a port to one of the available VLANs.

DHCP has no control there, it simply hands out addresses from IP ranges that are available on specific logical interfaces. Which of those logical interfaces the client connects to is handles way earlier.

I actually have not tried ranges, but if more than one port was in a single NAT rule, reflection did not work for me.

The concept of a firewall put "in front" of a router is valid for corporate networks where you have multiple external IPs and in the intranet, you need additional routing for segmentation of broadcast domains. That type of firewall is a kind of perimeter defense that mostly regulates incoming traffic to some exposed IPs.

In a small business / private networking context, you mostly have just one external IP, such that you need NAT anyway such that everything on your intranet hides behind that one IP. Thus, the rules on the firewall before a NATing router apply to just connections between this IP and the internet - you cannot discriminate between different clients on your internet apart from the port. In this scenario, the firewall could not really do very much useful.

The alternative would be to let the firewall do NAT (and firewalling), but in that case: what does the router then do anyway? Separating into different VLANs is possible in Opnsense as well.

So, I can see no real purpose for the additional router, because Opnsense can handle everything.

There are people who vote for the opposite: Placing a router before Opnsense. That CAN become neccessary if your ISP has a locked-down router and does not give you the means to build up the connection yourself and you don't trust the ISP so that you have an additional firewall to protect your intranet. If at all possible, I avoid that because of additional complexity (and power draw).

Es macht für manche Listen schon Sinn, RFC1918 zu enthalten, z.B. wenn es um Verbindungen vom WAN zum LAN geht - da will man das ja gerade.

Ansonsten ist auf jeder Seite doch genau erklärt, aus welchen Quellen sich die List speist, wie viele IPs da drin sind, wie hoch die Retention Time ist, wie sich die über die Welt verteilen.

Yes. Pretty much so. The definitions on the switch and firewall interfaces should match. As I said, you might as well LAGG the ports and use the LAGG as the basis for your VLANs on both the switch and the firewall - provided the switch supports that.

In that case, the LAGG is logically an interface which offers larger bandwidth and provides uniform accesss to VLANs, much as a single interface. You can simply layer this.

Exakt. Bei Firehol muss man sich sehr gut anschauen, was man blockt. Ich verwende z.B. https://iplists.firehol.org/?ipset=firehol_level3. Die verschiedenen Listen mit ihrem Inhalt sind links aufgeführt. Speziell mit Listen, die auch RFC1918-Bereiche enthalten, muss man vorsichtig sein.

Sure. If you have enough interfaces available, you can spread the VLANs over muliple interfaces. Say, if you have two VLANs, you could have each one on one port. If you have only one WAN, you could spread 3 VLANs over the 3 remaining ports if your appliance has 4 of them. Or you could have your main LAN on a physical port whereas a guest and IoT VLAN share another port.

Another possibility is to use link aggregation to the switch if it has the capability.

Apart from that, many devices nowadays offer more than 1 GBit bandwidth - e.g. 2.5 GBit. Alas, the Deciso boxes do not offer this (other than using a special SFP+ transceiver on the DEC750 or 850).

If you use 1 GBit, remember that when you use multiple VLANs on the same interface, the bandwith is shared between them, such that routed inter-VLAN traffic passes the interface twice. Which is why I prefer higher bandwith for local interconnections.

Zu 1: Was das Aussperren angeht: Es gibt eine Anti-Lockout-Regel, die genau das verhindern soll.


Zu 2: Das hängt davon ab, was Deine Regeln verbieten. Du kannst ja z.B. alle Zugriffe auf die Firewall selbst erlauben und alle Zugriffe ins Internet verbieten. Damit würden Firewall-Dienste wie DNS, DHCP, NTP usw. weiter funktionieren.

Zu 3: +1 wegen der portbasierten Regeln ins Internet... die würde ich mir auch sparen:
- Du administrierst Dich zu Tode
- Was bringt's? Wenn eine Malware "nach Hause telefonieren" will, kann sie das jederzeit auch über "empfohlene" Ports wie 443 o.ä. tun. Das wird sie auch, weil sie das dann verschlüsselt tun kann.
- Es ist interessanter, Zugriffe von / auf bekannte böswillige Ziele auszuschließen, z.B. mit Firehol (https://iplists.firehol.org/). Den Rest übernimmt der Virenscanner auf Deinen Client-PCs.

I cannot say for the DEC695, but for the DEC750, I can reach 3 GBit/s on a single 10 GBit Interface. I assume that the 1 GBit can easily be saturated on the DEC750 and that is probably what you ask because the DEC695 does not have 10 GBit in the first place.

Considering the negligible price difference between the two, I would always choose the DEC750.