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>