[ntp:questions] NTP over redundant peer links, undetected loops
davehart at gmail.com
Mon Feb 16 22:13:26 UTC 2009
On Feb 16, 8:57 pm, "Richard B. Gilbert" <rgilber... at comcast.net>
> Dave Hart wrote:
> > On the nonroutability of RFC1918 addresses, have you ever seen someone
> > try to VPN back to their home network from a hotel network and fail
> > miserably because the hotel network and the home network have
> > conflicting ideas of how to route RFC1918 addresses?
> RFC-1918 address are non-routeable by definition! They are intended for
> PRIVATE networks where the nodes need not be accessible from outside.
> Generally, any link with the outside must be initiated from inside.
> (Don't call us, we'll call you!)
Give me a half-ounce of credit, please. Yes, they are not routable on
the global internet. To suggest they are therefore never used by
machines with internet routes or never seen except in disconnected
islands is a vision from the past in need of a serious reality check.
> You can reach your home system from your hotel by addressing the
> external address of your router and selecting a port that the router
> will map to something you can talk to and can talk to you. This
> requires some setup on your router before you leave home!
The problem is on the client side of the VPN. I am in hotel NAT
cesspool 192.168.1.x, say 192.168.1.101 gateway 192.168.1.1. Now I
want to connect up a an IPSEC or PPTP tunnel to my home network, sure
I target the single public IP on my router for the VPN connection, but
when it comes up my local IP stack has a problem. You see, my network
at home is also in the ever-popular 192.168.1.x subnet. Every time I
try to send a packet to my desktop machine at 192.168.1.10, my IP
stack tries to deliver it to some other hotel NAT cesspool customer,
and the packet never makes it to the VPN. There are a million
variations possible. Build a B2B link between two companies whose
network architects didn't plan in advance for that scenario.
More information about the questions