WAN traffic graph not showing outbound traffic

stephenw10

Hmm, well that's odd!

I assume you're running Suricata on the WAN? What happens if you run it on LAN instread? That's usually preferred anyway as it gives you internal IP info.

Steve

pwnell

@stephenw10 Yes I am running Suricata in IPS on WAN, but as IDS on LAN. I always assumed it is better to stop the bad packets when they enter the WAN as opposed to when they have already had a chance to affect the firewall if you check it only on the LAN side.

johnpoz

@pwnell said in WAN traffic graph not showing outbound traffic:

When I disable Suricate IPS (Inline) mode the graphs all work fine

I'm going to move this to the IPS section, you prob get better traction there with people that have more exp with Suricata

stephenw10

It might be marginally better, especially in in-line mode, but the performance hit by running it twice on all traffic is far more significant IMO. You don't see traffic hitting the firewall itself of course so if you have services there open to the internet you might want it on WAN. Otherwise you are just scanning all the random traffic that is dropped by default anyway.

Steve

pwnell

@stephenw10 I have some port forwards - would that be protected equally well on the LAN side?

stephenw10

Yes Suricata would see that traffic on the LAN interface and it will see the actual public source IP and the internal destination IP. It would not see anything forwarded to localhost for example.

Steve

pwnell

This is strange. I changed WAN to IDS and LAN to IPS, now all graphs show inbound and outbound traffic. Why was only WAN affected? It is a different NIC - WAN is em and LAN is ix - does that make a difference?

stephenw10

It could do. The way Suricata uses netmap with different drivers could well tie in differently. That's outside my experience to be honest. @bmeeks may have more insight there.

Steve

bmeeks

Netmap is a NIC driver dependent thing. Suricata itself does not dictate how netmap works (or does not work). Netmap is a kernel device, and all Suricata does when running with Inline IPS Mode is just open the netmap device with an API call and start routing traffic to and from it using the same API calls. The FreeBSD kernel, the netmap device and lastly the NIC driver itself determine the specific behavior. My guess (and it is just a pure guess) is that the em NIC driver is not updating some kernel parameters during netmap operation while the ix NIC driver still updates those parameters when in netmap mode. I'm further guessing these kernel parameters would be those needed by the traffic graph application.

Inline IPS Mode in Suricata (and Snort on pfSense-2.5) seems to get blamed for a lot of stuff that is not really the fault of Suricata. The issues are with the netmap device itself, and that is a FreeBSD kernel responsibility along with the various vendors of network interface cards (NICs) and their associated NIC drivers.

pwnell

@bmeeks Thanks for the insight.