IP source and destination not in LAN or public ip…

[HELLO_wORLD]

Hi all,

This question is wider than just NG routers, but we have our community here

As you may have followed, I installed an IDS system to monitor any suspect activity, and I see some packets that have a source AND a destination IP that are not on my LAN (either private or public IP).
Unfortunately, I don't have the pcap for these packets, but here is the log.

Is it a normal thing to see such packets (not specifically these, but with source and destination not on the LAN at all) ?

{"timestamp":"2022-06-26T02:15:30.426516+0200","flow_id":1977470128689982,"in_iface":"enx00e04c680554","event_type":"flow","src_ip":"59.122.164.158","src_port":37282,"dest_ip":"118.5.144.243","dest_port":62691,"proto":"UDP","app_proto":"failed","flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":42,"bytes_toclient":0,"start":"2022-06-26T02:13:07.463678+0200","end":"2022-06-26T02:13:07.463678+0200","age":0,"state":"new","reason":"timeout","alerted":false},"community_id":"1:IbdB7sne69+9JmcTOiGX5udapVQ="}


{"timestamp":"2022-06-26T06:43:29.205541+0200","flow_id":850901262365038,"in_iface":"enx00e04c680554","event_type":"flow","src_ip":"59.122.164.158","src_port":36792,"dest_ip":"92.163.137.95","dest_port":65163,"proto":"UDP","app_proto":"failed","flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":42,"bytes_toclient":0,"start":"2022-06-26T06:41:31.356718+0200","end":"2022-06-26T06:41:31.356718+0200","age":0,"state":"new","reason":"timeout","alerted":false},"community_id":"1:H6kb5XrNeEP6vin9vxJJ3nTW7bc="}


{"timestamp":"2022-06-26T07:37:00.156285+0200","flow_id":1467693136150953,"in_iface":"enx00e04c680554","event_type":"flow","src_ip":"59.122.164.158","src_port":34301,"dest_ip":"220.202.93.106","dest_port":58597,"proto":"UDP","app_proto":"failed","flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":42,"bytes_toclient":0,"start":"2022-06-26T07:35:01.000425+0200","end":"2022-06-26T07:35:01.000425+0200","age":0,"state":"new","reason":"timeout","alerted":false},"community_id":"1:YP8ySWXaaZ1GREWYqMN3CnyLEEQ="}


{"timestamp":"2022-06-26T08:52:36.445298+0200","flow_id":1594008413317987,"in_iface":"enx00e04c680554","event_type":"flow","src_ip":"59.122.164.158","src_port":40290,"dest_ip":"28.209.165.183","dest_port":37613,"proto":"UDP","app_proto":"failed","flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":42,"bytes_toclient":0,"start":"2022-06-26T08:48:30.895843+0200","end":"2022-06-26T08:48:30.895843+0200","age":0,"state":"new","reason":"timeout","alerted":false},"community_id":"1:VBrsjmpK241wHG4eBFnExPagq8o="}


{"timestamp":"2022-06-26T10:07:22.039345+0200","flow_id":1410194846528738,"in_iface":"enx00e04c680554","event_type":"flow","src_ip":"59.122.164.158","src_port":28338,"dest_ip":"111.240.227.101","dest_port":63213,"proto":"UDP","app_proto":"failed","flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":42,"bytes_toclient":0,"start":"2022-06-26T10:03:48.537826+0200","end":"2022-06-26T10:03:48.537826+0200","age":0,"state":"new","reason":"timeout","alerted":false},"community_id":"1:yU1gRLwgcjZG4lByg+vGOTNtRwk="}


{"timestamp":"2022-06-26T13:30:54.773556+0200","flow_id":91256295693721,"in_iface":"enx00e04c680554","event_type":"flow","src_ip":"59.122.164.158","src_port":25208,"dest_ip":"162.116.99.54","dest_port":57594,"proto":"UDP","app_proto":"failed","flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":42,"bytes_toclient":0,"start":"2022-06-26T13:29:26.368025+0200","end":"2022-06-26T13:29:26.368025+0200","age":0,"state":"new","reason":"shutdown","alerted":false},"community_id":"1:VJi76Rn12meh8H6TIkXYdYB2+Oo="}

 

[Tech Junky]

Source / WAN - https://www.abuseipdb.com/check/59.122.164.158 / 59-122-164-158.dynamic-ip.hinet.net

