Re: NTP over redundant peer links, undetected loops

On Feb 16, 10:34 pm, "Richard B. Gilbert" <rgilber...@xxxxxxxxxxx>
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
.

Relevant Pages

  • Re: Connecting to Home Computer
    ... cannot transmit IP packets outside the local network). ... assigned by your router. ... You have to add the port too, ... Determine the ports (pcAnywhere uses 5631 for DATA, 5632 for STATUS, I ...
    (microsoft.public.windowsxp.work_remotely)
  • Re: Webcam with SBS-2003
    ... unless he was trying to create some kind of DMZ for the camera. ... attached to a port on the Westell router with an IP ... NICs and the network. ...
    (microsoft.public.windows.server.sbs)
  • Re: Remote Desktop Web Connection
    ... Or that the Web Client ActiveX control runs on the local computer, ... Windows Network Technology Community - ... >The router is what is restricting you from reaching multiple machines. ... and it understands rules about passing packets on port X ...
    (microsoft.public.windowsxp.work_remotely)
  • Re: moving sbs network
    ... The SBS network is connected to the LAN port. ... so the public wireless router is the DHCP ...
    (microsoft.public.windows.server.sbs)
  • Re: Using Remote Desktop From an SBS Domain
    ... After I thought about needing 3389 forwarded on my router to allow me to ... Remote Desktop "out" from a workstation on my SBS network to a host XP ... Hopefully next week I can attempt a connection while my ISP watches the ...
    (microsoft.public.windows.server.sbs)
Loading