[Openswan Users] Segfault on MIPS (Linksys WRT-54GL)
Chris Patch
chrispatch at intrstar.net
Tue Jul 25 13:51:07 CEST 2006
Just an aside,
Where did you find openswan-2.4.5 for whiterussian? I have been =
looking for that for a few weeks, to try to solve an mtu issue.
Thanks!
Chris Patch
-----Original Message-----
From: users-bounces at openswan.org [mailto:users-bounces at openswan.org] On =
Behalf Of users-request at openswan.org
Sent: Sunday, July 23, 2006 3:58 PM
To: users at openswan.org
Subject: Users Digest, Vol 32, Issue 42
Send Users mailing list submissions to
users at openswan.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openswan.org/mailman/listinfo/users
or, via email, send a message with subject or body 'help' to
users-request at openswan.org
You can reach the person managing the list at
users-owner at openswan.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Users digest..."
Today's Topics:
1. RE: [Openswan Users] (Greg Scott)
2. RE: [Openswan Users] (Greg Scott)
3. Segfault on MIPS (Linksys WRT-54GL) (Marcus Better)
4. RE: [Openswan Users] (Andy Gay)
5. Re: [Openswan Users] (Phillip T. George)
----------------------------------------------------------------------
Message: 1
Date: Sun, 23 Jul 2006 08:18:29 -0500
From: "Greg Scott" <GregScott at InfraSupportEtc.com>
Subject: RE: [Openswan Users]
To: "Andy Gay" <andy at andynet.net>
Cc: users at openswan.org
Message-ID:
<925A849792280C4E80C5461017A4B8A206F83D at mail733.InfraSupportEtc.com>
Content-Type: text/plain; charset=3D"us-ascii"
Hmmmm -=20
I compared the .config file with my 2.6.17.2 kernel with the fc5 kernel.
All the relevant options published in Paul Wouter's Openswan book are in
both. Mostly compiled as modules. And it looks like the latest and
greatest fc5 kernel is a few days older than mine. =20
I went through some netfilter notes and saw a mention about SNAT and
MASQUERADEing. I have firewall rules that MASQ everuthing going out ont
the Internet interface. It never was an issue before - but then we had
KLIPS and those ipsecnn devices. So it's possible with 2.6.17 my
sending firewall is MASQing - and that's why the packets go out in the
clear? So I would need a POSTROUTING rule that would just ACCEPT and
not SNAT or MASQ packets bound for the tunnel. And then on the
receiving side, I'd need a rule about the IP in IP stuff. =20
Hmmmm - This would explain the symptoms I see. I'm going to grab a few
hours sleep and come back to this. I will post a working ruleset
template if I can come with one. =20
- Greg
=20
-----Original Message-----
From: Andy Gay [mailto:andy at andynet.net]=20
Sent: Sunday, July 23, 2006 12:25 AM
To: Greg Scott
Cc: users at openswan.org
Subject: RE: [Openswan Users]
On Sun, 2006-07-23 at 00:09 -0500, Greg Scott wrote:
> Aw nuts, sorry about that. Lakeville is on the right, Roseville on=20
> the left. I got my diagram backwards and didn't notice until you=20
> pointed it out. For the record, it's like this:
>=20
>=20
> Roseville 10.15.1.75 71.216.115.33 Lakeville 209.130.212.154
> 10.13.1.1=20
> Left eth1 eth0 Right eth0 eth1
>=20
>=20
> The whole problem was, I used a kernel from kernel.org because of some
> other netfilter modules I wanted. Sheesh - I built it about 3 weeks=20
> ago and it's already obsolete. And I must have built it wrong because
> when I booted my test firewalls using the the original fc5 2.6.15.nnn=20
> kernel, now I see esp packets going out both interfaces.
>=20
If you were getting the IPsec SA established, your kernel is probably
OK.
There were some significant changes in the netfilter-ipsec interaction
since 2.6.16. SNAT is rumoured to work properly now, for instance.
One problem I found with 2.6.16+ is if you have an iptables DROP policy
for your INPUT chain, then you'll have to add an ACCEPT rule for
protocol 4 (IP-in-IP). Nobody seems to know just why that is.
> I'll bet by now there's an fc5 2.6.17.nnn kernel, so I'm going to grab
> that and use it.
>=20
> - Greg
>=20
>=20
>=20
> -----Original Message-----
> From: Andy Gay [mailto:andy at andynet.net]
> Sent: Saturday, July 22, 2006 11:56 PM
> To: Greg Scott
> Cc: users at openswan.org
> Subject: Re: [Openswan Users]
>=20
> On Sat, 2006-07-22 at 19:01 -0500, Greg Scott wrote:
> > I must be missing something basic here. I am trying to a simple=20
> > tunnel with 2 subnets. Here is the scenario below. Apologies if an
> > emailer somewhere along the line butchers the line wrapping.
> >=20
> > 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
>=20
> So here you say that leftsubnet is 10.13.1.0/24, rightsubnet is=20
> 10.15.1.0/24.
>=20
> But later on in your config file, you have those the other way around:
>=20
> > [root at lakeville-fw etc]# more ipsec.d/Roseville-Lakeville.conf
>=20
> > conn Roseville-Lakeville
> > left=3D71.216.115.33
> > leftsubnet=3D10.15.1.0/24
> > leftnexthop=3D71.216.115.38
> > leftid=3D at roseville.local
> > # RSA 2192 bits roseville-fw Thu Jul 20 18:47:26 2006
> > leftrsasigkey=3D0sAQPHZAiDY....
> > #
> > # Right security gateway, subnet behind it, next hop toward=20
> > left.
> > right=3D209.130.212.154
> > rightsubnet=3D10.13.1.0/24
> > rightnexthop=3D209.130.212.153
> > rightid=3D at lakeville.local
> > # RSA 2192 bits lakeville-fw Wed Jul 19 21:09:32 2006
> > rightrsasigkey=3D0sAQNb9diw....
> > #
> > auto=3Dstart
> >=20
>=20
>=20
>=20
------------------------------
Message: 2
Date: Sun, 23 Jul 2006 08:43:54 -0500
From: "Greg Scott" <GregScott at InfraSupportEtc.com>
Subject: RE: [Openswan Users]
To: "Andy Gay" <andy at andynet.net>, "Cameron Davidson"
<Cameron.Davidson at aanet.com.au>
Cc: users at openswan.org
Message-ID:
<925A849792280C4E80C5461017A4B8A206F83E at mail733.InfraSupportEtc.com>
Content-Type: text/plain; charset=3D"us-ascii"
> If you were getting the IPsec SA established, your kernel is probably
OK.
> There were some significant changes in the netfilter-ipsec interaction
> since 2.6.16. SNAT is rumoured to work properly now, for instance.
Thank you thank you thank you thank you thank you!!!!!
You guys were right - my kernel was OK. Yup, 2.6.17 does behave
differently than the earlier kernels. After sleeping a few hours a
re-reading your posts, I booted back ito 2.6.17.2 on both firewalls,
dropped all rules and turned on ip_forward. My pings are pinging now.
I tell ya, its's a thing of beauty! Just as you said, I was expecting
the firewalls to encrypt SNATed packets. Duh! =20
I can cobble together a working ruleset now thanks to your guidance. I
think the netfilter guys had a way to mark incoming esp packets so they
could be tested later on afer reinjection. I will look into that and if
I get somnething working I'll post it here. =20
Here is how tcpdump output should look! From the Roseville firewall,
with Roseville pinging Lakeville - eth1 inside, eth0 outside:
[root at roseville-fw gregs]#=20
[root at roseville-fw gregs]#=20
[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
08:32:42.370142 IP 10.15.1.111 > 10.13.1.111: ICMP echo request, id 512,
seq 4881, length 40
08:32:42.371949 IP 10.13.1.111 > 10.15.1.111: ICMP echo reply, id 512,
seq 4881, length 40
08:32:43.369982 IP 10.15.1.111 > 10.13.1.111: ICMP echo request, id 512,
seq 5137, length 40
08:32:43.370915 IP 10.13.1.111 > 10.15.1.111: ICMP echo reply, id 512,
seq 5137, length 40
08:32:44.370021 IP 10.15.1.111 > 10.13.1.111: ICMP echo request, id 512,
seq 5393, length 40
08:32:44.371995 IP 10.13.1.111 > 10.15.1.111: ICMP echo reply, id 512,
seq 5393, length 40
08:32:45.370057 IP 10.15.1.111 > 10.13.1.111: ICMP echo request, id 512,
seq 5649, length 40
08:32:45.370976 IP 10.13.1.111 > 10.15.1.111: ICMP echo reply, id 512,
seq 5649, length 40
08:32:46.370095 IP 10.15.1.111 > 10.13.1.111: ICMP echo request, id 512,
seq 5905, length 40
08:32:46.370946 IP 10.13.1.111 > 10.15.1.111: ICMP echo reply, id 512,
seq 5905, length 40
10 packets captured
20 packets received by filter
0 packets dropped by kernel
[root at roseville-fw gregs]#=20
[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
08:32:52.370513 IP 71.216.115.33 > 209.130.212.154:
ESP(spi=3D0xca12f1f8,seq=3D0x382), length 100
08:32:52.372242 IP 209.130.212.154 > 71.216.115.33:
ESP(spi=3D0x7af42d2e,seq=3D0x382), length 100
08:32:52.372242 IP 10.13.1.111 > 10.15.1.111: ICMP echo reply, id 512,
seq 7441, length 40
08:32:53.370515 IP 71.216.115.33 > 209.130.212.154:
ESP(spi=3D0xca12f1f8,seq=3D0x383), length 100
08:32:53.371202 IP 209.130.212.154 > 71.216.115.33:
ESP(spi=3D0x7af42d2e,seq=3D0x383), length 100
08:32:53.371202 IP 10.13.1.111 > 10.15.1.111: ICMP echo reply, id 512,
seq 7697, length 40
08:32:54.370556 IP 71.216.115.33 > 209.130.212.154:
ESP(spi=3D0xca12f1f8,seq=3D0x384), length 100
08:32:54.372311 IP 209.130.212.154 > 71.216.115.33:
ESP(spi=3D0x7af42d2e,seq=3D0x384), length 100
08:32:54.372311 IP 10.13.1.111 > 10.15.1.111: ICMP echo reply, id 512,
seq 7953, length 40
9 packets captured
18 packets received by filter
0 packets dropped by kernel
[root at roseville-fw gregs]#=20
- Greg
------------------------------
Message: 3
Date: Sun, 23 Jul 2006 16:06:50 +0200
From: Marcus Better <marcus at better.se>
Subject: [Openswan Users] Segfault on MIPS (Linksys WRT-54GL)
To: users at lists.openswan.org
Message-ID: <e9vvpq$nrb$2 at sea.gmane.org>
Content-Type: text/plain; charset=3Dus-ascii
Hi,
I'm having segfaults with Openswan on the Linksys WRT-54GL router with =
the
OpenWRT distribution (Whiterussian, current svn version). I tried both
Openswan 2.4.4 and 2.4.5.
Here is the log (cut off at 80 characters, sorry):
Jun 28 15:25:41 (none) kern.warn pluto[703]: Starting Pluto (Openswan
Version 2.)
Jun 28 15:25:41 (none) kern.warn pluto[703]: Setting NAT-Traversal =
port-4500
flon
Jun 28 15:25:41 (none) kern.warn pluto[703]: port floating activation
criteri1
Jun 28 15:25:41 (none) kern.warn pluto[703]: including NAT-Traversal =
patch
(Ve)
Jun 28 15:25:41 (none) kern.warn pluto[703]: ike_alg_register_enc():
Activating )
Jun 28 15:25:41 (none) kern.warn pluto[703]: starting up 1 cryptographic
helpers
Jun 28 15:25:41 (none) kern.warn pluto[703]: started helper pid=3D739 =
(fd:6)
Jun 28 15:25:41 (none) kern.warn pluto[703]: Using KLIPS IPsec interface
code on0
Jun 28 15:25:42 (none) kern.warn pluto[703]: Changing to
directory '/etc/ipsec.d/cacerts'
Jun 28 15:25:42 (none) daemon.err ipsec__plutorun: Segmentation fault
Now if I remove /etc/ipsec.d/cacerts, then it continues loading my
certificates and keys, but segfaults shortly afterwards.
Any idea what might be wrong? How do I debug this?
Marcus
------------------------------
Message: 4
Date: Sun, 23 Jul 2006 11:41:06 -0400
From: Andy Gay <andy at andynet.net>
Subject: RE: [Openswan Users]
To: Greg Scott <GregScott at InfraSupportEtc.com>
Cc: Cameron Davidson <Cameron.Davidson at aanet.com.au>
Message-ID: <1153669266.31136.0.camel at tahini.andynet.net>
Content-Type: text/plain
On Sun, 2006-07-23 at 08:43 -0500, Greg Scott wrote:=20
> I
> think the netfilter guys had a way to mark incoming esp packets so =
they
> could be tested later on afer reinjection.
Mark incoming ESP packets:
iptables -t mangle -A INPUT -i <interface> -p 50 -j MARK --set-mark =
0x50
If the packet survives IPsec policy checks, it'll show up later with the
mark still intact. So you can use it for example to bypass INPUT rules:
iptables -A INPUT -i <interface> -m mark --mark 0x50 -j ACCEPT
For anyone who knows the Cisco PIX, this is similar to setting 'sysopt
connection permit-ipsec'.
------------------------------
Message: 5
Date: Sat, 22 Jul 2006 19:52:15 -0500
From: "Phillip T. George" <me at coruscant.stellardreams.com>
Subject: Re: [Openswan Users]
To: Greg Scott <GregScott at InfraSupportEtc.com>
Cc: users at openswan.org
Message-ID: <44C2C83F.2040505 at coruscant.stellardreams.com>
Content-Type: text/plain; charset=3D"iso-8859-1"
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.=20
>
> 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. =20
>
> 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=3D>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. =20
>
> 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]#=20
> [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=3Dnone
> # plutodebug=3D"control parsing"
> nat_traversal=3Dyes
>
> include /etc/ipsec.d/*.conf
> [root at lakeville-fw etc]#=20
> [root at lakeville-fw etc]#=20
> [root at lakeville-fw etc]#=20
> [root at lakeville-fw etc]# ls /etc/ipsec.d
> examples hostkey.secrets no_oe.conf policies
> Roseville-Lakeville.conf
> [root at lakeville-fw etc]#=20
> [root at lakeville-fw etc]#=20
> [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=20
> auto=3Dignore
>
> conn private=20
> auto=3Dignore
>
> conn private-or-clear=20
> auto=3Dignore
>
> conn clear-or-private=20
> auto=3Dignore
>
> conn clear=20
> auto=3Dignore
>
> conn packetdefault=20
> auto=3Dignore
> [root at lakeville-fw etc]#=20
> [root at lakeville-fw etc]#=20
> [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=20
> 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=20
> =20
>> rightkey.txt
>> =20
> # Show this host's public key in a format suitable to insert =
into=20
> # 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=20
> # 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=3D71.216.115.33
> leftsubnet=3D10.15.1.0/24
> leftnexthop=3D71.216.115.38
> leftid=3D at roseville.local
> # RSA 2192 bits roseville-fw Thu Jul 20 18:47:26 2006
> leftrsasigkey=3D0sAQPHZAiDY....
> #
> # Right security gateway, subnet behind it, next hop toward
> left.
> right=3D209.130.212.154
> rightsubnet=3D10.13.1.0/24
> rightnexthop=3D209.130.212.153
> rightid=3D at lakeville.local
> # RSA 2192 bits lakeville-fw Wed Jul 19 21:09:32 2006
> rightrsasigkey=3D0sAQNb9diw....
> #
> auto=3Dstart
>
> [root at lakeville-fw etc]#=20
>
> 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 =20
> 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]#=20
>
> 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]#=20
> [root at lakeville-fw etc]# more /etc/ipsec.secrets
> include /etc/ipsec.d/*.secrets
> [root at lakeville-fw etc]#=20
>
> 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. =20
>
> - Greg Scott
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with Openswan:=20
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n(3155
> =20
-------------- next part --------------
An HTML attachment was scrubbed...
URL: =
http://lists.openswan.org/pipermail/users/attachments/20060722/bde271fa/a=
ttachment.htm
------------------------------
_______________________________________________
Users mailing list
Users at openswan.org
http://lists.openswan.org/mailman/listinfo/users
End of Users Digest, Vol 32, Issue 42
*************************************
--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--=20
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.4/396 - Release Date: =
7/24/2006
=20
--=20
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.4/396 - Release Date: =
7/24/2006
=20
More information about the Users
mailing list