> 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.

> --
> Matt Emmerton

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

Reply via email to