I am getting connection time out when I try to ssh to my Azure VM on a specific ISP provider, not any other ISP provider. I did notify them about this issue but they do not know what might seem to be the issue.
Also tried to create a new rule to open port 22 on windows Machine, followed all Azure troubleshooting methods, disabled my Firewall, but nothing seems to work, Only when I connect to a different ISP provider.
Please take note that the ISP through which you were trying to connect to your Azure VM over port 22 through SSH is blocked over public internet owing to various server side vulnerabilities. The vulnerabilities that the SSH server side is prone to includes Port forwarding, unauthorised SSH access, vulnerable SSH configuration, pivoting and unpatched SSH software. Along with Port 22, most ISPs also block SMB port 445 also on the public internet owing to frequent and hot instances of brute force as well as software manipulation attacks. Since, users are not known to take care or take appropriate security measures for avoiding such attacks, so the ISPs block the inbound as well as the outbound traffic on these ports overall.
You can check by connecting through some other ISP or using cell phone internet in that case as these ports are not blocked over there.
Related
I have an account in chatgpt but as I located in the restricted country, I tried to use AWS proxy (US server) to login chatgpt. Few weeks ago it worked but now I get an error message access denied error code 1020. I used tinyproxy in stealth mode at first but since I was unable to pass through the cloudflare, I guessed probably the proxy was not good enough to disguise itself as a proxy, so I tried squid vpn in stealth mode and algo vpn, but all did not work(Tried other AWS countries server as well other than US). Until now, I figure out chatgpt might probably just banned all connection from amazon or perhaps my proxy is just not smart enough to pass through cloudflare? What are more options? Any recommended free vpn proxy that I could installed into my AWS EC2 or perhaps I should try other less known cloud services instead? e.g. (other non-restricted country's local cloud services) Besides, I have consider using other free proxy from the internet but as I need to login my gmail, is it danger to do so but since its https so my username and password should be encrypted?
I have the same problem, simple ssh tunneling works you can use a jump server to bypass your country first and than use different server to use as proxy because some of your vps servers get banned with IP, so you may have to use another vpn with different proxy
ssh -D "port to make SOCKS 5 Connection like" <10808> -J <"user">#<"jump server IP"> <"user">#<"final server IP">
than you can use "foxyproxy" extention to build SOCKS5 proxy that uses specified port in this example 10808 to route your browser terrafic through tunnel in port 10808 to final server
or you can use something like sshuttle, but i was fine with this simple tunneling method in GFW
So, I've encountered a weird situation and am wondering whether you may have some suggestions as to how to investigate it...
I have a C# app that connects to Azure Blob Services using the latest SDK and TLS 1.2. When I am at home and on the Internet, I am able to upload files to blob storage without any issues. However, when I go into our office, using the same app on an office computer, I get a connection failure. I am able to access the Internet through a browser.
The networking is as simple as at my home... ISP connection, router/firewall, my computer.
I cannot imagine why enabling TLS1.2 would suddenly make my app not work in the office, but still work at home. Based on these tests, it seems like a NIC issue or an infrastructure issue at the office, but I have never heard of a NIC or router blocking TLS 1.2 outside of a VPN connection. There is no VPN involved.
I am planning on directly connecting my computer to the company's Internet connection, configuring the nic for the wan, and see what happens. If it works, then there must be something strange going on with the company's router (nothing elaborate; netgear, or such).
Has anyone encountered this issue? Seems really odd to me...
Thanks for your time and interest,
Mike
• It is not an issue with enabling of TLS 1.2 on your office network or your home network or even your Azure blob storage, it is basically related to the communication over SMB TCP port 445 from your local system to the mapped Azure blob storage on your system.
On your home network, you were able to access the blob storage and able to upload files in it because your ISP has enabled outbound communication over SMB TCP port 445 on his firewall and gateway server over the internet and thus, you were able to access the mapped Azure blob storage and upload files in it. But the same case is not valid for in your office network as it being a protected one, outbound communication over SMB TCP port 445 is restricted and not allowed.
• To test whether communication over TCP SMB port 445 can happen or not, I would request you to execute the below powershell command and check the results thereafter: -
Test-NetConnection -Port 445 -ComputerName somestoragexxx.file.core.windows.net
If this TCP 445 connectivity fails, then you could check with your ISP or your on-premises office network security is blocking communication over outbound port 445. Please note that you should open the outbound port instead of inbound port 445.
Kindly refer to the documentation link below for details to know the different ways to access files in Azure files: -
https://learn.microsoft.com/en-us/azure/storage/files/storage-files-faq#general
Also, refer to the link below for knowing the Azure routing mechanism to reach the resources hosted on Azure: -
https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview#default
I have the following setup:
2 computers (Cmp.A and Cmp.B)
Computers run Windows 10 and I have admin rights on both machines
Cmp.A is simultaneously connected to 2 VPN networks (different domains) using different solutions
Cmp.A has got OpenSSH server installed and enabled
Cmp.B should access the internet and all private domains (coming through the VPNs) via Cmp.A
Cmp.B should resolve host names through Cmp.A
in other words: DNS traffic should be resolved through Cmp.A as well
Currently, I achieve this by connecting to Cmp.B to Cmp.A via SSH which gives me a SOCKS proxy in the SSH tunnel. Cmp.B has got ProxyCap installed which routes all traffic (including DNS) to Cmp.A.
This setup works pretty well for me, but there's one ugly setback: ProxyCap does change the Winsock configuration of my Windows 10 (on Cmp.B) which results in incompatibility problems with my other applications. When I execute netsh winsock show catalog it does return dozens of new entries related to ProxyCap and I don't want this (if possible)
I would like to avoid using ProxyCap and save myself from an application messing around with such OS level socket settings, but I need all traffic (not just browser traffic) to go through Cmp.B.
Wrapping it up, my questions are:
How do I route all Win10 network traffic (including DNS) thorough another Windows 10 computer (over an SSH SOCKS5 proxy) without using ProxyCap?
How do I make Windows to resolve DNS through my already existing SOCKS5 tunnel?
I have a scenario where I have a Windows VM in windows Azure that needs to connect to an external customer network (and connect to a database that is not in Azure).
This traffic is uni-directional in that it is only my VM that needs to connect to the customer's databases and not the other way around. Site to site is managed on Azure, which I cannot really test locally.
Conceptually, connecting to the customer's network via a point-to-site VPN seems more suitable (by creating the VPN connection in Windows itself via the network config).
The customer prefers site-to-site even though they don't need to connect to my VM. Am I missing something?
In point-to-site, you have to connect to the network you want to access manually. Usually, if you log-off or restart the workstation it loses connection, and you have to reconnect every time. It's common to use this type of VPN when we are working remotely, and we need to access our company assets. The channel is bi-directional, but it's 1-to-many.
Site-to-site is used when you want to connect two networks and keep the communication up all the time. It's also bi-directional, but it's many-to-many and stays up no matter if your server/workstation is running or not because the connection is established through a network gateway and not from the computer operating system.
In Azure, the Virtual Network Gateway is the platform providing both functionalities. You can configure site-to-site to connect to your customer network. If this network is not running in Azure, they usually have an appliance to establish dedicated tunnels. As long as it supports IPsec IKE, you are good to go.
If you are using the VM in Azure as a workstation, then point-to-site may be enough, but if your application needs to get data from the customer database automatically with or without someone logged in the VM, then site-to-site is a better approach.
A better explanation can be found here
I have a client who is remote. I need to debug some weird problem that none of my other clients are having. Before I try and set up a conference with this client, I would like to know if there is some way of remotely debugging our application.
I see that there are remote debugging tools available for Visual Studio, but from what I've read, I need to be on the same subnet. As the person is remote, this is not a possibility. Also, as I'd like to keep our connection secure, I would need to connect up some sort of encrypted tunnel (this is where I'm a little fuzzy as my networking skills are mostly theoretical).
As I understand it, an encrypted tunnel is a bridge to another (different) subnet. This is to ensure that those computers on the other side won't interfere with the local subnet computers.
So, because the client's computer is on a different subnet, I think that this is not possible. Or is it? Should there not be a way of making the client's computer show up as a virtual computer on my subnet, by forwarding packets from one subnet to another? I would think that this is theoretically possible, but I'm not exactly sure how I would go about this.
Also, at the moment, my current way that we connect to clients is through GoToMeeting, but I don't think that it supports tunneling. If not, then I may need some way of generating a tunnel, so I was also thinking of maybe using some SSH programme like PuTTY.
As I have said before, my knowledge of networking is quite theoretical, so if the tools that I am suggesting are not the correct ones, please correct me. (I'm a programmer, damm it! Not a network engineer!)
Both computers are Windows boxes. Windows 10 (client) and Windows 8.1 (development).
If you can connect to an ssh server in the remote network, you can (subject to configuration on the server) create a tunnel such that you connect to a socket on your local pic and the connection appears from the server to an endpoint on the remote network.
You'll want to investigate the -L command of OpenSSH, which combined with the PuTTY docs, should help explain what's required.
By default, the endpoint would be a port on the ssh server, but it could be a port on a different host that the remote server can connect to.
I'm not familiar with the current state of Windows SSH servers, but even if there isn't a system server to hand, you should be able to have on run 'on demand' - if you run it on a non-privileged port and by the user you want to connect in as, it shouldn't even need Admin privileges.
I'm not familiar with GoToMeeting, but the one thing with SSH tunnelling it that IT depts should be familiar with SSH. If trying that, focus on getting a working connection in, then setting up the tunnel, then connecting through it as separate steps.
Once you have an SSH connection, then it doesn't need to do something itself, and you can then investigate connecting while specifying the port forwarding, but will will need to get the basic connection working correctly first.