Solved Why is Firefox listening on local UDP port?

[CaffeineAddict]

I run this command while Firefox is running:

sudo ss -tunlp

Excerpt from output is this:

Netid         State   Recv-Q       Send-Q            Local Address:Port     Peer Address:Port     Process
udp           UNCONN    0             0              0.0.0.0:45790          0.0.0.0:*            users:(("firefox-bin",pid=3291,fd=124))

Firefox is listening on port UDP port 45790 on all NIC's (0.0.0.0), why? what does this represent?

Meanwhile I noticed my firewall is dropping inbound UDP connection albeit on different port:

DROP response_icmp_4: IN= OUT=<MY_NIC> SRC=<LOCAL_NIC_IP> DST=162.159.128.233 LEN=576 TOS=0x00 PREC=0xC0 TTL=64 ID=36671 PROTO=ICMP TYPE=3 CODE=3 [SRC=162.159.128.233 DST=<LOCAL_IP> LEN=63 TOS=0x00 PREC=0x00 TTL=57 ID=1 DF PROTO=UDP SPT=443 DPT=39604 LEN=43 ]

ICMP Type 3 Code 3 is ICMP response "destination port unreachable"
162.159.128.233 conntacted local UDP port 39604 from remote UDP port 443.

I've run command:

whois 162.159.128.233

Here is response:

Spoiler: whois response

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2025, American Registry for Internet Numbers, Ltd.
#


NetRange: 162.158.0.0 - 162.159.255.255
CIDR: 162.158.0.0/15
NetName: CLOUDFLARENET
NetHandle: NET-162-158-0-0-1
Parent: NET162 (NET-162-0-0-0-0)
NetType: Direct Allocation
OriginAS: AS13335
Organization: Cloudflare, Inc. (CLOUD14)
RegDate: 2013-05-23
Updated: 2024-09-04
Comment: All Cloudflare abuse reporting can be done via https://www.cloudflare.com/abuse
Comment: Geofeed: https://api.cloudflare.com/local-ip-ranges.csv
Ref: https://rdap.arin.net/registry/ip/162.158.0.0



OrgName: Cloudflare, Inc.
OrgId: CLOUD14
Address: 101 Townsend Street
City: San Francisco
StateProv: CA
PostalCode: 94107
Country: US
RegDate: 2010-07-09
Updated: 2024-11-25
Ref: https://rdap.arin.net/registry/entity/CLOUD14


OrgTechHandle: ADMIN2521-ARIN
OrgTechName: Admin
OrgTechPhone: +1-650-319-8930
OrgTechEmail: [email protected]
OrgTechRef: https://rdap.arin.net/registry/entity/ADMIN2521-ARIN

OrgRoutingHandle: CLOUD146-ARIN
OrgRoutingName: Cloudflare-NOC
OrgRoutingPhone: +1-650-319-8930
OrgRoutingEmail: [email protected]
OrgRoutingRef: https://rdap.arin.net/registry/entity/CLOUD146-ARIN

OrgAbuseHandle: ABUSE2916-ARIN
OrgAbuseName: Abuse
OrgAbusePhone: +1-650-319-8930
OrgAbuseEmail: [email protected]
OrgAbuseRef: https://rdap.arin.net/registry/entity/ABUSE2916-ARIN

OrgNOCHandle: CLOUD146-ARIN
OrgNOCName: Cloudflare-NOC
OrgNOCPhone: +1-650-319-8930
OrgNOCEmail: [email protected]
OrgNOCRef: https://rdap.arin.net/registry/entity/CLOUD146-ARIN

RNOCHandle: NOC11962-ARIN
RNOCName: NOC
RNOCPhone: +1-650-319-8930
RNOCEmail: [email protected]
RNOCRef: https://rdap.arin.net/registry/entity/NOC11962-ARIN

RTechHandle: ADMIN2521-ARIN
RTechName: Admin
RTechPhone: +1-650-319-8930
RTechEmail: [email protected]
RTechRef: https://rdap.arin.net/registry/entity/ADMIN2521-ARIN

