[Openswan Users]

Sat Jul 22 22:14:18 CEST 2006

Here is a typical tcpdump command from both sides:

tcpdump -i eth0 net 209.130.212.154 or 71.216.115.33 -n

I now have a lab set up here at my place, complete with copies of the
firewalls at both locations, a simulated Internet, and hosts in both
LANs.  So now I have a completely controlled environment and I can do
more general tcpdump traces

I have a host inside my simulated Roseville trying to ping my simulated
Lakeville.  Here's an output sample from the Internet interface in my
simulated Roseville:

[root at roseville-fw gregs]# 
[root at roseville-fw gregs]# /usr/sbin/tcpdump -i eth0 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
20:50:08.516684 IP 71.216.115.33 > 10.13.1.111: ICMP echo request, id
512, seq 45830, length 40
20:50:13.516112 arp who-has 71.216.115.38 tell 71.216.115.33
20:50:13.517301 arp reply 71.216.115.38 is-at 00:01:02:c8:8c:f6
20:50:14.017088 IP 71.216.115.33 > 10.13.1.111: ICMP echo request, id
512, seq 46086, length 40
20:50:19.517078 IP 71.216.115.33 > 10.13.1.111: ICMP echo request, id
512, seq 46342, length 40
20:50:25.017498 IP 71.216.115.33 > 10.13.1.111: ICMP echo request, id
512, seq 46598, length 40
20:50:30.517484 IP 71.216.115.33 > 10.13.1.111: ICMP echo request, id
512, seq 46854, length 40

7 packets captured
14 packets received by filter
0 packets dropped by kernel
[root at roseville-fw gregs]# 

Here is a tcpdump sample from the Roseville LAN interface.

[root at roseville-fw gregs]# /usr/sbin/tcpdump -i eth1 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
20:43:05.001453 IP 10.15.1.111 > 10.13.1.111: ICMP echo request, id 512,
seq 26118, length 40
20:43:10.501434 IP 10.15.1.111 > 10.13.1.111: ICMP echo request, id 512,
seq 26374, length 40
20:43:16.001840 IP 10.15.1.111 > 10.13.1.111: ICMP echo request, id 512,
seq 26630, length 40
20:43:21.501841 IP 10.15.1.111 > 10.13.1.111: ICMP echo request, id 512,
seq 26886, length 40
20:43:27.002178 IP 10.15.1.111 > 10.13.1.111: ICMP echo request, id 512,
seq 27142, length 40

7 packets captured
14 packets received by filter
0 packets dropped by kernel
[root at roseville-fw gregs]#

When I did similar pings from the production sites yesterday, I would
sometimes get a destination unavailable reply from an Internet router
inside the ISP.  Of course, here in my lab I won't get that kind of
feedback from my simulated Internet.  My simulated Internet is just a
Linux sysem with 2 NICs and ip_forward turned on.  But notice that raw
ICMP echo requests are going out - but esp should be going out.

Meanwhile, nothing is coming into Lakeville:

[root at lakeville-fw etc]# 
[root at lakeville-fw etc]# date
Sat Jul 22 20:50:08 CDT 2006
[root at lakeville-fw etc]# /usr/sbin/tcpdump -i eth0 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

0 packets captured
0 packets received by filter
0 packets dropped by kernel
[root at lakeville-fw etc]# date
Sat Jul 22 20:50:53 CDT 2006
[root at lakeville-fw etc]# 

Results are the same when a Lakeville host tries to ping a Roseville
host:

[root at lakeville-fw etc]# /usr/sbin/tcpdump -i eth1 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
21:03:12.589121 IP 10.13.1.111 > 10.15.1.111: ICMP echo request, id
16171, seq 4
21:03:13.589052 IP 10.13.1.111 > 10.15.1.111: ICMP echo request, id
16171, seq 4
21:03:14.589131 IP 10.13.1.111 > 10.15.1.111: ICMP echo request, id
16171, seq 4
21:03:15.589209 IP 10.13.1.111 > 10.15.1.111: ICMP echo request, id
16171, seq 4
21:03:16.589287 IP 10.13.1.111 > 10.15.1.111: ICMP echo request, id
16171, seq 4
21:03:17.589367 IP 10.13.1.111 > 10.15.1.111: ICMP echo request, id
16171, seq 4
21:03:18.589443 IP 10.13.1.111 > 10.15.1.111: ICMP echo request, id
16171, seq 4

