[Openswan Users] openswan and red hat enterprise

Paul Wouters paul at xelerance.com
Sat Mar 27 20:59:09 CET 2004


On Fri, 26 Mar 2004, Morgan Marodin wrote:

> I have used the openswan26.spec to rpmbuild the tarball package in my red 
> hat enterprise es 3. All OK. I have installed the rpm with the userland 
> tool of openswan 2.1.1 and I have configured the configuration files. I 
> have defined a connection named "conntest" with an other VPN gateway based 
> on a superfreeswan.
> 
> I think that the NAT-Traversal patch is still in the kernel because i found 
> a patch called linux-2.4.21-ipsec.patch in the kernel-2.4.21-9.0.1.EL.src.rpm

With enterprise linux you shouldn't need to rebuild a kernel, since it uses
the ipsec backport.
 
> [root at platoon etc]# service ipsec start
> ipsec_setup: Starting Openswan IPsec 2.1.1...
> ipsec_setup: insmod: ipsec: no module by that name found

That's okay, since you're using the backport.

> ipsec_setup: /sbin/insmod /lib/modules/2.4.21-9.0.1.EL/kernel/net/key/af_key.o
> ipsec_setup: Using /lib/modules/2.4.21-9.0.1.EL/kernel/net/key/af_key.o

Part of which is loaded here.

> ipsec_setup: Symbol version prefix ''
> [root at platoon etc]#
> [root at platoon etc]# ipsec verify
> Checking your system to see if IPsec got installed and started correctly:
> Version check and ipsec on-path                                         [OK]
> Linux FreeS/WAN U2.1.1/K2.4.21-9.0.1.EL (native) (native)

(native) tells you that it is using the backport code.

> all seems well but ...

Indeed.
 
> [root at platoon etc]# ifconfig ipsec0
> ipsec0: error fetching interface information: Device not found

That is normal, since you are using the backport code. That does not supply a
virtual interface. All ipsec packets just travel over the ethX interface.

> Mar 26 11:19:40 platoon ipsec_setup: ...Openswan IPsec started
> Mar 26 11:19:41 platoon ipsec__plutorun: ipsec_auto: fatal error in 
> "packetdefault": %defaultroute requested but not known

> Mar 26 11:19:41 platoon ipsec__plutorun: ipsec_auto: fatal error in 
> "block": %defaultroute requested but not known
> Mar 26 11:19:41 platoon ipsec__plutorun: ipsec_auto: fatal error in 
> "clear-or-private": %defaultroute requested but not known

You have not disabled OE. If you installed by rpm, you can disable OE
by including the file /etc/ipsec.d/examples/no_oe.conf in /etc/ipsec.conf.


> BUT ... really ... the SA "conntest" was established.

Yes, the defaultroute part is for binding the virtual interface, which
does not apply on the native code. This is a buglet.

> ISAKMP SA established ... but I haven't the device ipsec0 and I haven't any 
> route to the "rightsubnet".

But does it all work or not? Remember you cannot run tcpdump on one of the
gateway hosts, because the traffic gets encrypted AFTER tcpdump can read
the packets. This is the method of the native code. This means that to properly
see if traffic encrypted, you should have a third machine in the middle to
run tcpdump on. We have also noticed in some situations that running tcpdump on
the middle machine causes the machine to duplicate packets. This results in
"ping duplicates" if you are testing the ipsec connection using ping.

> What's the problem?

Are you sure you have one? 

Paul



More information about the Users mailing list