Date: Mon, 10 Sep 2001 18:31:58 +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: <200109101731.f8AHVwJ69856@hak.lan.Awfulhak.org> In-Reply-To: Message from Matthew Emmerton <matt@gsicomp.on.ca> of "Mon, 10 Sep 2001 12:52:48 EDT." <Pine.BSF.4.21.0109101249310.35071-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, 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?
I think so. Try changing it to
spdadd 209.167.75.124/32 209.167.75.123/32 ip4 -P in ipsec esp/transport//require;
spdadd 209.167.75.123/32 209.167.75.124/32 ip4 -P out ipsec esp/transport//require;
> --
> 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?200109101731.f8AHVwJ69856>