RAbuseHandle: ABUSE2916-ARIN
RAbuseName: Abuse
RAbusePhone: +1-650-319-8930
RAbuseEmail: [email protected]
RAbuseRef: https://rdap.arin.net/registry/entity/ABUSE2916-ARIN

So this are 2 questions:
1.) Why is Firefox listening on seemingly random UDP port?
2.) I suspect the port is random and cloudflare tries to contact that port from UDP remote port 443 which is consistent. but I'm not sure about that.

 

[APTI]

strange. I would like to know also. I just tried that command on my system which has firefox open with half a dozen tabs. my firefox was not listed at all in the command output. Perhaps you have an extension using it?

 

[CaffeineAddict]

strange. I would like to know also. I just tried that command on my system which has firefox open with half a dozen tabs. my firefox was not listed at all in the command output. Perhaps you have an extension using it?

Firefox does not consistently open these ports but only on some occasions, you'll have to periodically run the ss command to catch it.

The following question gives hints about HTTP/3 and WebRTC:

On Linux Firefox is listening on several UDP ports on 0.0.0.0

On Linux, Firefox is listening on UDP port, usually on ports 30000 and higher. What is the reason for this and why not just localhost, but 0.0.0.0, i.e. the interface exposed to the network as well?

unix.stackexchange.com

Further research reveals that this may be caused by WebRTC:

Use specific ports for webRTC

When creating a peer to peer audio connection using webRTC, the STUN server we use will return the public IP if a user is behind a router. Now in the ICE objects, I can see that the rport is always

stackoverflow.com

I'm now sure it's WebRTC in Firefox, but need to figure out how to reproduce it to draw further conclusions.

EDIT:
I managed to come to repro steps, tun the following command:

watch sudo ss -tunlp

This will refresh ss command every 2 sec.
Next steps is to visit Youtube, and optionally start a video, then as video plays look at the terminal ss command and you'll notice Youtube uses WebRTC by opening a local port.

Here is confirmation:

How does youtube use webrtc? Is it used frequently?

I developed a video chat website for clients using webRTC. This was my graduation project and I have worked hard and will use it as a portfolio for employment. The company I want to go to is a video

stackoverflow.com

-----

I'm now down to figuring out:

1.) how exactly does WebRTC work?
2.) why does YT use it?
3.) how does networking (e.g. open ports, handshakes, NAT traversal etc.) work?
4.) are there any security implications?
5.) is it possible to disable WebRTC and at what expense?

etc. etc.

EDIT2:

Disabling WebRTC does not help, FF still listens to random ports:

GitHub - K3V1991/How-to-disable-WebRTC-in-Chrome-Firefox-Safari-Opera-and-Edge: How to disable WebRTC in Chrome, Firefox, Safari, Opera & Edge

How to disable WebRTC in Chrome, Firefox, Safari, Opera & Edge - K3V1991/How-to-disable-WebRTC-in-Chrome-Firefox-Safari-Opera-and-Edge

github.com

Also useful link to test WebRTC:

gUM Test Page

But none of this answers my initial questions.

 

[909mjolnir]

I don't know if this is helpful or not, but there's also some firefox addons to block WebRTC.
And wasnt' there some kind of block for WebRTC leaking in uBlock origin also?

 

[CaffeineAddict]

but there's also some firefox addons to block WebRTC.

There is no need for addons, the media.peerconnection.enabled in about:config does the job, see link above.
Addons only make a browser less reliable.

And wasnt' there some kind of block for WebRTC leaking in uBlock origin also?

Yes it was, but seems it no longer exists, that option was to prevent IP leak though not to disable WebRTC.

 

[Aristarchus]

I run this command while Firefox is running:

sudo ss -tunlp

Excerpt from output is this:

