[kwlug-disc] Web references on issues of router behind router?

[John Van Ostrand]

----- "unsolicited" <unsolicited at swiz.ca> wrote:
> John Van Ostrand wrote, On 05/26/2010 10:05 PM:
> > 1. Make sure the subnets are different. e.g. use 192.168.1.x on one
> > router and 192.168.2.x on the other.
> 
> Yes, that's taken care of.
> 
> > 2. If #1 is good, then you
> > should be able to have the inner subnet access the outer subnet's
> > systems.
> 
> Not happening, which is baffling me. It's a Cisco PIX off Roger's 
> modem, and debug packet inside <subnet>/24 sees nothing. Wireshark on
> 
> another machine never sees incoming packets from the WAN IP. Darned 
> strange. I expect the inner WAN to MAC find the outer one. Otherwise 
> it should go to the gateway and be routed back internally. [Seems to 
> me coming in and going back out the in is verbotten, but I also seem 
> to remember that had to do with routing protocols.] If nothing else, 
> after the first 'go here' the remaining packets would go directly.

Routing back is generally not done. It's also called hairpinning, because of the hairpin one would have to draw to show packet travel. I've done it on routers here at the office for convenience, now I use split DNS.

Hair-pinning doesn't work because of this:

1. Device "A" 192.168.1.100 sends packet to device "B" 1.2.3.4 (an address on your firewall).
2. Your firewall receives the packet, looks to it's NAT table and realizes this packet is for an inside system, say 192.168.1.200. It rewrites the destination address from 1.2.3.4 to 192.168.1.200 and passes the packet along.
3. Device 'B', the destination, gets the packet and sends a reply. The source IP for the packet is 192.168.1.200 and the destination is 192.168.1.100. The packet is sent directly back to device 'A' instead of the firewall since they share a LAN.
4. When Device 'A' receives the reply packet it looks to see what connection it relates to. It looks in it's table and finds a connection to 1.2.3.4, but that can't be it since this packet is from 192.168.1.200. It assumes the packet is erroneous and drops it.

One way to get hair-pinning to work is to perform SNAT on the packet on the firewall. That way Device 'B' will send the packet back to the firewall and it will be de-SNATed. 

The idea that your inner router (PIX) will perform ARP on it's WAN to route to your outer LAN.

Like this:

[Inner LAN] ---- [PIX] ---- [Outer LAN] ---- [Linksys?] ---- [Internet]

Structurally the Inner LAN to Outer LAN is identical to a typical home Internet connection, just change the labels. 192.168 addresses are called non-routable and some routers are configured so as not to route those addresses.

It's possible that the PIX has some setting for that.
 
> Problem is I don't have a dual NIC <something> around to put 
> transparently between the WAN and the rest of the network to see if 
> it's actually sending something out or not. Or the router is just 
> blocking everything to it's WAN subnet. The router can ping 
> everything, but not something behind the router. And, of course, the 
> outer can't ping the inner - no outgoing nat translation is present.

How about a linksys with OpenWRT? I bet you could set up port mirroring, or use the openwrt packet inspector.

> > 3. VPNs like openvpn should work fine. IPSec can work as
> > well, but it's trickier.
> 
> I'm actually thinking coming in from outside, not the reverse. But 
> it's reassuring to read your point.

So you have to orchestrate some firewall rules. In the process it can be confusing, certainly at first, to keep IP addresses correct.

> > 4. PPTP (is anyone still using this?) can
> > have issues with multiple VPNS sharing the same IP address.
> 
> Why would you have multiple VPNs? Assuming machine or net to net 
> connections. After that, it should all just be routing.

Multiple PCs going out to the same VPN server. I see it occasionally with customers.
 

-- 
John Van Ostrand 
CTO, co-CEO 
Net Direct Inc. 
564 Weber St. N. Unit 12, Waterloo, ON N2L 5C6 
Ph: 866-883-1172 x5102 
Fx: 519-883-8533 

Linux Solutions / IBM Hardware