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?



  • Hey there, before I move the clients from the existing LAN to the "new" LAN, I checked why the client to which I had removed its static IP assignment from LAN and recreated to the new LAN wouldn't get a new IP from that subnet... I think it has something to do with my Procurve switch but I am not sure.

    See the attached picture. This is what I would like to have in the end.

    • A bunch of computers, printers, scanners connected to the LAN (VLAN100 subnet 192.168.0.1)
      The Unifi AP also connected to the LAN under same subnet (192.168.0.1)
      Untrusted Wifi guests connecting to the Unifi AP and getting an IP from pfsense under VLAN300 (subnet 192.168.2.1)
      Trusted guests connecting to the Unifi AP and getting an IP from pfsense under VLAN200 (subnet 192.168.1.1)

    If the attached picture makes sense, then its easy to understand how the computers and printers, etc will be attached to VLAN100, since the procurve switch will tag their ports with VLAN100... What about the Unifi AP? Do I need to connect it to a VLAN100 tagged port or do I leave it on a untagged port? (I think the Procurve switch has a basic VLAN called VLAN1 to which all 24 ports belong)...

    Right now the problem I have is a device connected to an untagged port on the Procurve switch is NOT getting an IP from VLAN100. My current configuration is identical to the picture minus all ports on the Procurve switch are "untagged"



  • Uploaded pic on another post since this forum is losing its mind (Post content was flagged as spam by Akismet.com).......

    network.png


Log in to reply