[Oisf-users] Suricata in-line af-packet appears to be messing with RADIUS from my APs

[Chris Boley]

net.bridge.bridge-nf-filter-vlan-tagged = 1
net.bridge.bridge-nf-pass-vlan-input-dev = 1


In debian based distros, these two sysctl flags need be enabled to allow
IPTABLES to read the 8021q tagged packets on the bridge > Push the data
into Suricata userland > make a decision and if not dropped will be pushed
back out onto the wire on the other bridge interface. If you don't have
these flags enabled, you're not truly scanning 8021q traffic. You'd only be
seeing untagged packets. At least that has been my experience. I can only
offer what I've seen in my fumblings with suricata on a dot1q tagged link.
I may be blowing smoke.  :)

I hope what I wrote helped.

On Tue, May 30, 2017 at 5:35 PM, Dylan B. Walter <
DBWalter at goodwilleasterseals.org> wrote:

> This message was sent securely using ZixCorp.
> <http://www.zixcorp.com/get-started/>
>
> Hi,
>
>
>
> First time poster here.  I have Suricata in-line running in af-packet mode
> using the binary packages in the apt repository, IP tables completely empty
> on Ubuntu 16.04, fully patched.  It sits between my router and switch on an
> 802.1q trunk.  All services work fine for wired clients on all 4 VLANs.
> Radius logons work to my cisco catalyst switch (UDP 1645 auth/1646
> accounting), but my Meraki WAP’s radius fails (UDP 1812-auth).  If I
> disable Suricata and flip my inline pair to a bridge it works just fine.  I
> considered that maybe it was just 1812 and switched the Meraki’s to use
> 1645, same behavior.  If I capture packets from the IPS, from the perimeter
> router, from the core firewall, and from the RADIUS server itself it looks
> the same:
>
>
>
> Access-Request WAP->Radius Server
>
> Access-Challenge Radius Server->WAP
>
> Access-Request WAP->Radius Server
>
> Access-Challenge Radius Server->WAP (fragmented and re-assembled)
>
>
>
> What’s weird is I see nothing in fast.log or drop.log referencing my AP’s
> IP, nor my Radius server so one would think that means it’s not acting on
> it, but the problem goes away when it’s bypassed.
>
>
>
> I can included sanitized config snippets if that’s helpful?
>
>
>
> On my inline pair I’m disabling the following features on each nic, 0
> being the “outside” 1 being the “inside”.
>
>
>
> # ETH0
>
> auto enp0s20f0
>
>         iface enp0s20f0 inet manual
>
>         up ifconfig $IFACE 0.0.0.0 up
>
>         up ip link set $IFACE promisc on
>
>         post-up ethtool -K $IFACE tso off
>
>         post-up ethtool -K $IFACE gro off
>
>         post-up ethtool -K $IFACE lro off
>
>         post-up ethtool -K $IFACE gso off
>
>         post-up ethtool -K $IFACE rx off
>
>         post-up ethtool -K $IFACE tx off
>
>         post-up ethtool -K $IFACE sg off
>
>         post-up ethtool -K $IFACE rxvlan off
>
>         post-up ethtool -K $IFACE txvlan off
>
>         down ip link set $IFACE promisc off
>
>         down ifconfig $IFACE down
>
> # ETH1
>
> auto enp0s20f1
>
>         iface enp0s20f1 inet manual
>
>         up ifconfig $IFACE 0.0.0.0 up
>
>         up ip link set $IFACE promisc on
>
>         post-up ethtool -K $IFACE tso off
>
>         post-up ethtool -K $IFACE gro off
>
>         post-up ethtool -K $IFACE lro off
>
>         post-up ethtool -K $IFACE gso off
>
>         post-up ethtool -K $IFACE rx off
>
>         post-up ethtool -K $IFACE tx off
>
>         post-up ethtool -K $IFACE sg off
>
>         post-up ethtool -K $IFACE rxvlan off
>
>         post-up ethtool -K $IFACE txvlan off
>
>         down ip link set $IFACE promisc off
>
>         down ifconfig $IFACE down
>
>
>
> Any help or advice would be greatly appreciated,
>
>
>
> Dylan
>
>
>
>
>
> -------------------------------------------------------------------------
> This message was secured by *ZixCorp <http://www.zixcorp.com>(R)*.
> _______________________________________________
> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
> Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20170530/4a4a17d0/attachment-0002.html>