Messages

1

21.1 Legacy Series / Re: Cannot enable jumbo frames on vlan interfaces.

« on: August 03, 2021, 07:38:12 pm »

I have the same problem. The physical NIC can be set to MTU 9000 fine, but the child VLAN interfaces can't. The GUI remembers the 9000 just fine, but when I check assignments (or via ssh: ifconfig), the MTU of the vlan interface is set to 1500.

I'm running 21.7, btw

2

20.1 Legacy Series / Re: In/out firewall rules misunderstanding

« on: June 25, 2020, 02:12:18 pm »

Ok, I found out there was an error in my thinking. I figured I should give people an update.

My "beef" wasn't with the difference between iptables vs pf or something (actually have several FreeBSD boxes with manually managed pf firewalls), but with the fact that I usually only manage servers, not routers. So then it makes sense that in and out would be reversed.

I.e. incoming traffic for my server of my (V)LAN would be considered outgoing traffic for the router. And vice versa.

3

20.1 Legacy Series / In/out firewall rules misunderstanding

« on: June 24, 2020, 07:08:43 pm »

Hello,

I'm busy partitioning my network into VLANs. I started by allowing all traffic between the VLANs and am now starting to pull up walls between them. I'll give a simple example as to the source of my confusion:

Say I have 2 VLANs: 10 and 20. Both are set up as normal LAN interface with their own subnet and DHCP enabled. The subnet is 10.10.10.0/24 and 10.10.20.0/24, respectively.

OPNsense hands out the proper IP and internet access works. I can also reach resources on all subnets, regardless of VLAN, so it's safe to assume I didn't misconfigure my switches (which are managed L2 only).

My confusion is here: what I want is to deny all traffic from VLAN 20 to VLAN 10. VLAN 10 is allowed to access VLAN 20, however.

So I figured I should make a top rule with the following specs:

Action: reject
Quick: true
Interface: vlan_10
Direction: In
Source: vlan_20 net
Destination: *

The rest is all default

However, I could still reach VLAN 10 from VLAN 20. I even tried changing source to *. And I set an opposite rule with the following specs:

Action: reject
Quick: true
Interface: vlan_20
Direction: Out
Source: *
Destination: vlan_10 net

To no avail.

Then I found out that if I switch the direction in any rule from Out to In or vice versa, it does exactly what I want it to. Setting a reject rule for "in" traffic also blocks internet access and access to all other subnets through that interface, even though all "out" traffic has been whitelisted in an earlier rule.

What am I missing here? It seems that OPNsense does connection tracking, so stateless rules aren't necessary. Is my background in Linux/iptables playing tricks on me? What I want is the equivalent of:

Code: [Select]

iptables -i vlan10 -A INPUT -s 10.10.20.0/24 -j REJECT
and

Code: [Select]

iptables -o vlan20 -A OUTPUT -d 10.10.10.0/24 -j REJECT
Any help is appreciated!

4

20.1 Legacy Series / Re: VLAN+dhcp won't work

« on: June 13, 2020, 07:35:10 pm »

No, IDS/IPS has been fully disabled. Basically it's a clean setup with only a WAN, bridge and a VLAN configured.

5

20.1 Legacy Series / Re: VLAN+dhcp won't work

« on: June 13, 2020, 02:05:00 pm »

I had a problem with getting a DHCP lease on a VLAN and it was related to the Intrusion Detection service. With the Intrusion Detection service enabled devices connecting on a network associated with a VLAN couldn’t get a DHCP lease. With the Intrusion Detection service disabled they could. I didn’t want to disable the Intrusion Detection service so I eventually found that I could leave it enabled if I disabled VLAN Hardware Filtering (Interfaces->Settings->VLAN Hardware Filtering=Disable VLAN Hardware Filtering).

Whoah! This solved the problem for me! Thanks! I never would have found this out by myself!

I don't have IDS enabled (yet), but disabling VLAN HW Filtering solved my problem.

I do still find it unfortunate that I can create a VLAN interface with a bridge interface as parent. Well I can, but then it doesn't get a 802.11q tag so it never works. I don't see a reason why this shouldn't technically be possible so I see this as a OPNsense shortcoming tbh.

But creating VLANs for every physical interface and then bridging said interfaces into a vlan10_bridge works fine.  It's just a bit more work and fairly clunky to manage.

6

20.1 Legacy Series / Re: VLAN+dhcp won't work

« on: June 13, 2020, 01:23:42 pm »

Just completed testing here - working fine.


Did you select one the physical ports as the parent for the VLANs or the bridge interface?


The VLANs need to be attached to the physical interface, not the bridge interface.

I checked the entire list. In addition I made sure all physical and VLAN interfaces allow all incoming and outgoing traffic. All physical interfaces have been configured without ipv4 or ipv6 configuration.

The parent interface for the VLAN is igb1, so a physical NIC.

7

20.1 Legacy Series / Re: VLAN+dhcp won't work

« on: June 13, 2020, 07:57:53 am »

OK, I see. I do it in a different way.


It's much simpler just to put an un-managed or managed switch directly after the Qotom in the 'Fuse Box Closet', then you just 'trunk' everything out of a single port on the Qotom to that switch and then onto the other switches; you can then use a separate port on the Qotom for the cable modem management. Doing it that way reduces the CPU load on the Qotom,


