iptables as a proxy

Question

I'm not sure how to start better so i'll be straight. I have to travel to a foreign country, but i need access to a server that is local to my hometown network. I have a DD-WRT router with only my PC connected behind it. So my question is: Can i make some iptables rule that will allow me to connect to my router from outside network ( foreign country ) and will redirect me to my local network ( ISP provided ). I'll try to make a "map" of my need.

/Me - X/  
/My router - R/  
/Internet - I/  
/Local Server - S/  

My typical way to access S ( Local Server ) is as follows: X-R-S My typical way to access internet is: X-R-I My need is: R<--I<--X ( then from R i connect to S )
This is because i can not access S from outer network.
When i'm not in home there is no active PC behind the router so i can't just run proxy on it.

Answer 1

This should be relatively trivial; for SSH something like this should be fine:

iptables -t nat -A PREROUTING -p tcp \  
  -i ppp0 --dport 22 \  
  -j DNAT   \
  --to-destination 10.10.10.10:22

Assumption: The external interface of R is ppp0. That's the incoming interface to which the rule should apply.

Assumption: The IP Address of S is 10.10.10.10 - substitute the correct one of course.

What this does is "destination NAT"; basically exactly the same as "normal NAT" only it replaces the destination address with the internal server's, and undoes it on the way back. To use this, all you need to do on X is to run ssh R instead of ssh S to be connected to the sshd on S (this will only work if X is currently not on the internet, but on your internal network; you'd need to also run SNAT - "normal" or source NAT - to get the replies from S to be sent via R, and you'd need to change the rule from "-i ppp0" to "-d <external address of R>", to make it match when the packets are received from inside, not just from the outside; as you can tell, it gets a bit hairy).

Note: This can of course be done for any other ports as well, but I'd really strongly recommend against exposing Samba (Windows sharing), or unencrypted HTTP (unless it's public, unauthenticated content anyway). Or anything else, really. They're nontrivial to secure, where at all possible, so piggybacking on SSH's port forwarding is going to save you many headaches.

Except that Samba forwarding is hard, so you'd best try to do completely without that.