Hi there,
I am experiencing an issue that my VLANs can't communicate.
I have vlan020.1, vlan020.2, vlan050.1 and vlan050.2 on two interfaces igb2 and igb3.
I have bridged vlan020.1 and vlan020.2 and assigned the bridge 192.168.20.1/24
I did the same for vlan050.1 and vlan050.2 and assigned the bride 192.168.50.1/24.
The hosts in the VLAN20 net and VLAN50 net can talk withing their vlan and communicate over the gateway to the internet.
However I am not able to create rules to let them communicated from say 192.168.20.100 to 192.168.50.102.
I have created two firewall rules:
PASS in VLAN20 IPv4 * VLAN20 net * VLAN50 net * *
PASS in VLAN50 IPv4 * VLAN20 net * VLAN50 net * *
Am I doing something wrong here, is this an issue because of the bridged interfaces?
Thank you in advance.
Placing the VLAN subinterfaces in the bridge interfaces is absolutely the correct and only way to do it. Two possible causes of things "not working as expected":
- Interfaces: Assignments - you did assign the bridge interfaces to the symbolic names used in rules like "VLAN20"?
- System: Settings: Tunables - there are two mandatory tunables that must be set to turn OPNsense into a "switch" like you are trying.
Refer to the documentation, step six:
https://docs.opnsense.org/manual/how-tos/lan_bridge.html
Reboot afterwards.
HTH,
Patrick
[VLAN20_MAIN] vlan020.1 (Parent: igb3, Tag: 20)
[VLAN20_ALT] vlan020.2 (Parent: igb2, Tag: 20)
[VLAN20] bridge1()
[VLAN50_MAIN] vlan050.1 (Parent: igb3, Tag: 50)
[VLAN50_ALT] vlan050.2 (Parent: igb2, Tag: 50)
[VLAN50] bridge4()
This is the interface setup. When I created the firewall rules I used 'VLAN20 net' and 'VLAN50 net'.
Thank you for the hint with the Tunables. I had set 'net.link.bridge.pfil_member' but I did not have set 'net.link.bridge.pfil_bridge'.
Unfortunately the issue still persists. I did also do the reboot of course.
I did attach two pictures of the firewall rules I created, maybe I am doing something wrong there?
For a rule on interface VLAN50 the source should be "VLAN50 net" and the destination "VLAN20 net". You got that the wrong way round. The second screen shot looks ok.
I though I need an incoming rule on VLAN50 as well. I only want VLAN20 to be able to open connections to VLAN50, not the other way around.
Though still no luck. Could this be a hardware issue with the Intel I350 I am using? Maybe another idea, I have set NAT to manual, but from what I understand I do not need NAT ruled for one vlan to talk to another vlan, right?
If all devices in the two VLANs have the OPNsense IP address as their default gateway you do not need NAT.
So it's time for a packet trace on one interface at a time to watch what's going on. Also enable logging for the default deny rule in Firewall: Settings: Advanced and use the firewall live log.
Thank you I figured it out with your hint about the gateway.
Previously this setup would not work because I had not set the second tunable rule to allow filtering on the bridge interface.
However while testing I set a manual route on the client for 192.168.50.1/24 go through the VLAN interface on the client, which apparently is wrong.
With the manual route it looked like this and did NOT work (route -n on 192.168.20.100) ...
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 0.0.0.0 255.255.255.255 UH 400 0 0 VLAN020
0.0.0.0 192.168.20.1 0.0.0.0 UG 400 0 0 VLAN020
192.168.20.0 0.0.0.0 255.255.255.0 U 400 0 0 VLAN020
192.168.50.0 0.0.0.0 255.255.255.0 U 400 0 0 VLAN020
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
Without the manual route on 192.168.20.100 it looks like this an works ...
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 0.0.0.0 255.255.255.255 UH 400 0 0 VLAN020
0.0.0.0 192.168.20.1 0.0.0.0 UG 400 0 0 VLAN020
192.168.20.0 0.0.0.0 255.255.255.0 U 400 0 0 VLAN020
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
For my understanding Patrick, can you explain to me why setting this route on the client failed while not setting a route at all works?
It works without a specific route because of the default route:
0.0.0.0 mask 0.0.0.0 gateway 192.168.20.1
Your specific route is missing the gateway. The gateway column is 0.0.0.0. So that route is leading nowhere.
But the mask is 255.255.255.0 so that route when it exists takes precedence of the default route. So you explicitly routed
192.168.50.0 mask 255.255.255.0 gateway "nowhere" (0.0.0.0)
HTH,
Patrick
Then I was confused by the GUI in Network Manager. I thought since the interface has gotten it's gateway (192.168.20.1) from the DHCP server and I added the route 192.168.50.1/24 to the interface it would route traffic destined for the 192.168.50.1/24 subnet over the 192.168.20.1 gateway as well.
Thank you for helping me with this, I was pulling my hair out the entire afternoon yesterday.