Messages

I have an update:

Turns out this hack doesn't hold up -- any time interfaces are brought up/down, routing conflicts get in the way and can cause confusion and connectivity failures.

However, I did manage to get things going with a small modification:

* Use a subnet mask of /23 for the "dummy" VLAN interface.
* leave the static route in place with the smaller /24 mask.

Notes:

* Ensure your DHCP pool ranges are confined to the /24 (e.g., even though the "available" range for my 10.0.80.0 network shows "10.0.80.1 - 10.0.81.254", ensure your pool addresses don't exceed the range covered by the corresponding static route.
* The upper-half of the /23 subnet is effectively wasted, but make sure it doesn't conflict with a different subnet. If you give each subnet some breathing room, this shouldn't be a problem.

With this change, the configuration has been stable for almost a month, and has survived a couple reboots and interface reconfigurations.

Let me know if it works for you, or if I'm going to be sorry for doing this down the line... ;)

[10.0.200.0/24]

I came up with a workaround for this. It seems to work, but I'd be happy for anyone to tell me why I shouldn't do this. (apart from it being a somewhat gross hack, of course  :P)

For a while, I dropped a file in /usr/local/etc/dhcpd.opnsense.d/ containing my various subnet definitions. This worked, but has pretty poor UX -- adding static leases required editing the file instead of using the web-based config UI.

TL;DR -- create dummy VLAN interface in OPNsense for the express purpose of hanging DHCP configuration off of it. Carefully configure static routes to ensure reverse traffic flows correctly.

The setup: I've got an OPNsense gateway/firewall upstream from an L3 switch. I'd prefer to keep all of the routing between VLANs on the switch, for performance and resiliency, so am routing to/via the gateway via a single TRANSIT VLAN.

The TRANSIT VLAN ID is 200, and the subnet is 10.0.200.0/24. 10.0.200.2 (configured on my OPNsense router/firewall) is the upstream default gateway from my L3 switch. Traffic between VLANs is handled purely on-switch. Anything else is sent upstream to 10.0.200.2.

My L3 switch has 10.0.200.1 assigned as its address in the TRANSIT VLAN. In OPNsense, I configured a gateway (sw-core) pointing at 10.0.200.1 (for use in static-route configuration) to direct traffic back at the L3 switch as needed.

When adding a new VLAN, I went for a different approach. For this example, I'm setting up VLAN 80 with associated subnet 10.0.80.0/24:

1) Configure and enable a VLAN Interface in OPNsense for ID 80.

     * Subnet: 10.0.80.0/24
     * Static IPv4 address: 10.0.80.2 (10.0.80.1 is the router IP on my L3 switch)
     * The static IP assigned here should not be used for anything -- it's only needed to allow configuring DHCP service in the associated subnet.

2) Importantly, don't tag the uplink switchport for VLAN 80 -- it remains configured solely for my TRANSIT VLAN (which happens to be 200).

3) Configure a static route in OPNsense for 10.0.80.0/24. Assign sw-core as the gateway.

4) Configure DHCP service for your freshly configured VLAN 80 interface.

5) Configure my L3 switch to use 10.0.200.2 as a DHCP helper, so requests are relayed to OPNsense. In my case, I'm using a Ruckus/Brocade ICX series switch. Of course, this piece will vary depending on the switch vendor and software version. My config looks like this:

Code Select Expand


vlan 80 name DEMO by port
tagged ethe 1/1/14 to 1/1/18
router-interface ve 80

interface ve 80
ip address 10.0.80.1 255.255.255.0
ip helper-address 1 10.0.200.2



NB:

This explicitly goes against the warning in the OPNsense route configuration page:

Do not enter static routes for networks assigned on any interface of this firewall. Static routes are only used for networks reachable via a different router, and not reachable via your default gateway.

Additionally, once you have configured a static route for a given subnet, OPNsense will not let you alter interface configuration with a conflicting IP/subnet assignment. It is not enough to disable the static route -- you have to delete it, change your interface configuration, then re-create the static route.

In case it's not clear, you must configure the "dummy" VLAN interface prior to the associated static route. (the other way around is rejected by the interface configuration page.

Finally, while this appears to work correctly for me, so far, it may be cause problems with more complex routing or firewalling scenarios. (or just problems I haven't noticed yet, of course!)