We successfully installed the Azure connect end point and we are able to establish a connection between our Azure application and the end point. That's the good news!
The bad news is there is a web application on the same Windows machine which users access on their intranet over port 5555. As soon as we finished installing the end point, users started complaining they were no longer able to access the web application
over port 5555. We uninstalled the Azure Connect end point and the situation was back to normal.
Does it work fine if use another port, such as 6666? In addition, do you have multiple on-premises machines joining the same Connect group? If so, you may have problems because each machine has two network identities now: One intranet network identity and
one Connect VPN identity. The Connect VPN identity may take precedence. So you need to use the full name of the machine (such as bright-pc.corp.XXXX.XXXX.com) instead of a short name (such as bright-pc). Or use Connect’s IPv6 address instead of Intranet
IPv4 address. You can find the full name and the IPv6 address on Connect portal.
To answer you first question: there are no other local machine connected to same Connect group, it's the only one.
Regarding your second point: is it the expected behavior that the VPN identity takes precedence? It there a way to restore the precedence of the IPv4 identity? The reason why it's important is because there are a lot of users who are using
http://server01:5555/ to access the server. We woud prefer not to have to change all the bokkmarks, re-train our users, etc.
I just tried it but seems cannot reproduce the problem you mentioned. What happens if you ping server01 from your local machines? If it works the 5555 TCP port may be blocked somehow. Could you check the Firewall settings of the web server? Please also post
the error message when the users try to connect server01:5555.
As far as we know the Firewall is not enabled on this machine. Ping was successfull and also we were able to open a RDP session to the server.
The error message that users were getting when attempting to connect to
http://server01:5555/ with Internet Explorer was: "This program cannot display the webpage". We uninstalled the Azure Connect end point and users were immediately able to resume connecting to
http://server01:5555 without any problem.
you may have problems because each machine has two network identities now: One intranet network identity and one Connect VPN identity. The Connect VPN identity may take precedence.
The more I think about your idea the more I think it makes sense: it might be a DNS issue where the new IPv6 takes precedence and our users don't have IPv6 on their machines. If that's the case, would it be possible to make sure the IPv4 takes precedence?
It seems is not DNS issue as you can successfully ping server01. This means your users' machines can successfully connect to the web server. Could you provide the following information to help me narrow down the problem?
3. Test whether it works if you add another web site (for instance , listen on server01:6666).
4. Check the default web page of
http://server01:5555. Please try to replace with a static file such as .txt to see whether it works. It can help to exclude possibility that the web app relies on something that is somehow changed by the installation of Windows Azure Connect.
As I could not reproduce this issue this problem is likely to be caused by the environment specific issue. So I need more information to narrow down. Thanks!
I have a second customer who exprienced the exact same problem today so we had to uninstall the end point. He also lost the ability to connect to port 5555 after we installed the Azure Connect end point. This setup was working perfectly fine prior to the
installation and also the situation returned to normal after we uninstalled it.