Suricata inline issue with VLAN



  • Hi,

    Config :
    Pfsense 2.4.5-rc (in KVM on proxmox host with Virtio interfaces)
    Suricata inline mode

    At this moment I had setup 4 interfaces with VLAN tag managed on hypervisor. With this setup I need to set 5 suricata instances (one by interfaces, 1 WAN and 4 LAN). I host a server behind pfsense and VPN with Pfsense so suricata is set on WAN, and I wish to have detail on which host generate alert so I also enable suricata on each LAN interfaces.

    I would like to change this setup with only 2 interfaces WAN and LAN and then manage VLAN with pfsense. With this setup I will be able to set only 2 instances of suricata, one on WAN et other one on LAN (without VLAN tag). With promiscious mode suricata will be able to check all VLAN interfaces easily.

    WAN (<- Suricata)
    LAN no tag (<-Suricata promiscious mode)

    • VLAN1
    • VLAN2
    • VLAN3

    I tried this setup but I'm facing an issue, when I enable suricata, VLAN are broken!
    Host is able to set IPv6 for all VLAN subnet, IPv4 DHCP and connectivity are borken. It seems VLAN tags doesn't work. If I disable suricata, everything works good.

    Maybe I made a mistake in configuration, does I need to set something to make suricata works on primary interfaces or is it a real bug?

    Thank you for your help.


  • LAYER 8

    change the virtio interface driver, intel is more likely to work



  • Virtio is more performant than intel e1000 emulation and have netmap native support

    I guess I need to try to test with intel NIC to check if I can reproduce this bug.



  • Netmap does not support VLAN tagging in most configurations. Here is a link to a recent FreeBSD bug report with some explanations: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236219. Inline IPS Mode in Suricata uses the netmap kernel device.



  • @bmeeks said in Suricata inline issue with VLAN:

    Netmap does not support VLAN tagging in most configurations. Here is a link to a recent FreeBSD bug report with some explanations: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236219. Inline IPS Mode in Suricata uses the netmap kernel device.

    Thank you, hope this will be fixed in FreeBSD 12 and the new netmap implemenation. I suppose I will keep my configuration until Pfsense 2.5 reach rc release and give another try to reduce suricata instances.

    @bmeeks : based on my description could you confirm in my case running suricata on every interfaces WAN and LANs is usefull ?



  • @Le_Bleu said in Suricata inline issue with VLAN:

    @bmeeks said in Suricata inline issue with VLAN:

    Netmap does not support VLAN tagging in most configurations. Here is a link to a recent FreeBSD bug report with some explanations: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236219. Inline IPS Mode in Suricata uses the netmap kernel device.

    Thank you, hope this will be fixed in FreeBSD 12 and the new netmap implemenation. I suppose I will keep my configuration until Pfsense 2.5 reach rc release and give another try to reduce suricata instances.

    I don't think this fundamental issue with VLANs is going to be addressed anytime soon. I think it's a sort of "philosophy" thing among the kernel developers. But I have no secret insight, so who knows? Maybe some changes will be made as FreeBSD matures.

    @bmeeks : based on my description could you confirm in my case running suricata on every interfaces WAN and LANs is usefull ?

    I generally don't recommend putting an IDS/IPS on the WAN because of NAT. Suricata on the WAN lives directly between the NIC driver and the kernel network stack, and as a result sees outbound packets after NAT has been applied and it sees inbound packets before NAT is removed. This means all LAN host traffic shows up under the WAN IP address. So when chasing an alert and trying to find what host generated the alert, you can't easily do that because all alerts show local hosts as being the WAN IP address.

    However, when you run Suricata on a LAN, it sees local host traffic with the actual host address. Thus it is much easier to find infected hosts. There is really no compelling reason to run Suricata on the WAN unless you have sensitive public-facing services (web server, DNS, mail server, etc.) with servers sitting on your WAN IP.



  • @bmeeks said in Suricata inline issue with VLAN:

    However, when you run Suricata on a LAN, it sees local host traffic with the actual host address. Thus it is much easier to find infected hosts. There is really no compelling reason to run Suricata on the WAN unless you have sensitive public-facing services (web server, DNS, mail server, etc.) with servers sitting on your WAN IP.

    I do have public-facing services (web server, mail server, etc.) but servers are behind NAT on LAN1, so packet i checked twice on WAN and LAN.
    I decided to run Suricata on WAN to protect OpenVPN, only one service running directly on Pfsense and not cover by suricata on LAN interfaces.
    Is Suricata good to protect OpenVPN ? If not I suppose I can stop running it on WAN.



  • @Le_Bleu said in Suricata inline issue with VLAN:

    @bmeeks said in Suricata inline issue with VLAN:

    However, when you run Suricata on a LAN, it sees local host traffic with the actual host address. Thus it is much easier to find infected hosts. There is really no compelling reason to run Suricata on the WAN unless you have sensitive public-facing services (web server, DNS, mail server, etc.) with servers sitting on your WAN IP.

    I do have public-facing services (web server, mail server, etc.) but servers are behind NAT on LAN1, so packet i checked twice on WAN and LAN.
    I decided to run Suricata on WAN to protect OpenVPN, only one service running directly on Pfsense and not cover by suricata on LAN interfaces.
    Is Suricata good to protect OpenVPN ? If not I suppose I can stop running it on WAN.

    Suricata is not really useful for OpenVPN traffic as it is encrypted. Suricata will see the VPN traffic directly off the NIC before it is decrypted. For your setup, even with those handful of public services, I would put the IDS/IPS on the LAN side so that I can see the actual addresses. This is particularly true ince you are using NAT port forwarding.



  • Thank you for your help.


Log in to reply