FQDN not Resolving
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
The 'ssh -L 8080:<rdphost>:3389 user@host' command would be executed on the remote host I'm connected to, not the local Windows machine I'm on. So how would Windows know to do the redirection you're talking about?
Actually that is where it is run. It's just done from the GUI.
I don't understand, please explain.
I do understand that the PuTTY client itself has it's own VPN connection via the SSH. What I'm trying to understand is how are you telling windows to do the port forward?
It's in the tunnel section.
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
The 'ssh -L 8080:<rdphost>:3389 user@host' command would be executed on the remote host I'm connected to, not the local Windows machine I'm on. So how would Windows know to do the redirection you're talking about?
Actually that is where it is run. It's just done from the GUI.
I don't understand, please explain.
I do understand that the PuTTY client itself has it's own VPN connection via the SSH. What I'm trying to understand is how are you telling windows to do the port forward?
SSH is, like anything of its type, a form of VPN in and of itself. If you use SSH, you are a VPN client under the hood.
-
@Dashrender said:
@johnhooks said:
Yes, with PuTTY. But even if you are on a Linux desktop or laptop, wouldn't you want RDP access from that? Maybe I'm misunderstanding you. This is just so you can access RDP remotely inside your network.
How does PuTTY give you this on a Windows machine? When I'm running PuTTY on my windows machine, I'm connecting to another server, not my local host. There's nothing local about it.
The 'ssh -L 8080:<rdphost>:3389 user@host' command would be executed on the remote host I'm connected to, not the local Windows machine I'm on. So how would Windows know to do the redirection you're talking about?
You can also do the reverse with ssh -R. This will allow you to connect a local port to a remote port on another system. A simple use case for this would be you are working on a web site locally and want to show someone else really quickly. They can open localhost:8080 on their remote system and see your site on their end. You don't have to use 8080 in these scenarios, just a port I picked.
-
@Dashrender I wanted to do a quick demo for you. This is on my Chromebook, but I used the default SSH app, because most people aren't going to have it set up the way I do. I used ChromeRDP and attempted to connect to 127.0.0.1:8080 to show it wouldn't work, then connected normally to my Server 2012. Then, I ssh with tunneling and connect to Server 2012 at 127.0.0.1:8080.
-
@scottalanmiller said:
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
The 'ssh -L 8080:<rdphost>:3389 user@host' command would be executed on the remote host I'm connected to, not the local Windows machine I'm on. So how would Windows know to do the redirection you're talking about?
Actually that is where it is run. It's just done from the GUI.
I don't understand, please explain.
I do understand that the PuTTY client itself has it's own VPN connection via the SSH. What I'm trying to understand is how are you telling windows to do the port forward?
SSH is, like anything of its type, a form of VPN in and of itself. If you use SSH, you are a VPN client under the hood.
Yes I understand that.. but how does PuTTY put itself into the network stack to do a redirection?
A normal VPN does exactly that - it inserts itself into the network stat and redirects as needed.
I think an SSL VPN client requires local admin rights to be able to do the same thing, but ON Windows, I know that RDS/RDP also has a way of tying into a browser to encapsulate the traffic into the SSL tunnel, but really only RDS, not other applications running on Windows, say the accounting softtware - that would require a full blown VPN Client install, or a SSL VPN client that did the same as the full blown one, and installed itself into the network stack.
Are you guys saying that PuTTY has a way to insert itself into the network stack?
-
@johnhooks said:
@Dashrender I wanted to do a quick demo for you. This is on my Chromebook, but I used the default SSH app, because most people aren't going to have it set up the way I do. I used ChromeRDP and attempted to connect to 127.0.0.1:8080 to show it wouldn't work, then connected normally to my Server 2012. Then, I ssh with tunneling and connect to Server 2012 at 127.0.0.1:8080.
But Chromebooks are based on Linux, so it's not the same as doing it on windows.
So with Chromebooks I totally understand how this is working... you are opening a terminal session to your local machine.. then running a command which will interact with the network stack.
-
@Dashrender said:
Yes I understand that.. but how does PuTTY put itself into the network stack to do a redirection?
A normal VPN does exactly that - it inserts itself into the network stat and redirects as needed.
No, that's not how they work
-
@Dashrender said:
@johnhooks said:
@Dashrender I wanted to do a quick demo for you. This is on my Chromebook, but I used the default SSH app, because most people aren't going to have it set up the way I do. I used ChromeRDP and attempted to connect to 127.0.0.1:8080 to show it wouldn't work, then connected normally to my Server 2012. Then, I ssh with tunneling and connect to Server 2012 at 127.0.0.1:8080.
But Chromebooks are based on Linux, so it's not the same as doing it on windows.
So with Chromebooks I totally understand how this is working... you are opening a terminal session to your local machine.. then running a command which will interact with the network stack.
How does being Linux or Windows change anything? What makes you feel that one is unique in how this works?
-
@Dashrender said:
I think an SSL VPN client requires local admin rights to be able to do the same thing,
Think about the fact that every HTTPS web page has a VPN tunnel opened by the user. They are able to open that channel without needing admin rights. Same here.
-
@Dashrender said:
, but really only RDS, not other applications running on Windows, say the accounting softtware - that would require a full blown VPN Client install, or a SSL VPN client that did the same as the full blown one, and installed itself into the network stack.
?I don't understand what you are thinking here. Why do you feel that apps need to be that way?
-
@Dashrender said:
@johnhooks said:
@Dashrender I wanted to do a quick demo for you. This is on my Chromebook, but I used the default SSH app, because most people aren't going to have it set up the way I do. I used ChromeRDP and attempted to connect to 127.0.0.1:8080 to show it wouldn't work, then connected normally to my Server 2012. Then, I ssh with tunneling and connect to Server 2012 at 127.0.0.1:8080.
But Chromebooks are based on Linux, so it's not the same as doing it on windows.
So with Chromebooks I totally understand how this is working... you are opening a terminal session to your local machine.. then running a command which will interact with the network stack.
It's the same as here. You add the arguments in this screen:
Just the same as if you were using X11 forwarding
-
Where's the network shim come from?
If I have a local app sending packets to port 8080, and those are being forwarded to another IP on whatever port is assigned, that happens because a shim is in place, right?
a shim in this case is a good thing
-
@Dashrender said:
Where's the network shim come from?
If I have a local app sending packets to port 8080, and those are being forwarded to another IP on whatever port is assigned, that happens because a shim is in place, right?
a shim in this case is a good thing
https://chamibuddhika.wordpress.com/2012/03/21/ssh-tunnelling-explained/
localhost isn't the client you are on, you're accessing localhost on the remote system on port 8080
I guess I did say your localhost above, I apologize for the confusion.
-
@Dashrender said:
Where's the network shim come from?
If I have a local app sending packets to port 8080, and those are being forwarded to another IP on whatever port is assigned, that happens because a shim is in place, right?
a shim in this case is a good thing
No, not a shim at all, a tunnel. Very different. This is a normal application using the normal network stack. In no way is this shimming or hijacking or modifying the stack.
-
You can help me understand this later...
Where I am falling down is.... How does the locally installed RDS client know to send its traffic to the tunnel and not the normal network card?
-
@Dashrender said:
You can help me understand this later...
Where I am falling down is.... How does the locally installed RDS client know to send its traffic to the tunnel and not the normal network card?
The SSH server you log into is the one that that RDS is communicating with. Like in the image below, replace yahoo with the RDS server.
-
In looking at this graphic, the browser is on the opposite side of who is creating the SSH tunnel..
if you move the SSH to the work side... and leave the browser on that same side.. will it still work? -
The work side is creating the tunnel, and using their browser. The SSH server is on the home side.
You can easily flip it around and have the SSH server be on the work side and the home side connecting through the browser.
-
Well it only took nearly all day to understand what @johnhooks and @scottalanmiller where talking about... but now I do.
It works because the RDS client is not pointing to yourservername.domain.com or even your internal IP address.
Instead the RDS client is told to use localhost or 127.0.0.1. The local machine then, through a forwarder put in place by PuTTY sends all traffic destine for PuTTY assigned port to PuTTY and PuTTY forwards the traffic over the tunnel to port 3389 at the address set in the SSL -L command previously run.
OK I understand.
THANK the Maker! -C3P0
