FC3: IPSec Functionality
Aleksandar Milivojevic
amilivojevic at pbl.ca
Thu May 12 16:14:56 UTC 2005
Phillip T. George wrote:
> Hello,
>
> Does anyone seem to be having any trouble with using IPSec in FC3? I've
> tried using the network tool provided, but it doesn't seem to want to
> connect. I also tried using my own configuration files (ipsec.conf and
> ipsec.secrets) and that didn't seem to get anywhere. Here are the
> results in the logs:
> May 2 13:36:24 testimax ipsec: Starting Openswan IPsec
> U2.1.5/K2.6.9-1.667...
> May 2 13:36:25 testimax ipsec: /usr/lib/ipsec/_startklips: KLIPS ipsec0
> on eth1 70.182.220.68/255.255.255.224 broadcast 70.182.220.95
> May 2 13:36:25 testimax ipsec_setup: KLIPS ipsec0 on eth1
> 70.182.220.68/255.255.255.224 broadcast 70.182.220.95
> May 2 13:36:25 testimax ipsec: /usr/lib/ipsec/_plutorun: Starting Pluto
> subsystem...
> May 2 13:36:25 testimax ipsec_setup: Starting Pluto subsystem...
> May 2 13:36:25 testimax ipsec_setup: ...Openswan IPsec started
> May 2 13:36:25 testimax ipsec: Starting IPsec: succeeded
>
>
> IS there some new log file or some new trick I need to know about? I
> also didn't see ipsec0 listed in /sbin/ifconfig ... seems odd to me.
> I'm used to openswan on Red Hat 7.3...seemed to work great once I had it
> configured :) If anyone could provide me with a good link to
> documenation specifically for FC3 and ipsec, I'd very much appreciate
> it. I did update openswan and the ipsec-tools to the latest versions.
It seems something is broken in IPSec implementation. Either as
distributed by RedHat, or maybe in the upstream kernel or userland
tools. If you search the archives, you'll see many people having issues 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. This is between two RHEL4 clones (CentOS 4.0), and I
found this email of yours while searching the archives (I only found
questions about the same problem as mine, but absolutely no answers
other than "works for me").
First of all, if setting VPN (network 2 network), check this RHEL bug
report, and see if it applies to you:
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.
When done with that, and if it still doesn't work, you most likely have
similar problem as myself with automatic keying. Looking at log files
and looking with tcpdump what's going on on the wire (when doing "ping
host-b" from host-a):
- 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://listman.redhat.com/archives/fedora-list/attachments/20050512/f40345c2/attachment-0005.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: messages-host-b.txt
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20050512/f40345c2/attachment-0006.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tcpdump-host-a.txt
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20050512/f40345c2/attachment-0007.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: setkey-host-a.txt
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20050512/f40345c2/attachment-0008.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: setkey-host-b.txt
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20050512/f40345c2/attachment-0009.txt>
More information about the fedora-list
mailing list