Chrome OS devices sending UDP packets to gateway (seemingly not QUIC)
-
I suddenly have an extremely large number of UDP packets being sent to our gateway address from Chrome OS devices. I do not believe these are QUIC-related packets, as the destination address is our gateway and the ports are random (my understanding of QUIC is that the destination address is a google IP and the ports are 80 or 443). I honestly do not know when this started but I have a LOT of these and since we log our blocked egress traffic I'm generating 10+ GB log files every day on our syslog server! The devices are all NAT'd and no device is aware of our actual gateway address (the destination address of the traffic in question) so I'm not even sure what the traffic is; all the packets are small (packet length of 120 or 124).
This is how it looks on the pfsense box filter log:
Sep 15 08:28:05 WIFI 10.1.7.190:38278 x.y.170.122:28512 UDP
Sep 15 08:28:05 WIFI 10.1.1.22:57444 x.y.170.122:46168 UDP
Sep 15 08:28:05 WIFI 10.1.12.41:55681 x.y.170.122:60733 UDP
Sep 15 08:28:05 WIFI 10.1.10.150:34558 x.y.170.122:34777 UDP
Sep 15 08:28:05 WIFI 10.1.9.126:49166 x.y.170.122:29661 UDP
Sep 15 08:28:05 WIFI 10.1.4.14:49040 x.y.170.122:44746 UDP
Sep 15 08:28:05 WIFI 10.1.1.114:45037 x.y.170.122:57460 UDP
Sep 15 08:28:05 WIFI 10.1.12.41:47123 x.y.170.122:46437 UDP
Sep 15 08:28:05 WIFI 10.1.12.41:35915 x.y.170.122:34525 UDP
Sep 15 08:28:05 WIFI 10.1.11.158:44310 x.y.170.122:9932 UDP
Sep 15 08:28:05 WIFI 10.1.10.122:39512 x.y.170.122:23534 UDP
Sep 15 08:28:05 WIFI 10.1.4.205:52324 x.y.170.122:44181 UDP
Sep 15 08:28:05 LAN 172.29.20.147:59685 x.y.170.122:3473 UDPpacket capture as shown from the gui (different time range from above but same type of traffic):
13:26:27.557035 9c:d2:1e:8d:f2:7d > 00:1e:67:8a:14:eb, ethertype IPv4 (0x0800), length 162: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 148)
10.1.2.93.55343 > x.y.170.122.49908: [udp sum ok] UDP, length 120
13:26:27.559965 10:4a:7d:44:c4:ab > 00:1e:67:8a:14:eb, ethertype IPv4 (0x0800), length 162: (tos 0x0, ttl 64, id 20504, offset 0, flags [DF], proto UDP (17), length 148)
10.1.12.109.37166 > x.y.170.122.60621: [udp sum ok] UDP, length 120
13:26:27.561814 90:2e:1c:8c:41:e6 > 00:1e:67:8a:14:eb, ethertype IPv4 (0x0800), length 162: (tos 0x0, ttl 64, id 51074, offset 0, flags [DF], proto UDP (17), length 148)
10.1.10.225.53883 > x.y.170.122.12955: [udp sum ok] UDP, length 120
13:26:27.562278 cc:3d:82:e2:32:2c > 00:1e:67:8a:14:eb, ethertype IPv4 (0x0800), length 162: (tos 0x0, ttl 64, id 33515, offset 0, flags [DF], proto UDP (17), length 148)
10.1.12.230.55704 > x.y.170.122.5101: [udp sum ok] UDP, length 120
13:26:27.565822 90:2e:1c:8b:bd:57 > 00:1e:67:8a:14:eb, ethertype IPv4 (0x0800), length 166: (tos 0x0, ttl 64, id 15056, offset 0, flags [DF], proto UDP (17), length 152)
10.1.2.59.52581 > x.y.170.122.16024: [udp sum ok] UDP, length 124
13:26:27.567540 cc:3d:82:e2:63:14 > 00:1e:67:8a:14:eb, ethertype IPv4 (0x0800), length 162: (tos 0x0, ttl 64, id 55140, offset 0, flags [DF], proto UDP (17), length 148)
10.1.13.214.49352 > x.y.170.122.8372: [udp sum ok] UDP, length 120
13:26:27.568411 90:2e:1c:8b:bd:57 > 00:1e:67:8a:14:eb, ethertype IPv4 (0x0800), length 166: (tos 0x0, ttl 64, id 15057, offset 0, flagsand this is how the packet capture looks:
tcpdump -A -r packetcapture(1).capreading from file packetcapture(1).cap, link-type EN10MB (Ethernet)
13:26:27.557035 IP 10.1.2.93.55343 > x.y.170.122.49908: UDP, length 120
E…..@.@..
..]&..z./.........d!..B0kJxK4EOyWqO...!cjW+t8X/8gluGFeo:dxQ+bWeMSAK8YlTG....W.......)...
k...v..$..n.......~.0..p.
.@...6.y.c?+.(...9..
13:26:27.559965 IP 10.1.12.109.37166 > x.y.170.122.60621: UDP, length 120
E...P.@.@...
..m&..z......,....d!..B5sjVu9+v5UQr...!zCD2Tvkef16IxLqJ:DzkUq3iszriQzClX....W.......)..#x.....3.$..n...........03..n..r"..9.j.,.(...FU.
13:26:27.561814 IP 10.1.10.225.53883 > x.y.170.122.12955: UDP, length 120
E.....@.@...
.
.&..z.{2...U=...d!..BBPVTGUp5vKsX...!qNW7/ksj52FLyWZH:Epn665yQnkndGz3B....W.......).....p..,..$..n...........c...dj....K~.,..(...j..
13:26:27.562278 IP 10.1.12.230.55704 > x.y.170.122.5101: UDP, length 120
E.....@.@...
...&..z.......)...d!..B3ZRT7XtYcozH...!vv4XEyQT1zQduPll:xjeeB0vcoZ4cKPgX....W.......)..Q.Q.J.>h.$..n........wIk..h.zDL.TC.O B...(...T..
13:26:27.565822 IP 10.1.2.59.52581 > x.y.170.122.16024: UDP, length 124
E...:.@.@."C
..;&..z.e>....U...h!..Bb30JZskQ0LHk...!DzkUq3iszriQzClX:zCD2Tvkef16IxLqJ....W............E.$.B.%...$..n...........w..F.A@+..]..ZF^.(..E|<.
13:26:27.567540 IP 10.1.13.214.49352 > x.y.170.122.8372: UDP, length 120
E....d@.@.z.
h...d!..BShF4Nw3QhYji...!G4NJ2Bo+Fc/NhKLF:Donmy7j1NQGICzqH....W.......)..M&..k....$..n.......u,......:..BU...Q9...(...^..
13:26:27.568411 IP 10.1.2.59.50720 > x.y.170.122.58631: UDP, length 124
E...:.@.@."B
@.a:o.z.....(..q. .!..BN6FXuuyAmJmQ...!E2ipnM6M9UkpDAis:Pa8x/43NViW38vZv....W..........4T6/.s..%...$..n...........Jx..
13:26:27.568773 IP 10.1.4.159.47233 > x.y.170.122.63286: UDP, length 120
E.....@.@...
...&..z...6.......d!..B8Dj13CnC1Pl5...!uK8M6LqroTBNMM3R:ExSk/+hLdFTJMQ2n....W.......)...$.
1....$..n...........h..x...].S.d...u.(..... 13:26:27.569846 IP 10.1.3.175.37124 > x.y.170.122.29705: UDP, length 120 E...(w@.@.3, z..........(..)...Y....d!..BZz6jbBF2Je+Q...!zfNmCCo5GZvnxYXl:zBmG8MH4gXPja7OQ....W.......)..j...TP.|.$..n.......Q.B..Q..F 13:26:27.570018 IP 10.1.2.59.35721 > x.y.170.122.39889: UDP, length 124 E...:.@.@."A ..;&..z....../....h!..BHmIiFy/4h1OU...!4teoc1sxUd48U7XB:RYaRZsWWN0xDy9lU....W.......*.....%,o.j.%...$..n.......$8]....=.+..D..3s....(.....~ 13:26:27.570288 IP 10.1.2.59.52863 > x.y.170.122.30523: UDP, length 124 E...:.@.@."@ ..;&..z..w;..ge...h!..B+ufyp6eB33Mm...!xjeeB0vcoZ4cKPgX:vv4XEyQT1zQduPll....W.......*...........%...$..n.......tid0A....vLPf.v.."P..(..S8.. 13:26:27.571272 IP 10.1.2.59.51163 > x.y.170.122.61668: UDP, length 112 E...:.@.@."K ..;&..z.....x(....\!..BpXSKPGdsGbNX....qieA:y0rgxmfHq5F03wni....W.......*..p.....Q,.%...$..n.......ud..o-..._.5.......H.(..c3.. 13:26:27.571454 IP 10.1.14.66.56484 > x.y.170.122.37807: UDP, length 120 E...R.@.@..c ..B&..z......q<...d!..BxPJtaufnEtc4...!MOl+s9YQEhUe8qh2:ZWZ4W0hpElNaDfu4....W.......)..n..f.....$..n........sO......Eu..M..m.de.(...:.. 13:26:27.573243 IP 10.1.8.58.47341 > x.y.170.122.34628: UDP, length 120 E.....@.@... ..:&..z...D..Ei...d!..B4dkSTiU7FgS5...!mQ1jSUIkYi8I/g8j:/+36F+VNDeZU3Cmt....W.......)..i..F.....$..n........F...P1..1.Z.........(..39+
13:26:27.573831 IP 10.1.2.59.48131 > x.y.170.122.16291: UDP, length 124
E...:.@.@.">
..;&..z..?........h!..BVGnwTvpWqlF6...!ZWZ4W0hpElNaDfu4:MOl+s9YQEhUe8qh2....W.......*..T.......%...$..n.........L.....9.!_.^S......(....p.
13:26:27.575213 IP 10.1.2.59.47113 > x.y.170.122.60603: UDP, length 124
E...:.@.@."=
..;&..z. ....8....h!..BTYT0cXKdxChH...!ExSk/+hLdFTJMQ2n:uK8M6LqroTBNMM3R....W.......*....,%?."A.%...$..n............".......[[…q.(..e...
13:26:27.576857 IP 10.1.12.221.43495 > x.y.170.122.63417: UDP, length 120
E.....@.@.P.
...&..z.......x...d!..BtHdrBmQTPz3/...!J8PSYbZ7hTS+wSD+:KNMUkAtwPoQ5iNgJ....W.......)..h.f..'...$..n..........I.9....V....1....(....c.
13:26:27.577644 IP 10.1.10.182.58575 > x.y.170.122.51796: UDP, length 120
E....|@.@...
.
.&..z...T...n...d!..BnIbwt7rJk0a5...!Jaj523GtA0VFeEkO:v/N3+Ru085j3JGAE....W.......)...X....`3.$..n.......>t...p...... ..p..[/tt]I can obviously construct a rule to drop it without logging to solve my log file size but I'd really like to understand it since it's traffic with a destination address of our gateway. Any insights or explanations would be appreciated!
-
So this traffic is to your public IP of your gateway, and not the gateway of the wireless devices network, ie that 10.1.x network, or multiple networks?
My first guess with udp traffic on high ports would be P2P.. Can you post up some actual pcaps vs the ascii art ;) You can always replace your public IP in the sniff.
-
Yes, these packets have the destination address of the public IP of our Internet gateway, not the internal subnet gateway - and they are coming from Chrome OS devices on multiple internal networks (each of which would have its own default gateway i/f on the pfsense box but the packets are all destined for the public gateway IP - you can see this in the last two lines of the pfsense logs - last line is from LAN but the rest are from WIFI network).
2 example captures are attached. Thanks in advance!
-
huh? that is odd..
Anyway you can track what process is sending them from source? Looks like some sort of STUN
My shoot from the hip guess would be something to do with webrtc.. Chrome loves that shit ;)
-
Glad I'm not the only one who thought it was odd.
I'm not sure how I can track it since it's just a few packets then they go away, so it's kind of whack-a-mole to track it down (1,000 devices and they exhibit it randomly). I agree it's likely webrtc, I had figured hangouts or chat in google docs or something but I can't make it happen (which is odd because there are so many of these packets logged). \
Plus - and this is what's really interesting me - I can't understand why the external gateway is the destination unless it's a reverse nat issue . . .
-
Well yeah stun is going to try and transverse your nat ;) Which I take is something you don't want it to do ;) There is a way to disable webtrc in chrome browser, you could try doing that and see if that reduces your hits..
Guess your other option is just not log it.. You could still allow for dns and or quic, etc. but all other unknown UDP just drop it in the bin without logging.
