Date: Mon, 10 Sep 2001 12:52:48 -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.0109101249310.35071-100000@xena.gsicomp.on.ca> In-Reply-To: <200109101541.f8AFfVJ61047@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, 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. > > What does your security policy say ? I have this on the LAN1 gateway: > > spdadd LAN2PUB/32 LAN1PUB/32 ip4 -P in ipsec esp/transport//require; > spdadd LAN1PUB/32 LAN2PUB/32 ip4 -P out ipsec esp/transport//require; > > and of course the in/out bits reversed on the LAN2 gateway. The > important bit is the ``ip4'' bit. I don't expect connections to/from > the public IP numbers to be caught by the policy - and in fact run > NAT on both gateways. I have this: spdadd 10.0.2.0/26 10.0.2.128/28 any -P in ipsec esp/tunnel/209.167.75.124-209.167.75.123/require; spdadd 10.0.2.128/28 10.0.2.0/26 any -P out ipsec esp/tunnel/209.167.75.123-209.167.75.124/require; Although now I'm slightly confused since I had switched from 'tunnel' to 'transport' after someone pointed out that since gif is a tunnel, I don't have to rely on IPSec's 'tunnel' mode do do the encapsulation. Am I getting bit by one-too-many layers of IPv4? -- 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.0109101249310.35071-100000>