Windows Firewall (Windows 11) Blocks Selfhosted PairDrop, does not block pairdrop.net

[timespaced]

Setup:
2 devices: iPhone on latest iOS using Safari
Windows 11 PC on Wifi using Edge
Router/Firewall is pfSense with HAProxy, "option forwardfor" placed in backend pass thru

Issue:
Can see eachother on PairDrop.net.
Cannot see eachother on selfhosted version.
Turning off the Private Network Firewall in Windows Firewall allows selfhosted PairDrop to see eachother.

Troubleshooting:
Have tried using ip:port and through reverse proxy, neither work for selfhosted if Private Network Windows Firewall is enabled. Both work when Firewall is disabled.

Seems like I just need to let ports through the firewall maybe?

[schlagmichdoch]

Do you use https?

[timespaced]

For the reverse proxy yes, but when I access directly via ip:port, no.

[schlagmichdoch]

Sorry for the late reply!

Turning off the Private Network Firewall in Windows Firewall allows selfhosted PairDrop to see eachother.

That confirms that your configuration seems to be correct.

I'm not sure what the Private Network Windows Firewall does but I had another issue with PairDrop being falsely flagged as dangerous by Microsoft once: #102
This is different of course but I can imagine that the official instance is white listed wheras other (self hosted) instances are blocked per default.

Maybe there is a contact form for that Firewall too, I'll take a look into it.

[meichthys]

I'm also seeing this on a hardwired ethernet connection, but through wifi it seems to work. I suppose it's possibly a router issue (i'm also using pfsense for my wired connection).

[schlagmichdoch]

I do not know enough about pfsense. Could you solve this issue somehow?

[meichthys]

Although this could be a pfSense issue, related issues appear to be happening on other routers as well:
#130 (comment)

My suspicion is that it has something to do with how some routers handle certain traffic that pairdrop uses. I'm not familiar with how pairdrop works on the network level, but i know some network services like mdns can be affected by router firewalls/dns servers.

[jatin-threely]

Hey @schlagmichdoch I am also facing same issue, I hosted Pairdrop on an EC2 instance with a nginx reverse proxy and Cloudflare as a proxy. I started the server using this command DEBUG_MODE="true" IPV6_LOCALIZE=4 npm start and I am doing every thing on https with full(strict) setting of Cloudflare SSL. The hosted service is working fine with mostly every combination of devices but I am facing some inconsistency when I am using windows (windows 11) and IOS sometime they discover each other and sometimes not on a same network and I also tried it with disabling the private network firewall but facing same inconsistency.

I also tried the same thing on some other devices too ( windows and IOS ) but there I am also facing same issue.

Maybe there is something I am missing during the setup?

[schlagmichdoch]

If you take a look at your browser console in those cases where the devices appear to not find each other you will probably find that they do find each other but fail to connect via WebRTC and are therefore not shown to the user.

For some network and firewall situations apparently we need a TURN server even if all devices are on the same network.

Can you check the browser logs and try to add a TURN server?

[jatin-threely]

@schlagmichdoch yes now I am using metered TURN server and now it is stable than before but there is sill some inconsistency in message transferring like if I access my hosted one with domain name, message transferring not working between Android and macOS but if I do the same with IP it is working

Is it because of the Cloudflare?

[schlagmichdoch]

If you access you hosted instance via the domain name and you can discover devices, message transfer must work as well.
If you cannot discover devices, I'm not sure what the problem is.

1. Are there any error messages in the browser console on macOS?
2. Does you domain point to Cloudflare?
3. Is the IP address that is working the same as the IP address of you DNS entry?

[jatin-threely]

1. this is the error I can see in the console
2. Yes my domain is pointing to Cloudflare
3. Yes

[jatin-threely]

Hey @schlagmichdoch, I wanted to follow up regarding that device discovery issue and the other issues I mentioned earlier, especially after setting up the TURN server I am still facing it. I've provided all the details in my previous message, but I haven't received any feedback or suggestions yet. If there's any additional information you need from my end or if there's any workaround or update, please let me know.

[schlagmichdoch]

sorry for the delay! I was busy implementing public rooms and translations.

The error messages only say sth about the use of a STUN server. Now that you use a metered TURN server could you please provide the rtc-config.json that you are using? With redacted credentials obviously.

if you have only correctly specified the STUN server this would explain why it fails for Cloudflare, as you would probably need a turn server behind cloudflare.

[jatin-threely]

Here is the rtc_config.json I am using

{
    "sdpSemantics": "unified-plan",
    "iceServers": [
        {
            "urls": "stun:stun.relay.metered.ca:80"
        },
        {
            "urls": "turn:a.relay.metered.ca:80",
            "username": "d8ead83a4ea4c387a2875ffe",
            "credential": "xxxxxxxxxxxxxxxxx"
        },
        {
            "urls": "turn:a.relay.metered.ca:80?transport=tcp",
            "username": "d8ead83a4ea4c387a2875ffe",
            "credential": "xxxxxxxxxxxxxxxxx"
        },
        {
            "urls": "turn:a.relay.metered.ca:443",
            "username": "d8ead83a4ea4c387a2875ffe",
            "credential": "xxxxxxxxxxxxxxxxx"
        },
        {
            "urls": "turn:a.relay.metered.ca:443?transport=tcp",
            "username": "d8ead83a4ea4c387a2875ffe",
            "credential": "xxxxxxxxxxxxxxxxx"
        }
    ]
}

[schlagmichdoch]

That's odd as the error message you provided states the URL stun:stun.relay.metered.ca:443 which is not present in your config. Are you sure the config is loaded correctly?
You can check it by having a look at the browser console. There is a logged object with type: "rtc-config" which includes the config currently active.