I also run multiple VLANs and have a connection to the modem for monitoring purposes. I've never tried using bridge mode with VLANs, but I'll run it up on my test Qotom and see what gives, but  I would still suggest doing it the way I do it.

Thanks for you quick replies, but I don't think that that will solve my problem. I've basically already tried it by just creating the VLAN interface with igb1 as parent interface rather than bridge0. But it still won't answer DHCPcd/dhclient request.

I do see via SSH that it does have a vlan tag now though:

igb1_vlan10: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
   ether 40:62:31:0b:7a:61
   inet6 fe80::4262:31ff:fe0b:7a61%igb1_vlan10 prefixlen 64 scopeid 0xc
   inet 10.0.10.1 netmask 0xffffff00 broadcast 10.0.10.255
   nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
   media: Ethernet autoselect (1000baseT <full-duplex>)
   status: active
   vlan: 10 vlanpcp: 0 parent interface: igb1
   groups: vlan

8

20.1 Legacy Series / Re: VLAN+dhcp won't work

« on: June 13, 2020, 07:54:36 am »

I've logged in through SSH to inspect see various odd things.

First of all, I don't appear to have a /etc/dhcpd.conf, even though the process specifies that config file:

/usr/local/sbin/dhcpd -user dhcpd -group dhcpd -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid bridge0 bridge0_vlan10

In addition, the tag on my VLAN interface doesn't seem to have been set properly?

bridge0_vlan10: flags=8003<UP,BROADCAST,MULTICAST> metric 0 mtu 1500
   ether 00:00:00:00:00:00
   inet6 fe80::4262:31ff:fe0b:7a60%bridge0_vlan10 prefixlen 64 tentative scopeid 0xc
   inet 10.0.10.1 netmask 0xffffff00 broadcast 10.0.10.255
   nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
   vlan: 0 vlanpcp: 0 parent interface: <none>
   groups: vlan

9

20.1 Legacy Series / Re: VLAN+dhcp won't work

« on: June 13, 2020, 07:26:04 am »

Sure, but it's quite simple.



The dotted lines are tagged VLAN connections. The solid lines are physical cat6 cables. I know bridging happens in software and a switch can dedicate itself to switching at line speed, but hey, my OPNsense box is a relatively new i5, so it should be able to both route and bridge at Gigabit speeds (and it does).

What I'm trying to do is to get 10.0.10.2 and 10.0.10.3 replaced by a 10.0.10.x ip through DHCP. Because whilst in the current situation with tagged VLAN ports and static addresses, it works perfectly well, this won't be the case when I buy a VLAN aware UniFi switch which also connects IoT devices. This PoC is basically in preparation for my wireless also going VLAN.

10

20.1 Legacy Series / VLAN+dhcp won't work

« on: June 12, 2020, 10:40:03 pm »

Hello!

Recently I've decided to buy a mini PC to use as a router, with OPNsense on it. It's a Qotom with 6 i211 Intel NICs. Setting up routing, bridging, NAT and DHCP was a breeze. I'll try to explain what I have, what I want and what I tried:

What I have
- cable modem in bridge mode
- OPNsense box with 1 WAN interface in DHCP
- bridge0 created out of all interfaces (including WAN, because the modem has a web interface to monitor Docsis signal values) with subnet 192.168.0.1/24 and DHCP enabled. All LAN interfaces are set to enabled but have no configuration. In the firewall settings, I've allowed all in and out traffic for now.
- 2 ports are connected to two different Ubiquity EdgeSwitch 10X switches.
- My Linux NAS is connected to one switch and has an untagged default VLAN with a static IP in 192.168.0.1/24.
- In addition, it has a VLAN interface, let's say eth0.10 with 802.1q tag 10. The EdgeSwitch is set up to accept tagged VLAN 10 frames to and from this port. It has a static ip 10.0.10.2/24 on this interface
- The other EdgeSwitch has an almost similar Linux HTPC connected with a static IP in 192.168.0.1/24 and a VLAN 10 interface with a static ip 10.0.10.3/24.

I can ping and connect to various TCP ports from 10.0.10.3 and 10.0.10.2, so it works. I also set up a tagged VLAN 10 interface on my Macbook and this also works (wired). This also already worked before I bought the OPNsense box and everything was still connected to my ISP's modemrouter in router mode. This situation still works with my OPNsense box.

What I want
- A DHCP server for VLAN 10 for 10.0.10.0/24

What I tried
- Create a VLAN with tag 10 and parent interface bridge0
- Assign the new interface and set a static ipv4 of 10.0.10.1/24
- Apply the interface changes
- Enable the DHCPd4 service for the interface vlan_10 with a range of 10.0.10.100-10.0.10.200
- Apply the dhcpd changes
- Allow all traffic in and out the vlan_10 interface in the firewall.
- Apply firewall changes

Yet when execute sudo dhclient -v eth0.10 on either box, it won't get any kind of response. It just keeps doing a DHCPDISCOVER on an increasing interval until it gives up.

Does anyone have any idea what I've omitted/forgotten/misconfigured? Any help would be appreciated!