[Openswan Users] Misrouted packets in 'road warrior' configuration

Peter Collingbourne peter at peter.uk.to
Sun Sep 18 19:33:04 CEST 2005


Dear list,

I am testing Openswan for use in a 'road warrior' configuration to
provide access to an internal network.  I am using qemu emulated x86
boxes and the 'vde' package to create virtual networks.  The network is
structured as follows:


 Client             Server                  Real machine
                     (eth0)                     (tap0)
                  192.168.1.2 <------------> 192.168.1.1
1.1.1.2 <---------> 1.1.1.1                  10.179.131.1
 (eth0)             (eth1)                      (eth0)

The subnet 1.1.1.0/24 represents the Internet, and 192.168.1.0/24
represents the internal network.  I am attempting the road warrior
configuration between the client and the server.  After bringing up the
SA (using `ipsec auto --up road' on the client), I test it by performing
pings from the client machine.  When I ping 192.168.1.2 from the client,
I get responses, but I get no response when pinging 192.168.1.1.  If I
run `tcpdump -i eth1' on the server I get this while pinging 192.168.1.1:

04:39:20.184138 IP 1.1.1.2 > 1.1.1.1: ESP(spi=0xe8899ebc,seq=0x94)
04:39:20.184138 IP 1.1.1.2 > 192.168.1.1: icmp 64: echo request seq 1
04:39:21.098689 IP 1.1.1.2 > 1.1.1.1: ESP(spi=0xe8899ebc,seq=0x95)
04:39:21.098689 IP 1.1.1.2 > 192.168.1.1: icmp 64: echo request seq 2
04:39:22.119681 IP 1.1.1.2 > 1.1.1.1: ESP(spi=0xe8899ebc,seq=0x96)
04:39:22.119681 IP 1.1.1.2 > 192.168.1.1: icmp 64: echo request seq 3
04:39:23.097251 IP 1.1.1.2 > 1.1.1.1: ESP(spi=0xe8899ebc,seq=0x97)
04:39:23.097251 IP 1.1.1.2 > 192.168.1.1: icmp 64: echo request seq 4
04:39:24.097232 IP 1.1.1.2 > 1.1.1.1: ESP(spi=0xe8899ebc,seq=0x98)
04:39:24.097232 IP 1.1.1.2 > 192.168.1.1: icmp 64: echo request seq 5
04:39:25.116634 arp who-has 1.1.1.1 tell 1.1.1.2
04:39:25.117347 arp reply 1.1.1.1 is-at 52:54:00:12:34:57

and this while pinging 192.168.1.2:

04:40:32.402241 IP 1.1.1.2 > 1.1.1.1: ESP(spi=0xe8899ebc,seq=0x9d)
04:40:32.402241 IP 1.1.1.2 > 192.168.1.2: icmp 64: echo request seq 1
04:40:32.406213 IP 1.1.1.1 > 1.1.1.2: ESP(spi=0x70c3daf7,seq=0x39)
04:40:33.398378 IP 1.1.1.2 > 1.1.1.1: ESP(spi=0xe8899ebc,seq=0x9e)
04:40:33.398378 IP 1.1.1.2 > 192.168.1.2: icmp 64: echo request seq 2
04:40:33.402216 IP 1.1.1.1 > 1.1.1.2: ESP(spi=0x70c3daf7,seq=0x3a)
04:40:34.408209 IP 1.1.1.2 > 1.1.1.1: ESP(spi=0xe8899ebc,seq=0x9f)
04:40:34.408209 IP 1.1.1.2 > 192.168.1.2: icmp 64: echo request seq 3
04:40:34.412049 IP 1.1.1.1 > 1.1.1.2: ESP(spi=0x70c3daf7,seq=0x3b)
04:40:35.425569 IP 1.1.1.2 > 1.1.1.1: ESP(spi=0xe8899ebc,seq=0xa0)
04:40:35.425569 IP 1.1.1.2 > 192.168.1.2: icmp 64: echo request seq 4
04:40:35.429436 IP 1.1.1.1 > 1.1.1.2: ESP(spi=0x70c3daf7,seq=0x3c)
04:40:36.399873 IP 1.1.1.2 > 1.1.1.1: ESP(spi=0xe8899ebc,seq=0xa1)
04:40:36.399873 IP 1.1.1.2 > 192.168.1.2: icmp 64: echo request seq 5
04:40:36.403738 IP 1.1.1.1 > 1.1.1.2: ESP(spi=0x70c3daf7,seq=0x3d)

Running `tcpdump -i eth0' on the server during both pings yields no
output.

It appears that the problem is caused by the server misrouting packets
for 192.168.1.1 to eth1.  The problem should not occur, as the routing
table for the server shows:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
1.1.1.2         1.1.1.2         255.255.255.255 UGH   0      0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
1.1.1.0         0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

indeed it does not occur when not using IPsec as pings from the server
to 192.168.1.1 are correctly placed on eth0.

I am using Debian stable on both client and server with openswan 2.20-8.

Please cc responses to me as I am not on the list.

Here is the ipsec.conf file for the server:

------------------------------------------------------------
# /etc/ipsec.conf - Openswan IPsec configuration file
# RCSID $Id: ipsec.conf.in,v 1.13 2004/03/24 04:14:39 ken Exp $

# This file:  /usr/share/doc/openswan/ipsec.conf-sample
#
# Manual:     ipsec.conf.5


version	2.0	# conforms to second version of ipsec.conf specification

# basic configuration
config setup
	interfaces="ipsec0=eth1"
	# Debug-logging controls:  "none" for (almost) none, "all" for lots.
	# klipsdebug=none
	# plutodebug="control parsing"

# Add connections here

conn road
	left=%any
	leftrsasigkey=%cert
	right=1.1.1.1
	rightsubnet=192.168.1.1/24
	rightid=@debian.test
	rightrsasigkey=%cert
	rightcert=debianCert.pem
	auto=add

# sample VPN connection
#sample#	conn sample
#sample#		# Left security gateway, subnet behind it, next hop toward right.
#sample#		left=10.0.0.1
#sample#		leftsubnet=172.16.0.0/24
#sample#		leftnexthop=10.22.33.44
#sample#		# Right security gateway, subnet behind it, next hop toward left.
#sample#		right=10.12.12.1
#sample#		rightsubnet=192.168.0.0/24
#sample#		rightnexthop=10.101.102.103
#sample#		# To authorize this connection, but not actually start it, at startup,
#sample#		# uncomment this.
#sample#		#auto=start

#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf
------------------------------------------------------------

and the client:

------------------------------------------------------------
# /etc/ipsec.conf - Openswan IPsec configuration file
# RCSID $Id: ipsec.conf.in,v 1.13 2004/03/24 04:14:39 ken Exp $

# This file:  /usr/share/doc/openswan/ipsec.conf-sample
#
# Manual:     ipsec.conf.5


version	2.0	# conforms to second version of ipsec.conf specification

# basic configuration
config setup
	# Debug-logging controls:  "none" for (almost) none, "all" for lots.
	# klipsdebug=none
	# plutodebug="control parsing"

# Add connections here

conn road
	left=%defaultroute
	leftrsasigkey=%cert
	leftcert=clientCert.pem
	right=1.1.1.1
	rightsubnet=192.168.1.1/24
	rightid=@debian.test
	rightrsasigkey=%cert
	rightcert=debianCert.pem
	auto=add

# sample VPN connection
#sample#	conn sample
#sample#		# Left security gateway, subnet behind it, next hop toward right.
#sample#		left=10.0.0.1
#sample#		leftsubnet=172.16.0.0/24
#sample#		leftnexthop=10.22.33.44
#sample#		# Right security gateway, subnet behind it, next hop toward left.
#sample#		right=10.12.12.1
#sample#		rightsubnet=192.168.0.0/24
#sample#		rightnexthop=10.101.102.103
#sample#		# To authorize this connection, but not actually start it, at startup,
#sample#		# uncomment this.
#sample#		#auto=start

#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf
------------------------------------------------------------

-- 
Peter


More information about the Users mailing list