I have a react client running locally on my machine using react-scripts. I can work with it normally on that machine. I also have a nodeJS server running on a different port. I figured I should be able to connect to these from my other computer or cellphone and I can connect to the server using my local IPv4 address + server port, but when I try to connect to the client using the same address + client port I get a loading spinner in the browser tab and the connection times out after some time.
I figured it might be a firewall issue so I added an inbound rule (and an outbound one though I don't think that should do anything) on the machine running the client+server letting all traffic through the relevant port but this changed nothing. When I do a network diagnostic using chrome from the tab where I can't open the client it tells me the webpage is online but isn't responding. I get the same behavior when connection from my cellphone.
One thing that might be of note is that when I serve the build folder of my app through my NodeJS server, the app opens just fine on the other computer using the server port but I don't want to have to build my app after every change manually.
What could this be down to?
EDIT: Forgot to mention, all devices are on the same router. The laptop running the servers and the cellphone are connected via wireless and the PC is connected via ethernet.
Related
I have SQL Server Express 2017 running on Windows Server 2016 Standard (default instance, not named). It has remote connections enabled and is listening on port 1433 and has TCP/IP and Named Pipes enabled. I have several Surface Tablets running Windows 10 and Windows 11. These tablets make a VPN connection to the server to connect to SQL Server. All of the tablets, except one of them, can connect to SQL Server. All tablets connect using the server's IP address and with SQL Server Authentication. All tablets are connected to the same WiFi router - both the ones that CAN connect and the one that CANNOT, so I believe router settings are not the problem.
The tablet that fails to connect can ping the server successfully. It cannot, however, telnet to port 1433 on the server - this times out. All other tablets can make the telnet connection. Also, using sqlcmd to connect (sqlcmd -S ip-address -U user-name -P password) works on all tablets except the one. This returns error 53. Checking the SQL Server logs after attempting to connect using sqlcmd shows no errors. So this tablet is definitely not even reaching SQL Server.
I have disabled all Windows Firewall options on the tablet with no change - still cannot telnet or connect via sqlcmd.
I have walked through multiple remote connection troubleshooting guides step by step, but most of them assume that NO remote systems can connect to SQL Server. In this case, it is just one system. So I know that the server is configured properly to allow remote connections. I just cannot determine what is different about this one tablet that is preventing it from making a connection.
What might be preventing this one system from making this connection? Any settings or other options I should be looking at?
SOLVED: After performing tracert on multiple systems that connect to this server including the problem tablet as well as attempting to telnet to various ports at the server's IP address, I discovered that the WiFi network that the tablet was on had a conflicting IP address with the server. The previous tablets that tested fine were, unbeknownst to me, on different wifi networks that did not have this conflict. As a result, this tablet was attempting to connect to a completely different device despite being properly connected to the server's network via VPN.
So the additional piece of advice to add to this troubleshooting process would be to very closely scrutinize the output of ipconfig /all. Even though you may be connected to the network of the SQL Server system you are trying to connect to remotely, if the IP of the SQL Server system is duplicated on your local network, it can be very difficult to see that all of your connection attempts are actually routing to a different system - that is why the connection is failing.
What to look for in ipconfig /all... check the client system's IP address and the default gateway that it is using. If these are using private IP addresses (as most do) most commonly starting with 192.168.x.x, and you are trying to connect to SQL Server over VPN via which the server also has a private IP address, check if your local subnet is matching the server's subnet. For instance, both the client (tablet) subnet and the server subnet were 192.168.20.x There's a chance for an IP address conflict in these conditions.
Another check that I found was helpful was, on the client, to DISCONNECT from the remote server and then try to ping the SQL Server IP address. If the ping succeeds, the server's IP address is being duplicated by another system.
I'm connecting remotely from home (Workgroup) Win7 PC to an office (Domain) Win7 PC using VPN and Remote Desktop. Remote Desktop connects fine but doesn't share my local resources no matter what I do. So to print from host (office) to client (home) I've set up printer network sharing (it's an HP printer connected at home via USB) and created a separate regular user without login privileges. Every several weeks something happens and the connection stops working.
Most recently, connection attempts to the remote printer return error 0x00000709.
Troubleshooting I've done:
Turned off firewall on both RDP client (home) and host (office) computers
Confirmed \\x.x.x.x\c$ is accessible from host to client
Cleared all connections using "net use" in command prompt (\\x.x.x.x\IPC$ usually appears after I open explorer to the client machine IP address and authenticate with the workgroup user account)
Confirmed the client VPN IP address is the same (when it changes, I have to reconnect the printer via explorer)
On client, tried to connect to printer via \\localhost in explorer and got the same error.
It drives me crazy that this works for a while and then stops with no apparent rhyme or reason. Windows updates might be the cause but the last update since this last happened was Microsoft Removal Tool (this morning) and it doesn't make sense this would cause the problem.
Any ideas what to try next?
Thanks
Ultimately, disabling IPv6 on the home PC's Local Connection adapter resolved the issue.
During troubleshooting, I was able to connect the office PC to another home PC (connected over AnyConnect VPN client) for file and print sharing, further complicating root cause analysis. I used WireShark to check outgoing packets from the office PC but was unable to check incoming packets on either home PC due to encryption on the VPN interface. WireShark revealed SMB connections were being successfully requested, opened AFAIK, and closed.
The issue was temporarily resolved when I rebooted both the target home PC and the Cisco ASA. This resulted in a new VPN IP address being assigned to the home PC. The issue returned 1-2 days later. Logging into the office PC with a different domain account did not resolve the issue. Disabling IPv6 on the home PC's Local Connection adapter did resolve it. I thought to do this after noticing the public IP address given on whatismyip.net was an IPv6 address, where in the past I've always seen an IPv4 address.
I hope this helps someone.
I have a RPi running an instance of volttron-central. I can VNC into the RPi and view the Web UI from a browser pointed to localhost, so I know that it is running. However, when I attempt to connect from a PC connected to the same LAN using the RPi's IP address, I get "refused to connect" error.
Is this a security feature? If so, is there any-way of viewing the WEB UI from a different machine, or does it need to be running an instance of volttron-central locally?
Edit your config file to use an external address (e.g. not 127.0.0.1). In VOLTTRON_HOME (~/.volttron) edit the config file. Change the bind-web-address setting to equal (what you have above as 192.168.1.4) to http://192.168.1.4:8080. Then restart the platform.
Note: you should also make sure your /etc/hosts file has a mapping from the 192.168.1.4 onto your hostname, then you could goto https://foo:8080 rather than using the address. This will work with the bind-web-address, but not the vip-address.
I am trying to connect from a NoMachine client on a Windows 7 machine to an OpenSUSE machine. I can only connect via NX however I keep running into Error 138:Connection Timed out. I can connect via SSH on my Command prompt however Seem to be unable to connect via here. Does anyone know a solution - been doing this since morning with no light in sight!
Routers supporting UPnP or NAT-PMP are configured automatically to pass connections to NoMachine and all required information is displayed at initial screen (Welcome to NoMachine).
Routers not supporting UPnP or NAT-PMP and Firewalls have to be configured manually to pass traffic to port 4000 (NX protocol), 22 (SSH protocol on Linux/MacOSX) or (4022) (SSH protocol on Windows).
So, check the configuration first.
I have a similar issue setting up my ftp server.
There are a couple of possibilities why the connection was not established, but in my case, and perhaps yours, you must allow the service you're trying to execute in your firewall settings.
In my case I allowed the ftp port and some other specific port for tcp communication.
This (and the proper service, router, etc setup) allowed the communication to be established.
Objective : I am trying to establish a test environment with a test server instance running on a static machine. I wish to be able to connect/make use/test code against this server running from all other machines on the same local network.
Problem :
I am unable to establish a connection to the appserver that is running on a machine with static ip. It's an appengine server and runs without errors ( tested ). Connection can be established from the browser on the local machine but when trying to connect from any browser on another machine in the same network then no connection is established.
The same setup is made available for jenkins server and jenkins dashboard can be accessed from all other machines in the network.
If you are running a local version of app engine, you can use the --host option.
dev_appserver.py --host=0.0.0.0 myapp
The host address to use for the server. You may need to set this to be able to access the development server from another computer on your network. An address of 0.0.0.0 allows both localhost access and hostname access. Default is localhost.
https://cloud.google.com/appengine/docs/python/tools/devserver
For java, use the --address option instead.