search

aspnet / SignalR

[Archived] Incredibly simple real-time web for ASP.NET Core. Project moved to https://github.com/aspnet/AspNetCore
Apache License 2.0
2.38k stars 448 forks source link

Firewall blocking SignalR requests #2987

Closed Moolie closed 5 years ago

Moolie commented 6 years ago

Recently, I notice clients behind 'corporate' firewalls have trouble using pages on my site that use SignalR. I have seen Barracuda firewalls rejecting calls to /signalr/hub and /signalr/negotiate with a 406 status code (the latter after replacing /signalr/hub with a physical file).

There might be other firewall manufacturers as well that have updated their filters, and block SignalR functionality.

Has anyone else experienced this? We now tell these clients to update the firewall settings (whitelisting our domain or whitelist SignalR in general), not much else I can do about it AFAIK.

benaadams commented 6 years ago

Are you running over https? Proxies have historically had problems with websockets

Also https://www.devopsdude.uk/SignalR-WebSockets-And-Barracuda-WAF/ (seen in https://serverfault.com/questions/899339/enabling-websockets-signalr-with-a-barracuda-waf)

analogrelay commented 6 years ago

As @benaadams said, WebSockets can have this problem with certain corporate firewalls. However, SignalR should be falling back to a different transport in this scenario.

Can you provide more information regarding your environment?

Also, can you collect client and server logs as described in the Diagnostics Guide?

davidfowl commented 5 years ago

Are you using https?

Moolie commented 5 years ago

I'm using https, and my first guess when this problem occured was that it was the websocket issue. First I tried forcing long polling: didn't help. Then I found out that the signalr/hubs script failed to load with status code 406, as seen in this screenshot:

signalr_chrome_cloud

I checked the IIS logs of the server (Windows server 2012 r2) and found no evidence of the server generating the 406 status code, so it seemed the rejected call never reached the server.

I concluded it must be a proxy/firewall issue on the client side (our customer had this issue when using a VM, when he was using his own laptop everything was fine). Since /signalr/hubs returns a javacript file but doesn't have a .js extension, I tried generating a physical file as described in https://docs.microsoft.com/en-us/aspnet/signalr/overview/guide-to-the-api/hubs-api-guide-javascript-client#manualproxy

Now the file would load, but the negotiate call would be rejected with status code 406 (again, not generated by the server): negotiate406

The multiple negotiate calls are caused by a reconnect mechanism I built in. As you can see, websockets have not even come in play yet, the calls before that are already being rejected.

More info:

Server logs don't show anything, and I need to work on the client logs: I need to arrange a client showing this behaviour. Can't ask my customer to hand over his VMware client to me :).

For the record: we had multiple customer that were affected by the initial symptom: /signalr/hubs not loading. It seems that replacing that by a physical file has solved the issue for some, but I'm still researching. So client installations might vary.

davidfowl commented 5 years ago

Wait, this is the wrong version of SignalR (we know that's confusing). This repository is for ASP.NET Core SignalR. You're using ASP.NET SignalR. We'll move this issue to the appropriate place.

analogrelay commented 5 years ago

This issue was moved to SignalR/SignalR#4215