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.
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 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.
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.
What I can do:
can connect to desktop Win10pro from phone (wifi/data)
can connect to desktop Win10pro from laptop Win10pro (wifi only)
can connect to desktop Win10pro from work Win7 (desktop)
can connect to desktop Win10pro from TeamViewer
Problem:
When I try to connect to my desktop from my laptop using the usb ethernet dongle, everything listed above seizes to function; only a black screen after logging in. Keep in mind, this setup did work 5 months ago, only thing that changed was that I reset/refresh my laptop because it became bogged down and switched from college to home.
What I've tried:
System Restore on the host desktop
sfc /scannow both host and laptop
resetting network adapter and settings on laptop
checking regedit to make sure 3389 was listening on laptop
disabled/enabled NLA
disabled/enabled RDP on host desktop
enabled RDP on latop
uninstalled network adapter and reinstalled on laptop
turning off wifi on laptop and then trying to connect
If anyone has any other suggestions, that would be awesome.
UPDATE: As someone suggest to get a new USB Dongle, went out and bought one. Still does not work. Extremely laggy and black boxes everywhere.
What solved my issue was using the internal ipv4 address when I am on the local network; else, using the external ipv4 when I am away from home.
Thing to note is that even when I was internally using ipv6, I had a huge issue with this and could not connect to it internally using external ipv4 with :3389 at the end of it.
Hope this helps someone.
I installed Oracle 11g Standard Edition on my machine ( Windows 7 X64 ) and configured a listener. While being on the network , when I tried to connect through Jdev 11g , connection was successful. But when I'm off the network , I'm not able to connect to the Database thru Jdev. EM console is not opening too.
Is there any way I can connect to Database while I'm not on the network ?
Your listener has to be configured to listen to your localhost internal interface, 127.0.0.1, for you to be able to connect when not on a network.
If it's only configured with your network adapter's IP address you will only be able to connect while on the network. When you unplug your LAN cable the interface associated with that IP is disabled and no longer reachable, even from within your PC. You will also have problems if your IP is allocated by DHCP, and would need to use a DNS name that follows reallocation; that's why servers usually have fixed IPs.
You can configure the listener to use both addresses if you need to be able to connect locally when off the network, but have other clients connect to your database when you are on the network. Having a DB that others need to access on a machine that isn't always connected would be a bit odd though.