I've been googling and beating my head against this all day.

I have taken a working NETKEY openvpn connection awway from an old F8 box and tried to make it work on a more recent Ubuntu 10 LTS system. When the remote end was shifted to the new IP, the session was created immediately. So far so good.

Theres a new config value on the ubuntu system 'virtual_private' I've tried with and without.

Unfortunately no traffic is passing in either direction.

pinging the remote subnet from the ipsec host gets

"ping: sendmsg: Operation not permitted"

I've checked iptables, and apparmor are not interfering.

I've used tcpudump to look for ipsec packets going at co-incident times to my ping attempts: none.

I've checked logs and tcpdump on the firewall.

strace ping .... shows the pertinent failure is sendmsg() returns -1: EPERM (operation not permitted)

To complicate matters, the system is one of two using heartbeat to share an IP address in an active / standby arrangement. Each has its own address on each interface and may have the shared address. I've already established that as the address is moved from one host to the other, openswan does not notice. The active connection eventually dies and no new connection appears. I'll deal with that via heartbeat once traffic happens though.

I noticed in the logs that it is choosing the fixed address of the server for the connection rather than the shared address, but this does not seem to prevent the connection establishing so I don't think that's the cause.

I've obviously missed something fundumental here as every attempt to use the tunnel, as intended, results in 'Nup! not sendin it!' despite the session being up and stable.

Can anyone give me some pointers as to where to look next?
Maybe how to trace deeper into sendmsg()
Maybe "Have you set that 'enabled' flag" ;-)

I've drawn a blank here and any help would be appreciated.

Thanks
John