[HowTo] ssh to wl-500g under corporate proxy

Just would to share my expirience how to get connected to wl-500g if you are sitting behind
corporate proxy/firewall which disallowed either direct internet nor
"corp.proxy"->"wl-500g: port 22" connections.

The main steps are:
1. Start ssh daemon on yours wl-500g.
2. Create post-firewall script if one doesn't exist.
3. Change (add) iptables rules to redirect all incoming on port 443 traffic to port 22.
4. Configure your ssh client (I've tested with putty and WinSCP3) with your current proxy authetication settings and instruct to use port 443 instead of port 22.

Remark:
It works for me on wl-500g Deluxe router with Oleg's 1.9.2.7-4 firmware (as usual many thanks to Oleg :)).

Now a little bit more details:

Step 1: This is very good described by Oleg - how to get dropbear daemon running. Look here: http://wl500g.dyndns.org/ in section "Ssh and telnet daemons"
Step 2: For creating an empty post-firewall script please follow the procedure described by Oleg in the same document. But don't forget to put as first string following:

Code:

#!/bin/sh

Step 3: As I'm not really professional in network administration things, so I've learn those from alpha5's topic http://wl500g.info/showpost.php?p=8990&postcount=2 (thanks to alpha5 :))
Please add following strings to your's post-firewall script:

Code:

iptables -D INPUT -j DROP iptables -A INPUT -p tcp -m tcp -d 192.168.1.1 --dport 22 -j ACCEPT iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 443 -j DNAT --to-destination 192.168.1.1:22 iptables -A INPUT -j DROP

Save it and also don't forget to commit changes to flashfs as following (or in different way as you like):

Code:

flashfs save && flashfs commit && flashfs enable

Reboot yours wl-500g.

Step 4: Depending on yours ssh client set apropriated proxy settings (usual HTTP proxy) like address, port number, username and password. And most important thing: Instruct this client programm use port 443 instead of port 22.

Enjoy.

Quote:

Originally Posted by kiewer

3. Change (add) iptables rules to redirect all incoming on port 443 traffic to port 22.

An easier way to do this is to tell dropbear to listen on both port 22 and port 443 (using the "-p 22 -p 443" command line switches), and then just open the firewall to accept connections from the WAN on port 443.

-- Rod

Quote:

Originally Posted by rwhitby

An easier way to do this is to tell dropbear to listen on both port 22 and port 443 (using the "-p 22 -p 443" command line switches), and then just open the firewall to accept connections from the WAN on port 443.

-- Rod

I don't understand. Why don't just listen to port 22 and modify the INPUT chain to accept connection from the WAN on port 22 ? Why must we bother with port 443 at all ?

Cheers

Quote:

Originally Posted by mctiew

I don't understand. Why don't just listen to port 22 and modify the INPUT chain to accept connection from the WAN on port 22 ? Why must we bother with port 443 at all ?

Cheers

Corporate proxies often don't pass port 22, but do pass port 443 (for HTTPS traffic). That's what this thread is all about, right?

So people want external access to be on port 443, but LAN access to still be on port 22.

-- Rod

Quote:

Originally Posted by rwhitby

Corporate proxies often don't pass port 22, but do pass port 443 (for HTTPS traffic). That's what this thread is all about, right?

So people want external access to be on port 443, but LAN access to still be on port 22.

-- Rod

That's being the case why pick 443 ? Should just pick a big obscure number instead of 443, example 22443.

Cheers

Quote:

Originally Posted by mctiew

That's being the case why pick 443 ? Should just pick a big obscure number instead of 443, example 22443.

Cheers

Because usually port 80 and port 443 is *all* that the corporate firewall proxy passes.

-- Rod

Quote:

Originally Posted by rwhitby

An easier way to do this is to tell dropbear to listen on both port 22 and port 443 (using the "-p 22 -p 443" command line switches), and then just open the firewall to accept connections from the WAN on port 443.

-- Rod

Just didn't know that. Thanks.

So if I understand correctly, this approach would create a SSH-"tunnel" from a client pc in the corporate LAN, through port 443 (designated to traverse HTTPS connections) into the WL500G router, using PuTTY (or alike).

Now I wonder: I have read several statements that you can use a SSH-"tunnel" to route VNC traffic.

If I want to use a tunnel to a pc at home (192.168.1.15) which is running behind my WL-500G router (192.168.1.1), would I need to apply something like this in post-firewall?:

Code:

iptables -D INPUT -j DROP iptables -A INPUT -p tcp -m tcp -d 192.168.1.1 --dport 22 -j ACCEPT iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 443 -j DNAT --to-destination 192.168.1.15:22 iptables -A INPUT -j DROP

How can I use VNC to connect to a remote pc behind the WL-500G router, using a SSH-"tunnel" that is opened with PuTTY?

Quote:

Originally Posted by ikerstges

So if I understand correctly, this approach would create a SSH-"tunnel" from a client pc in the corporate LAN, through port 443 (designated to traverse HTTPS connections) into the WL500G router, using PuTTY (or alike).

No it doesn't create a ssh-tunnel. This is a simple port redirection. Unfortunatly I can't explain more about ssh-tunnel, because never did it.

The tunneling is very easy. but not done on the router side, but on the client side.

In putty (ssh client) go to the SSH->Tunnel tab

the source port is the port you want to connect to locally

so in your case you want to do
sourceport: 5900
destination: 192.168.1.15:5900
if you run vnc on a different port than 'display:0' than the 5900 becomes more
e.g. display 3=port5903

I hope somebody will please bare with me here?!..

I connect from the corporate office to my home LAN.

I Am able to SSH to my wl500g now. For that, I have changed my post-firewall so it forwards WAN connections that are coming in on port 443 to port 22 for SSH.

To SSH to the wl500g, I enter in PuTTY:
Connection/Proxy: HTTP with corporate browser proxy name and portnumber.
Session: Protocol=SSH, Host name=TestMyLogin.dyndns.org and Port=443

This opens the connection and I'm able to enter username and password.

Now I try to enter the tunnels information as informed in previous post for a VNC connection to a pc in my home LAN. I have entered:
Connection/SSH/Tunnels: Source port= 5900, Destination= 192.168.1.15:22:5900.
I clicked on 'add' to add this tunnel information to the PuTTY session. With this added tunnel to the session, I'm able to login on my wl500g.

But now:
I run VNC-viewer and try to open a connection to 'localhost', but this gives a timeout. I also tried run VNC-viewer and open a connection to TestMyLogin.dyndns.org (as I'm not sure how to understand this connection over SSH-tunnel) and again: timeout. GRRRrrrr....

Do I need to change the tunnel-destination to run on 443 instead of 22 in the Connection/SSH/Tunnels in PuTTY?
To what host do I connect VNC-viewer when running a connection over the ssh-tunnel?

Google is my best friend, I got it working..

The tunnel setup in PuTTY needs to be set as: Source port= 5900, Destination= 192.168.1.15:5900 and have VNC-viewer connect to localhost on my pc at the corporate network.

(Mind: without the :22 that I had in previous posts!)

I'm a happy camper now!

connection refused throught port 443

Hi all,

After I upgraded to version 1.9.2.7-7e, I've followed this how to. Now I'm able to connect to my router from the outside trought port 22 but not from the 443 as desired. The connection is refused. I don't know if I've something wrong in my configuration. My router's internal ip is 192.168.1.21. I don't understand very well the iptables...just starting. Just check out my configuration please:

[cocas@router root]$ cd /usr/local/sbin/

[cocas@router sbin]$ ls
post-boot post-firewall

[cocas@router sbin]$ ls -l
-rwxr-xr-x 1 cocas root 19 Jul 13 13:33 post-boot
-rwxr-xr-x 1 cocas root 230 Jul 13 13:45 post-firewall

[cocas@router sbin]$ cat post-boot
#!/bin/sh
dropbear

[cocas@router sbin]$ cat post-firewall
#!/bin/sh
iptables -D INPUT -j DROP
iptables -A INPUT -p tcp -m tcp -d 192.168.1.21 --dport 22 -j ACCEPT
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 443 -j DNAT --to-destination 192.168.1.21:22
iptables -A INPUT -j DROP

Now the status of the table filter and table nat:

[cocas@router etc]$ iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
VSERVER all -- anywhere bl8-162-17.dsl.telepac.pt
NETMAP udp -- anywhere bl8-162-17.dsl.telepac.ptudp spt:6112 192.168.1.0/24
DNAT tcp -- anywhere anywhere tcp dpt:https to:192.168.1.21:22

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
NETMAP udp -- 192.168.1.0/24 anywhere udp dpt:6112 85.241.162.17/32
MASQUERADE all -- !bl8-162-17.dsl.telepac.pt anywhere
MASQUERADE all -- 192.168.1.0/24 192.168.1.0/24

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain VSERVER (1 references)
target prot opt source destination

[cocas@router etc]$ iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all -- anywhere anywhere state INVALID
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere state NEW
ACCEPT all -- anywhere anywhere state NEW
SECURITY all -- anywhere anywhere state NEW
ACCEPT tcp -- anywhere anywhere tcp dpt:ftp
ACCEPT tcp -- anywhere router tcp dpt:ssh
DROP all -- anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
DROP all -- anywhere anywhere state INVALID
TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN tcpmss match 1453:65535TCPMSS set 1452
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
SECURITY all -- anywhere anywhere state NEW
ACCEPT all -- anywhere anywhere ctstate DNAT

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain MACS (0 references)
target prot opt source destination

Chain SECURITY (2 references)
target prot opt source destination
RETURN tcp -- anywhere anywhere tcp flags:SYN,RST,ACK/SYN limit: avg 1/sec burst 5
RETURN tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/RST limit: avg 1/sec burst 5
RETURN udp -- anywhere anywhere limit: avg 5/sec burst 5
RETURN icmp -- anywhere anywhere limit: avg 5/sec burst 5
DROP all -- anywhere anywhere

Chain logaccept (0 references)
target prot opt source destination
LOG all -- anywhere anywhere state NEW LOG level warning tcp-sequence tcp-options ip-options prefix `ACCEPT '
ACCEPT all -- anywhere anywhere

Chain logdrop (0 references)
target prot opt source destination
LOG all -- anywhere anywhere state NEW LOG level warning tcp-sequence tcp-options ip-options prefix `DROP '
DROP all -- anywhere anywhere

congratulations for the FW... very nice.

Regards

This is just working fine ! Thank you ! But i was just wondering why we use the post-firewall script instead of the "virtual server" feature from the web interface....