Any Azure gurus around?
-
Cross-posting from ServerFault:
I've got a custom web server that I uploaded to an Azure VM running Windows Server. It accepts HTTP connections on port 80, and websocket connections on port 2468. Everything works fine locally, but on Azure, the HTTP connections will connect but the websocket connections won't.
In the Azure Network Security Group attached to the server, both ports are open for incoming TCP connections. In the Windows firewall for the server, both ports are open for incoming TCP connections. Netstat shows that my process is listening on port 2468, but Microsoft Network Monitor never shows any incoming connections on port 2468 when I try to connect from my browser.
All the stuff I know of to make sure the connection will work, I've done for both ports, and it works for port 80. How do I figure out what's keeping my websocket connections from working?
Note: this is a custom server app, not running on IIS, Apache, etc. Answers should be purely Windows Server/Azure related.
-
I assume when you say the firewall is accepting port 2468, you are talking about the firewall settings in the portal itself?
You may need to RDP to the VM and make sure there's no separate setting in the OS that is blocking that port for whatever reason. AFAIK Azure VMs come with its own anti-virus and other features that might also be blocking it on that side.
-
In the Azure Network Security Group attached to the server, both ports are open for incoming TCP connections. In the Windows firewall for the server, both ports are open for incoming TCP connections.
-
I seem to recall something about there being 3 kinds of levels influencing a Network Security Group with each having settings which could be overridden by another level. Sadly I cannot remember how to get to it or how it's exactly called.
-
@jbert There's two and he has them both covered.
I remember there was some chatter some time back about some ISPs blocking websocket traffic for stupid reasons, have you eliminated that possibility?
I don't remember Websocket, but do you also need to open UDP traffic for it?
Sorry that's about all that's in my head right now. You might get more responses on stack overflow if you don't assume the problem is with Azure-- it could just as easily be with Windows Server, or something in your app.
EDIT: you said your server never registers any connection attempt; does the client report any error? If so, what? Could it be as simple as putting it on Azure changed the domain name, and now you're butting up against browser XSS protections?
-
@blakeyrat said in Any Azure gurus around?:
@jbert There's two and he has them both covered.
I remember there was some chatter some time back about some ISPs blocking websocket traffic for stupid reasons, have you eliminated that possibility?
My ISP certainly isn't; sites such as StackOverflow, GitHub and this forum, which use Websockets to take care of pushing updates to the browser, work fine.
I don't remember Websocket, but do you also need to open UDP traffic for it?
Wikipedia says: "WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection."
Sorry that's about all that's in my head right now. You might get more responses on stack overflow if you don't assume the problem is with Azure-- it could just as easily be with Windows Server, or something in your app.
I assume it's either with Azure or Windows Server. The app works just fine, at least at the "establish an initial connection" level.
EDIT: you said your server never registers any connection attempt; does the client report any error? If so, what? Could it be as simple as putting it on Azure changed the domain name, and now you're butting up against browser XSS protections?
The client reports that it can't establish a websocket connection to the server. Nothing about XSS. I did make sure that on the server, the page it's serving up tells it to connect to the server and not to localhost. Good thought, though. :)
-
Upon further testing, trying to run the HTTP server on port 2468 and the websocket listener on port 80, I'm still able to connect on port 80 and not on port 2468. So apparently it's not protocol related at all; even though both firewalls are open on both ports, stuff is only getting through on port 80...
-
Taking a step back, from someone completely unfamiliar with Azure and merely browsing the "How to create a network security group" thing, but did you make sure your NSG is associated with the right subnet/network interface?
-
Finally got this working. There was one little detail in the firewall configuration that I missed: on the rule for port 2468 I put that port in on both Source and Destination, and apparently that's a mistake and it should only be on Destination. Fixing that made it work.
-
@masonwheeler said in Any Azure gurus around?:
and apparently that's a mistake
Unless the client is setting the port it's sending from, instead of defaulting to a random one from the ephemeral range, then yes.
There's very few protocols (I can't actually think of any well-known common ones[1]) that specify the port the client packets must come from.
[1] One in-house protocol we use at work used to be like this, but I managed to get that changed.
-
@masonwheeler said in Any Azure gurus around?:
Finally got this working. There was one little detail in the firewall configuration that I missed: on the rule for port 2468 I put that port in on both Source and Destination, and apparently that's a mistake and it should only be on Destination. Fixing that made it work.
Oh. See that's what I meant by opening up your question-- that's a mistake you could have made on any firewall product, it really has nothing to do with Azure.
-
@pjh said in Any Azure gurus around?:
@masonwheeler said in Any Azure gurus around?:
and apparently that's a mistake
Unless the client is setting the port it's sending from, instead of defaulting to a random one from the ephemeral range, then yes.
There's very few protocols (I can't actually think of any) that specify the port the client packets must come from.
Actually, there are quite a few applications that constrain the client port to a known value so that the server only has to open that specific incoming. Thus, while the protocol supports using any port (ideally in the proper dynamic range) these attempts are most likely to fail. Note, when doing this it is extremely rare to use a client port the same as the server port.
-
@thecpuwizard said in Any Azure gurus around?:
Actually, there are quite a few applications that constrain the client port to a known value so that the server only has to open that specific incoming.
For most applications, that's a bad idea in a subtle way: it prevents two users on the same machine from using the same client software. I guess that could be of use occasionally, but it's usually a pain. Specifying the client IP address is useful though; it lets you stop all sorts of nonsense on systems with multiple network adapters. (That's quite common now — wired and wireless — and can cause real pain when the OS gets confused about which is which. Alas, I've seen that happen in the wild…)
-
@dkf said in Any Azure gurus around?:
@thecpuwizard said in Any Azure gurus around?:
Actually, there are quite a few applications that constrain the client port to a known value so that the server only has to open that specific incoming.
For most applications, that's a bad idea in a subtle way: it prevents two users on the same machine from using the same client software. I guess that could be of use occasionally, but it's usually a pain. Specifying the client IP address is useful though; it lets you stop all sorts of nonsense on systems with multiple network adapters. (That's quite common now — wired and wireless — and can cause real pain when the OS gets confused about which is which. Alas, I've seen that happen in the wild…)
Yes, that is quite common, but IP spoofing is trivial. I have decimated the security of many a corporate network [as part of PEN testing, duly authorized).
The more tool's one has in their toolbox (on both sides of the game), the more interesting the game becomes :)
-
@thecpuwizard said in Any Azure gurus around?:
Yes, that is quite common, but IP spoofing is trivial.
I wasn't thinking about it from that perspective: just about making sure that the damn messages go to the machine they're supposed to. ;) I do work with quite a bit of kit that likes to sit on its own physically separate network (often just plugged straight into a spare network socket on a host computer) and that in turn has some interesting consequences as not all computers run by default the services needed to let it autoconfigure. Of course
hilaritymisconfiguration happens.In terms of bandwidth, recent USB might be slightly better, but that has other constraints and we'd need to get our hardware people to knock up an adapter that runs on our FPGAs to do that. (At least it isn't using classic serial lines or parallel ports! Those were electrically simple, and a PITA…)
-
-
@masonwheeler said in Any Azure gurus around?:
@dkf said in Any Azure gurus around?:
we'd need to get our hardware people to knock up an adapter
What, you didn't know how they fuck things up to make new things? ;)
