On Feb 16, 10:34 pm, "Richard B. Gilbert" <rgilber...@comcast.net> wrote: > Dave Hart wrote: > > 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. > > I think your problem is that you are trying to use an RFC-1918 address > to access your desk top. You must address the packet to your home > router's external IP address. Your home router must be configured to > map some port on the router to the RFC-1918 address of your desktop. > Pick an arbitrary port number greater than 1024 and less than 65536. > Configure your router to send all traffic addressed to that port to the > RFC-1918 address of your desktop. Let's assume that your router has > been configured to send incoming traffic addressed to port 2009 to your > desktop. When you connect from outside, you simply send to port 2009 at > your external IP address and your router should hand it to your desktop.
VPN means Virtual Private Network and it means using one network (usually the internet) as an underlying transport to connect parts of another. The problem I describe is a conflict between the IPs used on the private network I'm connecting to via VPN from my laptop, and the private network addresses used by the, ahem, internet provider. Even though those IPs are not publicly routable, it isn't hard to come up with real-world scenarios where devices see private addresses as well as public and communicate with both. Given the ambiguity of a widely- shared RFC1918 address as a refid, I suggested and still suggest that if ntpd is changed to using a single refid across all interfaces RFC1918 should only be used as last choice. Cheers, Dave Hart Cheers, Dave Hart _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