destination:
https://www.abuseipdb.com/check/118.5.144.243 / p307243-ipngn200306gifu.gifu.ocn.ne.jp
https://www.abuseipdb.com/check/92.163.137.95 / Orange S.A.
https://www.abuseipdb.com/check/220.202.93.106 / China Unicom
https://www.abuseipdb.com/check/28.209.165.183 / DoD Network Information Center
https://www.abuseipdb.com/check/111.240.227.101 / 111-240-227-101.dynamic-ip.hinet.net
https://www.abuseipdb.com/check/162.116.99.54 / allergan.com

Just looking at these the DOD one stands out for a reason obviously. A couple of them look like non-commercial use IP's but, the others could be questionable. Since logs are showing it being UDP and the source ports being a bit random it doesn't seem like it's a perpetual stream of data being sent to those destinations.

The good thing is they're failing and not setting up a session to leak data.

Now, as to what's "normal" if you're looking for something you'll find something. Most of the stuff in logs is just clutter unless there's something interesting to filter down to. Using a syslog server makes this task a bit easier to track something down.

 

[eibgrad]

Is it a normal thing to see such packets (not specifically these, but with source and destination not on the LAN at all) ?

Where is this data being captured? I assume it's on the router, and that this is outbound traffic, with src_ip set to your public WAN ip (59.122.164.158), since it remains constant. If it's data inbound to the WAN, how can the destination IP be anything but your own public IP? Public IPs can NOT be spoofed else they would never reach their intended target.

In short, you can't make a determination of what is suspicious about the lack of private IP unless you know where the data is being collected; either on the router itself (WAN) or some LAN device behind it.

 

[HELLO_wORLD]

Where is this data being captured? I assume it's on the router, and that this is outbound traffic, with src_ip set to your public WAN ip (59.122.164.158), since it remains constant. If it's data inbound to the WAN, how can the destination IP be anything but your own public IP? Public IPs can NOT be spoofed else they would never reach their intended target.

In short, you can't make a determination of what is suspicious about the lack of private IP unless you know where the data is being collected; either on the router itself (WAN) or some LAN device behind it.

It is collected on a separate device on which ALL traffic to, from and through the router is teed as is (like mirrored).

I tee the traffic in INPUT, OUTPUT and FORWARD net filter tables, to keep/know the local LAN adresses involved. If I tee only on the WAN in/out (on mangle PREROUTING for example), I lose this info.

 

[ColinTaylor]

I can't see how any of this traffic can be getting to your router unless 59.122.164.158 is your WAN IP address?

The only other thing I can think of that might cause this is the use of a VPN client on the router.

 

[eibgrad]

It is collected on a separate device on which ALL traffic to, from and through the router is teed as is (like mirrored).

I tee the traffic in INPUT, OUTPUT and FORWARD net filter tables, to keep/know the local LAN adresses involved. If I tee only on the WAN in/out (on mangle PREROUTING for example), I lose this info.

Ok, then the source of the data is always from the perspective of the router. So if the traffic is as it appears to be (outgoing over the WAN), as I said, I see nothing inherently suspicious about it. NOT unless the IDS is flagging the public destination IP for some reason.

P.S. @ColinTaylor makes a good point about a VPN client. Fact is, there's NOT enough details here about your router and how its configured to be sure about much of anything. We're both just guessing at this point based on assumptions.

 

[HELLO_wORLD]

@ColinTaylor : no VPN on the router. The only VPN is a client in a docker on a NAS, and it is fully contained in there. Even though, non of the IP involved are VPN related.
An indeed, what is strange is that neither the source or the destination are in my LAN at all… both are outside public adresses…

@eibgrad : I don't think this was captured over the WAN, as it would really make no sense the router would send packets with a spoofed IP (that would not pass ACL anyway).
I suspect it is packets in the LAN, reaching the router, but with a source IP that is spoofing a public IP… The router is not routing these, so they are harmless, but we agree it is not normal to see this kind of packets…

Anyway, I have not seen them back. If I do, I will try to capture them to know more about what they are…

 

[Tech Junky]

@HELLO_wORLD

The session ID's / originating port should match up with something on the LAN. Of course with NAT you only see the WAN in the logs based on whatever pattern you're using to match traffic events with. Another possibility is the LAN isn't triggering message that are being logged / sent to the syslog you're using. I use NTOP for monitoring network traffic and splice things down depending on the IF being used. LAN / WAN / VPN and then from there can drill down into the packet level per IP.