Netid         State   Recv-Q       Send-Q            Local Address:Port     Peer Address:Port     Process
udp           UNCONN    0             0              0.0.0.0:45790          0.0.0.0:*            users:(("firefox-bin",pid=3291,fd=124))

Firefox is listening on port UDP port 45790 on all NIC's (0.0.0.0), why? what does this represent?

Meanwhile I noticed my firewall is dropping inbound UDP connection albeit on different port:

DROP response_icmp_4: IN= OUT=<MY_NIC> SRC=<LOCAL_NIC_IP> DST=162.159.128.233 LEN=576 TOS=0x00 PREC=0xC0 TTL=64 ID=36671 PROTO=ICMP TYPE=3 CODE=3 [SRC=162.159.128.233 DST=<LOCAL_IP> LEN=63 TOS=0x00 PREC=0x00 TTL=57 ID=1 DF PROTO=UDP SPT=443 DPT=39604 LEN=43 ]

ICMP Type 3 Code 3 is ICMP response "destination port unreachable"
162.159.128.233 conntacted local UDP port 39604 from remote UDP port 443.

I've run command:

whois 162.159.128.233

Here is response:

Spoiler: whois response

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2025, American Registry for Internet Numbers, Ltd.
#


NetRange: 162.158.0.0 - 162.159.255.255
CIDR: 162.158.0.0/15
NetName: CLOUDFLARENET
NetHandle: NET-162-158-0-0-1
Parent: NET162 (NET-162-0-0-0-0)
NetType: Direct Allocation
OriginAS: AS13335
Organization: Cloudflare, Inc. (CLOUD14)
RegDate: 2013-05-23
Updated: 2024-09-04
Comment: All Cloudflare abuse reporting can be done via https://www.cloudflare.com/abuse
Comment: Geofeed: https://api.cloudflare.com/local-ip-ranges.csv
Ref: https://rdap.arin.net/registry/ip/162.158.0.0



OrgName: Cloudflare, Inc.
OrgId: CLOUD14
Address: 101 Townsend Street
City: San Francisco
StateProv: CA
PostalCode: 94107
Country: US
RegDate: 2010-07-09
Updated: 2024-11-25
Ref: https://rdap.arin.net/registry/entity/CLOUD14


OrgTechHandle: ADMIN2521-ARIN
OrgTechName: Admin
OrgTechPhone: +1-650-319-8930
OrgTechEmail: [email protected]
OrgTechRef: https://rdap.arin.net/registry/entity/ADMIN2521-ARIN

OrgRoutingHandle: CLOUD146-ARIN
OrgRoutingName: Cloudflare-NOC
OrgRoutingPhone: +1-650-319-8930
OrgRoutingEmail: [email protected]
OrgRoutingRef: https://rdap.arin.net/registry/entity/CLOUD146-ARIN

OrgAbuseHandle: ABUSE2916-ARIN
OrgAbuseName: Abuse
OrgAbusePhone: +1-650-319-8930
OrgAbuseEmail: [email protected]
OrgAbuseRef: https://rdap.arin.net/registry/entity/ABUSE2916-ARIN

OrgNOCHandle: CLOUD146-ARIN
OrgNOCName: Cloudflare-NOC
OrgNOCPhone: +1-650-319-8930
OrgNOCEmail: [email protected]
OrgNOCRef: https://rdap.arin.net/registry/entity/CLOUD146-ARIN

RNOCHandle: NOC11962-ARIN
RNOCName: NOC
RNOCPhone: +1-650-319-8930
RNOCEmail: [email protected]
RNOCRef: https://rdap.arin.net/registry/entity/NOC11962-ARIN

RTechHandle: ADMIN2521-ARIN
RTechName: Admin
RTechPhone: +1-650-319-8930
RTechEmail: [email protected]
RTechRef: https://rdap.arin.net/registry/entity/ADMIN2521-ARIN

RAbuseHandle: ABUSE2916-ARIN
RAbuseName: Abuse
RAbusePhone: +1-650-319-8930
RAbuseEmail: [email protected]
RAbuseRef: https://rdap.arin.net/registry/entity/ABUSE2916-ARIN

