VLAN DHCP Issue with IPS Enabled

[youngnicks]

OPNsense version 19.1 Suricata version 4.1.2

VLAN clients are unable to obtain an IP address via DHCP when IPS is enabled on the parent interface. It doesn't matter if IPS is enabled on the VLAN interface or if Promiscuous mode is enabled. Once IPS is disabled on the parent interface, clients quickly connect to VLAN. Looking at the logs, it appears that VLAN clients are trying to be assigned an IP from the parent interface when IPS is enabled on the parent interface.

[AdSchellevis]

could be driver related. which network card are you using? and what does the setup look like.

[youngnicks]

System is a Protectli Firewall Micro Appliance With 6x Gigabit Intel LAN Ports, AES-NI, i3, 4GB RAM, 32GB mSATA.

• Intel® Dual Core i3 7100U, 64 bit, 2.4GHz, 3MB Smart Cache, Intel® AES-NI hardware support
• 6x Intel® Gigabit Ethernet NIC ports
• 4GB DDR4 RAM, 32GB mSATA SSD
• 4x USB 3.0, 1x RJ-45 COM, 1x HDMI

Wifi is provided via Ubiquiti UAP-AC-Pro. Everything was working while using pfSense and IPS enabled.

There are 3 VLANs running all on the LAN network. Everything works fine with IPS enabled on the VLANs, but when IPS is enabled on LAN (parent interface) DHCP for VLANs breaks.

[youngnicks]

Network card is: vendor = 'Intel Corporation' device = '82583V Gigabit Network Connection'

[AdSchellevis]

dhcp client on a vlan? could be a specific issue with 82583V and netmap, pfSense might have been in ids mode using a firewall table to drop traffic (not inline mode)

[youngnicks]

I have a workaround by putting everything on a VLAN and not run IPS on the parent, but I don't think that should be the permanent solution.

[fichtner]

This will probably work for you: https://forum.opnsense.org/index.php?topic=11477.0

[youngnicks]

I tried installing the updated kernel, but it did not seem to help. Another strange, possibly related, issue has been happening over the past couple weeks now as well. Every morning I have to reboot OPNsense to get DHCP and possibly other services working. I'm unable to even access the firewall without a reboot.

I'm willing to help do some investigation for a little while, but ultimately I need a stable firewall which doesn't require reboots.

[youngnicks]

I switched the pattern matcher to Hyperscan and no longer need a daily reboot. I am still unable to enable IPS on my LAN network without breaking the VLANs using it as a parent.

[fichtner]

DHCP on WAN has this issue to be fixed in 19.1.2 soon: https://github.com/opnsense/core/issues/3197#issuecomment-463988437

[youngnicks]

I installed the update and tried enabling IPS on the parent interface again. At first I thought it was working, but it must have not fully been applied yet as it shortly stopped working. Disabling intrusion detection on the parent interface restored my ability to connect to wifi.

[Deutschi]

Just wanted to let you know that the described issue, but with DHCP for VLAN on a LAN parent, also does not work for me right now with OPNsense 19.1.8 and Suricata 4.1.4_1. Disable IPS on parent interface is still a workaround, but not ideal.

[ghost]

Still not fixed in 19.1.10

[fichtner]

Yes.

[ghost]

same here with broadcom 10GBE adapters. intrusion detection without vlan support doesn't make any sense...

[tunip]

Same issue here with an Intel NIC on 19.7.2. So no working IPS in such scenario. Sensei works fine with interfaces where VLANs are configured...

[breucode]

I have the same issue with an Intel I210-AT on 19.7.4.

[bf8392]

Same issue

[AdSchellevis]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.

[youngnicks]

@AdSchellevis The issue is still ongoing and several people have recently mentioned that it is ongoing for them. I feel like this is a complex issue that will be hard for community support to achieve. Yes, there is a workaround, however, it is not an ideal solution. I think the ticket should be kept open until the issue is actually resolved.

[AdSchellevis]

@youngnicks sorry, we have to be firm here, we decided to automatically close these issues for valid reasons. Managing these issues cost a lot of our time, which doesn't really make sense as long as no one is really working on it. We can always reopen issues if someone is willing to do the work needed, we just can't afford reading through these issues on every release in the hope that someone else will eventually step up.

You can always use the forum to discuss possible solutions, work with others to propose solutions and give it another try when things change in the future.

[youngnicks]

@AdSchellevis That is totally understandable. I would suggest possibly adding a label to this ticket to specify that it hasn't been successfully resolved even though it is closed. That would help with future questions on this issue still remaining and yet the ticket is closed. It would also make it easier to find closed yet unresolved tickets for future projects.

[AdSchellevis]

@youngnicks we'll have to discuss that internally, personally I don't mind adding a tag named "timeout" to these tickets, but I expect quite some support tickets will receive one in that case (lately about 80% of the tickets is support related).

Thank you for your understanding, I'll get back to you about the tag question.

[youngnicks]

Conversely, you could leave the tickets open and put a timeout label on them. Just make it a procedure that you don't talk about timeout tickets in your meetings. It would signal to the community that they are still an issue, but you aren't actively working on them.

[AdSchellevis]

eventually they have to be closed, so we'll keep the procedure but might add a label as suggested.

[ghost]

Just adding one comment from my side: for me as an admin using OpnSense, it doesn't matter if it is closed or timed out - it is still unresolved and an issue in production. Having VLAN's, DHCP and IPS is a majority to separate and secure networks. Instead of talking about how to close the ticket, it would be more helpful for all who are experiencing the same issue to check why it happens and how it could be resolved in future releases. For me it seems that nothing happened in the past 9 months. In my opinion, it should be a principle to make software better and more robust and working on new features in parallel.

[fichtner]

it is still unresolved and an issue in production

Nobody claimed otherwise. The team is small and efforts to resolve things outside the scope building a security "distribution" the main ingredient is time, which in some form or another translates to outside help or changes elsewhere in the ecosystem that will finally resolve those issues.

Apart from that, nobody claimed projects and products you find out there--free or otherwise--are prefect in every sense of the way. A bit of wisdom one of my favourite teacher was that if you see something that hasn't been done yet it's an opportunity to do it yourself.

So circling back we do not sit idly waiting for time to pass by in order to be able to close tickets this one way. We always have and will close tickets that resolve real world issues. We just can't promise everybody will end up with the same experience.

If you want to read more about the changes we've done take a look at https://github.com/opnsense/changelog -- maybe you'll find something of value there of the past couple of years that you already whole heartedly enjoy. :)

Cheers, Franco

[AdSchellevis]

@youngnicks we've discussed the tag, since we already have a "help wanted" tag, we're going to use that for timeouts as well.

[mdrichardson]

Just chiming in to say that I'm experiencing this as well with an Intel i350-4t.

[ternium1]

Hello, experiencing the same issue with an HP523SFP NIC (10GbE) and Opnsense 22.7.9. However, I'm noting that during a boot, the DHCPv4 server works for a few moments (probably when suricata is not started yet), and then the leases are marked as offline. Does anyone has managed to find a workaround or a fix?

[loxK]

I have the same issue.