Date: Tue, 13 Aug 2002 17:08:29 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Lars Eggert <larse@ISI.EDU> Cc: Les Biffle <les@safety.net>, hackers@freebsd.org Subject: Re: IP routing question Message-ID: <3D599F7D.D64008AC@mindspring.com> References: <200208131813.g7DIDiH14643@ns3.safety.net> <3D599416.5CDE92D9@mindspring.com> <3D599679.5090507@isi.edu> <3D599992.7C954D42@mindspring.com> <3D599D00.8070807@isi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Lars Eggert wrote: > Terry Lambert wrote: > > As you say, SA's are not interfaces. Try pinging over the link > > from hosts on either side of the tunnel, e.g.: > > > > 10.0.1.15/8<--->10.0.1.1/8 10.0.2.1/8<---->10.0.2.11/8 > > public IP #1<----------->public IP #2 > > > > Ping #1 <--------------------------> works > > Ping #2 <----------------------------------------->broken > > > > Get rid of the default route, and ping #2 starts working. > > That looks like a routing issue on the tunnel endpoint that's > independent from IPsec - what's in the routing table? Now? Not a default route, that's for sure... 8-) 8-) ;^). I traced the problem down to the cloning of routes, and given the opacity of the code, and the fact I had a workaround avaiable, didn't bother chasing it further. The response packets got *back* to 10.0.1.1, but 10.0.1.1 did not forward them on the local net to 10.0.1.15, but pushed them out the default interface instead. -- 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?3D599F7D.D64008AC>