So this are 2 questions:
1.) Why is Firefox listening on seemingly random UDP port?
2.) I suspect the port is random and cloudflare tries to contact that port from UDP remote port 443 which is consistent. but I'm not sure about that.

No, Firefox is fine. It is your config. Just need user input.
I believe that it is better to stay/start use Librewolf as Firefox replacement. It has all stuff disabled. Otherwise some things should be pretty obvious. I am not trying to make your life difficult but from my experience you will get annoyed fast so I suggest to use Librewolf or other browser that you trust. Anyway, you are not "hacked". What you see is default Firefox connection.

Also, addons also are making connections.

Librewolf is the simplest solution.

 

[CaffeineAddict]

@Aristarchus
Sorry but I'm not converting to another browser.

Anyway, you are not "hacked". What you see is default Firefox connection.

I need hints to derive at expert breakdown that I can verify and test myself.
I need to know what network protocols are used to study them etc. you know, have a look under the hood.

"default Firefox connection" is not very useful, it's like saying that in order to visit a website Firefox need internet connection, which is obvious but does not explain how that connection works.

 

[Aristarchus]

Just telemetry. Unfortunately to shut down these connections, you need to edit several files. Also, the problem is related to your distro packaging: what was done. I have no idea if this is pure source or more distro specific build.
If you had Firefox build just with the default settings: you need to edit about:config and omni.ja files to close all automatic connections
assuming default settings:
use Narsil's user.js and his "recipe" for cleaning up omni.ja
You can see of course what's inside user.js which will make obvious what's going on

If after this if you still have automatic connections blame your distro and yourself

user.js

user.js

codeberg.org

 

[theLegionWithin]

ran sudo ss -tunlp when both chrome and firefox were open & only chrome is listed in the output - firefox wasnt. kind of neat

 

[CaffeineAddict]

Just telemetry.

ran sudo ss -tunlp when both chrome and firefox were open & only chrome is listed in the output - firefox wasnt. kind of neat

It's not telemetry, if you read my post #3 steps to reproduce are to run youtube video, this should trigger opening local UDP port.

Since UDP is connection-less unlike TCP this means local application needs to open a listening port to able to receive UDP responses which itself initiated.

 

[CaffeineAddict]

I managed to pinpoint down why FF opens local UDP port, it's used by QUIC protocol.

I've launched the following command to determine what's happening:

sudo tcpdump -i 1 udp port 44782

And here is output:

19:12:06.568599 IP me.44782 > cache.google.com.https: UDP, length 36
19:12:06.568741 IP cache.google.com.https > me.44782: UDP, length 1252
19:12:06.568951 IP cache.google.com.https > me.44782: UDP, length 1252
19:12:06.569011 IP me.44782 > cache.google.com.https: UDP, length 36
19:12:06.569705 IP cache.google.com.https > me.44782: UDP, length 269
19:12:06.589151 IP me.44782 > cache.google.com.https: UDP, length 37

HTTPS UDP is QUIC

I still need to figure out what's causing cloudflare to probe random UDP ports from remote 443, but this is happening rarely so I'll just mark this thread as solved.

 

[Aristarchus]

I have dot, doh, quic disabled. Other vpn is waste.

 

[CaffeineAddict]

I have dot, doh, quic disabled.

Why?
DoT and DoH provide encrypted DNS and QUIC makes videos smoother and faster.

Btw. I have DoT and DoH disabled as well in web browser because using custom DoT with unbound for all DNS queries.

 

[Aristarchus]

Because if you have co figured vpn and on top of that dot/doh in browser then browser is "stealing" DNS requests and connecting to dot/doh DNS server. If you prefer dot/doh then vpn is waste and other way around too.
QUIC is not advised from privacy stand point as you proved yourself.
If you do google search the info is available.
Of course nothing is obligatory.