Date: Mon, 10 Sep 2001 10:54:20 -0400 (EDT) From: Matthew Emmerton <matt@gsicomp.on.ca> To: Brian Somers <brian@freebsd-services.com> Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp>, freebsd-net@FreeBSD.ORG Subject: Re: Forward: Re: ping gif0 Message-ID: <Pine.BSF.4.21.0109101046410.34800-100000@xena.gsicomp.on.ca> In-Reply-To: <200109101422.f8AEM8J60160@hak.lan.Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 10 Sep 2001, Brian Somers wrote: > > >>>>> On Mon, 10 Sep 2001 11:54:49 +0100, > > >>>>> Brian Somers <brian@freebsd-services.com> said: > > > > > The local endpoint can't be pinged unless you've got a route for > > > it... that's just the way the routing code works. > > > > > You can ping the local address for an Ethernet interface, but that's > > > just because the hardware returns such packets. > > > > > Adding a loopback route or address alias is the way to handle this. > > > > Correct, but in this case, pinging the other end of the link also > > failed: > > > > gif0: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1280 > > inet 10.0.2.130 --> 10.0.2.2 netmask 0xffffffff > > physical address inet 209.167.75.123 --> 209.167.75.124 > > > > waterloo.heers.on.ca# ping 10.0.2.2 > > PING 10.0.2.2 (10.0.2.2): 56 data bytes > > ^C > > --- 10.0.2.2 ping statistics --- > > 15 packets transmitted, 0 packets received, 100% packet loss > > > > I don't get the reason for this part. This is perhaps due to some > > IPsec issues? netstat gave us an interesting result: > > > > 34 inbound packets violated process security policy > > This rings bells. I have been having difficulties with an IPSEC over > gif setup recently, but they went away with the latest racoon update > in the ports collection. They *may* have appeared with the previous > racoon update - I'm not sure. The symptoms were bizarre. However, I'm not using racoon. Static keys, using '-E simple ""' as the encryption algorithm. (This helps me figure out whats going on with tcpdump and ethereal much more easily.) LAN1 machines can talk to LAN2 machines and vice versa with absolutely no problems. However, the LAN1 gateway can't talk to the LAN2 gateway and vice versa. As was pointed out, I need to set up some localhost routes in order to ping the local end of the tunnel. What remains is a) why can't I ping the remote end of the tunnel without receiving these "violated process security policy" messages, and b) why can't I connect to the remote end of the tunnel. The latter breaks DNS forwarding / HTTP proxy / sendmail forwarding, and is becoming a real problem. -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0109101046410.34800-100000>