Unexpected incoming UDP traffic

[ds_sonic_asif]

I am a 1G Fiber customer in Berkeley with a Smart/RG SR516ac WiFi/Router provided by Sonic. On the router there is no port triggering or virtual servers. An Ubuntu server is the only thing connected to the router, and it provides packet forwarding connectivity to everything else in the house on a separate interface card and subnet.

At the server, I am seeing lots of inbound UDP packets arriving from the WAN and being blocked by the server firewall. Here is an example:

ufw.log:Sep 4 00:24:14 kiwi kernel: [1432477.824804] [UFW BLOCK] IN=enp7s0 OUT= MAC=**************** SRC=157.240.22.19 DST=192.168.42.3 LEN=61 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=UDP SPT=443 DPT=64552 LEN=41

enp7s0 is the network card that connects the server to the router and 192.168.42.3 is the server's IP LAN address obtained via DHCP from the router.

My question is why are these packets getting through the router? My understanding is that all incoming IP traffic should be blocked.

Thanks in advance.

[ngufra]

Source ip is 157.240.22.19 and it seems to be facebook (edge-star-shv-01-sjc3.facebook.com)
Source port 443 is https.
Destination port 64552 is a private port.

Is the Smart/RG in bridge mode?

ideally you could record the traffic on wireshark (put filter on the port so you don't need to capture all traffic) to see what is the 61 bytes of payload.

[ds_sonic_asif]

Source ip is 157.240.22.19 and it seems to be facebook (edge-star-shv-01-sjc3.facebook.com)
Source port 443 is https.
Destination port 64552 is a private port.

Is the Smart/RG in bridge mode?

ideally you could record the traffic on wireshark (put filter on the port so you don't need to capture all traffic) to see what is the 61 bytes of payload.

Hello. Thanks.

This was just an example. Not all of them are Facebook. Some others look more like UDP port scanning over limited ranges of ports at the upper end of the range. I am not particularly interested in what the traffic is. UFW is blocking it all just fine.

The question for me is why is it coming through the router? My expectation was that it should be blocked there.

The router is not in bridge mode. It started with a default setup from Sonic. Several years ago I had port triggering configured for an ssh port, but quickly grew tired of the endless external attempts to get in, and removed it, replacing it with zerotier.com. I also had ICMP disabled in the Management section for a long while, but turned it back on in case Sonic had some interest in being able to ping me. So the configuration should be back to default.

[dancingsnails]

UDP works using conntrack rules. Presumably 192.168.43.3 started the conversation and the nat router remembered that that source with dest port 64552 should go to it.

[ds_sonic_asif]

UDP works using conntrack rules. Presumably 192.168.43.3 started the conversation and the nat router remembered that that source with dest port 64552 should go to it.

Thanks. That sounds quite plausible. I will go back to ngufra's suggestion and do some packet capturing. Then I should be able to look backwards in time from a UFW rejection and see if there was traffic recently flowing on a given UDP port.

[daniel15]

QUIC and HTTP/3 can both use UDP so the traffic from Facebook would just be regular web traffic. Same for any other UDP traffic you see with a source port of 443.

[ds_sonic_asif]

I used tshark and captured UDP packets between the FaceBook address and my SmartRG router assigned IP. Saw nothing until I asked my wife do some typical FB usage. Then I saw all of the QUIC traffic. Interestingly we couldn't capture a UFW reject involving her MacBook Air:

Air -> House Wifi (not SmartRG) -> House Server -> SmartRG

but were able to with an iPhone:

iPhone -> House WiFi (not SmartRG) -> House Server -> SmartRG.

No doubt there are subtleties involved with QUIC connection shutdown, conntrack timeouts at some or all of the components in this path, and iOS networking. But I am satisfied now that it isn't the SmartRG grossly misbehaving.

Thank you all for the info.

[virtualmike]

FB often is cited as one of the apps that uses a lot of battery on mobile devices, and some people have suggested the app is constantly phoning home with info like location and the other running apps on the device. Could that be the cause?