search

SignalR / SignalR

Incredibly simple real-time web for .NET
http://signalr.net
Other
9.2k stars 2.28k forks source link

Firewall blocking SignalR requests #4215

Closed analogrelay closed 6 years ago

analogrelay commented 6 years ago

From @Moolie on Thursday, 20 September 2018 15:26:14

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.

Copied from original issue: aspnet/SignalR#2987

analogrelay commented 6 years ago

From @benaadams on Thursday, 20 September 2018 15:47:20

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

From @anurse on Thursday, 20 September 2018 17:32:54

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?

analogrelay commented 6 years ago

From @davidfowl on Saturday, 22 September 2018 05:46:10

Are you using https?

analogrelay commented 6 years ago

From @Moolie on Saturday, 22 September 2018 12:54:21

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.

analogrelay commented 6 years ago

From @davidfowl on Saturday, 22 September 2018 15:57:19

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 6 years ago

@Moolie It looks like the Barracuda firewall is the one rejecting the request if you're not seeing the server issue the 406. Is there any way to get logs from the firewall? It sounds like you'll need to configure the firewall to allow this traffic, but first we need to track down why the firewall is blocking the request :).

Moolie commented 6 years ago

I've requested some logs.

analogrelay commented 6 years ago

I'm going to close this for now since we aren't able to do much more without logs. When you get some more information from your firewall, please feel free to re-open so we can continue investigating!

Moolie commented 6 years ago

Sorry, it was a false alarm. Our hosting provider put a Geo IP block on the /signalr path (that we never requested them to do :/), and any client using a proxy with an IP address from another country would experience this issue.