I tried to get access to private windows vm through iap tunnel with the following:
gcloud compute start-iap-tunnel win-vm 3389 --zone=us-central1-a
However, when I try to connect to localhost:port with the Remote Desktop is unable to connect and show error 204.
I already added permission role IAP-secured Tunnel User
I also added the firewall configuration to allow rdp on port 3389, and it fails. I allowed all ports. but rdp is still failing.
when using external ip , the rdp is working correctly.
Anyone know how to fix this?
Related
Unable to run the test for the webapps running in cloud ( application is accessible via browser only through VPN). Getting error.
You must first setup a tunnel from testRigor to your machine, then try accessing the page.
Read the tunnel documentation.
Set up a tunnel on your machine.
Request a port from testRigor support
Then run your test
Docs for setting up a tunnel:
https://docs.google.com/document/d/1MMQ9WBwRTSPUI589PKv5YxiyM7r5rE1K5iP_Dj5xl0Q/edit#
I'm currently trying to connect to my Virtual Machine with Windows Server 2012 Datacenter and connect to it via Certification Test Tool 1.2 for Azure. And always getting this error:
Connecting to remote server xyz-vm.westeurope.cloudapp.azure.com
failed with the following error message: WinRM cannot complete the
operation. Verify that the specified computer name is valid, that the
computer is accessible over the network, and that a firewall exception
for the WinRM service is enabled and allows access from this computer.
By default, the WinRM firewall exception for public profiles limits
access to remote computers within the same local subnet. For more
information, see the about_Remote_Troubleshooting Help topic.
I guess the tool is using PSRemot so I checked that:
"winrm" is running.
"PS Remoting" is enabled in the firewall.
Port 5985 and 5986 are in the network security group in Azure and at the local VM Firewall allowed.
I tested the connection via Test-WSMan and I got a connection:
screenshot. But the connection with the Certification Test Tool still failed.
Even after turning the Firewall of the VM completely of, it didn't work
Thank you for your Help
Can you please run in cmd on the Virtual Machine netsh winhttp show proxy
If this shows port 8080 could you then run netsh winhttp reset proxy
According to #Shengbao Shui - MSFT
For a existing VM, you also check this blog. You need create a self-certificate and enable https.
I am getting below error message when I try to access one of the AWS Cloud Servers through"Enter-PSSession" cmdlet. I have Admin rights on the server and provide the necessary credential as well but still no gain. Please help to resolve or suggest alternate way to remotely access the Server.
------------------Connecting to remote server XYZ.XXXXXX.com failed with the following error message : WinRM cannot complete the
operation. Verify that the specified computer name is valid, that the
computer is accessible over the network, and that a firewall
exception for the WinRM service is enabled and allows access from this
computer. By default, the WinRM firewall exception for public
profiles limits access to remote computers within the same local
subnet. For more information, see the about_Remote_Troubleshooting
Help topic.
Make sure that the server behind that name has the proper IP address.
You can do that if you ping the host name, and then ping the turned IP with attribute -a
Ping server.com
Ping -a <IP returned by that hostname>
If the second ping return different hostname, thats were you have problem.
If it does not return any hostname, then it might be behind switch or firewall rule that does not allow reverse lookup.
If everything is good, try to see if the WinRM is working with the following command
Test-WSMan <hostname or an IP>
If that is return the ProductVersion then that machine has WindowsRemote Manager enabled.
If that is not working then you dont have windows remote management enabled on that machine, and of course check the firewall.
But if you dont have an issue here then you better check if you have CredSSP enabled/disabled, but for that you would need to read a bit more, here is a nice article about it :
https://4sysops.com/archives/using-credssp-for-second-hop-powershell-remoting/
And if after all that you still have the issue, make sure you know if you are using Certificates to authenticate, if thats the case it really depend on how your PKI is all set.
Make sure the remote host is reachable over you network .
if reachable over network, make make sure remoting is enabled on the derstination server.
if windows firewall service is not running, start it on the destination server .
Sorry for the basic question but im a complete noob on those matters.
I have a cloud server where i run a jup[yter notebook server, which normally is run on port 8888.
However when i try to connect to it from work, it doesnt work, which i suspect is due to the firewall.
I can connect from work to a regular ssh session through port 22 or 443.
However the jupyter notebook refuses to be run on those ports, probably because they are allocated already.
I tried to run PortQry to get the open ports on my work server (which is windows) and it reurned port 50248. I tried to have my jupyter server to listen on that one but it didnt work.
I also tried to scan the open port of my work server, but i received a warning from AWS! And the few ports that were returned as seemingly opened didnt work either when i set up my jupyter notebook to listen on them.
I would like to understand:
On my own server: How can i identify which port the jupyter server program can listen on?
On my work machine: How can i identify which one of my own server port would be let through the firewall of my work?
You need to use SSH local port forwarding.
https://help.ubuntu.com/community/SSH/OpenSSH/PortForwarding
You will open a SSH connection to your server but a local port, lets say 4444, will connect over the SSH connection and resolve to 8888 on the remote server.
With this you'd be able to open a browser locally and go to localhost:4444 and it would resolve to your remote hosted site. The command for this locally would be something like -
ssh -L 4444:localhost:8080 yourremoteserveraddress
An alternative option would be to use a SOCKS proxy via dynamic forwarding but this would involve needing to reconfigure your browser.
Always keep in mind any company policies around this type of thing. Even though 22 and 443 are open to the internet, use of them in this manner may break a policy and there is always the possibility of the company using a MITM proxy to monitor for this type of usage, specifically on 443.
I created a Google dataproc cluster. After logging into master node I started spark-shell then trying to access spark history page using
http://<external_ip_masternode>:4040
It get redirected to
http://<hostname_mastername>:8088/proxy/application_1487485713573_0002/
Browser is rejecting with error "DNS address could not be found." which is understandable.
Following are VM instance setting
Public IP type Ephermal
tcp:4040 opened in firewall
ip forwarding Off: Unable to edit this configuration
Following troubleshooting done but did not help
Telnet to :4040 -> Working
Access from Ubantu host/ browser Chrome: Getting redirected and name lookup failure
Access from Ubantu host /browser Firefox: Getting redirected and name lookup failure
Access from Mac OSX host /browser Safari : Getting redirected and name lookup failure
Access from Mac OSX host/ browser chrome : Getting redirected and name lookup failure
To view Hadoop web interfaces in Dataproc, it is recommended to follow the instructions for running an SSH-based SOCKS proxy: https://cloud.google.com/dataproc/docs/concepts/cluster-web-interfaces
If you follow the instructions there, it'll also have you run a separate browser session using your SSH tunnel, and sets hostname resolution to occur on the VM side of the tunnel. That way, all the links in the Hadoop pages will automatically work, since they all reference each other using internal hostnames, and intentionally avoid any dependency on "external IP addresses".
Using the SSH tunnel is also much more secure than opening up firewall rules to visit the unencrypted HTTP traffic directly coming from the Hadoop HTTP servers (if you accidentally open up your firewall rules too broadly, then other people on the internet will be able to access your external IP addresses, and even if you don't, attackers could see your unencrypted web traffic served up by the ApplicationMaster, HistoryServer, etc.).