Re: kxchg: Operation not permitted

Allan Latham <[email protected]>
Newsgroups gmane.comp.encryption.cipe
Message-ID <[email protected]>
Hi

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

In any case you know where to concentrate your efforts.

Best regards

Allan

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.


--
Message sent by the [email protected] mailing list.
Unsubscribe: mail [email protected], "unsubscribe cipe-l" in body
Other commands available with "help" in body to the same address.
CIPE info and list archive: <URL:http://sites.inka.de/~bigred/devel/cipe.html>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.