Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 07 Feb 2002 15:15:20 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Ian <freebsd@damnhippie.dyndns.org>
Cc:        freebsd-hackers <freebsd-hackers@freebsd.org>
Subject:   Re: natd UDP errors with PPP demand dial
Message-ID:  <3C630A88.5986BF8E@mindspring.com>
References:  <B88816A7.9D9E%freebsd@damnhippie.dyndns.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Ian wrote:
> > Out [TCP]  [TCP] 192.168.0.10:3979 -> 207.69.200.225:110 aliased to
> >            [TCP] 207.69.102.20:3979 -> 207.69.200.225:110
> > Out [TCP]  [TCP] 192.168.0.10:3979 -> 207.69.200.225:110 aliased to
> >            [TCP] 207.69.102.20:3979 -> 207.69.200.225:110
> > Out [TCP]  [TCP] 192.168.0.10:3979 -> 207.69.200.225:110 aliased to
> >            [TCP] 207.69.102.20:3979 -> 207.69.200.225:110
> 
> Where did these packets go?  I can't answer that.  However I can speculate
> that perhaps they didn't go very far at all, just into the IP stack on the
> local machine.  Then we get some more routing info:

FWIW: I've seen something similar with an IPSEC based VPN;
it's my opinion that the problems are related, and that
this is a routing issue, not a NAT issue.

In the IPSEC case, if there is an explicit point-to-point
route, and the default route is *NOT* set, then you get
packets.  If the default route is used to deliver the
packets to the tunnel, then the packets get to the remote
end, but the reply packets to the local end, which show up
in tcpdump as hitting the local wire, don't make it up the
stack for some reason.

There appears to be a problem with the route cloning code
not noticing correctly when a new route is established that
applies to an already cloned connection, I think.

This normally isn't a problem, but in the IPSEC or NAT
case, wheere you are on a network border with another
network in the same box, and you effectively need to
have the moral equivalent of two different default
routes, it seems to become an issue.

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C630A88.5986BF8E>