7 packets captured
14 packets received by filter
0 packets dropped by kernel
[root at lakeville-fw etc]# /usr/sbin/tcpdump -i eth0 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
21:03:23.589984 IP 209.130.212.154 > 10.15.1.111: ICMP echo request, id
16171, 4
21:03:24.590007 IP 209.130.212.154 > 10.15.1.111: ICMP echo request, id
16171, 4
21:03:25.590084 IP 209.130.212.154 > 10.15.1.111: ICMP echo request, id
16171, 4
21:03:26.590163 IP 209.130.212.154 > 10.15.1.111: ICMP echo request, id
16171, 4
21:03:27.590245 IP 209.130.212.154 > 10.15.1.111: ICMP echo request, id
16171, 4
21:03:28.590321 IP 209.130.212.154 > 10.15.1.111: ICMP echo request, id
16171, 4
21:03:29.590399 IP 209.130.212.154 > 10.15.1.111: ICMP echo request, id
16171, 4

7 packets captured
14 packets received by filter
0 packets dropped by kernel
[root at lakeville-fw etc]# 

Here is the routing table from Roseville:

[root at roseville-fw gregs]# 
[root at roseville-fw gregs]# /sbin/ip route show
71.216.115.32/29 dev eth0  proto kernel  scope link  src 71.216.115.33 
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.2 
10.10.10.0/24 dev eth2  proto kernel  scope link  src 10.10.10.187 
10.13.1.0/24 via 71.216.115.38 dev eth0 
10.15.1.0/24 dev eth1  proto kernel  scope link  src 10.15.1.75 
169.254.0.0/16 dev eth2  scope link 
default via 71.216.115.38 dev eth0 
[root at roseville-fw gregs]# 

And the routing table from Lakeville:  (remember the Roseville LAN is
10.15.1.0/24)

[root at lakeville-fw etc]# 
[root at lakeville-fw etc]# /sbin/ip route show
209.130.212.152/30 dev eth0  proto kernel  scope link  src
209.130.212.154 
10.2.1.0/24 via 10.13.1.254 dev eth1 
10.14.1.0/24 via 10.13.1.254 dev eth1 
10.21.1.0/24 via 10.13.1.254 dev eth1 
10.19.1.0/24 via 10.13.1.254 dev eth1 
10.17.1.0/24 via 10.13.1.254 dev eth1 
10.10.10.0/24 dev eth2  proto kernel  scope link  src 10.10.10.189 
10.1.1.0/24 via 10.13.1.254 dev eth1 
10.15.1.0/24 via 209.130.212.153 dev eth0 
10.44.1.0/24 via 10.13.1.254 dev eth1 
10.13.1.0/24 dev eth1  proto kernel  scope link  src 10.13.1.1 
10.11.1.0/24 via 10.13.1.254 dev eth1 
169.254.0.0/16 dev eth2  scope link 
192.168.0.0/16 via 10.13.1.254 dev eth1 
default via 209.130.212.153 dev eth0 
[root at lakeville-fw etc]# 

Near as I can tell, the routing tables on both firewalls look like
they're supposed to look.  

I suppose the argument could be made that my simulated Internet is
messed up.  But both firewalls can ping each other.  (I have a rule that
lets each firewall see the other.)  My Lakeville host can ping the
Roseville firewall and the Roseville host can ping the Lakeville
firewall.  So I feel pretty good about my testbed here.  

The argument could also be made that a firewall rule is causing the
problems.  I could very well have a messed up rule - but the receiving
firewall never sees the packets to test them.  And the sending side
isn't sending esp.  

