CentOS - May 2005 - Has anybody managed to get native IPSec working?

I've just wrote a lenghty email on Fedora ML as reply to Phillip who 
seems to be in the same trouble as myself...  Found that while searching 
all mailing list archives and bugzillas I could think off (not really 
successfully, many people with same problems, no answers other than 
"works for me" -- glad to hear it works for somebody else, but it
would
be nice if he/she was a bit more elaborate why it "works for me").

I'd really like to get IPSec VPN working.  I know about OpenVPN, and I 
know it works very well, and all that.  But being userland application 
based on SSL, it works only between Linux and Windows machines.  While 
it would do as temporary solution for short period of time, I might need 
something that has possiblity to interoperate with things such as Cisco 
routers and/or dedicated VPN boxes too, if need for it arises in the 
future (and I see it comming, since I do have some Cisco routers around, 
and some dedicated VPN boxes, all capable of IPSec).  So, OpenVPN 
woudn't be a good way to go (maybe as temporary solution, until I'm able
to get IPSec stuff working).

Anyhow, the machines in question are CentOS 4.0 with all updates 
installed.  And since what I actually use is labeled CentOS, thought 
about asking here also...

It seems something is broken in IPSec implementation.  Either as 
distributed by RedHat (and therefore present in CentOS), or maybe in the 
upstream kernel or userland tools.  By searching the archives of various 
mailing lists, I found many people having problems with it.

I'm attempting to setup IPSec (host2host for now, VPN when I'm done with
simpler host2host setup) as I write this.  Using native 2.6 kernel 
implementation, between two fully updated CentOS 4.0 boxes.

I found this bug report that affects VPN configuration, not really 
relevant to my case (host 2 host).  I've applied the patches since 
configuring VPN is going to be my next step anyhow:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146169

There are two proposed patches for ifup-ipsec and ifdown-ipsec scripts 
that will go into RHEL3 U6 and RHEL4 U2.  Probably Fedora Core has the 
same issues.

Looking at log files and monitoring the network with tcpdump (when doing 
"ping host-b" from host-a), this seems to be happening.  The first 
packet from host-a doesn't fly anywhere, as expected.  Subsequent 
packets are sent, but no response is ever received from host-b.  Pinging 
from host-b doesn't work at all (no packet leaving host-b, ever). 
Sumarized:

   - host-a attempts to negotiate automatic keying with host-b (success)
   - sends encrypted ICMP echo packet to host-b
   - host-b attempts to negotiate automatic keying with host-a (looks 
like success)
   - host-b repeats previous step indefinetly and never sends back 
encrypted ICMP echo-reply packet to host-a

Looking at the output of "setkey -D" on both hosts, the key tables are
huge after some time.  Something doesn't look righ, and I can't pinpoint
down what's wrong.  It looks like new pair of keys is generate each time 
host-b is supposed to send packet to host-a.

The /etc/sysconfig/network-scripts/ifcfg-IPSecToHostB on host-a looks 
something like this:

DST=192.168.1.100
TYPE=IPSEC
ONBOOT=no
IKE_METHOD=X509
IKE_CERTFILE=/etc/racoon/certs/host-a
IKE_PEER_CERTFILE=/etc/racoon/certs/host-b

The /etc/sysconfig/network-scripts/ifcfg-IPSecToHostA on host-b looks 
similar (DST and IKE_*CERTFILE pointing the other way).  Keys and 
certificates for host-a are stored in host-a.private (no passphrase, so 
that racoon can read the key) and host-a.public and likewise for host-b, 
just the way ifup-ipsec script expects them to be.

After doing "ifup IPSecToHostB" on host-a, and "ifup
IPSecToHostA" on
host-b, the generated racoon configuration looks good (long 
certificate_type line might get wrapped around by my mail client, but it 
is a single line in the configuration file).  This is store in 
/etc/racoon/192.168.1.100.conf, which is included from racoon.conf.

remote 192.168.1.100
{
         exchange_mode aggressive, main;
         my_identifier asn1dn;
         peers_identifier asn1dn;
         certificate_type x509 "/etc/racoon/certs/host-a.public" 
"/etc/racoon/certs/host-a.private";
         peers_certfile "/etc/racoon/certs/host-b.public";
         proposal {
                 encryption_algorithm 3des;
                 hash_algorithm sha1;
                 authentication_method rsasig;
                 dh_group 2;
         }
}

The racoon.conf file looks like this (I made no changes to it, as 
installed by ipsec-tools, include statement added by ifup-ipsec script):

# Racoon IKE daemon configuration file.
# See 'man racoon.conf' for a description of the format and entries.

path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";

sainfo anonymous
{
         pfs_group 2;
         lifetime time 1 hour ;
         encryption_algorithm 3des, blowfish 448, rijndael ;
         authentication_algorithm hmac_sha1, hmac_md5 ;
         compression_algorithm deflate ;
}
include "/etc/racoon/192.168.120.165.conf";

Configuration on host-b looks similar, referencing back to host-a.

When I ping host-b, the first packet is dropped, as expected (while 
Racoon does its job with automatic keying).  I've included excerpt from 
/var/log/message from both host-a and host-b as attachments 
(messages-host-*.txt), as well as output of "tcpdump host-b" that was 
running on host-a (tcpdump-host-a.txt).  I've put them as attachments to 
avoid my mail client making them unreadable by wrapping around long lines.

All in all, either I'm missing something really obvious, or something is 
really broken as distributed in Fedora/RHEL (and clones)...

-- 
Aleksandar Milivojevic <amilivojevic at pbl.ca>    Pollard Banknote
Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: messages-host-a.txt
URL:
<http://lists.centos.org/pipermail/centos/attachments/20050512/69700d2c/attachment-0020.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: messages-host-b.txt
URL:
<http://lists.centos.org/pipermail/centos/attachments/20050512/69700d2c/attachment-0021.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tcpdump-host-a.txt
URL:
<http://lists.centos.org/pipermail/centos/attachments/20050512/69700d2c/attachment-0022.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: setkey-host-a.txt
URL:
<http://lists.centos.org/pipermail/centos/attachments/20050512/69700d2c/attachment-0023.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: setkey-host-b.txt
URL:
<http://lists.centos.org/pipermail/centos/attachments/20050512/69700d2c/attachment-0024.txt>

yes, i got ipsec working.  and yes there are some issues with the 
network-scripts bits.  redhat is aware of them, and hopefully they'll be 
fixed in u1 or u2 release of rhel4.  what i ended up doing was hand 
creating the bits and a small startup script.  getting it to work with 
iptables is even more fun if you try to avoid private network addresses 
from leaking in/out of your network.  i can provide the scripts and setups 
i used if you want to contact me directly.  or if enough people care, i 
can send things to the list.