Date: Mon, 10 Sep 2001 16:41:31 +0100 From: Brian Somers <brian@freebsd-services.com> To: Matthew Emmerton <matt@gsicomp.on.ca> Cc: Brian Somers <brian@freebsd-services.com>, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp>, freebsd-net@FreeBSD.ORG, brian@freebsd-services.com Subject: Re: Forward: Re: ping gif0 Message-ID: <200109101541.f8AFfVJ61047@hak.lan.Awfulhak.org> In-Reply-To: Message from Matthew Emmerton <matt@gsicomp.on.ca> of "Mon, 10 Sep 2001 10:54:20 EDT." <Pine.BSF.4.21.0109101046410.34800-100000@xena.gsicomp.on.ca>
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.
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.
> --
> Matt Emmerton
--
Brian <brian@freebsd-services.com> <brian@Awfulhak.org>
http://www.freebsd-services.com/ <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour ! <brian@[uk.]OpenBSD.org>
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?200109101541.f8AFfVJ61047>