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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
