There’s surprisingly little info about this on the Internet. Most of the documentation for routing – whether it’s a little “blue box” from Best Buy™ or a Dell Poweredge running OpenSuse with several “eth” interfaces – just assumes that your topology will always be
internet --> Router --> Network Switch -> [all the other PCs]
or even (a router box with three NICs):
internet --> Router --> Network Switch #1 --> [group of PCs]
|
---> Network Switch #2 --> [group of PCs]
There’s plenty of discussion about how to get the second group to see the first, or to do DNAT on incoming packets into either group. What I want to do is,
Internet #1 --> Router --> Network Switch --> [group of PCs]
|
Internet #2 --> separate PC, two NICs -
In case that last drawing doesn’t make complete sense, I want to DNAT through the 2nd Internet connection to a machine on the first network. I’m having a wonderful time making this work. The PC on the first network is running SSHD. I know the server is running and that my routing on “separate PC” must be at least halfway right, because I can SSH from “separate PC” into that PC on the first network just fine. But when I set up the DNAT rule on “separate PC” and try to go in with SSH from outside the building, the connection just times out.
Incidentally, I’ve also had trouble with this topology using a “blue box” router on another similar setup. I wanted a second Internet path into a particular local network and never could get that to work, either.
I’ve seen references on line that say that the targeted PC in the local network must use the router (“separate PC” in this example) as a gateway. I’ve tried that with no luck.
I realize this is both unusual and a tad advanced, but what am I missing? Do the routing gurus here have any suggestions? Any response is deeply appreciated.
(Signed copies of my wonderful ASCII network art are also available, suitable for framing. lol! )
The main thing to remember is that routing is stateless. You sort of think there must be a way to make packets remember which router they came in on so that you can make the reply packets go back the same way. But no, packets go where the route rules tell them to.
Ok, the easy solution is for “separate PC” to NAT the packets from Internet 2 so that the connection appears to come from “separate PC” and not the outside world.
There might be a way to work out using the LARTC guide to mark and track the connection, but I don’t feel up to delving into that.
I thought that was what I was doing. The connection coming in to “separate PC” via Internet #2 is being NAT’d over to the PC on the local network. But I’ve suspected what you say – I’m probably reaching the local PC on the incoming, but the outgoing replies don’t know where to go.
Sigh. Guess it is indeed time to look at the LARTC again.
But on the other hand … I thought about this on the way to work.
Routing is indeed stateless, but if we’re talking about IP addresses on the local network, they’re ARP’d. To send the reply, the network stack in the SSHD machine should look at the IP address, apply the netmask and see that it’s local, and then use ARP to find the target (which would be the second NIC on the “separate PC”). Ergo, I suspect that “separate PC” can’t figure out what to do with the reply. That’s what I’m looking at how.
Here are the IP addresses, by the way.
216.x.x.1 192.168.50.99
Internet 1 --> router --> network switch --> Target SSHD machine
|
216.x.x.2 192.168.50.38 |
Internet 2 --> separate PC --------
If the ssh packet has a source IP of 192.168.50.38 then yes, it will be go back to “separate PC” which will then reverse the NAT and send it back out to the Internet.
On the other hand, if the ssh packet has a source IP of the sender in the outside world, then 192.168.50.99 will say, that’s not a local IP, so I will send it to the default gateway which is the router, not labelled with an IP in your diagram. So the packet wiil (try to) go back a different route from the one coming in. Which may be a problem if there is connection state in the router.
You are (were) absolutely right, and this is proof that even an old dog like me can learn something every day.
I’m posting back in case someone runs across this thread in a Web search. The Shorewall FAQs have a good discussion of this (Shorewall FAQs). For some reason, I just assumed that when the DNAT occurred, it would change the source IP to that of the routing machine. It doesn’t. So, as you correctly point out (and as I observed quite clearly with Wireshark), the incoming packet is still marked with the public IP from the Internet. When the target machine tried to ACK reply to the SYN packet on the initial connection attempt, it was sending the reply through its default gateway.
Solution: either set the default gateway on the target machine to point to the PC doing the DNAT routing, or create a really ugly mangle rule that changes the IP on the packet headed to the target machine.
There’s another way around this and that is to use ssh forwarding. Say the alternate gateway is A and the target machine is B. From the outside you do:
ssh -L 2200:B:22 A
That says, make localhost port 2200 a tunnel to B port 22. Then open up another terminal session and do:
