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

[unsolicited]

John Van Ostrand wrote, On 05/26/2010 10:05 PM:
> ----- "unsolicited" <unsolicited at swiz.ca> wrote:
> 
>> I'm playing with a (different) wi-fi residential router behind my
>> main
>> 
>> home gateway.
>> 
>> I'm intentionally using the wan port, examining what's what. The
>> WAN port is getting DHCP internally, and computers on the subnet
>> get out to the internet just fine.
>> 
>> Anyone got any good links to articles that discuss this setup -
>> I'm not getting expected results, and I suspect I'm over-thinking
>> things.
>> 
>> e.g. - I'd be surprised if something like VPN made it through
>> both routers
>> 
>> to the additional internal subnet. Anyone know of articles that 
>> discuss what else might be broken?
>> 
>> - as expected, machines on the internal subnets can't talk to
>> each other. But what if I wanted them to?
>> 
>> Anyone have any favourite web links that discuss this?
> 
> I don't have articles but I do have some pointers:
> 
> 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.

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.

> 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.

> 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.

> 5.
> Complications can arise with timeouts. VPNs often use UDP packets
> and since they do not have recognizable sessions routers use
> timeouts to determine when a connection is done. Timeouts are often
> in the single digit minute range. If your VPN does not send a
> packet, say in 2 minutes, the router will forget the connection and
> response packets will not pass through. Having two routers with two
> different timers will fail using the lowest timeout.

Thankfully, VPN not in the picture at the moment, at least from here. 
Hate VPNs, nasty insecure things. Unless net to net, and appropriate 
controls can be put in place. Not saying it's not the 'easiest' way of 
dealing with things, though. (-:

I'd rather see ssh/tunnels, but such is a nightmare to explain / 
support, particularly on any scale.

My search problem is not coming up with terms that don't mean drinking 
massive amounts of anecdotal forum postings. A nice Cisco technical 
document would be welcome.

Richard's comment about a small OpenWRT box as a diagnostic tool to be 
kept in the kit bag is haunting me at the moment!

That and I haven't had to think or do such network diagnosing in some 
time. Ultimately, the answer will prove to be a typo, or self-evident. 
  Afterwards.