Description of problem: i have a vpn connection that used to work like a charm in fedora 10... now i have to issue a command by hand for having the tunnel work again... i mean that if i start ipsec now i get this error in /var/log/secure: Dec 23 10:41:20 <servername> pluto[15860]: "<connection_name>": route-client output: /usr/libexec/ipsec/_updown.netkey: doroute `ip route replace 192.168.25.0/24 dev eth1 src 192.168.0.212' failed (RTNETLINK answers: Operation not permitted) anyway the ipsec tunnel is up and if i do as root: "ip route replace 192.168.25.0/24 dev eth1 src 192.168.0.212" which is the command that the script /usr/libexec/ipsec/_updown.netkey tries to run by its own... it works again i have selinux disabled so it should not be an issue related to selinux... Version-Release number of selected component (if applicable): openswan-2.6.23-1.fc12.i686 kernel-PAE-2.6.31.6-166.fc12.i686 How reproducible: start ipsec with a connection defined in /etc/ipsec.d Steps to Reproduce: 1. start ipsec 2. see the logs Actual results: i have to type ip route... by hand Expected results: it works like a charm Additional info:
Could you please provide your vpn configuration setup? More details the better, you can hide machines' real ips or whatever else in case if you have.
ok here goes my config... first of all ifconfig -a: eth0 Link encap:Ethernet HWaddr 00:19:DB:F7:3D:DA inet addr:192.168.0.212 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::219:dbff:fef7:3dda/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:174458 errors:0 dropped:0 overruns:0 frame:0 TX packets:530087 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:18422096 (17.5 MiB) TX bytes:762836847 (727.4 MiB) Interrupt:27 Base address:0x8000 eth1 Link encap:Ethernet HWaddr 00:19:DB:F7:3D:DB inet addr:79.31.XXX.XXX Bcast:79.31.217.255 Mask:255.255.255.0 inet6 addr: fe80::219:dbff:fef7:3ddb/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5926365 errors:0 dropped:0 overruns:0 frame:0 TX packets:4017539 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1748711719 (1.6 GiB) TX bytes:617331959 (588.7 MiB) Interrupt:21 Base address:0x6400 so eth0 is the server address in my lan... now cat /etc/sysconfig/iptables # Generated by iptables-save v1.4.5 on Sat Dec 5 22:37:54 2009 *nat :PREROUTING ACCEPT [11:944] :POSTROUTING ACCEPT [2:119] :OUTPUT ACCEPT [2:119] -A POSTROUTING -s 192.168.0.0/24 ! -d 192.168.0.0/16 -o eth1 -j MASQUERADE COMMIT # Completed on Sat Dec 5 22:37:54 2009 # Generated by iptables-save v1.4.5 on Sat Dec 5 22:37:54 2009 *filter :INPUT DROP [11:944] :FORWARD DROP [0:0] :OUTPUT ACCEPT [242:147757] -A INPUT -p esp -j ACCEPT -A INPUT -p udp -m udp --sport 500 --dport 500 -j ACCEPT -A INPUT -p udp -m udp --sport 123 --dport 123 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 1024:5999 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p udp -m udp --dport 1024:5999 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 6010:65535 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p udp -m udp --dport 6010:65535 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -p tcp -m tcp --dport 2220 -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -s 192.168.0.0/24 -i eth0 -j ACCEPT -A INPUT -p icmp -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 192.168.0.0/24 -i eth0 -o eth1 -j ACCEPT -A FORWARD -d 192.168.0.0/24 -i eth1 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT COMMIT # Completed on Sat Dec 5 22:37:54 2009 this server is my lan router/firewall so some natting here ofr the 192.168.0.X lan. The lan i have to connect to via openswan has got the 192.168.25.0 and 192.168.26.0 addresses, so this is why i am not natting packets that goes to 192.168.0.0/16 at last my openswan configuration... /etc/ipsec.conf is the default one i just removed the # on the last line to include conf files in /etc/ipsec.d/ my /etc/ipsec.d/connection_name.conf looks like: conn <connection_name1> type=tunnel auth=esp authby=secret auto=start esp=3des-md5 left=%defaultroute leftid=.by.dyndns leftsubnet=192.168.0.212/32 leftsourceip=192.168.0.212 right=194.XXX.XXX.XXX (the netscreen firewall) rightsubnet=192.168.25.0/24 conn <connection_name2> type=tunnel auth=esp authby=secret auto=start esp=3des-md5 left=%defaultroute leftid=.by.dyndns leftsubnet=192.168.0.212/32 leftsourceip=192.168.0.212 right=194.XXX.XXX.XXX (the netscreen firewall) rightsubnet=192.168.26.0/24 im using my private lan 192.168.0.212 address because i have dynamic ip address on the adsl link. as I said, it used to work with fedora 10... now the two tunnels go up nicely but i got that error in /var/log/secure Dec 23 15:00:14 niceleprotto pluto[24430]: "<connection_name1>": route-client output: /usr/libexec/ipsec/_updown.netkey: doroute `ip route replace 192.168.25.0/24 dev eth1 src 192.168.0.212' failed (RTNETLINK answers: Operation not permitted). and Dec 23 15:00:14 niceleprotto pluto[24430]: "<connection_name2>": route-client output: /usr/libexec/ipsec/_updown.netkey: doroute `ip route replace 192.168.26.0/24 dev eth1 src 192.168.0.212' failed (RTNETLINK answers: Operation not permitted). anyway if i run ip route replace 192.168.25.0/24 dev eth1 src 192.168.0.212 ip route replace 192.168.26.0/24 dev eth1 src 192.168.0.212 everything is fine again... if there is not an error in /usr/libexec/ipsec/_updown.netkey it seems to me that the script for some reason is not run as root because i - of course - got the same error if i run the ip command as regular user :-)
Dropping the LIBCAP_NG hunk fixes this, so I suspect the inherited privileges when running the _updown wrapper are wrong.
Yeah, the problem is your patch clears CAP_NET_ADMIN from the bounding set, which means when it is &-d against the permitted set on execve, it will be cleared in the child (ie: the child scripts won't have the permission to.) Patch posted to dev fixes that.
That would be nice to get that into a release ASAP or a Fedora patch and into the packages. Fedora 11 and Fedora 12 are both broken on this and in a way that costs crazy amounts of time trying to track it down.
This issue, that occurred due to libcap-ng, is already fixed in openswan upstream. I will apply the patch in F12 too soon. But openswan in F11 does not have not support for libcap-ng so why do you see the error in F11?
Crud... Just went back and checked and that's because that system had been upgraded to 2.6.23 because of the broken local subnets (local subnets can not communicate with the gateway even though they can communicate through the gateway) and the passthrough conns under NetKey that were fixed in 2.6.23. My bad. Yeah, and I can't downgrade that system because 2.6.22 is broken in that case. Never mind the F11 case.
Closing the bz as the problem has been resolved upstream, and also fixed in F12. Please reopen if you see the issue again. Thanks for reporting the bz.