This is more helpful in trying to pin something down like what you're seeing. A little more intuitive to decoding things quicker than parsing the logs and resolving names to figure out what's being chatty. Breaking the monitoring out into different interfaces allows you to pin things down to a specific client if need be as well.

For instance your phone is generating a bunch of traffic you notice in your DNS to a URL like wzkrt above... you can dig into the history and try to correlate this with the change that invoked the traffic. Was it an app update / new install / something on the carrier side that started generating traffic. For instance I tried VZW's - Visible MVNO and it pings their vzwwo.com for something / telemetry most likely so I blocked it in the DNS side. Just like most of the Google telemetry / ads / etc.

I don't know what they need to be collecting or what they plan on doing with it so it gets blocked. If the phone works w/o it being enabled then it doesn't need to be leaking data in the first place. Just like windows doesn't need to be skimming data and sending it off to MSFT all of the time. Changing DNS checks away from OEM options to point to public stable IP's instead like 8.8.8.8 / 4.2.2.2 / 1,1,1,1 vs leaving a domain session open for telemetry.

You could be amazed at all of the little bits that get siphoned just by being connected to the internet. Different tools give different insight to what's going where and in what amounts. Sometimes a simple packet CLI monitoring program will help in detecting something abnormal.

 

[HELLO_wORLD]

@Tech Junky this is very interesting…

I am getting the info from Suricata installed on a SBC connected through the LAN, and with a second eth. interface connected to the router as the listening port.
On the router, I tried first the native port mirroring offered by Netgear, but it impacted routing performances… So @Voxel installed the TEE netfilter module allowing me to copy all the traffic I want through iptables and send it to my SBC.
The way I did that is on the router :
– create a permanent ARP table entry between the MAC of the listening interface, and a private IP/32 that is not on my LAN subnet.
– create a route to the private IP/32 on the router's routing table as it is not on the LAN subnet.
– create the iptables TEE rules to copy all the traffic after the firewall.

/usr/sbin/ip n a IP lladdr MAC nud permanent dev br0
/usr/sbin/ip r a IP/32 dev br0
/usr/sbin/iptables -w -I INPUT ! -i lo -j TEE --gateway IP
/usr/sbin/iptables -w -I OUTPUT ! -o lo ! -d IP -j TEE --gateway IP
/usr/sbin/iptables -w -I FORWARD ! -d IP -j TEE --gateway IP

On the SBC (armbian), I set up the interface this way :

nmcli con mod conname ethtool.feature-lro off ethtool.feature-gro off ethtool.feature-tso off ethtool.feature-gso off ethtool.feature-sg off ethtool.feature-rx off ethtool.feature-tx off ethtool.feature-rxvlan off ethtool.feature-txvlan off

ethtool -G ifname rx 4096

ip link set dev ifname arp off
ip link set dev ifname multicast off
ip link set dev ifname promisc on

iptables -t raw -F PREROUTING
iptables -t raw -A PREROUTING -i ifname -j DROP
iptables -t raw -F OUTPUT
iptables -t raw -A OUTPUT -o ifname -j DROP

So that all the traffic coming from it does not interfere (it just needs to be listen to).

For the interface setup, I got inspired from this: https://snort-org-site.s3.amazonaws.com/production/document_files/files/000/003/977/original/Snort_3_GA_on_CentOS_8_Stream.pdf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAU7AK5ITMJQBJPARJ/20220626/us-east-1/s3/aws4_request&X-Amz-Date=20220626T151318Z&X-Amz-Expires=172800&X-Amz-SignedHeaders=host&X-Amz-Signature=f027c37e8ac71e82a9818db733f5f5a8bceb270af85e75c8c30abbb41d84bf47
Section 10.1 Configuring Network Capturing Interfaces

The SBC also has filebeat installed, and is sending the logs to my ELK (elastic search + kibana) stack on my NAS.

And it is from the kibana interface than I see these weird routes (that I can see in the suricate logs):

Any optimization / improvement / correction to my approach/method is welcome

 

[Tech Junky]

@HELLO_wORLD

That's a work around if I ever saw one. Then again this is what happens when you want enterprise options with consumer HW.

