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

To: Cipe Mailing List <cipe-l,AT,inka,DOT,de>
Subject: Re: kxchg: Operation not permitted
From: Berend Veldkamp <berend.veldkamp,AT,aris,DOT,nl>
Date: Wed, 17 Sep 2003 16:23:21 +0200
Organization: ARIS
References: <000801c37cf8$71a0c0c0$d620a8c0@pcw_hans.hnsasd.priv>

Hans,

Thanks for your reply. 
Yes we're using a static key, so why would pkcipe try to exchange 
dynamic keys? 
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?

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.

The ip-up.local script we're using is included below, if anyone cares 
to have a look...

Regards, Berend

Hans Steegers wrote:
> 
> Berend,
> I searched my log files, but couldn't find a trace of such an error message.
> 
> The error message "kxchg: send: .." is generated by ciped (in kxchg(), after
> a send(2) returns an error, while sending  NK_REQ, NK_ACK or NK_IND).
> The error code EPERM "Operation not permitted" is probably orginating from
> the ip-layer IP(7):  "User doesn't have permission to set high priority,
> change  configuration, or send signals to the requested process or group."
> 
> * It is NOT related to connectionless UDP traffic (send(2) assumes a
> connection).
> * If you are running PKCIPE, see section 4.3 of the manual: "The pkcipe
> program must be run as root. (Do not make it setuid.)"....
> *** Verify if PKCIPE's TCP (!) connection with the remote PKCIPE is allowed
> and not blocked by a firewall!!
> * DEBUG: Run PKCIPE with -D debug; Run cipcb in debug mode, or better: run a
> debug version (configured without --disable_debug).
> 
> My guess is that cipe is working with the static key and that pkcipe is
> causing the messages because ciped isn't able to exchange (dynamic) keys.
> But it's only a wild guess, based on a minimum of information....
> 
> If you are NOT using pkcipe: a minor mismatch between the cipcb module and
> your kernel MAY cause this kind of erratic behaviour: the module must have
> been built using the same compiler and (identical configured) source tree as
> used to build you running kernel.
> 
> I hope this is of any help or use.
> 
> Hans Steegers.
> 
> -----Original Message-----
> 
> >So,
> >
> >Can anyone tell me what rule to add to allow kxchg? I have searched
> >the archives, but I can't find this specific problem.
> >Let me repeat that cipe is already working, it's just that I want to
> >get rid of the messages in /var/log/messages.
> >
> >Thanks, Berend

ip-up.local script:

#!/bin/bash
device=$1       # the CIPE interface
me=$2           # our UDP address
pid=$3          # the daemon's process ID
ipaddr=$4       # IP address of our CIPE device
ptpaddr=$5      # IP address of the remote CIPE device
option=$6       # argument supplied via options

option_file=/etc/cipe/options.$device
remote_ip=`grep ^peer $option_file | cut -d \  -f 2 | cut -d : -f 1`
local_ip=`grep ^me $option_file | cut -d \  -f 2 | cut -d : -f 1`
cipe_port=`grep ^me $option_file | cut -d : -f 2`
ext_if=ppp0

#------------------------------------------------------------------------------

# Add route entry for remote cipe network
remote_net=`expr $ptpaddr : '\([0-9]*\.[0-9]*\.[0-9]*\.\)'`0
route add -net $remote_net netmask 255.255.255.0 dev $device

#------------------------------------------------------------------------------

# Create new ipchain for cipe interface input rules
iptables -N $device"i"
# flush all rules in chain
iptables -F $device"i"

# deny incoming packets, cipe interface, claiming to be from localnet
iptables -A $device"i" -i $device \
         -s $ipaddr/24 \
         -d $ipaddr/24 -j DROP

# accept incoming packets from localnet to remote net on cipe
interface
iptables -A $device"i" -i $device \
         -s $ipaddr/24 \
         -d $ptpaddr/24 -j ACCEPT

# accept incoming packets from remotenet to localnet on cipe interface
iptables -A $device"i" -i $device \
         -s $ptpaddr/24 \
         -d $ipaddr/24 -j ACCEPT

iptables -A $device"i" -i $ext_if -d udp \
         -s $remote_ip \
         -d $local_ip -j ACCEPT

# deny all other incoming packets
iptables -A $device"i" -s 0/0 -d 0/0 -j DROP

#------------------------------------------------------------------------------
# Create new ipchain for cipe interface output rules
iptables -N $device"o"
# flush all rules
iptables -F $device"o"

# deny outgoing to localnet from localnet, cipe interface
iptables -A $device"o" -o $device \
         -s $ipaddr/24 \
         -d $ipaddr/24 -j DROP

# accept outgoing from localnet to remotenet on cipe interface
iptables -A $device"o" -o $device \
         -s $ipaddr/24 \
         -d $ptpaddr/24 -j ACCEPT

# accept outgoing from remotenet to localnet on cipe interface
iptables -A $device"o" -o $device \
         -s $ptpaddr/24 \
         -d $ipaddr/24 -j ACCEPT

# deny all other outgoing packets
iptables -A $device"o" -s 0/0 -d 0/0 -j DROP

#------------------------------------------------------------------------------
# The forward chain is configured so machines on your local network do
not
# get masqueraded to the remote network. This provides better access
control
# between networks

# Create new ipchain for cipe interface forward rules
iptables -N $device"f"
# Flush all rules in chain
iptables -F $device"f"

# accept forwarding from localnet to remotenet on cipe interface
iptables -A $device"f" -i $device \
         -s $ipaddr/24 \
         -d $ptpaddr/24 -j ACCEPT

# accept forwarding from remotenet to localnet on cipe interface
iptables -A $device"f" -i $device \
         -s $ptpaddr/24 \
         -d $ipaddr/24 -j ACCEPT

# deny all other forwarding
iptables -A $device"f" -s 0/0 -d 0/0 -j DROP

#------------------------------------------------------------------------------

iptables -I INPUT -i $device -j $device"i"
iptables -I OUTPUT -o $device -j $device"o"
iptables -I FORWARD -i $device -j $device"f"

# Om een of andere reden werkt het niet als de volgende regel in de
# cipcb0i chain wordt gezet
iptables -I INPUT -i $ext_if -p udp \
         -s $remote_ip --source-port $cipe_port \
         -d $local_ip --destination-port $cipe_port -j ACCEPT

exit 0

-- 
____________________________

Berend Veldkamp - ARIS
http://www.aris.nl/
____________________________


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