The problem has to be an ipsec config parameter that I messed up
someplace...

- Greg

________________________________

From: Phillip T. George [mailto:me at coruscant.stellardreams.com] 
Sent: Saturday, July 22, 2006 7:52 PM
To: Greg Scott
Cc: users at openswan.org
Subject: Re: [Openswan Users]

Greg,

What interface is tcpdump monitoring?  What other arguments are you
using when you run tcpdump?

Also...routing tables from both sides would be useful...

-Phillip

Greg Scott wrote: 

	I must be missing something basic here.  I am trying to a simple
tunnel
	with 2 subnets.  Here is the scenario below.  Apologies if an
emailer
	somewhere along the line butchers the line wrapping. 

	Roseville
	Lakeville
	Left
	Right
	               Left Firewall  <-Internet--> Right Firewall
	10.13.1.0/24  eth1       eth0             eth0             eth1
	10.15.1.0/24
	              10.13.1.1  71.216.115.33    209.130.212.154
10.15.1.75

	The left firewall and right firewall are running fc5 with the
netkey
	stack and kernel 2.6.17.2 from kernel.org.  

	When I watch /var/log/secure on both systems, I see a series of
	messages, ending with messages like this:

	Jul 22 18:17:02 lakeville-fw pluto[5492]: "Roseville-Lakeville"
#5:
	transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
	Jul 22 18:17:02 lakeville-fw pluto[5492]: "Roseville-Lakeville"
#5:
	STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0xad5f74c3}

	This tells me the SA is established between the subnets, so
	communication between the two subnets should go over the tunnel.
But
	that's not what happens.  When a host in either subnet tries to
ping the
	other side, tcpdump on the sending firewall tells me the packets
route
	in the clear out across the Internet.  I should see esp messages
going
	to/from the other subnet.  But instead, I see icmp echo request
messages
	coming from the sending subnet.  Yuck!

	I must be missing a simple setup step but I don't see it.  

	Here is ipsec.conf I am using, along with the included files and
my conn
	definition.  I like the way fc5 packages these config files,
except that
	it isn't working for me:

	[root at lakeville-fw gregs]# 
	[root at lakeville-fw gregs]# cd /etc
	[root at lakeville-fw etc]# more ipsec.conf
	# /etc/ipsec.conf - Openswan IPsec configuration file
	#
	# Manual:     ipsec.conf.5
	#
	# Please place your own config files in /etc/ipsec.d/ ending in
