<< | Thread Index | >> ]    [ << | Date Index | >> ]

To: "CIPE-list" <cipe-l,AT,inka,DOT,de>
Subject: Re: kxchg: Operation not permitted
From: Allan Latham <alatham,AT,flexsys-group,DOT,com>
Date: Thu, 18 Sep 2003 09:46:11 +0200
In-reply-to: <000801c37d52$6cad68c0$d620a8c0@pcw_hans.hnsasd.priv>
References: <000801c37d52$6cad68c0$d620a8c0@pcw_hans.hnsasd.priv>


I've only ever seen this as a firewall problem.

Do the following:

1. turn off all firewalling.
2. start cipe
3. check with tcpdump that packets are being routed where you expect.

From this you learn:

1. If the packets are not going where you expect - you have a routing problem.
2. If it works you have a firewall rules problem with the rules you were 

In any case you know where to concentrate your efforts.

Best regards


On Wednesday 17 September 2003 21:32, Hans Steegers wrote:
> Berend,
> Some answers..
> >Yes we're using a static key, so why would pkcipe try to exchange
> >dynamic keys?
> If you are only using a static key, PKCIPE shouldn't be running at all.
> >Besides, the connection is already working (Our remote office is able
> >to logon, browse shared drives, ...). Or is dynamic key exchange done
> >in another way, do I need to open additional ports?
> If you want PKCIPE to communicate with the PKCIPE at the remote peer, you
> need to allow tcp traffic between both peers. (See manual).
> ** However, since you only want to use a static key, you don't need PKCIPE
> at all!
> >I compiled cipe with the gcc package that's included with the distro,
> >RH 7.2, I'm guessing the kernel was compiled with the same version,
> >but I'm not sure how to check that.
> If you are only using the default 7.2 kernel- and compiler packages, it
> should be ok if your source tree was properly configured. Only if cipe
> behaves in a unexplainable weird manner, suspect this as a possibility.
> >The ip-up.local script we're using is included below, if anyone cares
> >to have a look...
> Sorry, no time for that: I am not running a free debugging service!
> Some remarks..
> ** ip-up script looks unnecessary complex to me, if not weird.
> ** Firewall:
> For cipe all you need is a hole in the firewall for the UDP traffic via the
> external interface (ppp0?) with the peer's (public) ip-address and port to
> use.
> And vice versa! No more and no less!
> All traffic between the cipe interface with the local (loopback) interface
> (lo)and the LAN-interface (eth0?) should be allowed, unless you have
> special reasons not to.
> Note: Your last remark in your firewall script (in dutch, translated:)..
> > For some reasons the following rule doesn't work if used in the cipcb0
> chain..
> Of course it doesn't work in the cipcb0 chain: this UDP traffic isn't going
> via the cipe interface. It is the UDP traffic transporting the encrypted
> encapsulated IP-packets to the other cipe interface. (You also need a
> similar OUTPUT rule: I couldn't find one...).
> Hans.

<< | Thread Index | >> ]    [ << | Date Index | >> ]