The only thing I would consider is being inline as a tap to allow a device to be the capture that's more robust than the limited iptables are giving you. Making the ELK as you put it the gateway / dns / etc. for the clients would give you more insight to all traffic. Whether the ELK can handle the throughput is a different story. The apps I'm using for monitoring don't take a huge amount of resources though. The one that might be an issue would be ntop as it's almost a DPI level monitor and when the packets are screaming it does ramp up on CPU use. Netwatch is pretty basic but, you can use the arrow keys to change the view of the right side panel to go IP+port and some other options.

Netwatch doesn't give a place to store historical data AFAIK / use it for so, it's more of in the moment monitoring / troubleshooting. NTOP is where the value is for storing the data to look back as needed. There's a paid option with NTOP as well if you feel you want more features but not enterprise costs. Netwatch also doesn't pick up on the VPN interface for seeing traffic passing through the tunnel which is where NTOP gets to be the better option.

It's all useful info though if you're tracking something in particular but, visibility of LAN and WAN traffic helps.

 

[HELLO_wORLD]

Using iptables allows to fine tune though, I can tap WAN incoming traffic after the firewall (aegis), so only what is really hitting the router and LAN.

I will need to see if I can mark somehow the packets teed (and recover the info in suricate) so I could differentiate what is coming from INPUT, OUTPUT and FORWARD. filebeat and elastic search are using a host tag, so I could have visual hosts for WAN, LAN, etc…

Now, how involved and possible that would be… I don't know.

 

[ColinTaylor]

An indeed, what is strange is that neither the source or the destination are in my LAN at all… both are outside public adresses…

I would concentrate on this before getting bogged down in more and more complex monitoring solutions.

If 59.122.164.158 exists on your LAN as you think it does then it ought to be visible on the router with arp -an

 

[HELLO_wORLD]

I would concentrate on this before getting bogged down in more and more complex monitoring solutions.

If 59.122.164.158 exists on your LAN as you think it does then it ought to be visible on the router with arp -an

59.122.164.158 does not exist on my LAN, and as expected, arp returns only my public IP on brwan, and adresses of my devices in my LAN on br0 (into the private subnet allocated to my LAN).
I suspect there were packets with a spoofed source address 59.122.164.158 in my LAN when it happened. If I had captured the packets, I could have checked the MAC at the ether level of these packets and see from which device they came from, and see the content of the packets as well.

Suricata offers a pcap capture and saving, but I am afraid it would overload the process (ram, cpu and disk space…)

 

[ColinTaylor]

I suspect there were packets with a spoofed source address 59.122.164.158 in my LAN when it happened. If I had captured the packets, I could have checked the MAC at the ether level of these packets and see from which device they came from, and see the content of the packets as well.

Well if it's not doing it anymore and you didn't capture the packets there's not a lot you can do retrospectively. I would insert the following rule (or it's equivalent for your setup) on the router and periodically check its syslog.

iptables -I FORWARD -s 59.122.0.0/16 -j LOG --log-prefix "TEST " --log-tcp-sequence --log-tcp-options --log-ip-options

Do you have any Chinese IoT devices, like cameras? That'd be the first thing I'd check.

 

[HELLO_wORLD]

Well if it's not doing it anymore and you didn't capture the packets there's not a lot you can do retrospectively. I would insert the following rule (or it's equivalent for your setup) on the router and periodically check its syslog.

iptables -I FORWARD -s 59.122.0.0/16 -j LOG --log-prefix "TEST " --log-tcp-sequence --log-tcp-options --log-ip-options

Do you have any Chinese IoT devices, like cameras? That'd be the first thing I'd check.

The only Chinese device I have (TV cast system) is unplugged unless I use it (did not happen in weeks).
Anyway, I block any device that has no reason to communicate outside the LAN with an iptables rule blocking its MAC:

/usr/sbin/ipset -N lan_only_mac hash:mac
/usr/sbin/ipset add lan_only_mac d0:c0:bf:34:XX:XX #MiraScreen
/usr/sbin/ipset add lan_only_mac 84:0D:8E:82:XX:XX #Device2
/usr/sbin/iptables -w -I FORWARD -i br0 -o brwan -m set --match-set lan_only_mac src -j REJECT --reject-with icmp-admin-prohibited

I just set the ipset "lan_only_mac" with the MAC addresses I want to block.

 

[ColinTaylor]

In which case I'd insert a LOG rule just before your REJECT rule so that you can see what's being blocked.

 