.conf

	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"
	        nat_traversal=yes

	include /etc/ipsec.d/*.conf
	[root at lakeville-fw etc]# 
	[root at lakeville-fw etc]# 
	[root at lakeville-fw etc]# 
	[root at lakeville-fw etc]# ls /etc/ipsec.d
	examples  hostkey.secrets  no_oe.conf  policies
	Roseville-Lakeville.conf
	[root at lakeville-fw etc]# 
	[root at lakeville-fw etc]# 
	[root at lakeville-fw etc]# more ipsec.d/no_oe.conf
	# 'include' this file to disable Opportunistic Encryption.
	# See /usr/share/doc/openswan/policygroups.html for details.
	#
	# RCSID $Id: no_oe.conf.in,v 1.2 2004/10/03 19:33:10 paul Exp $
	conn block 
	    auto=ignore

	conn private 
	    auto=ignore

	conn private-or-clear 
	    auto=ignore

	conn clear-or-private 
	    auto=ignore

	conn clear 
	    auto=ignore

	conn packetdefault 
	    auto=ignore
	[root at lakeville-fw etc]# 
	[root at lakeville-fw etc]# 
	[root at lakeville-fw etc]# more ipsec.d/Roseville-Lakeville.conf
	# /etc/ipsec.d/Lakeville-Roseville.conf - IPsec configuration
file for
	this conn
	ection.
	# The HOME office in Lakeville is always on the right.  ("Make
yerself
	RIGHT at 
	home!",
	# while the other branch stores have LEFT home.)
	#
	# Openswan bundled with fc5 - see thee include directive from
	/etc/ipsec.conf.
	#
	#       Here are some useful commands:
	#
	#       /usr/sbin/ipsec showhostkey --file
/etc/ipsec.d/hostkey.secrets
	--right
	#       /usr/sbin/ipsec showhostkey --file
/etc/ipsec.d/hostkey.secrets
	--left
	#
	#       /usr/sbin/ipsec showhostkey --file
/etc/ipsec.d/hostkey.secrets
	--right 

		rightkey.txt

	#       Show this host's public key in a format suitable to
insert into 
	#       ipsec.conf.  This host can be either the left or right
key.
	#
	#       /usr/sbin/ipsec auto --down london-farout
	#       Brings down the tunnel named london-farout
	#
	#       /usr/sbin/ipsec auto --up london-farout
	#       Brings up the tunnel named london-farount
	#
	#       /usr/local/sbin/ipsec look
	#       To observe all kinds of stuff about the IPSEC tunnels
	#
	#       /usr/local/sbin/ipsec showhostkey > junk.tmp
	#       Generates a DNS key record into the file junk.tmp for
later 
	#       insertion into a DNS zone file
	#
	#       These were some equivalent commands under prior versions
of Open
	S/WAN
	#       /usr/sbin/ipsec showhostkey --left
	#       /usr/sbin/ipsec showhostkey --right
	#       /usr/sbin/ipsec showhostkey --left > junk.tmp
	#

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

	# basic configuration

	conn Roseville-Lakeville
	        left=71.216.115.33
	        leftsubnet=10.15.1.0/24
	        leftnexthop=71.216.115.38
	        leftid=@roseville.local
	        # RSA 2192 bits   roseville-fw   Thu Jul 20 18:47:26
2006
	        leftrsasigkey=0sAQPHZAiDY....
	        #
	        # Right security gateway, subnet behind it, next hop
toward
	left.
	        right=209.130.212.154
	        rightsubnet=10.13.1.0/24
	        rightnexthop=209.130.212.153
	        rightid=@lakeville.local
	        # RSA 2192 bits   lakeville-fw   Wed Jul 19 21:09:32
2006
	        rightrsasigkey=0sAQNb9diw....
	        #
	        auto=start

	[root at lakeville-fw etc]# 

	This is what ipsec verify tells me:

	[root at lakeville-fw etc]# /usr/sbin/ipsec verify
	Checking your system to see if IPsec got installed and started
	correctly:
	Version check and ipsec on-path
[OK]
	Linux Openswan U2.4.4/K2.6.17.2fw21 (netkey)
	Checking for IPsec support in kernel
[OK]
	Checking for RSA private key (/etc/ipsec.secrets)
[FAILED]
	hostname: Unknown host
	ipsec showhostkey: no default key in "/etc/ipsec.secrets"
	Checking that pluto is running
[OK]
	Two or more interfaces found, checking IP forwarding
[OK]
	Checking NAT and MASQUERADEing                              
	Checking for 'ip' command
[OK]
	Checking for 'iptables' command
[OK]
	Checking for 'setkey' command for NETKEY IPsec stack support
[OK]
	Opportunistic Encryption Support
	[DISABLED]
	[root at lakeville-fw etc]# 

	It says the RSA private key failed - but it isn't really a
failure
	because of the way fc5 packages ipsec.secrets, like this:
	[root at lakeville-fw etc]# 
	[root at lakeville-fw etc]# more /etc/ipsec.secrets
	include /etc/ipsec.d/*.secrets
	[root at lakeville-fw etc]# 

	And I know the RSA keys are good because I establish an SA.  I
must be
	missing a simple setup someplace - but what??

	Thanks for any advice.  

	- Greg Scott
	_______________________________________________
	Users at openswan.org
	http://lists.openswan.org/mailman/listinfo/users
	Building and Integrating Virtual Private Networks with Openswan:

http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n(3155