Snort interferes with traffic on VLAN - Known issue, any solutions?



  • Hello, I figured asking about this on this forum since there are a lot of knowledgeable folks. Here it goes:

    We have a pfsense box running snort on a physical interface to which a Wifi AP is connected. On this AP we have 2 LANs. One for known (trusted) devices, one for guests using a VLAN from pfsense.

    Known (trusted) guests are using the same subnet as the one where the AP is connected (sub 192.168.0.1) while the VLAN provides IP's to the untrusted (guests) devices (sub 192.168.2.1).

    Because our intention is to have the trusted devices "proctected" by snort, all works well having the trusted devices behind snort. The issue is for untrusted devices. Snorts operates in promiscuous mode and therefore sees the traffic between untrusted devices and the physical interface simply as tagged 192.168.0.1 traffic, and does not make distinction between VLAN and non-VLAN.

    This is basically making guests devices not working at all. Even with the basic set of rules (we tried balanced & connectivity), there's always someone complaining their device doesnt behave normally, pages not loading, etc..... We end up logging in pfsense to empty the blocked list or deactivating rules multiple times per day which is NOT acceptable (and certainly not a viable long term solution).

    Solution 1: Although not preferred, would be to purchase another Wifi AP and connect it to a different interface, but unfortunately, the pfsense box doesnt have another physical interface to connect to it.

    Solution 2: Another solution would be to get rid of snort altogether but that's even less preferable and would compromise all other subs.

    Anybody has a good solution that would involve simply reconfiguring pfsense and not purchase additional hardware?


  • Galactic Empire

    You can run snort on the vlans you want and not run it on the parent / untagged interface.

    So create another VLAN and don’t use the parent interface for trusted users.

    Screenshot 2019-06-03 at 19.08.42.png



  • Excellent idea! Thanks for this, I didnt know you could run Snort on VLAN tagged interfaces and not parent (underlying) interfaces... Very good to know!

    However, I am having a bit of pain to get rid of the existing LAN interface and migrate its clients to a new VLAN called "LAN"...

    Is there a way to easily migrate all static assignments to a new interface?

    What about the anti lockout rule? Its active on the LAN interface and doesnt seem to be a standard FW rule like my other rules (doesnt allow editing, etc...) which makes me believe the actual LAN interface has something special over other interfaces created after initial pfsense setup... Am I wrong?

    I deleted a client's static IP assignment from LAN and recreated it to a new VLAN interface called "LAN2" which uses the existing LAN interface (hardware em4) as its parent interface. However, after performing an IP renewal on the client, I realised it was not getting an IP from the new VLAN interface but was still getting an IP from the LAN interface even if its static assignment was deleted!!

    How's that possible? Do I need to restart the DHCP service after deleting a static assignment so it is "flushed" and no longer usable?


  • Galactic Empire

    @pftdm007 said in Snort interferes with traffic on VLAN - Known issue, any solutions?:

    Excellent idea! Thanks for this, I didnt know you could run Snort on VLAN tagged interfaces and not parent (underlying) interfaces... Very good to know!
    However, I am having a bit of pain to get rid of the existing LAN interface and migrate its clients to a new VLAN called "LAN"...
    Is there a way to easily migrate all static assignments to a new interface?

    You could backup the DHCP section and take a text editor to it.

    DiagnosticsBackup & Restore -> Backup & Restore

    If you do decide to use a text editor, have a look at notepad++

    https://notepad-plus-plus.org/download/v7.7.html

    What about the anti lockout rule? Its active on the LAN interface and doesnt seem to be a standard FW rule like my other rules (doesnt allow editing, etc...) which makes me believe the actual LAN interface has something special over other interfaces created after initial pfsense setup... Am I wrong?

    You need to recreate the anti-lockout rule for the interface you want to manage pfSense from, pfSense by default creates an anti-lockout rule on the LAN interface.

    I deleted a client's static IP assignment from LAN and recreated it to a new VLAN interface called "LAN2" which uses the existing LAN interface (hardware em4) as its parent interface. However, after performing an IP renewal on the client, I realised it was not getting an IP from the new VLAN interface but was still getting an IP from the LAN interface even if its static assignment was deleted!!

    Check the DHCP lease times, could be the device is in the wrong VLAN.

    How's that possible? Do I need to restart the DHCP service after deleting a static assignment so it is "flushed" and no longer usable?



  • All fixed now, have DHCP running on each VLANs with proper FW rules! Thanks @NogBadTheBad !



  • This post is deleted!

Log in to reply