Port forward NAT (broadband router) port 22 to the server PC at home.SSH tunneling is a really neat all-purpose technique for getting TCP/IP traffic securely from you to a remote server. Block localport 22 in/out from any IP, TCP/UDP (make sure the firewall rule ordering does not cancel the above).Optionally: Allow localport 22 in/out from local server intranet, TCP only.Allow localport 22 in/out from Work IP only, TCP only. ![]() ![]() Add more loopback adaptors with different IP addresses (and incremental port numbers using netsh for same reasons as given for 8080 vs 8081 above) for each Samba share if needed. Netsh interface portproxy add v4tov4 listenaddress=192.168.2.123 listenport=445Ĭonnectaddress=192.168.2.123 connectport=44445Ĭonfirm lanmanserver is running and rule is correctly applied: sc query lanmanserver Start console window (run as administrator): sc config lanmanserver start= delayed-auto So it is required to delay startup of lanmanserver (make sure IpHlpSvc driver is running) and install a portproxy rule. However, lanmanserver driver uses this port for all interfaces. It needs to be on a seperate interface to represent another PC. Additional actions for port 445įile share needs to be accessed using TCP port 445. one tunnel of port 8080 and one of 8081 rather than two 8080's. It may not be necessary to use 8081 on second interface but there were some unusual behaviours occuring when connecting to different web servers in this manner which were fixed by using only one "instance" of a port 8080 tunnel i.e. SSH client will forward them to the specified location (inside the corporate network). SSH server will listen for connections to these ports and direct them to the SSH client. Generally, the remote connection requests a tunnel to be created on the specified interface and port. Here for example, a webserver on client network at 192.168.12.34:80 (assuming it is accessible when dsat at the client PC) can be accessed from the ssh-server PC by visiting 192.168.2.123:80 on the server PC, which was redirected using the netsh command to 192.168.2.123:8080, which is then being listened to by the ssh-server (after the connection is made using the -R option above) and tunnelled to 192.168.12.34:80 within the client network. Use these ports in the SSH command line (SSH to this host from a remote client, setting up a tunnel from the remote server side instead of -L local client side): -R 192.168.2.123:8080:192.168.12.34:80 The above netsh commands have redirected ports lower than 1024 to the higher port numbers (ready for the SSH tunnel to use) but so far nothing is using them. See also Additional actions for port 445. ![]() Netsh interface portproxy add v4tov4 listenaddress=192.168.3.123 listenport=80 connectaddress=192.168.3.123 connectport=8081 One time only (persistant) otherwise elevated permission would be required for ssh (cant tunnel ports below 1024 as user): netsh interface portproxy add v4tov4 listenaddress=192.168.2.123 listenport=80 connectaddress=192.168.2.123 connectport=8080 The same reasoning also occurs below for connections to two seperate web-servers on port 80.Įxample set in host file: #127.0.0.1 .required alias another-alias #commentġ92.168.2.123 myworkpc #445 -> 44445 (reminder of which ports intending to use for this 2nd IP local subnet)ġ92.168.2.123 myalias #80 -> 8080 (nb: these ports are actually set below)ġ92.168.3.123 anotherPClongname anotherPC #80 -> 8081 (note that this is 3rd IP local subnet to avoid conflict with above) This method is required to ensure Windows File Sharing is working locally as well as via ssh because connections to multiple devices on the same port 445 are required. all could be mapped to 127.0.0.1 if the port numbers where unique. ![]() Note that physical servers might be allocated to a single connection locally e.g.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |