Strange ICMP packets on physical NIC while connected

[cheapsheep 6]

Hello,

I have experienced something similar. I downloaded an Archlinux torrent while not binding the torrent interface to Eddie (or its internal ip respectively). However, i had the network lock activated in Eddie.

After checking flow in Wireshark, i observed multicast traffic from one non-private IP in "Endpoints". I have noticed this in my routers fitrewall logs as well. The packet was dropped.

I would have expected to only see the Air IP and other internal IPs of my local network under the main network interface and the "real traffic" under Eddie interface.

I know that it was coming from qBittorent as i use the AirVPN port (src port) for torrenting.

UPnP was disabled at that time.

Any thoughts on this? Thanks.



.

[OpenSourcerer 1435]

NetLock is an outgoing traffic filter. It does not prevent incoming traffic of any kind, it only prevents it from going out the non-VPN interface. ICMP packets from internet hosts to your computer are something to be expected in such a setup, but they don't constitute a problem.
Also, I'll have you know that ICMP doesn't know ports. I'm looking forward to your explanation on how you know it was caused by qB. No offense, though; what I mean to say is that you might've intercepted unrelated packets from unrelated applications, in this case something tried to reach 62.155.244.x but got an ICMP Type 3 Code 0 back from some router, telling the application that the destination network is unreachable (or rather, that host is the router).

[cheapsheep 6]

40 minutes ago, OpenSourcerer said:

NetLock is an outgoing traffic filter. It does not prevent incoming traffic of any kind, it only prevents it from going out the non-VPN interface. ICMP packets from internet hosts to your computer are something to be expected in such a setup, but they don't constitute a problem.
Also, I'll have you know that ICMP doesn't know ports. I'm looking forward to your explanation on how you know it was caused by qB. No offense, though; what I mean to say is that you might've intercepted unrelated packets from unrelated applications, in this case something tried to reach 62.155.244.x but got an ICMP Type 3 Code 0 back from some router, telling the application that the destination network is unreachable (or rather, that host is the router).

Quote

it only prevents it from going out the non-VPN interface

That's why i was wondering how it showed up in my routers firewall logs which basically means traffic was sent outside the tunnel. How would it otherwise be supposed to come back from the outside?
 

Quote

I'm looking forward to your explanation on how you know it was caused by qB.

The User Datagram Protocol shows the port which i have setup in AirVPN specifically for torrenting as Src Port. Besides, i have not had any other programs running and the traffic showed up when i started the torrent (i was watching the traffic).
 

Quote

might've intercepted unrelated packets from unrelated applications

This might be true. But i have never observed something similar. Besides, i would expect an external IP to show up inside the interface created by Eddie and not my main networking interface with network lock enabled.

[Flx 76]

16 hours ago, cheapsheep said:

That's why i was wondering how it showed up in my routers firewall logs which basically means traffic was sent outside the tunnel. How would it otherwise be supposed to come back from the outside?

In your router's firewall did you also block icmp for v4 and v6 for "icmp flood prevention"?
https://www.enterprisenetworkingplanet.com/standards-protocols/networking-101-understanding-multicast-routing/

[cheapsheep 6]

2 hours ago, Flx said:

In your router's firewall did you also block icmp for v4 and v6 for "icmp flood prevention"?

Yes. That's why the packet got dropped.

However, @OpenSourcerers suggestion that it might be unrelated is probably right. I just checked the logs and still see these packets although no software is running. 
 

Quote

Nov 29 07:xx:xx kernel: DROP IN=ppp0 OUT= MAC= SRC=62.155.244.xx DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=54558 OPT (94040000) PROTO=2 

But i'm still wondering why an external IP is causing multicast traffic.

[OpenSourcerer 1435]

That IP belongs to Deutsche Telekom. Could it be your own? Because I've seen in the screenshots you at least speak German.

[cheapsheep 6]

28 minutes ago, OpenSourcerer said:

That IP belongs to Deutsche Telekom. Could it be your own? Because I've seen in the screenshots you at least speak German.

Nope, i also thought about that and have checked it. I have also never been assigned to a range similar to that IP (62.155.128.0 - 62.155.247.255)

I checked the firewall logs again. The packets are coming in every minute. No clue..

[OpenSourcerer 1435]

I've split your topic from the other because it's getting much more focused on your particular problem and not with any violation notice from an ISP, also you don't live in AU.

Try to ping it yourself, portscan it, connect to it.

[cheapsheep 6]

...Sonos speakers.

But i still have no clue why my firewall is showing an external IP (always the same) that is "flooding" my network with multicast requests:

[OpenSourcerer 1435]

On 12/2/2022 at 10:57 PM, cheapsheep said:

...Sonos speakers.

Not your speakers, but the IP address.

In any case, since it gets DROPped, anyway, I wouldn't worry.

[cheapsheep 6]

On 12/11/2022 at 8:09 PM, OpenSourcerer said:

Not your speakers, but the IP address.

In any case, since it gets DROPped, anyway, I wouldn't worry.

Hey @OpenSourcerer. Quick feedback on this one. I was wrong and finally found out.
It is my ISP (uplink gateway, first hop) doing a multicast for IPTV. That's why and 'external' IP was even able to show up in the logs as multicast.