[HELLO_wORLD]

In which case I'd insert a LOG rule just before your REJECT rule so that you can see what's being blocked.

Good idea… Only thing is logs are not lasting very long on the router… I will need to tweak it the same way I do with aegis
I might also simply make a tcpdump daemon on the router to capture and save packets with net 59.122.0.0/16 on br0 and let it run for a few days. I already have multiple tcpdump running on the router to monitor some garbage on the WAN side.

 

[Tech Junky]

@HELLO_wORLD

So, if the 59.x.x.x IP isn't your WAN or VPN IP then it seems like you might be being used as a relay for someone else's traffic. Someone might be using your IP as an arbitrary destination to send unwanted traffic. Since it didn't originate from you it just bounces off the router/FW and that's it.

This is fine with the exception that if the source is attacked and dumps a ton of traffic in your direction you're essentially DOS'd by the traffic.

For my rules I DROP instead of giving them any response at all. It just goes to purgatory and times out on their end eventually.

 

[HELLO_wORLD]

@HELLO_wORLD

So, if the 59.x.x.x IP isn't your WAN or VPN IP then it seems like you might be being used as a relay for someone else's traffic. Someone might be using your IP as an arbitrary destination to send unwanted traffic. Since it didn't originate from you it just bounces off the router/FW and that's it.

This is fine with the exception that if the source is attacked and dumps a ton of traffic in your direction you're essentially DOS'd by the traffic.

For my rules I DROP instead of giving them any response at all. It just goes to purgatory and times out on their end eventually.

You mean from the WAN?

Not possible for several reasons:
1) the ISP router would not allow it (I mean the router after the gateway, on the ISP infra)
2) it would be blocked at the entrance of my router, not reaching TEE rule and suricata logging:

root@HERMES:~$ iptables -t raw -S
-P PREROUTING ACCEPT
-P OUTPUT ACCEPT
-A PREROUTING -s 0.0.0.0/32 -i br0 -j ACCEPT
-A PREROUTING -m rpfilter --invert -j DROP
-A PREROUTING -i brwan -m set ! --match-set brwan_in_auth dst -j DROP
-A OUTPUT -o lo -j NOTRACK

And in the brwan_in_auth set, I have my public IP, my public IP's subnet broadcast IP, and 255.255.255.255.

As a general rule, I DROP anything I want to block from WAN, and REJECT anything I want to block from LAN.

EDIT/PS: I just launched this on the router: tcpdump -i br0 -w /mnt/optware/59.122.0.0.pcap net 59.122.0.0/16 &

 

[HELLO_wORLD]

Ok, so it came back, and I captured some packets:

First, what I captured on br0:

root@HERMES:~$ tcpdump -r /mnt/optware/59.122.0.0.br0.pcap -vvvenn
reading from file /mnt/optware/59.122.0.0.br0.pcap, link-type EN10MB (Ethernet)
00:50:17.957174 LAN_DEVICE_MAC > ROUTER_LAN_MAC, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 556, offset 0, flags [DF], proto ICMP (1), length 84)
    LAN_DEVICE_IP > 59.122.164.158: ICMP echo request, id 2116, seq 1, length 64
00:50:17.957268 ROUTER_LAN_MAC > IDS_DEVICE_MAC, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 556, offset 0, flags [DF], proto ICMP (1), length 84)
    LAN_DEVICE_IP > 59.122.164.158: ICMP echo request, id 2116, seq 1, length 64
00:50:18.961829 LAN_DEVICE_MAC > ROUTER_LAN_MAC, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 565, offset 0, flags [DF], proto ICMP (1), length 84)
    LAN_DEVICE_IP > 59.122.164.158: ICMP echo request, id 2116, seq 2, length 64
00:50:18.961892 ROUTER_LAN_MAC > IDS_DEVICE_MAC, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 565, offset 0, flags [DF], proto ICMP (1), length 84)
    LAN_DEVICE_IP > 59.122.164.158: ICMP echo request, id 2116, seq 2, length 64
00:50:19.989789 LAN_DEVICE_MAC > ROUTER_LAN_MAC, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 756, offset 0, flags [DF], proto ICMP (1), length 84)
    LAN_DEVICE_IP > 59.122.164.158: ICMP echo request, id 2116, seq 3, length 64
