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.
On Wednesday 17 September 2003 21:32, Hans Steegers wrote:
> 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
> 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
> 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...).