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 openswan.org [mailto:users-bouncesopenswan.org] On Behalf Of users-requestopenswan.org
Sent: Sunday, July 23, 2006 3:58 PM
To: usersopenswan.org
Subject: Users Digest, Vol 32, Issue 42
Send Users mailing list submissions to
usersopenswan.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-requestopenswan.org
You can reach the person managing the list at
users-owneropenswan.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" <GregScottInfraSupportEtc.com>
Subject: RE: [Openswan Users]
To: "Andy Gay" <andyandynet.net>
Cc: usersopenswan.org
Message-ID:
<925A849792280C4E80C5461017A4B8A206F83Dmail733.InfraSupportEtc.com>
Content-Type: text/plain; charset="us-ascii"
Hmmmm -
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.
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.
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.
- Greg
-----Original Message-----
From: Andy Gay [mailto:andyandynet.net]
Sent: Sunday, July 23, 2006 12:25 AM
To: Greg Scott
Cc: usersopenswan.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
> the left. I got my diagram backwards and didn't
notice until you
> pointed it out. For the record, it's like this:
>
>
> Roseville 10.15.1.75 71.216.115.33 Lakeville
209.130.212.154
> 10.13.1.1
> Left eth1 eth0 Right
eth0 eth1
>
>
> 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
> 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
> kernel, now I see esp packets going out both
interfaces.
>
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.
>
> - Greg
>
>
>
> -----Original Message-----
> From: Andy Gay [mailto:andyandynet.net]
> Sent: Saturday, July 22, 2006 11:56 PM
> To: Greg Scott
> Cc: usersopenswan.org
> Subject: Re: [Openswan Users]
>
> 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
> > 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
>
> So here you say that leftsubnet is 10.13.1.0/24,
rightsubnet is
> 10.15.1.0/24.
>
> But later on in your config file, you have those the
other way around:
>
> > [rootlakeville-fw etc]# more
ipsec.d/Roseville-Lakeville.conf
>
> > 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
> >
>
>
>
------------------------------
Message: 2
Date: Sun, 23 Jul 2006 08:43:54 -0500
From: "Greg Scott" <GregScottInfraSupportEtc.com>
Subject: RE: [Openswan Users]
To: "Andy Gay" <andyandynet.net>, "Cameron Davidson"
<Cameron.Davidsonaanet.com.au>
Cc: usersopenswan.org
Message-ID:
<925A849792280C4E80C5461017A4B8A206F83Email733.InfraSupportEtc.com>
Content-Type: text/plain; charset="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!
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.
Here is how tcpdump output should look! From the Roseville
firewall,
with Roseville pinging Lakeville - eth1 inside, eth0
outside:
[rootroseville-fw gregs]#
[rootroseville-fw gregs]#
[rootroseville-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
[rootroseville-fw gregs]#
[rootroseville-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=0xca12f1f8,seq=0x382), length 100
08:32:52.372242 IP 209.130.212.154 > 71.216.115.33:
ESP(spi=0x7af42d2e,seq=0x382), 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=0xca12f1f8,seq=0x383), length 100
08:32:53.371202 IP 209.130.212.154 > 71.216.115.33:
ESP(spi=0x7af42d2e,seq=0x383), 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=0xca12f1f8,seq=0x384), length 100
08:32:54.372311 IP 209.130.212.154 > 71.216.115.33:
ESP(spi=0x7af42d2e,seq=0x384), 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
[rootroseville-fw gregs]#
- Greg
------------------------------
Message: 3
Date: Sun, 23 Jul 2006 16:06:50 +0200
From: Marcus Better <marcusbetter.se>
Subject: [Openswan Users] Segfault on MIPS (Linksys
WRT-54GL)
To: userslists.openswan.org
Message-ID: <e9vvpq$nrb$2sea.gmane.org>
Content-Type: text/plain; charset=us-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=739 (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 <andyandynet.net>
Subject: RE: [Openswan Users]
To: Greg Scott <GregScottInfraSupportEtc.com>
Cc: Cameron Davidson <Cameron.Davidsonaanet.com.au>
Message-ID: <1153669266.31136.0.cameltahini.andynet.net>
Content-Type: text/plain
On Sun, 2006-07-23 at 08:43 -0500, Greg Scott wrote:
> 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" <mecoruscant.stellardreams.com>
Subject: Re: [Openswan Users]
To: Greg Scott <GregScottInfraSupportEtc.com>
Cc: usersopenswan.org
Message-ID: <44C2C83F.2040505coruscant.stellardreams.com>
Content-Type: text/plain; charset="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.
>
> 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:
>
> [rootlakeville-fw gregs]#
> [rootlakeville-fw gregs]# cd /etc
> [rootlakeville-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
> [rootlakeville-fw etc]#
> [rootlakeville-fw etc]#
> [rootlakeville-fw etc]#
> [rootlakeville-fw etc]# ls /etc/ipsec.d
> examples hostkey.secrets no_oe.conf policies
> Roseville-Lakeville.conf
> [rootlakeville-fw etc]#
> [rootlakeville-fw etc]#
> [rootlakeville-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
> [rootlakeville-fw etc]#
> [rootlakeville-fw etc]#
> [rootlakeville-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 bond-farout
> # Brings down the tunnel named bond-farout
> #
> # /usr/sbin/ipsec auto --up bond-farout
> # Brings up the tunnel named bond-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
>
> [rootlakeville-fw etc]#
>
> This is what ipsec verify tells me:
>
> [rootlakeville-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]
> [rootlakeville-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:
> [rootlakeville-fw etc]#
> [rootlakeville-fw etc]# more /etc/ipsec.secrets
> include /etc/ipsec.d/*.secrets
> [rootlakeville-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
> _______________________________________________
> Usersopenswan.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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/
pipermail/users/attachments/20060722/bde271fa/attachment.htm
------------------------------
_______________________________________________
Users mailing list
Usersopenswan.org
http
://lists.openswan.org/mailman/listinfo/users
End of Users Digest, Vol 32, Issue 42
*************************************
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
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
--
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
_______________________________________________
Usersopenswan.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
|