[R7800] Deceived by WAN Port mirror to LAN port1

[HELLO_wORLD]

I prepared my SBC (odroid N2+) to do some IDS (and to spare the router to do any analysis).
I got a second ethernet port (USB3), connected it to the R7800 LAN1 and enabled the port mirroring (from debug page)
It works, and installing an IDS software on the SBC listening to second ethernet port, I do see all WAN traffic.

I noticed that the router is loosing performance when doing port mirroring (IDS active or not, it is irrelevant to the problem)… Not visible with netdata or top, but doing a Speedtest from the LAN to internet is usually 950/950 Mbps for me. When port mirroring is enabled, it drops to 940/730 Mbps, showing that port mirroring as a serious impact.

This is very deceiving, and I will abandon the IDS project for now. I will need to install a small hub between internet and the WAN port of the router (before the router then) to duplicate the traffic without impacting performances.

If there is a way to do a more efficient port mirroring from command line, I am interested…

 

[eibgrad]

Just my gut reaction.

I suppose "seriousness" is in the eye of the beholder. Personally, while a drop of about 24% on the upload side is non-trivial, this needs to be kept in context. The vast majority of the time is spent on the download side, NOT the upload side. There are exceptions, of course, such as occasional long uploads (e.g., YouTube content creator). But for most ppl, most of the time, I doubt anyone would notice a difference other than via the results of direct testing. IOW, there's a big difference between measured differences vs. perceived differences. And many times, it's the latter that has more impact.

Also, a loss of efficiency is not unexpected. These consumer-grade routers were only ever intended to do *one* thing efficiently; route packets. Everything else is a side-show. Even though we expect them to do other things which require acting as a client application, the fact is, they are routinely inefficient at it. Heck, look at the OpenVPN client and server. Or even running speedtest using the CLI. Relative to a desktop PC performing the same functions, they suck!

The OEMs are partially to blame here. They want to add bullet points to their marketing material, to make it seem their products are full-featured and capable of great feats. But they rarely provide the hardware to make that happen. As long as it works AT ALL, that's usually considered sufficient. Esp. given the competitive marketplace in which they dwell.

Bottomline, I don't see anything either unusual or unexpected here. In fact, I'm pleasantly surprised it works as well as it does (at least in terms of efficiency). I certainly wouldn't abandon the use of the mirroring feature based on what you've reported so far. But as I said, what is or isn't a serious impact may differ from user to user.

 

[HELLO_wORLD]

@eibgrad I totally agree on the router consumer market "lies". I only use my router to route and do some firewalling. All cloud and bells and whistles are worthless IMO.

However, I was expecting better for a simple switch function like port mirroring… I understand the mirrored port could have performance issues in the very rare case the WAN is used at full capacity and full duplex (2 x 1 Gb), or even that the performance of the mirrored port would not be perfect, but it is deceiving that this is affecting the performance of the main traffic…

The only way to enable the port mirroring is through the debug page. No options, no idea on how to do that (or tweak it) in command line.
I am looking of other ways, where I could "mirror" only part of the traffic (LAN and WLAN, so duplicating br0 to either one port or one address)
@Voxel is there a way to implement the ROUTE or TEE kernel module for iptables (netfilter) in your firmwares? I don't think they are present.

iptables duplicate traffic to another ip

This blog post has a template iptables rule to forward traffic, to and from the router to another ip address. iptables -t mangle -A POSTROUTING \ -d [IP to spy on] \ -j ROUTE –tee –gw [...

superuser.com

 

[Voxel]

@Voxel is there a way to implement the ROUTE or TEE kernel module for iptables (netfilter) in your firmwares? I don't think they are present.

ROUTE seems for me something strange. TEE: try SnapShot version (I did not test it, sorry).

Voxel.

 

[HELLO_wORLD]

ROUTE seems for me something strange. TEE: try SnapShot version (I did not test it, sorry).

Voxel.

Thank you !

I will test it this week.

 

[HELLO_wORLD]

I will test it this week.

ROUTE seems for me something strange. TEE: try SnapShot version (I did not test it, sorry).

Voxel.

You are a master: it works like a charm.
Thank you!

I will now have to test to mirror a lot of traffic that way to see how it impacts performance, but with this, I can fine tune what to tee.
It is definitely a nice feature to have in a router

 

[HELLO_wORLD]

Just tried with higher traffic and these quick and dirty rules:

root@HERMES:~$ iptables -t mangle -S POSTROUTING
-P POSTROUTING ACCEPT
-A POSTROUTING -o br0 -j TEE --gateway 192.168.0.xx
-A POSTROUTING -o brwan -j TEE --gateway 192.168.0.xx

I could see all the traffic teed to the device.

And then I ran the speedtest:

root@hestia:~# speedtest

   Speedtest by Ookla

     Server: LaFibre.info BBR - Massy (id = 2231)
        ISP: K-NET SARL
    Latency:    26.71 ms   (0.03 ms jitter)
   Download:   965.83 Mbps (data used: 1.1 GB )                               
     Upload:   920.79 Mbps (data used: 1.0 GB )                               
Packet Loss:     0.0%

This is just GREAT

 

[HELLO_wORLD]

Here is the script I am using now :

#!/bin/sh
IPT='/usr/sbin/iptables -w'
TIP='192.168.99.99'

/usr/sbin/ip r a $TIP/32 dev br0

# FILTER TABLE
$IPT -I INPUT ! -d $TIP -j TEE --gateway $TIP
$IPT -I OUTPUT ! -d $TIP -j TEE --gateway $TIP
$IPT -I FORWARD ! -d $TIP -j TEE --gateway $TIP

That tees pretty much all the traffic going through, to and from the router, any interface.
No impact on the router perfs whatsoever ; make the port mirroring from NG looking like cr*p, really… And I do receive all the teed traffic on the device.

On the device, I use iptables to drop all traffic to and from the device (in the raw table), as the only goal is to allow an IDS to listen to the traffic, but it should not interfere with the network itself, the device using its main ethernet port to connect to the LAN.

Note : for the INPUT rule, the ! -d $TIP is probably unnecessary as it was already routed to the router itself (so not the device).

Note 2 : this way (filter table vs mangle), only the traffic that goes through the firewall is teed, so anything blocked by aegis or other rules are discarded (no need to monitor them with IDS…). This also allows to know which device on the LAN is aimed by a malicious packet (or at the origin of it).