00:50:19.989852 ROUTER_LAN_MAC > IDS_DEVICE_MAC, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 756, offset 0, flags [DF], proto ICMP (1), length 84)
    LAN_DEVICE_IP > 59.122.164.158: ICMP echo request, id 2116, seq 3, length 64
00:50:21.009845 LAN_DEVICE_MAC > ROUTER_LAN_MAC, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 807, offset 0, flags [DF], proto ICMP (1), length 84)
    LAN_DEVICE_IP > 59.122.164.158: ICMP echo request, id 2116, seq 4, length 64
00:50:21.009908 ROUTER_LAN_MAC > IDS_DEVICE_MAC, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 807, offset 0, flags [DF], proto ICMP (1), length 84)
    LAN_DEVICE_IP > 59.122.164.158: ICMP echo request, id 2116, seq 4, length 64
00:50:22.033869 LAN_DEVICE_MAC > ROUTER_LAN_MAC, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 1015, offset 0, flags [DF], proto ICMP (1), length 84)
    LAN_DEVICE_IP > 59.122.164.158: ICMP echo request, id 2116, seq 5, length 64
00:50:22.033931 ROUTER_LAN_MAC > IDS_DEVICE_MAC, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 1015, offset 0, flags [DF], proto ICMP (1), length 84)
    LAN_DEVICE_IP > 59.122.164.158: ICMP echo request, id 2116, seq 5, length 64
00:50:23.058049 LAN_DEVICE_MAC > ROUTER_LAN_MAC, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 1154, offset 0, flags [DF], proto ICMP (1), length 84)
    LAN_DEVICE_IP > 59.122.164.158: ICMP echo request, id 2116, seq 6, length 64
00:50:23.058143 ROUTER_LAN_MAC > IDS_DEVICE_MAC, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 1154, offset 0, flags [DF], proto ICMP (1), length 84)
    LAN_DEVICE_IP > 59.122.164.158: ICMP echo request, id 2116, seq 6, length 64

Then what I captured on brwan:

root@HERMES:~$ tcpdump -r /mnt/optware/59.122.0.0.brwan.pcap -vvvenn
reading from file /mnt/optware/59.122.0.0.brwan.pcap, link-type EN10MB (Ethernet)
00:50:17.957487 ROUTER_WAN_MAC > ISP_GATEWAY_MAC, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 556, offset 0, flags [DF], proto ICMP (1), length 84)
    MY_PUBLIC_IP > 59.122.164.158: ICMP echo request, id 2116, seq 1, length 64
00:50:18.961985 ROUTER_WAN_MAC > ISP_GATEWAY_MAC, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 565, offset 0, flags [DF], proto ICMP (1), length 84)
    MY_PUBLIC_IP > 59.122.164.158: ICMP echo request, id 2116, seq 2, length 64
00:50:19.989914 ROUTER_WAN_MAC > ISP_GATEWAY_MAC, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 756, offset 0, flags [DF], proto ICMP (1), length 84)
    MY_PUBLIC_IP > 59.122.164.158: ICMP echo request, id 2116, seq 3, length 64
00:50:21.010001 ROUTER_WAN_MAC > ISP_GATEWAY_MAC, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 807, offset 0, flags [DF], proto ICMP (1), length 84)
    MY_PUBLIC_IP > 59.122.164.158: ICMP echo request, id 2116, seq 4, length 64
00:50:22.033994 ROUTER_WAN_MAC > ISP_GATEWAY_MAC, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 1015, offset 0, flags [DF], proto ICMP (1), length 84)
    MY_PUBLIC_IP > 59.122.164.158: ICMP echo request, id 2116, seq 5, length 64
00:50:23.058236 ROUTER_WAN_MAC > ISP_GATEWAY_MAC, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 1154, offset 0, flags [DF], proto ICMP (1), length 84)
    MY_PUBLIC_IP > 59.122.164.158: ICMP echo request, id 2116, seq 6, length 64

Nothing shocking or abnormal here.
1) the LAN_DEVICE is sending a ping to 59.122.164.158.
2) the router receives it on br0 and it is captured by tcpdump at 00:50:17.957174
3) the router tees the packet to IDS_DEVICE at 00:50:17.957268.
4) the router figures it must be routed to WAN.
5) the router sends the packet to ISP_GATEWAY from brwan and it is captures by tcpdump at 00:50:17.957487
… (repeats with other emitted pings)

1/2