From david at craigon.co.uk  Thu Jan  1 06:20:10 2009
From: david at craigon.co.uk (David J Craigon)
Date: Thu, 1 Jan 2009 11:20:10 +0000
Subject: [Openswan Users] Can't get NAT traversal to work
Message-ID: <c1ace6860901010320y44268a18sacf85f2ebab7157e@mail.gmail.com>

Hello,

Happy new year! What do you do when you are off on your holidays? Naturally,
I play with VPNs. :-)

Anyway, I cannot get NAT traversal to work. My setup is as follows- I want
to get a VPN running between two hosts both running Openswan. One is on the
internet and has a public IP address, and is running Fedora 9. The other is
my laptop sat at home behind a NAT running Fedora 10.

I've successfully created a VPN between two hosts on the same subnet (behind
the NAT). So now I'm trying to get NAT traversal to work.

Here is my config file:

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

config setup
    protostack=netkey
    nat_traversal=yes

conn host-to-host
    left=192.168.2.34
    leftid=81.76.68.138
    leftnexthop=192.168.2.1
    leftsubnet=192.168.2.0/24
 leftrsasigkey=blah blah blah
    right=94.102.146.99               # Remote vitals
    rightid=94.102.146.99
    rightsubnet=94.102.146.96/29
    rightrsasigkey=blah blah blah
    rightnexthop=94.102.146.97     # correct in many situations
    auto=add                       # authorizes but doesn't start this
                                   # connection at startup


---------------------

When I do on the box behind the NAT I get:

[root at localhost log]# ipsec auto --up host-to-host
104 "host-to-host" #1: STATE_MAIN_I1: initiate
010 "host-to-host" #1: STATE_MAIN_I1: retransmission; will wait 20s for
response


and I see in /etc/secure on the remote box:
Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500: ignoring
unknown Vendor ID payload [4f457d5a765a404d5b4f5744]
Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500: received
Vendor ID payload [Dead Peer Detection]
Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500: received
Vendor ID payload [RFC 3947] method set to=109
Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already
using method 109
Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already
using method 109
Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already
using method 109
Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500: initial
Main Mode message received on 94.102.146.99:500 but no connection has been
authorized with policy=RSASIG


Any ideas? Thanks in advance,

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090101/7b8aa327/attachment.html 

From paul at xelerance.com  Thu Jan  1 19:52:10 2009
From: paul at xelerance.com (Paul Wouters)
Date: Thu, 1 Jan 2009 19:52:10 -0500 (EST)
Subject: [Openswan Users] IPSEC SA only being installed on one side
In-Reply-To: <Pine.LNX.4.64.0812301739240.4268@fedex.thefeds.net>
References: <Pine.LNX.4.64.0812301739240.4268@fedex.thefeds.net>
Message-ID: <Pine.LNX.4.64.0901011950550.6849@newtla.xelerance.com>

On Tue, 30 Dec 2008, openswan at thefeds.net wrote:

There have been some fixes to rekeying lately. Please try the latest
test release (2.6.20rc1). Though this bug might still exist.

Paul

> Date: Tue, 30 Dec 2008 18:35:42 +0000 (GMT)
> From:  <openswan at thefeds.net>
> To:  <users at openswan.org>
> Subject: [Openswan Users] IPSEC SA only being installed on one side
> 
> I am trying to track down a problem I am having quite frequently where my 
> phase 1 SA is fine (and thus DPD doesn't see any problems) but my phase 2 
> SAs aren't in step and thus traffic can't get through.
> 
> The problem appears to be that sometimes when a new phase 2 SA is 
> negotiated one side is happy and installs the SA, but the other side 
> (never the initiator) doesn't install the SA. The side with the newer SA 
> then sends packets encrypted with the new SPI which the other side cannot 
> understand.
> 
> I have the following extracts from /var/log/secure:
> 
> The initiator:
> Dec 30 12:40:04 vpn01d pluto[4943]: "tun02a01d" #442: STATE_MAIN_I4: 
> ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 
> prf=oakley_sha group=modp1536}
> Dec 30 12:40:04 vpn01d pluto[4943]: "tun02a01d" #442: Dead Peer Detection 
> (RFC 3706): enabled
> Dec 30 14:32:40 vpn01d pluto[4943]: "tun02a01d" #455: initiating Quick 
> Mode PSK+ENCRYPT+PFS+UP+IKEv2ALLOW to replace #428 {using isakmp#442 
> msgid:1ff67d30 proposal=AES(12)_256-SHA1(2)_160 
> pfsgroup=OAKLEY_GROUP_MODP1536}
> Dec 30 14:32:40 vpn01d pluto[4943]: "tun02a01d" #455: Dead Peer Detection 
> (RFC 3706): enabled
> Dec 30 14:32:40 vpn01d pluto[4943]: "tun02a01d" #455: transition from 
> state STATE_QUICK_I1 to state STATE_QUICK_I2
> Dec 30 14:32:40 vpn01d pluto[4943]: "tun02a01d" #455: STATE_QUICK_I2: sent 
> QI2, IPsec SA established transport mode {ESP=>0x0f2d2e3a <0x36134870 
> xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=none DPD=enabled}
> Dec 30 14:32:50 vpn01d pluto[4943]: "tun02a01d" #455: message ignored 
> because it contains an unexpected payload type (ISAKMP_NEXT_HASH)
> Dec 30 14:32:50 vpn01d pluto[4943]: "tun02a01d" #455: sending encrypted 
> notification INVALID_PAYLOAD_TYPE to <vpn02a ip>:500
> 
> The reciever:
> Dec 30 12:40:04 vpn02a pluto[547]: "tun02a01d" #480: STATE_MAIN_R3: sent 
> MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 
> prf=oakley_sha group=modp1536}
> Dec 30 12:40:04 vpn02a pluto[547]: "tun02a01d" #480: Dead Peer Detection 
> (RFC 3706): enabled
> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #480: the peer proposed: 
> <vpn02a ip>/32:0/0 -> <vpn02d ip>/32:0/0
> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515: responding to Quick 
> Mode proposal {msgid:1ff67d30}
> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515:     us: 
> <vpn02a ip><<vpn02a ip>>[+S=C]---<vpn02a nh>
> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515:   them: 
> <vpn01d nh>---<vpn01d ip><<vpn01d ip>>[+S=C]
> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515: keeping 
> refhim=4294901761 during rekey
> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515: transition from state 
> STATE_QUICK_R0 to state STATE_QUICK_R1
> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515: STATE_QUICK_R1: sent 
> QR1, inbound IPsec SA installed, expecting QI2
> Dec 30 14:32:40 vpn02a pluto[547]: packet from <vpn01d ip>:500: 
> Informational Exchange is for an unknown (expired?) SA
> Dec 30 14:32:50 vpn02a pluto[547]: "tun02a01d" #480: ignoring 
> informational payload, type INVALID_PAYLOAD_TYPE msgid=00000000
> Dec 30 14:32:50 vpn02a pluto[547]: "tun02a01d" #480: received and ignored 
> informational message
> 
> I then end up with the following SAs on vpn02a:
> 000 #523: "tun02a01d":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established); 
> EVENT_SA_REPLACE in 9590s; newest ISAKMP; lastdpd=2s(seq in:24780 out:0); 
> idle; import:not set
> 000 #480: "tun02a01d":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established); 
> EVENT_SA_REPLACE in 2449s; lastdpd=1210s(seq in:7855 out:0); idle; 
> import:not set
> 000 #470: "tun02a01d":500 STATE_QUICK_R2 (IPsec SA established); 
> EVENT_SA_REPLACE in 2026s; newest IPSEC; eroute owner; isakmp#454; idle; 
> import:not set
> 000 #470: "tun02a01d" esp.f2d777e3@<vpn01d ip> esp.8ca1e089@<vpn02a ip> 
> ref=0 refhim=4294901761
> 
> and vpn01d:
> 000 #466: "tun02a01d":500 STATE_MAIN_I4 (ISAKMP SA established); 
> EVENT_SA_REPLACE in 5934s; newest ISAKMP; lastdpd=1s(seq in:3752 out:0); 
> idle; import:admin initiate
> 000 #455: "tun02a01d":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); 
> EVENT_SA_REPLACE in 5593s; newest IPSEC; eroute owner; isakmp#442; idle; 
> import:admin initiate
> 000 #455: "tun02a01d" esp.f2d2e3a@<vpn02a ip> esp.36134870@<vpn01d ip> 
> ref=0 refhim=4294901761
> 000 #442: "tun02a01d":500 STATE_MAIN_I4 (ISAKMP SA established); 
> EVENT_SA_EXPIRE in 6050s; lastdpd=1209s(seq in:17036 out:0); idle; 
> import:admin initiate
> 000 #428: "tun02a01d":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); 
> EVENT_SA_EXPIRE in 5627s; isakmp#411; idle; import:admin initiate
> 000 #428: "tun02a01d" esp.8ca1e089@<vpn02a ip> esp.f2d777e3@<vpn01d ip> 
> ref=0 refhim=4294901761
> 
> So you can see that vpn02a does have esp.36134870@<vpn01d ip> 
> esp.f2d2e3a@<vpn02a ip> installed and as that is newest on vpn01d that is 
> what it is using for all traffic to vpn02a.
> 
> I am guessing that the log entry of:
> Dec 30 14:32:40 vpn02a pluto[547]: packet from <vpn01d ip>:500: 
> Informational Exchange is for an unknown (expired?) SA
> May be the QI2 packet from vpn01d that vpn01d doesn't understand? I 
> thought at one time that the phase 1 SA may be expiring at this point, but 
> I am seeing this happen far too often for that. Plus as the logs show the 
> phase 1 SA was renegotiated 112 minutes and 48 seconds earlier and I have 
> a key life of 240 minutes with a rekeying margin of 120 minutes and a 
> rekeying fuzz of 1% so the next phase 1 rekeying isn't due for another 6 
> minutes to 7 minutes 12 seconds. I do see the phase 1 rekey happen in the 
> logs 6 minutes and 25 seconds later.
> 
> Does anyone have any idea how I can go about finding out why the recieving 
> end sometimes doesn't install the new phase 2 SA?
> 
> Thanks in advance for any help
> Tim
> _______________________________________________
> 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=283155
> 

From paul at xelerance.com  Thu Jan  1 19:53:48 2009
From: paul at xelerance.com (Paul Wouters)
Date: Thu, 1 Jan 2009 19:53:48 -0500 (EST)
Subject: [Openswan Users] Can't ping peer after connection...
In-Reply-To: <1113201c96a9f$4e9287e0$ebb797a0$@com>
References: <1113201c96a9f$4e9287e0$ebb797a0$@com>
Message-ID: <Pine.LNX.4.64.0901011953180.6849@newtla.xelerance.com>

On Tue, 30 Dec 2008, Dan Brown wrote:

run ipsec barf on both ends and fix any potential warnings. check you're
not NAT'ing ipsec packets by accident.

Paul

> So yesterday we got our IPSec connection up for a little while after some
> troubleshooting.  A couple of hours later with no changes on either end the
> connection failed to renegotiate and could not properly reconnect.  During
> the period of a successful connection, I could ping the peer, but I couldn't
> connect to the server on the other side of the VPN gateway.  An nmap said
> the internal server was down (regardless of port).  
> 
> We were thinking the problem may have been with the firewalling on the
> internal server.  Now I am not so sure.  
> 
> If I start a ping, then bring up the connection, the responses stop.  I
> could never ping or see an open port on the internal server so perhaps two
> one-sided tunnels were actually created from the other side.
> 
> This is what ipsec whack --status shows for this connection:
> 
> 000 "g2c-p":
> 209.167.162.84/32===209.167.162.84...207.236.235.99===199.43.146.0/24;
> erouted; eroute owner: #3
> 000 "g2c-p":     srcip=unset; dstip=unset; srcup=ipsec _updown; dstup=ipsec
> _updown;
> 000 "g2c-p":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s;
> rekey_fuzz: 100%; keyingtries: 0
> 000 "g2c-p":   policy: PSK+ENCRYPT+TUNNEL+PFS+UP; prio: 32,24; interface:
> eth0; encap: esp;
> 000 "g2c-p":   newest ISAKMP SA: #1; newest IPsec SA: #3; 
> 000 "g2c-p":   IKE algorithms wanted: 3DES_CBC(5)_000-SHA1(2)-MODP1536(5),
> 3DES_CBC(5)_000-SHA1(2)-MODP1024(2); flags=strict
> 000 "g2c-p":   IKE algorithms found:
> 3DES_CBC(5)_192-SHA1(2)_002-MODP1536(5),
> 3DES_CBC(5)_192-SHA1(2)_002-MODP1024(2)
> 000 "g2c-p":   IKE algorithm newest: 3DES_CBC_192-SHA1-MODP1024
> 000 "g2c-p":   ESP algorithms wanted: AES(12)_128-SHA1(2),
> 3DES(3)_000-SHA1(2); flags=strict
> 000 "g2c-p":   ESP algorithms loaded: AES(12)_128-SHA1(2),
> 3DES(3)_000-SHA1(2); flags=strict
> 000 "g2c-p":   ESP algorithm newest: 3DES_0-HMAC_SHA1; pfsgroup=<Phase1>
> 000  
> 000 #3: "g2c-p":500 STATE_QUICK_I2 (sent QI2, IPsec SA established);
> EVENT_SA_REPLACE in 27211s; newest IPSEC; eroute owner
> 000 #3: "g2c-p" esp.79e8e525 at 207.236.235.99 esp.e6dcb67b at 209.167.162.84
> tun.0 at 207.236.235.99 tun.0 at 209.167.162.84
> 000 #2: "g2c-p":500 STATE_QUICK_I2 (sent QI2, IPsec SA established);
> EVENT_SA_REPLACE in 26516s
> 000 #2: "g2c-p" esp.8bbfd32c at 207.236.235.99 esp.f5f4af97 at 209.167.162.84
> tun.0 at 207.236.235.99 tun.0 at 209.167.162.84
> 000 #1: "g2c-p":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE
> in 1229s; newest ISAKMP; lastdpd=2s(seq in:0 out:0)
> 000  
> 
> 
> To me this looks like two one sided connections.  Should I be able to ping
> the peer after the tunnel starts?
> 
> ---------------
> Dan Brown
> danb at zu.com
> 
> 
> 
> _______________________________________________
> 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=283155
> 

From paul at xelerance.com  Thu Jan  1 19:54:54 2009
From: paul at xelerance.com (Paul Wouters)
Date: Thu, 1 Jan 2009 19:54:54 -0500 (EST)
Subject: [Openswan Users] Trouble getting NAT-T patch to work
In-Reply-To: <E80B65F27529BB409F833498BB79F84E07B28C@r2d2.heartslc.com>
References: <E80B65F27529BB409F833498BB79F84E07B28C@r2d2.heartslc.com>
Message-ID: <Pine.LNX.4.64.0901011954100.6849@newtla.xelerance.com>

On Wed, 31 Dec 2008, Jonathan Larsen wrote:

Please try 2.6.20rc1 (from testing/) as we fixed some header defines that
were wrong for some kernels.

Paul

> Date: Wed, 31 Dec 2008 07:57:47 -0700
> From: Jonathan Larsen <jon at heartslc.com>
> To:  <users at openswan.org>
> Subject: [Openswan Users] Trouble getting NAT-T patch to work
> 
> I am using Slackware 12.1 for my servers which runs Kernel 2.6.24.5.  I have had no luck with the patch working, just get 6 hunk failures on udp.c.  So i've downloaded kernels directly from kernel.org.  the one i've had the most luck with is 2.6.19.  I am also using openswan 2.6.19.  Patch works fine.  Recompile the kernel, no problem.  go to make module in the openswan dir and i have problems.  Maybe there is a recommended kernel to use?  Below is the compile issues i had with make module.
> 
> ln -s -f /usr/src/openswan-2.6.19/linux/net/ipsec/ipsec_xmit.c /usr/src/openswan-2.6.19/modobj26/ipsec_xmit.c
> 
>   CC [M]  /usr/src/openswan-2.6.19/modobj26/ipsec_xmit.o
> 
> /usr/src/openswan-2.6.19/modobj26/ipsec_xmit.c: In function 'ipsec_xmit_esp':
> 
> /usr/src/openswan-2.6.19/modobj26/ipsec_xmit.c:729: warning: implicit declaration of function 'skb_set_transport_header'
> 
> /usr/src/openswan-2.6.19/modobj26/ipsec_xmit.c: In function 'ipsec_xmit_cont':
> 
> /usr/src/openswan-2.6.19/modobj26/ipsec_xmit.c:1072: warning: implicit declaration of function 'skb_set_network_header'
> 
> /usr/src/openswan-2.6.19/modobj26/ipsec_xmit.c: In function 'ipsec_xmit_send':
> 
> /usr/src/openswan-2.6.19/modobj26/ipsec_xmit.c:2006: warning: passing argument 2 of 'ip_route_output_key' from incompatible pointer type
> 
> /usr/src/openswan-2.6.19/modobj26/ipsec_xmit.c:2046: warning: implicit declaration of function 'skb_network_header'
> 
> /usr/src/openswan-2.6.19/modobj26/ipsec_xmit.c:2046: error: invalid operands to binary -
> 
> /usr/src/openswan-2.6.19/modobj26/ipsec_xmit.c:2053: error: invalid operands to binary -
> 
> /usr/src/openswan-2.6.19/modobj26/ipsec_xmit.c:2057: error: invalid operands to binary -
> 
> make[3]: *** [/usr/src/openswan-2.6.19/modobj26/ipsec_xmit.o] Error 1
> 
> make[2]: *** [_module_/usr/src/openswan-2.6.19/modobj26] Error 2
> 
> make[2]: Leaving directory `/usr/src/linux-2.6.19'
> 
> make[1]: *** [module26] Error 2
> 
> make[1]: Leaving directory `/usr/src/openswan-2.6.19'
> 
> make: *** [module] Error 2
> 
> 
> 

From paul at xelerance.com  Thu Jan  1 19:59:22 2009
From: paul at xelerance.com (Paul Wouters)
Date: Thu, 1 Jan 2009 19:59:22 -0500 (EST)
Subject: [Openswan Users] Can't get NAT traversal to work
In-Reply-To: <c1ace6860901010320y44268a18sacf85f2ebab7157e@mail.gmail.com>
References: <c1ace6860901010320y44268a18sacf85f2ebab7157e@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0901011955230.6849@newtla.xelerance.com>

On Thu, 1 Jan 2009, David J Craigon wrote:

> Anyway, I cannot get NAT traversal to work. My setup is as follows- I want
> to get a VPN running between two hosts both running Openswan. One is on the
> internet and has a public IP address, and is running Fedora 9. The other is
> my laptop sat at home behind a NAT running Fedora 10.

I have a similar setup on my laptop, where I tunnel my own /29 onto my laptop.

> conn host-to-host
>     left=192.168.2.34
>     leftid=81.76.68.138
>     leftnexthop=192.168.2.1
>     leftsubnet=192.168.2.0/24
>  leftrsasigkey=blah blah blah
>     right=94.102.146.99               # Remote vitals
>     rightid=94.102.146.99
>     rightsubnet=94.102.146.96/29
>     rightrsasigkey=blah blah blah
>     rightnexthop=94.102.146.97     # correct in many situations
>     auto=add                       # authorizes but doesn't start this
>                                    # connection at startup

With both ends being openswan, ditch PSK and use raw RSA. eg:

	authby=rsasig
	leftrsasigkey=XXXX
	rightrsasigkey=YYY
	leftid=@laptop
	rightid=@server
	left=%defaultroute

get the rsasigkey lines using: ipsec showhostkey --left (--right) on the
two machines. This will avoid PSK authentication by IP while having other
IP's due to NAT.

> 
> When I do on the box behind the NAT I get:
> 
> [root at localhost log]# ipsec auto --up host-to-host
> 104 "host-to-host" #1: STATE_MAIN_I1: initiate
> 010 "host-to-host" #1: STATE_MAIN_I1: retransmission; will wait 20s for
> response
> 
> 
> and I see in /etc/secure on the remote box:
> Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500: ignoring
> unknown Vendor ID payload [4f457d5a765a404d5b4f5744]
> Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500: received
> Vendor ID payload [Dead Peer Detection]
> Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500: received
> Vendor ID payload [RFC 3947] method set to=109
> Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500: received
> Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already
> using method 109
> Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500: received
> Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already
> using method 109
> Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500: received
> Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already
> using method 109
> Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500: initial
> Main Mode message received on 94.102.146.99:500 but no connection has been
> authorized with policy=RSASIG

You are missing authby=secret to use PSK's on the laptop.

Paul

From muir.james.a at gmail.com  Fri Jan  2 21:22:56 2009
From: muir.james.a at gmail.com (James Muir)
Date: Fri, 02 Jan 2009 21:22:56 -0500
Subject: [Openswan Users] mtu problems
In-Reply-To: <49579F5A.80004@gmail.com>
References: <49579F5A.80004@gmail.com>
Message-ID: <495ECC00.9040306@gmail.com>

James Muir wrote:
> Is there something analogous to overridemtu= that I can set with NETKEY? 
>   I have tried changing the MTU value on eth0 using ifconfig, but that 
> did not seem to help.

any hints on this one?  If I knew where the mtu was set in the openswan 
code, I could try recompiling with a hard coded value...

I am anticipating that someone will say use KLIPS rather than NETKEY :-(

incidentally, the KLIPS module fails to build on my machine (kernel 
2.6.24, openswan 2.6.19):

make[2]: Entering directory `/usr/src/linux-source-2.6.24'

   WARNING: Symbol version dump /usr/src/linux-source-2.6.24/Module.symvers
            is missing; modules will have no dependencies and modversions.

ln -s -f /scratch/openswan-2.6.19/linux/net/ipsec/ipsec_init.c 
/scratch/openswan-2.6.19/modobj26/ipsec_init.c
   CC [M]  /scratch/openswan-2.6.19/modobj26/ipsec_init.o
In file included from /scratch/openswan-2.6.19/modobj26/ipsec_init.c:57:
include/net/ip.h: In function ?ip_hdrlen?:
include/net/ip.h:49: error: ?const struct sk_buff? has no member named ?nh?

-James

From paul at xelerance.com  Sat Jan  3 08:58:45 2009
From: paul at xelerance.com (Paul Wouters)
Date: Sat, 3 Jan 2009 08:58:45 -0500 (EST)
Subject: [Openswan Users] mtu problems
In-Reply-To: <495ECC00.9040306@gmail.com>
References: <49579F5A.80004@gmail.com> <495ECC00.9040306@gmail.com>
Message-ID: <Pine.LNX.4.64.0901030857460.19783@newtla.xelerance.com>

On Fri, 2 Jan 2009, James Muir wrote:

> James Muir wrote:
> > Is there something analogous to overridemtu= that I can set with NETKEY? 
> >   I have tried changing the MTU value on eth0 using ifconfig, but that 
> > did not seem to help.
> 
> any hints on this one?  If I knew where the mtu was set in the openswan 
> code, I could try recompiling with a hard coded value...

Did you set the mtu on both ends?

> incidentally, the KLIPS module fails to build on my machine (kernel 
> 2.6.24, openswan 2.6.19):

try 2.6.20rc1 from testing/

Paul

From broda at billiger-mietwagen.de  Sat Jan  3 12:47:50 2009
From: broda at billiger-mietwagen.de (Thomas Broda)
Date: Sat, 03 Jan 2009 18:47:50 +0100
Subject: [Openswan Users] Problem distinguishing roadwarrriors
Message-ID: <495FA4C6.8080603@billiger-mietwagen.de>

Hi,

I have an annoying problem with my roadwarrior configuration. I've got
several Linux and Windows roadwarriors.

Regarding the Linux users, there are several entries in ipsec.conf like
following one, of course with individual IDs:

conn roadwarrior-linux1
authby=rsasig
left=%defaultroute
leftrsasigkey=%cert
leftid="/C=DE/ [...]"
leftcert=leftcertfile.pem
leftsubnet=192.168.3.0/24
right=%any
rightrsasigkey=%cert
rightid="/C=DE/ [...]"
auto=add

The Linux users can establish connections without any problem.

Then, there's a standard config for the Windows users using the builtin
L2TP client:

conn roadwarrior-l2tp
authby=secret
rekey=no
pfs=no
keyingtries=1
left=%defaultroute
leftprotoport=17/1701
right=%any
rightprotoport=17/1701
auto=add

This config works fine, but only if it is the only roadwarrior entry in
ipsec.conf.

If ipsec.conf contains both kinds of configurations (several Linux
roadwarriors AND the Windows L2TP config), then connection attempts from
the Windows clients end up in the wrong configuration context. That is,
Openswan will try to apply the configuration from "conn
roadwarrior-linux1" (as an example) instead using "conn roadwarrior-l2tp".

What do I need to change in order to make Openswan use the right
configuration for the Windows clients?

Cheers,

-- 
Thomas

From paul at xelerance.com  Sat Jan  3 20:13:31 2009
From: paul at xelerance.com (Paul Wouters)
Date: Sat, 3 Jan 2009 20:13:31 -0500 (EST)
Subject: [Openswan Users] Problem distinguishing roadwarrriors
In-Reply-To: <495FA4C6.8080603@billiger-mietwagen.de>
References: <495FA4C6.8080603@billiger-mietwagen.de>
Message-ID: <Pine.LNX.4.64.0901032009280.21386@newtla.xelerance.com>

On Sat, 3 Jan 2009, Thomas Broda wrote:

> I have an annoying problem with my roadwarrior configuration. I've got
> several Linux and Windows roadwarriors.

> If ipsec.conf contains both kinds of configurations (several Linux
> roadwarriors AND the Windows L2TP config), then connection attempts from
> the Windows clients end up in the wrong configuration context. That is,
> Openswan will try to apply the configuration from "conn
> roadwarrior-linux1" (as an example) instead using "conn roadwarrior-l2tp".
> 
> What do I need to change in order to make Openswan use the right
> configuration for the Windows clients?

Note that openswan can "correct" the connection if multiple configurations
overlap in phase1 (eg if phase1 is not distinctive enough). So it might
look like it picks the wrong connection while in fact it might not be.

But some logs would help to determine if this is the case.

Since l2tp is in transport mode, and the linux clients are not, try
adding an explicite type=transport to the roadwarriors-l2tp conn to
see if that makes any difference.

Paul

From muir.james.a at gmail.com  Sat Jan  3 22:06:07 2009
From: muir.james.a at gmail.com (James Muir)
Date: Sat, 03 Jan 2009 22:06:07 -0500
Subject: [Openswan Users] mtu problems
In-Reply-To: <Pine.LNX.4.64.0901030857460.19783@newtla.xelerance.com>
References: <49579F5A.80004@gmail.com> <495ECC00.9040306@gmail.com>
	<Pine.LNX.4.64.0901030857460.19783@newtla.xelerance.com>
Message-ID: <4960279F.30607@gmail.com>

Paul Wouters wrote:
> On Fri, 2 Jan 2009, James Muir wrote:
> 
>> James Muir wrote:
>>> Is there something analogous to overridemtu= that I can set with NETKEY? 
>>>   I have tried changing the MTU value on eth0 using ifconfig, but that 
>>> did not seem to help.
>> any hints on this one?  If I knew where the mtu was set in the openswan 
>> code, I could try recompiling with a hard coded value...
> 
> Did you set the mtu on both ends?

no.  I am using openswan only on my end; the other end is a sonicwall. 
I am not able to set the mtu on the sonicwall.

Just to recap, after I connect to the sonicwall

this works:  ping -s 1402

this does not:  ping -s 1403

The larger packet size causes an "icmp fragmentation needed" response.

the freeswan faq suggests that I should try using the option 
overridemtu= to fix this, but this option is for KLIPS only.  Is there 
something that can be done with NETKEY??

>> incidentally, the KLIPS module fails to build on my machine (kernel 
>> 2.6.24, openswan 2.6.19):
> 
> try 2.6.20rc1 from testing/

If there is zero possibility of correcting the mtu size with the NETKEY 
stack, then I will give KLIPS a try.  However, my feeling is that it 
should be possible make NETKEY work.

-James

From user001 at eatsrootsandleaves.com  Thu Jan  1 16:34:33 2009
From: user001 at eatsrootsandleaves.com (Alex Ip)
Date: Fri, 02 Jan 2009 08:34:33 +1100
Subject: [Openswan Users] alloc_bytes1() was mistakenly asked to malloc 0
 bytes for st_skey_ar in duplicate_state
Message-ID: <495D36E9.5040706@eatsrootsandleaves.com>

G'day...

	I don't know whether this is due to a misconfiguration on my part, but I keep getting this message in my logs for an otherwise perfectly functional link. It doesn't seem to be causing any problems, but I thought it might be important to report it to the developers. Any ideas?

Regards,

Alex.

--------------------- FreeS/WAN Begin ------------------------ 

 UNKNOWN: Jan  1 00:23:49 mail pluto[9456]: "thom-moor" #112: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_ar in duplicate_state, please report to dev at openswan.org
 UNKNOWN: Jan  1 00:23:49 mail pluto[9456]: "thom-moor" #112: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_er in duplicate_state, please report to dev at openswan.org
 UNKNOWN: Jan  1 00:23:49 mail pluto[9456]: "thom-moor" #112: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pi in duplicate_state, please report to dev at openswan.org
 UNKNOWN: Jan  1 00:23:49 mail pluto[9456]: "thom-moor" #112: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pr in duplicate_state, please report to dev at openswan.org
 UNKNOWN: Jan  1 08:13:40 mail pluto[9456]: "thom-moor" #123: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_ar in duplicate_state, please report to dev at openswan.org
 UNKNOWN: Jan  1 08:13:40 mail pluto[9456]: "thom-moor" #123: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_er in duplicate_state, please report to dev at openswan.org
 UNKNOWN: Jan  1 08:13:40 mail pluto[9456]: "thom-moor" #123: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pi in duplicate_state, please report to dev at openswan.org
 UNKNOWN: Jan  1 08:13:40 mail pluto[9456]: "thom-moor" #123: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pr in duplicate_state, please report to dev at openswan.org
 UNKNOWN: Jan  1 15:56:31 mail pluto[9456]: "thom-moor" #134: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_ar in duplicate_state, please report to dev at openswan.org
 UNKNOWN: Jan  1 15:56:31 mail pluto[9456]: "thom-moor" #134: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_er in duplicate_state, please report to dev at openswan.org
 UNKNOWN: Jan  1 15:56:31 mail pluto[9456]: "thom-moor" #134: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pi in duplicate_state, please report to dev at openswan.org
 UNKNOWN: Jan  1 15:56:31 mail pluto[9456]: "thom-moor" #134: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pr in duplicate_state, please report to dev at openswan.org
 UNKNOWN: Jan  1 23:44:34 mail pluto[9456]: "thom-moor" #145: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_ar in duplicate_state, please report to dev at openswan.org
 UNKNOWN: Jan  1 23:44:34 mail pluto[9456]: "thom-moor" #145: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_er in duplicate_state, please report to dev at openswan.org
 UNKNOWN: Jan  1 23:44:34 mail pluto[9456]: "thom-moor" #145: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pi in duplicate_state, please report to dev at openswan.org
 UNKNOWN: Jan  1 23:44:34 mail pluto[9456]: "thom-moor" #145: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pr in duplicate_state, please report to dev at openswan.org
 Overview summary of log files:
 	 Jan 1 had 544 entries of which 84 were relevant
 Summary by peer:
   Peer thom-moor caused 513 lines of output.
 	connected from: 
 	Keyed: 30 successes 0 failures (max retries: 0)
 	IPsec SAs: 4

---------------------- FreeS/WAN End ------------------------- 

The (censored) configuration file for the link is as follows:



# /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"
        # For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
        protostack=netkey
        nat_traversal=yes

conn thom-moor
        # moor
        left=XXX.XXX.XXX.XXX
        leftid=@somewhere.com
        leftsubnet=192.168.64.0/24
        leftnexthop=
        leftrsasigkey=<secret stuff>
        # thom
        right=YYY.YYY.YYY.YYY
        rightid=@somewhere.else.com
        rightsubnet=192.168.0.0/24
        rightnexthop=
        rightrsasigkey=<secret stuff>
        auto=start






From paul at xelerance.com  Sun Jan  4 01:51:37 2009
From: paul at xelerance.com (Paul Wouters)
Date: Sun, 4 Jan 2009 01:51:37 -0500 (EST)
Subject: [Openswan Users] mtu problems
In-Reply-To: <4960279F.30607@gmail.com>
References: <49579F5A.80004@gmail.com> <495ECC00.9040306@gmail.com>
	<Pine.LNX.4.64.0901030857460.19783@newtla.xelerance.com>
	<4960279F.30607@gmail.com>
Message-ID: <Pine.LNX.4.64.0901040150250.22158@newtla.xelerance.com>

On Sat, 3 Jan 2009, James Muir wrote:

> no.  I am using openswan only on my end; the other end is a sonicwall. 
> I am not able to set the mtu on the sonicwall.
> 
> Just to recap, after I connect to the sonicwall
> 
> this works:  ping -s 1402
> 
> this does not:  ping -s 1403
> 
> The larger packet size causes an "icmp fragmentation needed" response.
> 
> the freeswan faq suggests that I should try using the option 
> overridemtu= to fix this, but this option is for KLIPS only.  Is there 
> something that can be done with NETKEY??
> 
> >> incidentally, the KLIPS module fails to build on my machine (kernel 
> >> 2.6.24, openswan 2.6.19):
> > 
> > try 2.6.20rc1 from testing/
> 
> If there is zero possibility of correcting the mtu size with the NETKEY 
> stack, then I will give KLIPS a try.  However, my feeling is that it 
> should be possible make NETKEY work.

With netkey, you can do something like:

ip route change 1.2.3.0/24 via gwip mtu 1400

in the updown script

Paul

From paul at xelerance.com  Sun Jan  4 09:32:46 2009
From: paul at xelerance.com (Paul Wouters)
Date: Sun, 4 Jan 2009 09:32:46 -0500 (EST)
Subject: [Openswan Users] alloc_bytes1() was mistakenly asked to malloc
 0 bytes for st_skey_ar in duplicate_state
In-Reply-To: <495D36E9.5040706@eatsrootsandleaves.com>
References: <495D36E9.5040706@eatsrootsandleaves.com>
Message-ID: <Pine.LNX.4.64.0901040932070.2105@newtla.xelerance.com>

On Fri, 2 Jan 2009, Alex Ip wrote:

> Subject: [Openswan Users] alloc_bytes1() was mistakenly asked to malloc 0
>     bytes for st_skey_ar in duplicate_state
> 
> 	I don't know whether this is due to a misconfiguration on my part, but I keep getting this message in my logs for an otherwise perfectly functional link. It doesn't seem to be causing any problems, but I thought it might be important to report it to the developers. Any ideas?

It's harmless. If you upgrade it will go away.

Paul


From muir.james.a at gmail.com  Sun Jan  4 14:46:01 2009
From: muir.james.a at gmail.com (James Muir)
Date: Sun, 04 Jan 2009 14:46:01 -0500
Subject: [Openswan Users] mtu problems
In-Reply-To: <Pine.LNX.4.64.0901040150250.22158@newtla.xelerance.com>
References: <49579F5A.80004@gmail.com> <495ECC00.9040306@gmail.com>
	<Pine.LNX.4.64.0901030857460.19783@newtla.xelerance.com>
	<4960279F.30607@gmail.com>
	<Pine.LNX.4.64.0901040150250.22158@newtla.xelerance.com>
Message-ID: <496111F9.6090906@gmail.com>

Paul Wouters wrote:
> With netkey, you can do something like:
> 
> ip route change 1.2.3.0/24 via gwip mtu 1400
> 
> in the updown script

I think you are suggesting that I change the mtu value on my network
interface.  I've already given that a try:

ifconfig eth0 mtu 1400

However, this doesn't seem to solve my problem.  There is still a 
threshold packet-size beyond which my ip packets do not make it into the 
private network (e.g. "ping -s 1410" works but "ping -s 1411" does not).

 From what I see in wireshark, it looks like an icmp fragmentation 
issue.  I cannot send fragmented packets through the tunnel.

Is there a particular reason (related to the ipsec protocol) why the 
sonicwall appliance might disallow fragmented packets?  Perhaps openswan 
is not fragmenting the way that the sonicwall expects.

-James


From david at craigon.co.uk  Sun Jan  4 17:34:56 2009
From: david at craigon.co.uk (David J Craigon)
Date: Sun, 4 Jan 2009 22:34:56 +0000
Subject: [Openswan Users] Can't get NAT traversal to work
In-Reply-To: <Pine.LNX.4.64.0901011955230.6849@newtla.xelerance.com>
References: <c1ace6860901010320y44268a18sacf85f2ebab7157e@mail.gmail.com>
	<Pine.LNX.4.64.0901011955230.6849@newtla.xelerance.com>
Message-ID: <c1ace6860901041434o1bbb042bgfa0b87272ea3a7c7@mail.gmail.com>

Hi,

Thanks for the reply, but it still doesn't work for me. I'm not totally sure
what the difference is between the config you've given me, and the one I'm
using- as far as I can tell I _am_ using PSK- I got the codes from ipsec
showhost key.

Thanks,

David

2009/1/2 Paul Wouters <paul at xelerance.com>

> On Thu, 1 Jan 2009, David J Craigon wrote:
>
> > Anyway, I cannot get NAT traversal to work. My setup is as follows- I
> want
> > to get a VPN running between two hosts both running Openswan. One is on
> the
> > internet and has a public IP address, and is running Fedora 9. The other
> is
> > my laptop sat at home behind a NAT running Fedora 10.
>
> I have a similar setup on my laptop, where I tunnel my own /29 onto my
> laptop.
>
> > conn host-to-host
> >     left=192.168.2.34
> >     leftid=81.76.68.138
> >     leftnexthop=192.168.2.1
> >     leftsubnet=192.168.2.0/24
> >  leftrsasigkey=blah blah blah
> >     right=94.102.146.99               # Remote vitals
> >     rightid=94.102.146.99
> >     rightsubnet=94.102.146.96/29
> >     rightrsasigkey=blah blah blah
> >     rightnexthop=94.102.146.97     # correct in many situations
> >     auto=add                       # authorizes but doesn't start this
> >                                    # connection at startup
>
> With both ends being openswan, ditch PSK and use raw RSA. eg:
>
>        authby=rsasig
>        leftrsasigkey=XXXX
>        rightrsasigkey=YYY
>        leftid=@laptop
>        rightid=@server
>        left=%defaultroute
>
> get the rsasigkey lines using: ipsec showhostkey --left (--right) on the
> two machines. This will avoid PSK authentication by IP while having other
> IP's due to NAT.
>
> >
> > When I do on the box behind the NAT I get:
> >
> > [root at localhost log]# ipsec auto --up host-to-host
> > 104 "host-to-host" #1: STATE_MAIN_I1: initiate
> > 010 "host-to-host" #1: STATE_MAIN_I1: retransmission; will wait 20s for
> > response
> >
> >
> > and I see in /etc/secure on the remote box:
> > Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500:
> ignoring
> > unknown Vendor ID payload [4f457d5a765a404d5b4f5744]
> > Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500:
> received
> > Vendor ID payload [Dead Peer Detection]
> > Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500:
> received
> > Vendor ID payload [RFC 3947] method set to=109
> > Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500:
> received
> > Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already
> > using method 109
> > Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500:
> received
> > Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already
> > using method 109
> > Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500:
> received
> > Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already
> > using method 109
> > Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500:
> initial
> > Main Mode message received on 94.102.146.99:500 but no connection has
> been
> > authorized with policy=RSASIG
>
> You are missing authby=secret to use PSK's on the laptop.
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090104/a062a6f1/attachment.html 

From richard at mdr.co.uk  Mon Jan  5 06:03:45 2009
From: richard at mdr.co.uk (Richard de Rivaz)
Date: Mon, 5 Jan 2009 11:03:45 +0000
Subject: [Openswan Users] Openswan on Ubuntu 8.10
In-Reply-To: <1230572347383031500@mdr.co.uk>
References: <1230572347383031500@mdr.co.uk>
Message-ID: <1231153425871598500@mdr.co.uk>

An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.openswan.org/pipermail/users/attachments/20090105/b169d753/attachment-0001.pl 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090105/b169d753/attachment-0001.html 

From openswan at thefeds.net  Mon Jan  5 08:45:36 2009
From: openswan at thefeds.net (openswan at thefeds.net)
Date: Mon, 5 Jan 2009 13:45:36 +0000 (GMT)
Subject: [Openswan Users] Openswan on Ubuntu 8.10
In-Reply-To: <1231153425871598500@mdr.co.uk>
References: <1230572347383031500@mdr.co.uk> <1231153425871598500@mdr.co.uk>
Message-ID: <Pine.LNX.4.64.0901051344320.15158@fedex.thefeds.net>

I had to add protostack=netkey to ipsec.conf to get openswan to start on 
CentOS 5.0. Without that it would start on the second attempt, but not the 
first.

Tim

On Mon, 5 Jan 2009, Richard de Rivaz wrote:

> Hi
>
> I wonder if anyone has example config files that work with Netkey?
>
> Regards Richard
>
>
> Richard de Rivaz  wrote:
>>                 Hi
>>
>> I am trying to use Openswan on Ubuntu to create an ipsec vpn but so far do not seem able to get Openswan to startup correctly. 'ipsec verify' produces the following:
>>
>> Checking your system to see if IPsec got installed and started correctly:
>> Version check and ipsec on-path                                 [OK]
>> Linux Openswan U2.4.12/K2.6.27-9-generic (netkey)
>> Checking for IPsec support in kernel                            [OK]
>> NETKEY detected, testing for disabled ICMP send_redirects       [FAILED]
>>
>>   Please disable /proc/sys/net/ipv4/conf/*/send_redirects
>>   or NETKEY will cause the sending of bogus ICMP redirects!
>>
>> NETKEY detected, testing for disabled ICMP accept_redirects     [FAILED]
>>
>>   Please disable /proc/sys/net/ipv4/conf/*/accept_redirects
>>   or NETKEY will accept bogus ICMP redirects!
>>
>> Checking for RSA private key (/etc/ipsec.secrets)               [DISABLED]
>>   ipsec showhostkey: no default key in "/etc/ipsec.secrets"
>> Checking that pluto is running                                  [FAILED]
>>   whack: Pluto is not running (no "/var/run/pluto/pluto.ctl")
>> Two or more interfaces found, checking IP forwarding            [FAILED]
>>   whack: Pluto is not running (no "/var/run/pluto/pluto.ctl")
>> Checking NAT and MASQUERADEing                                  [N/A]
>>   whack: Pluto is not running (no "/var/run/pluto/pluto.ctl")
>> Checking for 'ip' command                                       [OK]
>> Checking for 'iptables' command                                 [OK]
>> Opportunistic Encryption Support                                [DISABLED]
>>
>>
>> sysctl.conf is as follows:
>>
>> #
>> # /etc/sysctl.conf - Configuration file for setting system variables
>> # See /etc/sysctl.d/ for additional system variables.
>> # See sysctl.conf (5) for information.
>> #
>>
>> #kernel.domainname = example.com
>>
>> # Uncomment the following to stop low-level messages on console
>> #kernel.printk = 4 4 1 7
>>
>> ##############################################################3
>> # Functions previously found in netbase
>> #
>>
>> # Uncomment the next two lines to enable Spoof protection (reverse-path filter)
>> # Turn on Source Address Verification in all interfaces to
>> # prevent some spoofing attacks
>> net.ipv4.conf.default.rp_filter = 0
>> net.ipv4.conf.all.rp_filter = 1
>>
>> # Uncomment the next line to enable TCP/IP SYN cookies
>> # This disables TCP Window Scaling (http://lkml.org/lkml/2008/2/5/167),
>> # and is not recommended.
>> net.ipv4.tcp_syncookies = 1
>>
>> # Uncomment the next line to enable packet forwarding for IPv4
>> net.ipv4.ip_forward = 1
>>
>> # Uncomment the next line to enable packet forwarding for IPv6
>> net.ipv6.conf.all.forwarding=1
>>
>>
>> ###################################################################
>> # Additional settings - these settings can improve the network
>> # security of the host and prevent against some network attacks
>> # including spoofing attacks and man in the middle attacks through
>> # redirection. Some network environments, however, require that these
>> # settings are disabled so review and enable them as needed.
>> #
>> # Ignore ICMP broadcasts
>> net.ipv4.icmp_echo_ignore_broadcasts = 1
>> #
>> # Ignore bogus ICMP errors
>> net.ipv4.icmp_ignore_bogus_error_responses = 1
>> #
>> # Do not accept ICMP redirects (prevent MITM attacks)
>> net.ipv4.conf.all.accept_redirects = 0
>> net.ipv6.conf.all.accept_redirects = 0
>> # _or_
>> # Accept ICMP redirects only for gateways listed in our default
>> # gateway list (enabled by default)
>> net.ipv4.conf.all.secure_redirects = 0
>> #
>> # Do not send ICMP redirects (we are not a router)
>> net.ipv4.conf.all.send_redirects = 0
>> #
>> # Do not accept IP source route packets (we are not a router)
>> net.ipv4.conf.all.accept_source_route = 0
>> net.ipv6.conf.all.accept_source_route = 0
>> #
>> # Log Martian Packets
>> net.ipv4.conf.all.log_martians = 1
>> #
>> # The contents of /proc/<pid>/maps and smaps files are only visible to
>> # readers that are allowed to ptrace() the process
>> sys.kernel.maps_protect = 1
>>
>> I would be grateful for any help in getting Openswan to work on Ubuntu 8.10
>>
>> Regards Richard
>> --
>>
>> Richard de Rivaz
>> MDR Interfaces Ltd
>> Computer Control Specialists
>>
>> Tel: +44(0)1825 790294  Fax: +44(0)1825 790119
>> Reg in England No. 1577056 Directors: R de Rivaz   Z de Rivaz
>> Reg Address: Little Bridge House, Danehill, Sussex RH17 7JD
>>
>> http://www.mdr.co.uk
>
-------------- next part --------------
_______________________________________________
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=283155

From paul at xelerance.com  Mon Jan  5 07:42:50 2009
From: paul at xelerance.com (Paul Wouters)
Date: Mon, 5 Jan 2009 07:42:50 -0500 (EST)
Subject: [Openswan Users] Openswan on Ubuntu 8.10
In-Reply-To: <Pine.LNX.4.64.0901051344320.15158@fedex.thefeds.net>
References: <1230572347383031500@mdr.co.uk> <1231153425871598500@mdr.co.uk>
	<Pine.LNX.4.64.0901051344320.15158@fedex.thefeds.net>
Message-ID: <Pine.LNX.4.64.0901050741300.23946@newtla.xelerance.com>

On Mon, 5 Jan 2009, openswan at thefeds.net wrote:

> I had to add protostack=netkey to ipsec.conf to get openswan to start on
> CentOS 5.0. Without that it would start on the second attempt, but not the
> first.

Then someone should file a bug report against RHEL for that. I know the
fedora package ships with protostack=netkey.

Or this is because ipsec.conf already existed from an openswan 2.4.x config
when the rpm was upgraded to openswan 2.6.x.

Paul

From openswan at thefeds.net  Mon Jan  5 11:00:10 2009
From: openswan at thefeds.net (openswan at thefeds.net)
Date: Mon, 5 Jan 2009 16:00:10 +0000 (GMT)
Subject: [Openswan Users] Openswan on Ubuntu 8.10
In-Reply-To: <Pine.LNX.4.64.0901050741300.23946@newtla.xelerance.com>
References: <1230572347383031500@mdr.co.uk> <1231153425871598500@mdr.co.uk>
	<Pine.LNX.4.64.0901051344320.15158@fedex.thefeds.net>
	<Pine.LNX.4.64.0901050741300.23946@newtla.xelerance.com>
Message-ID: <Pine.LNX.4.64.0901051535120.15158@fedex.thefeds.net>

The ipsec.conf I used was pre existing. I didn't look at any 
/etc/ipsec.conf that might have been installed by the openswan rpm I built 
from sources, it was overwritten with my file by my configuration rpm 
(which trigered the install of openswan through a requires clause).

I did look at an example file 
(/usr/share/doc/openswan-2.6.19/linux-linux.conf) which doesn't have 
protostack=netkey in when installed via rpm onto CentOS. It might be nice 
if it did, depending on what OS the rpm was built for/installed on but it 
isn't likely to be an issue for most people.

Next time I build a CentOS 5 box (in the next few days) I will install the 
openswan rpm on it's own and check the /etc/ipsec.conf and report back.

Tim

On Mon, 5 Jan 2009, Paul Wouters wrote:

> On Mon, 5 Jan 2009, openswan at thefeds.net wrote:
>
>> I had to add protostack=netkey to ipsec.conf to get openswan to start on
>> CentOS 5.0. Without that it would start on the second attempt, but not the
>> first.
>
> Then someone should file a bug report against RHEL for that. I know the
> fedora package ships with protostack=netkey.
>
> Or this is because ipsec.conf already existed from an openswan 2.4.x config
> when the rpm was upgraded to openswan 2.6.x.
>
> Paul
>

From openswan at thefeds.net  Mon Jan  5 11:02:26 2009
From: openswan at thefeds.net (openswan at thefeds.net)
Date: Mon, 5 Jan 2009 16:02:26 +0000 (GMT)
Subject: [Openswan Users] IPSEC SA only being installed on one side
In-Reply-To: <Pine.LNX.4.64.0901011950550.6849@newtla.xelerance.com>
References: <Pine.LNX.4.64.0812301739240.4268@fedex.thefeds.net>
	<Pine.LNX.4.64.0901011950550.6849@newtla.xelerance.com>
Message-ID: <Pine.LNX.4.64.0901051600560.15158@fedex.thefeds.net>

2.6.20rc1 has been running for three days and is much better.

I would say it is perfect for phase 2 rekeying but there are two incidents 
I am still investigating.

My monitoring is still picking up quite a few incidents where I have no
phase 1 SA but this could be because I only have a 60 second rekeying 
margin (to mitigate the effects of the rekeying problems). I will push out 
new configs with a higher rekeying margin and see what happens.

Thanks
Tim

On Thu, 1 Jan 2009, Paul Wouters wrote:

> On Tue, 30 Dec 2008, openswan at thefeds.net wrote:
>
> There have been some fixes to rekeying lately. Please try the latest
> test release (2.6.20rc1). Though this bug might still exist.
>
> Paul
>
>> Date: Tue, 30 Dec 2008 18:35:42 +0000 (GMT)
>> From:  <openswan at thefeds.net>
>> To:  <users at openswan.org>
>> Subject: [Openswan Users] IPSEC SA only being installed on one side
>>
>> I am trying to track down a problem I am having quite frequently where my
>> phase 1 SA is fine (and thus DPD doesn't see any problems) but my phase 2
>> SAs aren't in step and thus traffic can't get through.
>>
>> The problem appears to be that sometimes when a new phase 2 SA is
>> negotiated one side is happy and installs the SA, but the other side
>> (never the initiator) doesn't install the SA. The side with the newer SA
>> then sends packets encrypted with the new SPI which the other side cannot
>> understand.
>>
>> I have the following extracts from /var/log/secure:
>>
>> The initiator:
>> Dec 30 12:40:04 vpn01d pluto[4943]: "tun02a01d" #442: STATE_MAIN_I4:
>> ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256
>> prf=oakley_sha group=modp1536}
>> Dec 30 12:40:04 vpn01d pluto[4943]: "tun02a01d" #442: Dead Peer Detection
>> (RFC 3706): enabled
>> Dec 30 14:32:40 vpn01d pluto[4943]: "tun02a01d" #455: initiating Quick
>> Mode PSK+ENCRYPT+PFS+UP+IKEv2ALLOW to replace #428 {using isakmp#442
>> msgid:1ff67d30 proposal=AES(12)_256-SHA1(2)_160
>> pfsgroup=OAKLEY_GROUP_MODP1536}
>> Dec 30 14:32:40 vpn01d pluto[4943]: "tun02a01d" #455: Dead Peer Detection
>> (RFC 3706): enabled
>> Dec 30 14:32:40 vpn01d pluto[4943]: "tun02a01d" #455: transition from
>> state STATE_QUICK_I1 to state STATE_QUICK_I2
>> Dec 30 14:32:40 vpn01d pluto[4943]: "tun02a01d" #455: STATE_QUICK_I2: sent
>> QI2, IPsec SA established transport mode {ESP=>0x0f2d2e3a <0x36134870
>> xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=none DPD=enabled}
>> Dec 30 14:32:50 vpn01d pluto[4943]: "tun02a01d" #455: message ignored
>> because it contains an unexpected payload type (ISAKMP_NEXT_HASH)
>> Dec 30 14:32:50 vpn01d pluto[4943]: "tun02a01d" #455: sending encrypted
>> notification INVALID_PAYLOAD_TYPE to <vpn02a ip>:500
>>
>> The reciever:
>> Dec 30 12:40:04 vpn02a pluto[547]: "tun02a01d" #480: STATE_MAIN_R3: sent
>> MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256
>> prf=oakley_sha group=modp1536}
>> Dec 30 12:40:04 vpn02a pluto[547]: "tun02a01d" #480: Dead Peer Detection
>> (RFC 3706): enabled
>> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #480: the peer proposed:
>> <vpn02a ip>/32:0/0 -> <vpn02d ip>/32:0/0
>> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515: responding to Quick
>> Mode proposal {msgid:1ff67d30}
>> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515:     us:
>> <vpn02a ip><<vpn02a ip>>[+S=C]---<vpn02a nh>
>> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515:   them:
>> <vpn01d nh>---<vpn01d ip><<vpn01d ip>>[+S=C]
>> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515: keeping
>> refhim=4294901761 during rekey
>> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515: transition from state
>> STATE_QUICK_R0 to state STATE_QUICK_R1
>> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515: STATE_QUICK_R1: sent
>> QR1, inbound IPsec SA installed, expecting QI2
>> Dec 30 14:32:40 vpn02a pluto[547]: packet from <vpn01d ip>:500:
>> Informational Exchange is for an unknown (expired?) SA
>> Dec 30 14:32:50 vpn02a pluto[547]: "tun02a01d" #480: ignoring
>> informational payload, type INVALID_PAYLOAD_TYPE msgid=00000000
>> Dec 30 14:32:50 vpn02a pluto[547]: "tun02a01d" #480: received and ignored
>> informational message
>>
>> I then end up with the following SAs on vpn02a:
>> 000 #523: "tun02a01d":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established);
>> EVENT_SA_REPLACE in 9590s; newest ISAKMP; lastdpd=2s(seq in:24780 out:0);
>> idle; import:not set
>> 000 #480: "tun02a01d":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established);
>> EVENT_SA_REPLACE in 2449s; lastdpd=1210s(seq in:7855 out:0); idle;
>> import:not set
>> 000 #470: "tun02a01d":500 STATE_QUICK_R2 (IPsec SA established);
>> EVENT_SA_REPLACE in 2026s; newest IPSEC; eroute owner; isakmp#454; idle;
>> import:not set
>> 000 #470: "tun02a01d" esp.f2d777e3@<vpn01d ip> esp.8ca1e089@<vpn02a ip>
>> ref=0 refhim=4294901761
>>
>> and vpn01d:
>> 000 #466: "tun02a01d":500 STATE_MAIN_I4 (ISAKMP SA established);
>> EVENT_SA_REPLACE in 5934s; newest ISAKMP; lastdpd=1s(seq in:3752 out:0);
>> idle; import:admin initiate
>> 000 #455: "tun02a01d":500 STATE_QUICK_I2 (sent QI2, IPsec SA established);
>> EVENT_SA_REPLACE in 5593s; newest IPSEC; eroute owner; isakmp#442; idle;
>> import:admin initiate
>> 000 #455: "tun02a01d" esp.f2d2e3a@<vpn02a ip> esp.36134870@<vpn01d ip>
>> ref=0 refhim=4294901761
>> 000 #442: "tun02a01d":500 STATE_MAIN_I4 (ISAKMP SA established);
>> EVENT_SA_EXPIRE in 6050s; lastdpd=1209s(seq in:17036 out:0); idle;
>> import:admin initiate
>> 000 #428: "tun02a01d":500 STATE_QUICK_I2 (sent QI2, IPsec SA established);
>> EVENT_SA_EXPIRE in 5627s; isakmp#411; idle; import:admin initiate
>> 000 #428: "tun02a01d" esp.8ca1e089@<vpn02a ip> esp.f2d777e3@<vpn01d ip>
>> ref=0 refhim=4294901761
>>
>> So you can see that vpn02a does have esp.36134870@<vpn01d ip>
>> esp.f2d2e3a@<vpn02a ip> installed and as that is newest on vpn01d that is
>> what it is using for all traffic to vpn02a.
>>
>> I am guessing that the log entry of:
>> Dec 30 14:32:40 vpn02a pluto[547]: packet from <vpn01d ip>:500:
>> Informational Exchange is for an unknown (expired?) SA
>> May be the QI2 packet from vpn01d that vpn01d doesn't understand? I
>> thought at one time that the phase 1 SA may be expiring at this point, but
>> I am seeing this happen far too often for that. Plus as the logs show the
>> phase 1 SA was renegotiated 112 minutes and 48 seconds earlier and I have
>> a key life of 240 minutes with a rekeying margin of 120 minutes and a
>> rekeying fuzz of 1% so the next phase 1 rekeying isn't due for another 6
>> minutes to 7 minutes 12 seconds. I do see the phase 1 rekey happen in the
>> logs 6 minutes and 25 seconds later.
>>
>> Does anyone have any idea how I can go about finding out why the recieving
>> end sometimes doesn't install the new phase 2 SA?
>>
>> Thanks in advance for any help
>> Tim
>> _______________________________________________
>> 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=283155
>>
>

From broda at billiger-mietwagen.de  Mon Jan  5 09:26:36 2009
From: broda at billiger-mietwagen.de (Thomas Broda)
Date: Mon, 05 Jan 2009 15:26:36 +0100
Subject: [Openswan Users] Problem distinguishing roadwarrriors
In-Reply-To: <Pine.LNX.4.64.0901032009280.21386@newtla.xelerance.com>
References: <495FA4C6.8080603@billiger-mietwagen.de>
	<Pine.LNX.4.64.0901032009280.21386@newtla.xelerance.com>
Message-ID: <4962189C.4050502@billiger-mietwagen.de>

Paul Wouters schrieb:

> But some logs would help to determine if this is the case.

I've attached an excerpt from the logs.

 > Since l2tp is in transport mode, and the linux clients are not, try
> adding an explicite type=transport to the roadwarriors-l2tp conn to
> see if that makes any difference.

hmm...adding "type=transport" didn't help.

I got the following, when I try to connect from a Windows L2TP
client..."samba3" refers to the following connection:

conn samba3
    authby=rsasig
    left=%defaultroute
    leftrsasigkey=%cert
    leftid= [...]
    leftcert=leftcert.pem
    leftsubnet=192.168.3.0/24
    right=%any
    rightrsasigkey=%cert
    rightid= [...]
    rightsubnetwithin=192.168.0.19/24
    auto=add

Actually, this connection should be picked:

conn roadwarrior-l2tp
    type=transport
    authby=secret
    type=transport
    rekey=no
    pfs=no
    keyingtries=1
    left=%defaultroute
    leftprotoport=17/1701
    right=%any
    rightprotoport=17/1701
    auto=add


Log:

Jan  5 15:20:46 deimos pluto[9365]: "samba3"[4] 82.141.54.110 #9:
responding to Main Mode from unknown peer 82.141.54.110
Jan  5 15:20:46 deimos pluto[9365]: "samba3"[4] 82.141.54.110 #9: policy
does not allow OAKLEY_PRESHARED_KEY authentication.  Attribute
OAKLEY_AUTHENTICATION_METHOD
Jan  5 15:20:46 deimos pluto[9365]: "samba3"[4] 82.141.54.110 #9: policy
does not allow OAKLEY_PRESHARED_KEY authentication.  Attribute
OAKLEY_AUTHENTICATION_METHOD
Jan  5 15:20:46 deimos pluto[9365]: "samba3"[4] 82.141.54.110 #9: policy
does not allow OAKLEY_PRESHARED_KEY authentication.  Attribute
OAKLEY_AUTHENTICATION_METHOD
Jan  5 15:20:46 deimos pluto[9365]: "samba3"[4] 82.141.54.110 #9:
OAKLEY_DES_CBC is not supported.  Attribute OAKLEY_ENCRYPTION_ALGORITHM
Jan  5 15:20:46 deimos pluto[9365]: "samba3"[4] 82.141.54.110 #9:
OAKLEY_DES_CBC is not supported.  Attribute OAKLEY_ENCRYPTION_ALGORITHM
Jan  5 15:20:46 deimos pluto[9365]: "samba3"[4] 82.141.54.110 #9: no
acceptable Oakley Transform
Jan  5 15:20:46 deimos pluto[9365]: "samba3"[4] 82.141.54.110 #9:
sending notification NO_PROPOSAL_CHOSEN to 82.141.54.110:17
Jan  5 15:20:46 deimos pluto[9365]: "samba3"[4] 82.141.54.110: deleting
connection "samba3" instance with peer 82.141.54.110 {isakmp=#0/ipsec=#0}


Cheers,

-- 
Thomas

From paul at xelerance.com  Mon Jan  5 10:00:43 2009
From: paul at xelerance.com (Paul Wouters)
Date: Mon, 5 Jan 2009 10:00:43 -0500 (EST)
Subject: [Openswan Users] Problem distinguishing roadwarrriors
In-Reply-To: <4962189C.4050502@billiger-mietwagen.de>
References: <495FA4C6.8080603@billiger-mietwagen.de>
	<Pine.LNX.4.64.0901032009280.21386@newtla.xelerance.com>
	<4962189C.4050502@billiger-mietwagen.de>
Message-ID: <Pine.LNX.4.64.0901050957370.26399@newtla.xelerance.com>

On Mon, 5 Jan 2009, Thomas Broda wrote:

> 
> I've attached an excerpt from the logs.
> 
>  > Since l2tp is in transport mode, and the linux clients are not, try
> > adding an explicite type=transport to the roadwarriors-l2tp conn to
> > see if that makes any difference.
> 
> hmm...adding "type=transport" didn't help.
> 
> I got the following, when I try to connect from a Windows L2TP
> client..."samba3" refers to the following connection:
> 
> conn samba3
>     authby=rsasig
>     left=%defaultroute
>     leftrsasigkey=%cert
>     leftid= [...]
>     leftcert=leftcert.pem
>     leftsubnet=192.168.3.0/24
>     right=%any
>     rightrsasigkey=%cert
>     rightid= [...]
>     rightsubnetwithin=192.168.0.19/24
>     auto=add

You cannot by dynamic on both ends of the connection because then
openswan does not know which side it is. You must use a left=1.2.3.4,
where the ip is a local ip configured on the box (not some public ip
it becomes after nat)

also do not use subnetwithin. Instead ouse virtual_private= along with
rightsubnet=vhost:%priv,%no

> Actually, this connection should be picked:
> 
> conn roadwarrior-l2tp
>     type=transport
>     authby=secret
>     type=transport
>     rekey=no
>     pfs=no
>     keyingtries=1
>     left=%defaultroute
>     leftprotoport=17/1701
>     right=%any
>     rightprotoport=17/1701
>     auto=add

This connection has the same problem as above.

both connections will have failed to load, which you can verify
with: ipsec auto --add roadwarrior-l2tp or ipsec auto --status.

Paul

From jon at heartslc.com  Mon Jan  5 14:56:45 2009
From: jon at heartslc.com (Jonathan Larsen)
Date: Mon, 5 Jan 2009 12:56:45 -0700
Subject: [Openswan Users] Connection disconnects frequently and will not
	connect with NAT-T enabled
Message-ID: <E80B65F27529BB409F833498BB79F84E491205@r2d2.heartslc.com>

I am using Openswan Version 2.4.13 w/KLIPS.

Using kernel 2.6.19

 

I do not control the other end of the VPN.  All I know is that it's a
cisco vpn 3000, or at least that is what openswan reports back.

We've been having trouble with the connection saying connected.  Maybe
about after 15 min, it disconnects.  This is when NAT-T is off, it's the
only way I actually have been able to get it connected.

Here is the output when we connect.

root at windu:~# /usr/local/sbin/ipsec auto --up stmarks_meditech

112 "stmarks_meditech" #1: STATE_AGGR_I1: initiate

003 "stmarks_meditech" #1: received Vendor ID payload [Cisco-Unity]

003 "stmarks_meditech" #1: received Vendor ID payload [XAUTH]

003 "stmarks_meditech" #1: received Vendor ID payload [Dead Peer
Detection]

003 "stmarks_meditech" #1: ignoring Vendor ID payload [FRAGMENTATION
c0000000]

003 "stmarks_meditech" #1: ignoring Vendor ID payload [Cisco VPN 3000
Series]

003 "stmarks_meditech" #1: protocol/port in Phase 1 ID Payload must be
0/0 or 17/500 but are 17/0

003 "stmarks_meditech" #1: protocol/port in Phase 1 ID Payload must be
0/0 or 17/500 but are 17/0

004 "stmarks_meditech" #1: STATE_AGGR_I2: sent AI2, ISAKMP SA
established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192
prf=oakley_sha group=modp1024}

117 "stmarks_meditech" #2: STATE_QUICK_I1: initiate

004 "stmarks_meditech" #2: STATE_QUICK_I2: sent QI2, IPsec SA
established {ESP=>0x824bfd5f <0xa1558950 xfrm=3DES_0-HMAC_SHA1 NATD=none
DPD=none}

root at windu:~# /usr/local/sbin/ipsec auto --up stmarks_pacs

117 "stmarks_pacs" #3: STATE_QUICK_I1: initiate

004 "stmarks_pacs" #3: STATE_QUICK_I2: sent QI2, IPsec SA established
{ESP=>0xdf4e67d5 <0xa1558951 xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}

root at windu:~# /usr/local/sbin/ipsec auto --up stmarks_tracemaster

117 "stmarks_tracemaster" #4: STATE_QUICK_I1: initiate

004 "stmarks_tracemaster" #4: STATE_QUICK_I2: sent QI2, IPsec SA
established {ESP=>0x2811a7fb <0xa1558952 xfrm=3DES_0-HMAC_SHA1 NATD=none
DPD=none}

root at windu:~# /usr/local/sbin/ipsec auto --up stmarks_pacs2

117 "stmarks_pacs2" #5: STATE_QUICK_I1: initiate

004 "stmarks_pacs2" #5: STATE_QUICK_I2: sent QI2, IPsec SA established
{ESP=>0x8cbcff6f <0xa1558953 xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}

 

Here are the errors from the secure log just before we notice that it's
stopped working.

 

Jan  5 12:25:14 windu pluto[4637]: packet from 199.91.34.69:500:
received Vendor ID payload [Cisco-Unity]

Jan  5 12:25:14 windu pluto[4637]: packet from 199.91.34.69:500:
received Vendor ID payload [XAUTH]

Jan  5 12:25:14 windu pluto[4637]: packet from 199.91.34.69:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106,
but port floating is off

Jan  5 12:25:14 windu pluto[4637]: packet from 199.91.34.69:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but
port floating is off

Jan  5 12:25:14 windu pluto[4637]: packet from 199.91.34.69:500:
ignoring Vendor ID payload [FRAGMENTATION c0000000]

Jan  5 12:25:14 windu pluto[4637]: "stmarks_pacs2" #10: protocol/port in
Phase 1 ID Payload must be 0/0 or 17/500 but are 17/0

Jan  5 12:25:14 windu pluto[4637]: "stmarks_pacs2" #10: Aggressive mode
peer ID is ID_IPV4_ADDR: '199.91.34.69'

Jan  5 12:25:14 windu pluto[4637]: "stmarks_pacs2" #10: responding to
Aggressive Mode, state #10, connection "stmarks_pacs2" from 199.91.34.69

Jan  5 12:25:14 windu pluto[4637]: "stmarks_pacs2" #10: transition from
state STATE_AGGR_R0 to state STATE_AGGR_R1

Jan  5 12:25:14 windu pluto[4637]: "stmarks_pacs2" #10: STATE_AGGR_R1:
sent AR1, expecting AI2

Jan  5 12:25:14 windu pluto[4637]: "stmarks_pacs2" #10: received Vendor
ID payload [Dead Peer Detection]

Jan  5 12:25:14 windu pluto[4637]: "stmarks_pacs2" #10: ignoring Vendor
ID payload [Cisco VPN 3000 Series]

Jan  5 12:25:14 windu pluto[4637]: "stmarks_pacs2" #10: Aggressive mode
peer ID is ID_IPV4_ADDR: '199.91.34.69'

Jan  5 12:25:14 windu pluto[4637]: "stmarks_pacs2" #10: received Hash
Payload does not match computed value

Jan  5 12:25:14 windu pluto[4637]: "stmarks_pacs2" #10: sending
encrypted notification INVALID_HASH_INFORMATION to 199.91.34.69:500

Jan  5 12:25:52 windu pluto[4637]: "stmarks_meditech" #8: received
Delete SA payload: deleting ISAKMP State #8

Jan  5 12:25:52 windu pluto[4637]: packet from 199.91.34.69:500:
received and ignored informational message

Jan  5 12:26:03 windu pluto[4637]: "stmarks_pacs2" #10: next payload
type of ISAKMP Hash Payload has an unknown value: 180

Jan  5 12:26:03 windu pluto[4637]: "stmarks_pacs2" #10: malformed
payload in packet

Jan  5 12:26:03 windu pluto[4637]: | payload malformed after IV

Jan  5 12:26:03 windu pluto[4637]: |   41 77 8e 33  c5 40 5a a5  94 33
84 f2  7f fe f8 eb

Jan  5 12:26:03 windu pluto[4637]: |   ce e3 99 33

Jan  5 12:26:03 windu pluto[4637]: "stmarks_pacs2" #10: sending
notification PAYLOAD_MALFORMED to 199.91.34.69:500

Jan  5 12:26:05 windu pluto[4637]: "stmarks_pacs2" #10: next payload
type of ISAKMP Hash Payload has an unknown value: 250

Jan  5 12:26:05 windu pluto[4637]: "stmarks_pacs2" #10: malformed
payload in packet

Jan  5 12:26:05 windu pluto[4637]: | payload malformed after IV

Jan  5 12:26:05 windu pluto[4637]: |   41 77 8e 33  c5 40 5a a5  94 33
84 f2  7f fe f8 eb

Jan  5 12:26:05 windu pluto[4637]: |   ce e3 99 33

Jan  5 12:26:05 windu pluto[4637]: "stmarks_pacs2" #10: sending
notification PAYLOAD_MALFORMED to 199.91.34.69:500

Jan  5 12:26:07 windu pluto[4637]: "stmarks_pacs2" #10: next payload
type of ISAKMP Hash Payload has an unknown value: 209

Jan  5 12:26:07 windu pluto[4637]: "stmarks_pacs2" #10: malformed
payload in packet

Jan  5 12:26:07 windu pluto[4637]: | payload malformed after IV

Jan  5 12:26:07 windu pluto[4637]: |   41 77 8e 33  c5 40 5a a5  94 33
84 f2  7f fe f8 eb

Jan  5 12:26:07 windu pluto[4637]: |   ce e3 99 33

Jan  5 12:26:07 windu pluto[4637]: "stmarks_pacs2" #10: sending
notification PAYLOAD_MALFORMED to 199.91.34.69:500

Jan  5 12:26:09 windu pluto[4637]: "stmarks_pacs2" #10: next payload
type of ISAKMP Hash Payload has an unknown value: 163

Jan  5 12:26:09 windu pluto[4637]: "stmarks_pacs2" #10: malformed
payload in packet

Jan  5 12:26:09 windu pluto[4637]: | payload malformed after IV

Jan  5 12:26:09 windu pluto[4637]: |   41 77 8e 33  c5 40 5a a5  94 33
84 f2  7f fe f8 eb

Jan  5 12:26:09 windu pluto[4637]: |   ce e3 99 33

Jan  5 12:26:09 windu pluto[4637]: "stmarks_pacs2" #10: sending
notification PAYLOAD_MALFORMED to 199.91.34.69:500

Jan  5 12:26:09 windu pluto[4637]: "stmarks_pacs2" #10: next payload
type of ISAKMP Hash Payload has an unknown value: 120

Jan  5 12:26:09 windu pluto[4637]: "stmarks_pacs2" #10: malformed
payload in packet

Jan  5 12:26:09 windu pluto[4637]: "stmarks_pacs2" #10: next payload
type of ISAKMP Hash Payload has an unknown value: 25

Jan  5 12:26:09 windu pluto[4637]: "stmarks_pacs2" #10: malformed
payload in packet

Jan  5 12:26:09 windu pluto[4637]: "stmarks_pacs2" #10: next payload
type of ISAKMP Hash Payload has an unknown value: 229

Jan  5 12:26:09 windu pluto[4637]: "stmarks_pacs2" #10: malformed
payload in packet

Jan  5 12:26:09 windu pluto[4637]: "stmarks_pacs2" #10: next payload
type of ISAKMP Hash Payload has an unknown value: 226

Jan  5 12:26:09 windu pluto[4637]: "stmarks_pacs2" #10: malformed
payload in packet

Jan  5 12:26:24 windu pluto[4637]: "stmarks_pacs2" #10: max number of
retransmissions (2) reached STATE_AGGR_R1

 

I am behind a firewall (where everyone is natted behind), and my VPN
server is not DMZ'd.  I have a SNAT rule on my firewall that translates
the 10.65.33.252/30 network into the public IP that the otherside of the
VPN is looking for.

 

When I enable NAT-T, it fails on "STATE_QUICK_I1: initiate" for any
connection.

When I create an alias of eth0 to be the public IP and add
ipsec1=eth0:0, and change the to: left="my public ip" it hangs on
"STATE_AGGR_I1: initiate".

I can see it leave my firewall at that point too.  Just no traffic
coming back from the right side.

 

I had a feeling that it has to do with me getting it setup correctly
with NAT-T since they are sending, "[draft-ietf-ipsec-nat-t-ike-02_n]"
and I am not sending nat-t back.

 

Any help will be greatly appreciated!

Oh since this is really my first time posting to the list, all this info
is pretty long.  Is it more customary to post it elsewhere and provide
links or send it as attachments?

 

Below is the output of ipsec barf

 

windu

Wed Dec 31 15:28:53 MST 2008

+ _________________________ version

+ ipsec --version

Linux Openswan 2.4.13 (klips)

See `ipsec --copyright' for copyright information.

+ _________________________ /proc/version

+ cat /proc/version

Linux version 2.6.19-smp (root at windu) (gcc version 4.2.3) #1 SMP Tue Dec
30 20:03:07 MST 2008

+ _________________________ /proc/net/ipsec_eroute

+ test -r /proc/net/ipsec_eroute

+ sort -sg +3 /proc/net/ipsec_eroute

0          10.65.33.252/30    -> 10.162.187.18/32   =>
tun0x100e at 199.91.34.69

0          10.65.33.252/30    -> 10.163.173.6/32    =>
tun0x1010 at 199.91.34.69

0          10.65.33.252/30    -> 10.163.173.23/32   =>
tun0x100c at 199.91.34.69

6          10.65.33.252/30    -> 170.229.48.128/26  =>
tun0x100a at 199.91.34.69

+ _________________________ netstat-rn

+ netstat -nr

+ head -n 100

Kernel IP routing table

Destination     Gateway         Genmask         Flags   MSS Window  irtt
Iface

10.163.173.23   0.0.0.0         255.255.255.255 UH        0 0          0
ipsec0

10.163.173.6    0.0.0.0         255.255.255.255 UH        0 0          0
ipsec0

10.162.187.18   0.0.0.0         255.255.255.255 UH        0 0          0
ipsec0

10.65.33.252    0.0.0.0         255.255.255.252 U         0 0          0
eth0

10.65.33.252    0.0.0.0         255.255.255.252 U         0 0          0
ipsec0

170.229.48.128  0.0.0.0         255.255.255.192 U         0 0          0
ipsec0

127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0
lo

0.0.0.0         10.65.33.254    0.0.0.0         UG        0 0          0
eth0

+ _________________________ /proc/net/ipsec_spi

+ test -r /proc/net/ipsec_spi

+ cat /proc/net/ipsec_spi

esp0xbea0f371 at 199.91.34.69 ESP_3DES_HMAC_SHA1: dir=out src=10.65.33.253
iv_bits=64bits iv=0x6918bb2a742c0600 ooowin=64 alen=160 aklen=160
eklen=192 life(c,s,h)=addtime(2562,0,0) natencap=none natsport=0
natdport=0 refcount=4 ref=77

esp0xada163c at 10.65.33.253 ESP_3DES_HMAC_SHA1: dir=in  src=199.91.34.69
iv_bits=64bits iv=0x735ee61890057643 ooowin=64 alen=160 aklen=160
eklen=192 life(c,s,h)=addtime(2082,0,0) natencap=none natsport=0
natdport=0 refcount=4 ref=84

esp0xada163b at 10.65.33.253 ESP_3DES_HMAC_SHA1: dir=in  src=199.91.34.69
iv_bits=64bits iv=0x673a56d08b0daa62 ooowin=64 alen=160 aklen=160
eklen=192 life(c,s,h)=addtime(2562,0,0) natencap=none natsport=0
natdport=0 refcount=4 ref=72

esp0xada163a at 10.65.33.253 ESP_3DES_HMAC_SHA1: dir=in  src=199.91.34.69
iv_bits=64bits iv=0xf317201755ecad6e ooowin=64 alen=160 aklen=160
eklen=192 life(c,s,h)=addtime(2592,0,0) natencap=none natsport=0
natdport=0 refcount=4 ref=58

esp0xada1639 at 10.65.33.253 ESP_3DES_HMAC_SHA1: dir=in  src=199.91.34.69
iv_bits=64bits iv=0x61c2d594c8801e24 ooowin=64 alen=160 aklen=160
eklen=192 life(c,s,h)=addtime(2592,0,0) natencap=none natsport=0
natdport=0 refcount=4 ref=48

tun0x1010 at 199.91.34.69 IPIP: dir=out src=10.65.33.253
life(c,s,h)=addtime(2082,0,0) natencap=none natsport=0 natdport=0
refcount=4 ref=88

tun0x100e at 199.91.34.69 IPIP: dir=out src=10.65.33.253
life(c,s,h)=addtime(2562,0,0) natencap=none natsport=0 natdport=0
refcount=4 ref=76

tun0x100c at 199.91.34.69 IPIP: dir=out src=10.65.33.253
life(c,s,h)=addtime(2592,0,0) natencap=none natsport=0 natdport=0
refcount=4 ref=62

tun0x100a at 199.91.34.69 IPIP: dir=out src=10.65.33.253
life(c,s,h)=bytes(408,0,0)addtime(2592,0,0)usetime(195,0,0)packets(6,0,0
) idle=184 natencap=none natsport=0 natdport=0 refcount=10 ref=52

esp0x67efcd68 at 199.91.34.69 ESP_3DES_HMAC_SHA1: dir=out src=10.65.33.253
iv_bits=64bits iv=0xca515cf3e17ca76b ooowin=64 alen=160 aklen=160
eklen=192 life(c,s,h)=addtime(2082,0,0) natencap=none natsport=0
natdport=0 refcount=4 ref=89

esp0xf3df6674 at 199.91.34.69 ESP_3DES_HMAC_SHA1: dir=out src=10.65.33.253
iv_bits=64bits iv=0xab7500e3fa8ead03 ooowin=64 seq=6 alen=160 aklen=160
eklen=192
life(c,s,h)=bytes(624,0,0)addtime(2592,0,0)usetime(195,0,0)packets(6,0,0
) idle=184 natencap=none natsport=0 natdport=0 refcount=4 ref=53

tun0x100f at 10.65.33.253 IPIP: dir=in  src=199.91.34.69
policy=10.163.173.6/32->10.65.33.252/30 flags=0x8<>
life(c,s,h)=addtime(2082,0,0) natencap=none natsport=0 natdport=0
refcount=4 ref=83

esp0x77377c44 at 199.91.34.69 ESP_3DES_HMAC_SHA1: dir=out src=10.65.33.253
iv_bits=64bits iv=0x0b4debc088777ad6 ooowin=64 alen=160 aklen=160
eklen=192 life(c,s,h)=addtime(2592,0,0) natencap=none natsport=0
natdport=0 refcount=4 ref=63

tun0x100d at 10.65.33.253 IPIP: dir=in  src=199.91.34.69
policy=10.162.187.18/32->10.65.33.252/30 flags=0x8<>
life(c,s,h)=addtime(2562,0,0) natencap=none natsport=0 natdport=0
refcount=4 ref=71

tun0x100b at 10.65.33.253 IPIP: dir=in  src=199.91.34.69
policy=10.163.173.23/32->10.65.33.252/30 flags=0x8<>
life(c,s,h)=addtime(2592,0,0) natencap=none natsport=0 natdport=0
refcount=4 ref=57

tun0x1009 at 10.65.33.253 IPIP: dir=in  src=199.91.34.69
policy=170.229.48.128/26->10.65.33.252/30 flags=0x8<>
life(c,s,h)=addtime(2592,0,0) natencap=none natsport=0 natdport=0
refcount=4 ref=47

+ _________________________ /proc/net/ipsec_spigrp

+ test -r /proc/net/ipsec_spigrp

+ cat /proc/net/ipsec_spigrp

tun0x1010 at 199.91.34.69 esp0x67efcd68 at 199.91.34.69 

tun0x100e at 199.91.34.69 esp0xbea0f371 at 199.91.34.69 

tun0x100c at 199.91.34.69 esp0x77377c44 at 199.91.34.69 

tun0x100a at 199.91.34.69 esp0xf3df6674 at 199.91.34.69 

tun0x100f at 10.65.33.253 esp0xada163c at 10.65.33.253 

tun0x100d at 10.65.33.253 esp0xada163b at 10.65.33.253 

tun0x100b at 10.65.33.253 esp0xada163a at 10.65.33.253 

tun0x1009 at 10.65.33.253 esp0xada1639 at 10.65.33.253 

+ _________________________ /proc/net/ipsec_tncfg

+ test -r /proc/net/ipsec_tncfg

+ cat /proc/net/ipsec_tncfg

ipsec0 -> eth0 mtu=1400(1500) -> 1400

ipsec1 -> NULL mtu=0(0) -> 0

ipsec2 -> NULL mtu=0(0) -> 0

ipsec3 -> NULL mtu=0(0) -> 0

+ _________________________ /proc/net/pfkey

+ test -r /proc/net/pfkey

+ _________________________ /proc/sys/net/ipsec-star

+ test -d /proc/sys/net/ipsec

+ cd /proc/sys/net/ipsec

+ egrep '^' debug_ah debug_eroute debug_esp debug_ipcomp debug_netlink
debug_pfkey debug_radij debug_rcv debug_spi debug_tunnel debug_verbose
debug_xform icmp inbound_policy_check pfkey_lossage tos

debug_ah:0

debug_eroute:0

debug_esp:0

debug_ipcomp:0

debug_netlink:0

debug_pfkey:0

debug_radij:0

debug_rcv:0

debug_spi:0

debug_tunnel:0

debug_verbose:0

debug_xform:0

icmp:1

inbound_policy_check:1

pfkey_lossage:0

tos:1

+ _________________________ ipsec/status

+ ipsec auto --status

000 interface ipsec0/eth0 10.65.33.253

000 %myid = (none)

000 debug none

000  

000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=64,
keysizemin=192, keysizemax=192

000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=128,
keysizemin=128, keysizemax=256

000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5,
keysizemin=128, keysizemax=128

000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1,
keysizemin=160, keysizemax=160

000  

000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8,
keydeflen=192

000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16,
keydeflen=128

000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16

000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20

000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024

000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536

000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048

000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072

000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096

000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144

000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192

000  

000 stats db_ops.c: {curr_cnt, total_cnt, maxsz} :context={0,12,36}
trans={0,12,72} attrs={0,12,48} 

000  

000 "stmarks_meditech":
10.65.33.252/30===10.65.33.253...199.91.34.69===170.229.48.128/26;
erouted; eroute owner: #7

000 "stmarks_meditech":     srcip=unset; dstip=unset; srcup=ipsec
_updown; dstup=ipsec _updown;

000 "stmarks_meditech":   ike_life: 3600s; ipsec_life: 28800s;
rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3

000 "stmarks_meditech":   policy: PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE;
prio: 30,26; interface: eth0; encap: esp;

000 "stmarks_meditech":   newest ISAKMP SA: #0; newest IPsec SA: #7; 

000 "stmarks_meditech":   IKE algorithms wanted:
3DES_CBC(5)_000-SHA1(2)-MODP1024(2); flags=strict

000 "stmarks_meditech":   IKE algorithms found:
3DES_CBC(5)_192-SHA1(2)_160-MODP1024(2)

000 "stmarks_meditech":   ESP algorithms wanted: 3DES(3)_000-SHA1(2);
flags=strict

000 "stmarks_meditech":   ESP algorithms loaded: 3DES(3)_000-SHA1(2);
flags=strict

000 "stmarks_meditech":   ESP algorithm newest: 3DES_0-HMAC_SHA1;
pfsgroup=<N/A>

000 "stmarks_pacs":
10.65.33.252/30===10.65.33.253...199.91.34.69===10.162.187.18/32;
erouted; eroute owner: #9

000 "stmarks_pacs":     srcip=unset; dstip=unset; srcup=ipsec _updown;
dstup=ipsec _updown;

000 "stmarks_pacs":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin:
540s; rekey_fuzz: 100%; keyingtries: 3

000 "stmarks_pacs":   policy: PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE; prio:
30,32; interface: eth0; encap: esp;

000 "stmarks_pacs":   newest ISAKMP SA: #0; newest IPsec SA: #9; 

000 "stmarks_pacs":   IKE algorithms wanted:
3DES_CBC(5)_000-SHA1(2)-MODP1024(2); flags=strict

000 "stmarks_pacs":   IKE algorithms found:
3DES_CBC(5)_192-SHA1(2)_160-MODP1024(2)

000 "stmarks_pacs":   ESP algorithms wanted: 3DES(3)_000-SHA1(2);
flags=strict

000 "stmarks_pacs":   ESP algorithms loaded: 3DES(3)_000-SHA1(2);
flags=strict

000 "stmarks_pacs":   ESP algorithm newest: 3DES_0-HMAC_SHA1;
pfsgroup=<N/A>

000 "stmarks_pacs2":
10.65.33.252/30===10.65.33.253...199.91.34.69===10.163.173.23/32;
erouted; eroute owner: #8

000 "stmarks_pacs2":     srcip=unset; dstip=unset; srcup=ipsec _updown;
dstup=ipsec _updown;

000 "stmarks_pacs2":   ike_life: 3600s; ipsec_life: 28800s;
rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3

000 "stmarks_pacs2":   policy: PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE; prio:
30,32; interface: eth0; encap: esp;

000 "stmarks_pacs2":   newest ISAKMP SA: #0; newest IPsec SA: #8; 

000 "stmarks_pacs2":   IKE algorithms wanted:
3DES_CBC(5)_000-SHA1(2)-MODP1024(2); flags=strict

000 "stmarks_pacs2":   IKE algorithms found:
3DES_CBC(5)_192-SHA1(2)_160-MODP1024(2)

000 "stmarks_pacs2":   ESP algorithms wanted: 3DES(3)_000-SHA1(2);
flags=strict

000 "stmarks_pacs2":   ESP algorithms loaded: 3DES(3)_000-SHA1(2);
flags=strict

000 "stmarks_pacs2":   ESP algorithm newest: 3DES_0-HMAC_SHA1;
pfsgroup=<N/A>

000 "stmarks_tracemaster":
10.65.33.252/30===10.65.33.253...199.91.34.69===10.163.173.6/32;
erouted; eroute owner: #10

000 "stmarks_tracemaster":     srcip=unset; dstip=unset; srcup=ipsec
_updown; dstup=ipsec _updown;

000 "stmarks_tracemaster":   ike_life: 3600s; ipsec_life: 28800s;
rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3

000 "stmarks_tracemaster":   policy: PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE;
prio: 30,32; interface: eth0; encap: esp;

000 "stmarks_tracemaster":   newest ISAKMP SA: #0; newest IPsec SA: #10;


000 "stmarks_tracemaster":   IKE algorithms wanted:
3DES_CBC(5)_000-SHA1(2)-MODP1024(2); flags=strict

000 "stmarks_tracemaster":   IKE algorithms found:
3DES_CBC(5)_192-SHA1(2)_160-MODP1024(2)

000 "stmarks_tracemaster":   ESP algorithms wanted: 3DES(3)_000-SHA1(2);
flags=strict

000 "stmarks_tracemaster":   ESP algorithms loaded: 3DES(3)_000-SHA1(2);
flags=strict

000 "stmarks_tracemaster":   ESP algorithm newest: 3DES_0-HMAC_SHA1;
pfsgroup=<N/A>

000  

000 #7: "stmarks_meditech":500 STATE_QUICK_I2 (sent QI2, IPsec SA
established); EVENT_SA_REPLACE in 25630s; newest IPSEC; eroute owner

000 #7: "stmarks_meditech" used 82s ago; esp.f3df6674 at 199.91.34.69
esp.ada1639 at 10.65.33.253 tun.100a at 199.91.34.69 tun.1009 at 10.65.33.253

000 #9: "stmarks_pacs":500 STATE_QUICK_I2 (sent QI2, IPsec SA
established); EVENT_SA_REPLACE in 25490s; newest IPSEC; eroute owner

000 #9: "stmarks_pacs" esp.bea0f371 at 199.91.34.69
esp.ada163b at 10.65.33.253 tun.100e at 199.91.34.69 tun.100d at 10.65.33.253

000 #8: "stmarks_pacs2":500 STATE_QUICK_I2 (sent QI2, IPsec SA
established); EVENT_SA_REPLACE in 25175s; newest IPSEC; eroute owner

000 #8: "stmarks_pacs2" esp.77377c44 at 199.91.34.69
esp.ada163a at 10.65.33.253 tun.100c at 199.91.34.69 tun.100b at 10.65.33.253

000 #10: "stmarks_tracemaster":500 STATE_QUICK_I2 (sent QI2, IPsec SA
established); EVENT_SA_REPLACE in 25718s; newest IPSEC; eroute owner

000 #10: "stmarks_tracemaster" esp.67efcd68 at 199.91.34.69
esp.ada163c at 10.65.33.253 tun.1010 at 199.91.34.69 tun.100f at 10.65.33.253

000  

+ _________________________ ifconfig-a

+ ifconfig -a

eth0      Link encap:Ethernet  HWaddr 00:0c:29:28:42:ff  

          inet addr:10.65.33.253  Bcast:10.65.33.255
Mask:255.255.255.252

          inet6 addr: fe80::20c:29ff:fe28:42ff/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1400  Metric:1

          RX packets:288626 errors:0 dropped:0 overruns:0 frame:0

          TX packets:40327 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:134195488 (127.9 MiB)  TX bytes:17223353 (16.4 MiB)

          Base address:0x1070 Memory:e8820000-e8840000 

 

eth0:0    Link encap:Ethernet  HWaddr 00:0c:29:28:42:ff  

          inet addr:65.121.183.8  Bcast:255.255.255.255
Mask:255.255.255.255

          UP BROADCAST RUNNING MULTICAST  MTU:1400  Metric:1

          Base address:0x1070 Memory:e8820000-e8840000 

 

ipsec0    Link encap:Ethernet  HWaddr 00:0c:29:28:42:ff  

          inet addr:10.65.33.253  Mask:255.255.255.252

          inet6 addr: fe80::20c:29ff:fe28:42ff/64 Scope:Link

          UP RUNNING NOARP  MTU:1400  Metric:1

          RX packets:14419 errors:0 dropped:0 overruns:0 frame:0

          TX packets:9842 errors:0 dropped:3 overruns:0 carrier:0

          collisions:0 txqueuelen:10 

          RX bytes:12046081 (11.4 MiB)  TX bytes:1228044 (1.1 MiB)

 

ipsec1    Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  

          NOARP  MTU:0  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:10 

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

 

ipsec2    Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  

          NOARP  MTU:0  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:10 

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

 

ipsec3    Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  

          NOARP  MTU:0  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:10 

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

 

lo        Link encap:Local Loopback  

          inet addr:127.0.0.1  Mask:255.0.0.0

          inet6 addr: ::1/128 Scope:Host

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:14 errors:0 dropped:0 overruns:0 frame:0

          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0 

          RX bytes:984 (984.0 B)  TX bytes:984 (984.0 B)

 

+ _________________________ ip-addr-list

+ ip addr list

1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue 

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

    inet6 ::1/128 scope host 

       valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1400 qdisc pfifo_fast qlen
1000

    link/ether 00:0c:29:28:42:ff brd ff:ff:ff:ff:ff:ff

    inet 10.65.33.253/30 brd 10.65.33.255 scope global eth0

    inet 65.121.183.8/32 brd 255.255.255.255 scope global eth0:0

    inet6 fe80::20c:29ff:fe28:42ff/64 scope link 

       valid_lft forever preferred_lft forever

195: ipsec0: <NOARP,UP,10000> mtu 1400 qdisc pfifo_fast qlen 10

    link/ether 00:0c:29:28:42:ff brd ff:ff:ff:ff:ff:ff

    inet 10.65.33.253/30 brd 10.65.33.255 scope global ipsec0

    inet6 fe80::20c:29ff:fe28:42ff/64 scope link 

       valid_lft forever preferred_lft forever

196: ipsec1: <NOARP> mtu 0 qdisc noop qlen 10

    link/void 

197: ipsec2: <NOARP> mtu 0 qdisc noop qlen 10

    link/void 

198: ipsec3: <NOARP> mtu 0 qdisc noop qlen 10

    link/void 

+ _________________________ ip-route-list

+ ip route list

10.163.173.23 dev ipsec0  scope link 

10.163.173.6 dev ipsec0  scope link 

10.162.187.18 dev ipsec0  scope link 

10.65.33.252/30 dev eth0  proto kernel  scope link  src 10.65.33.253 

10.65.33.252/30 dev ipsec0  proto kernel  scope link  src 10.65.33.253 

170.229.48.128/26 dev ipsec0  scope link 

127.0.0.0/8 dev lo  scope link 

default via 10.65.33.254 dev eth0  metric 1 

+ _________________________ ip-rule-list

+ ip rule list

0:            from all lookup local 

32766:   from all lookup main 

32767:   from all lookup default 

+ _________________________ ipsec_verify

+ ipsec verify --nocolour

Checking your system to see if IPsec got installed and started
correctly:

Version check and ipsec on-path                             [OK]

Linux Openswan 2.4.13 (klips)

Checking for IPsec support in kernel
[OK]

KLIPS detected, checking for NAT Traversal support
[OK]

Checking for RSA private key (/etc/ipsec.d/hostkey.secrets)       [OK]

Checking that pluto is running                                    [OK]

Checking for 'ip' command                                           [OK]

Checking for 'iptables' command                             [OK]

 

Opportunistic Encryption DNS checks:

   Looking for TXT in forward dns zone: windu
[MISSING]

   Does the machine have at least one non-private address?        [OK]

   Looking for TXT in reverse dns zone: 8.183.121.65.in-addr.arpa.
[MISSING]

+ _________________________ mii-tool

+ '[' -x /sbin/mii-tool ']'

+ /sbin/mii-tool -v

eth0: negotiated 1000baseT-FD flow-control, link ok

  product info: Yukon 88E1011 rev 3

  basic mode:   autonegotiation enabled

  basic status: autonegotiation complete, link ok

  capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD
10baseT-HD

  advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD

  link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD
10baseT-HD

+ _________________________ ipsec/directory

+ ipsec --directory

/usr/local/lib/ipsec

+ _________________________ hostname/fqdn

+ hostname --fqdn

windu.heartslc.com

+ _________________________ hostname/ipaddress

+ hostname --ip-address

10.65.33.253 

+ _________________________ uptime

+ uptime

 15:28:55 up  5:49,  4 users,  load average: 2.14, 2.05, 2.01

+ _________________________ ps

+ ps alxwf

+ egrep -i 'ppid|pluto|ipsec|klips'

F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME
COMMAND

0     0 17578 10918  18   0   2772  1380 -      R+   pts/0      0:00  |
\_ /bin/sh /usr/local/libexec/ipsec/barf

1     0 31782     1  24   0   2560   468 wait   S    ?          0:00
/bin/sh /usr/local/lib/ipsec/_plutorun --debug  --uniqueids yes
--nocrsend  --strictcrlpolicy  --nat_traversal no --keep_alive
--protostack auto --force_keepalive  --disable_port_floating
--virtual_private  --crlcheckinterval 0 --ocspuri  --nhelpers  --dump
--opts  --stderrlog  --wait no --pre  --post  --log daemon.error --pid
/var/run/pluto/pluto.pid

1     0 31783 31782  24   0   2560   644 wait   S    ?          0:00  \_
/bin/sh /usr/local/lib/ipsec/_plutorun --debug  --uniqueids yes
--nocrsend  --strictcrlpolicy  --nat_traversal no --keep_alive
--protostack auto --force_keepalive  --disable_port_floating
--virtual_private  --crlcheckinterval 0 --ocspuri  --nhelpers  --dump
--opts  --stderrlog  --wait no --pre  --post  --log daemon.error --pid
/var/run/pluto/pluto.pid

4     0 31784 31783  15   0   2720  1380 -      S    ?          0:00  |
\_ /usr/local/libexec/ipsec/pluto --nofork --secretsfile
/etc/ipsec.secrets --ipsecdir /etc/ipsec.d --use-auto --uniqueids

1     0 31857 31784  26  10   2656   524 -      SN   ?          0:00  |
\_ pluto helper  #  0


0     0 31858 31784  25   0   1636   304 429496 S    ?          0:00  |
\_ _pluto_adns

0     0 31794 31782  16   0   2540  1224 pipe_w S    ?          0:00  \_
/bin/sh /usr/local/lib/ipsec/_plutoload --wait no --post 

0     0 31813     1  18   0   1692   528 pipe_w S    ?          0:00
logger -s -p daemon.error -t ipsec__plutorun

+ _________________________ ipsec/showdefaults

+ ipsec showdefaults

# no default route

+ _________________________ ipsec/conf

+ ipsec _include /etc/ipsec.conf

+ ipsec _keycensor

 

#< /etc/ipsec.conf 1

# /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

                forwardcontrol=yes

                interfaces="ipsec0=eth0"

                nat_traversal=no

                plutowait=no

                uniqueids=yes

 

conn stmarks_meditech

                aggrmode=yes

                auth=esp

                authby=secret

                auto=add

                compress=no

                esp=3des-sha1

                ike=3des-sha1-modp1024

                keyexchange=ike

                keyingtries=3

                left=10.65.33.253

                leftsubnet=10.65.33.252/30

                pfs=no

                right=199.91.34.69

                rightsubnet=170.229.48.128/26

                type=tunnel

 

conn stmarks_pacs

                aggrmode=yes

                auth=esp

                authby=secret

                auto=add

                compress=no

                esp=3des-sha1

                ike=3des-sha1-modp1024

                keyexchange=ike

                keyingtries=3

                left=10.65.33.253

                leftsubnet=10.65.33.252/30

                pfs=no

                right=199.91.34.69

                rightsubnet=10.162.187.18/32

                type=tunnel

 

conn stmarks_tracemaster

                aggrmode=yes

                auth=esp

                authby=secret

                auto=add

                compress=no

                esp=3des-sha1

                ike=3des-sha1-modp1024

                keyexchange=ike

                keyingtries=3

                left=10.65.33.253

                leftsubnet=10.65.33.252/30

                pfs=no

                right=199.91.34.69

                rightsubnet=10.163.173.6/32

                type=tunnel

 

conn stmarks_pacs2

                aggrmode=yes

                auth=esp

                authby=secret

                auto=add

                compress=no

                esp=3des-sha1

                ike=3des-sha1-modp1024

                keyexchange=ike

                keyingtries=3

                left=10.65.33.253

                leftsubnet=10.65.33.252/30

                pfs=no

                right=199.91.34.69

                rightsubnet=10.163.173.23/32

                type=tunnel

+ _________________________ ipsec/secrets

+ ipsec _include /etc/ipsec.secrets

+ ipsec _secretcensor

 

#< /etc/ipsec.secrets 1

: RSA      {

                # RSA 2192 bits   windu   Tue Nov 25 18:56:50 2008

                # for signatures only, UNSAFE FOR ENCRYPTION

                #pubkey=[keyid AQNmyHZSA]

                Modulus: [...]

                PublicExponent: [...]

                # everything after this point is secret

                PrivateExponent: [...]

                Prime1: [...]

                Prime2: [...]

                Exponent1: [...]

                Exponent2: [...]

                Coefficient: [...]

                }

# do not change the indenting of that "[sums to 7d9d...]"

: PSK "[sums to 92d6...]"

+ _________________________ ipsec/listall

+ ipsec auto --listall

000  

000 List of Public Keys:

000  

+ '[' /etc/ipsec.d/policies ']'

+ for policy in '$POLICIES/*'

++ basename /etc/ipsec.d/policies/block

+ base=block

+ _________________________ ipsec/policies/block

+ cat /etc/ipsec.d/policies/block

# This file defines the set of CIDRs (network/mask-length) to which

# communication should never be allowed.

#

# See /usr/local/share/doc/openswan/policygroups.html for details.

#

# $Id: block.in,v 1.4 2003-02-17 02:22:15 mcr Exp $

#

 

+ for policy in '$POLICIES/*'

++ basename /etc/ipsec.d/policies/clear

+ base=clear

+ _________________________ ipsec/policies/clear

+ cat /etc/ipsec.d/policies/clear

# This file defines the set of CIDRs (network/mask-length) to which

# communication should always be in the clear.

#

# See /usr/local/share/doc/openswan/policygroups.html for details.

#

# $Id: clear.in,v 1.4.30.3 2006-11-21 19:49:51 paul Exp $

#

#

#             Michael's idea: Always have ROOT NAMESERVERS in the clear.

#             It will make OE work much better on machines running
caching

#             resolvers.

#

#             Based on: http://www.internic.net/zones/named.root

#       This file holds the information on root name servers needed to

#       last update:    Jan 29, 2004

#       related version of root zone:   2004012900

0.0.0.0/0

+ for policy in '$POLICIES/*'

++ basename /etc/ipsec.d/policies/clear-or-private

+ base=clear-or-private

+ _________________________ ipsec/policies/clear-or-private

+ cat /etc/ipsec.d/policies/clear-or-private

# This file defines the set of CIDRs (network/mask-length) to which

# we will communicate in the clear, or, if the other side initiates
IPSEC,

# using encryption.  This behaviour is also called "Opportunistic
Responder".

#

# See /usr/local/share/doc/openswan/policygroups.html for details.

#

# $Id: clear-or-private.in,v 1.4 2003-02-17 02:22:15 mcr Exp $

#

0.0.0.0/0

+ for policy in '$POLICIES/*'

++ basename /etc/ipsec.d/policies/private

+ base=private

+ _________________________ ipsec/policies/private

+ cat /etc/ipsec.d/policies/private

# This file defines the set of CIDRs (network/mask-length) to which

# communication should always be private (i.e. encrypted).

# See /usr/local/share/doc/openswan/policygroups.html for details.

#

# $Id: private.in,v 1.4 2003-02-17 02:22:15 mcr Exp $

#

0.0.0.0/0

+ for policy in '$POLICIES/*'

++ basename /etc/ipsec.d/policies/private-or-clear

+ base=private-or-clear

+ _________________________ ipsec/policies/private-or-clear

+ cat /etc/ipsec.d/policies/private-or-clear

# This file defines the set of CIDRs (network/mask-length) to which

# communication should be private, if possible, but in the clear
otherwise.

#

# If the target has a TXT (later IPSECKEY) record that specifies

# authentication material, we will require private (i.e. encrypted)

# communications.  If no such record is found, communications will be

# in the clear.

#

# See /usr/local/share/doc/openswan/policygroups.html for details.

#

# $Id: private-or-clear.in,v 1.5 2003-02-17 02:22:15 mcr Exp $

#

 

0.0.0.0/0

+ _________________________ ipsec/ls-libdir

+ ls -l /usr/local/lib/ipsec

total 116

-rwxr-xr-x 1 root root 15848 Dec 31 09:33 _confread

-rwxr-xr-x 1 root root 14289 Dec 31 09:33 _copyright

-rwxr-xr-x 1 root root  2379 Dec 31 09:33 _include

-rwxr-xr-x 1 root root  1475 Dec 31 09:33 _keycensor

-rwxr-xr-x 1 root root  3648 Dec 31 09:33 _plutoload

-rwxr-xr-x 1 root root  8069 Dec 31 09:33 _plutorun

-rwxr-xr-x 1 root root 12324 Dec 31 09:33 _realsetup

-rwxr-xr-x 1 root root  1975 Dec 31 09:33 _secretcensor

-rwxr-xr-x 1 root root 11102 Dec 31 09:33 _startklips

-rwxr-xr-x 1 root root 13918 Dec 31 09:33 _updown

-rwxr-xr-x 1 root root 15746 Dec 31 09:33 _updown_x509

+ _________________________ ipsec/ls-execdir

+ ls -l /usr/local/libexec/ipsec

total 4548

-rwxr-xr-x 1 root root   28489 Dec 31 09:32 _pluto_adns

-rwxr-xr-x 1 root root  375943 May 12  2008 addconn.old

-rwxr-xr-x 1 root root   18891 Dec 31 09:33 auto

-rwxr-xr-x 1 root root   11367 Dec 31 09:33 barf

-rwxr-xr-x 1 root root     816 Dec 31 09:33 calcgoo

-rwxr-xr-x 1 root root  199893 Dec 31 09:32 eroute

-rwxr-xr-x 1 root root   65085 Dec 31 09:33 ikeping

-rwxr-xr-x 1 root root  129819 Dec 31 09:32 klipsdebug

-rwxr-xr-x 1 root root    1836 Dec 31 09:33 livetest

-rwxr-xr-x 1 root root    2604 Dec 31 09:33 look

-rwxr-xr-x 1 root root  839794 May 12  2008 lwdnsq.old

-rwxr-xr-x 1 root root    7094 Dec 31 09:33 mailkey

-rwxr-xr-x 1 root root   16015 Dec 31 09:33 manual

-rwxr-xr-x 1 root root    1951 Dec 31 09:33 newhostkey

-rwxr-xr-x 1 root root  115216 Dec 31 09:32 pf_key

-rwxr-xr-x 1 root root 1914326 Dec 31 09:32 pluto

-rwxr-xr-x 1 root root   21174 Dec 31 09:33 ranbits

-rwxr-xr-x 1 root root   50625 Dec 31 09:33 rsasigkey

-rwxr-xr-x 1 root root     766 Dec 31 09:33 secrets

lrwxrwxrwx 1 root root      22 Dec 31 09:33 setup ->
/etc/rc.d/init.d/ipsec

-rwxr-xr-x 1 root root    1054 Dec 31 09:33 showdefaults

-rwxr-xr-x 1 root root    4845 Dec 31 09:33 showhostkey

-rwxr-xr-x 1 root root   60365 May 12  2008 showpolicy.old

-rwxr-xr-x 1 root root  325143 Dec 31 09:32 spi

-rwxr-xr-x 1 root root  164884 Dec 31 09:32 spigrp

-rwxr-xr-x 1 root root   24248 Dec 31 09:32 tncfg

-rwxr-xr-x 1 root root   13530 Dec 31 09:33 verify

-rwxr-xr-x 1 root root  159092 Dec 31 09:32 whack

+ _________________________ ipsec/updowns

++ ls /usr/local/libexec/ipsec

++ egrep updown

+ _________________________ /proc/net/dev

+ cat /proc/net/dev

Inter-|   Receive                                                |
Transmit

 face |bytes    packets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed

    lo:     984      14    0    0    0     0          0         0
984      14    0    0    0     0       0          0

  eth0:134198590  288645    0    0    0     0          0         0
17223679   40331    0    0    0     0       0          0

ipsec0:12046081   14419    0    0    0     0          0         0
1228044    9842    0    3    0     0       0          0

ipsec1:       0       0    0    0    0     0          0         0
0       0    0    0    0     0       0          0

ipsec2:       0       0    0    0    0     0          0         0
0       0    0    0    0     0       0          0

ipsec3:       0       0    0    0    0     0          0         0
0       0    0    0    0     0       0          0

+ _________________________ /proc/net/route

+ cat /proc/net/route

Iface      Destination         Gateway              Flags      RefCnt
Use        Metric   Mask                     MTU      Window
IRTT                                                       

ipsec0   17ADA30A           00000000             0005       0
0              0              FFFFFFFF             0              0
0


ipsec0   06ADA30A           00000000             0005       0
0              0              FFFFFFFF             0              0
0


ipsec0   12BBA20A           00000000             0005       0
0              0              FFFFFFFF             0              0
0


eth0       FC21410A            00000000             0001       0
0              0              FCFFFFFF             0              0
0


ipsec0   FC21410A            00000000             0001       0
0              0              FCFFFFFF             0              0
0


ipsec0   8030E5AA            00000000             0001       0
0              0              C0FFFFFF             0              0
0


lo            0000007F             00000000             0001       0
0              0              000000FF             0              0
0


eth0       00000000             FE21410A             0003       0
0              1              00000000             0              0
0


+ _________________________ /proc/sys/net/ipv4/ip_forward

+ cat /proc/sys/net/ipv4/ip_forward

1

+ _________________________ /proc/sys/net/ipv4/tcp_ecn

+ cat /proc/sys/net/ipv4/tcp_ecn

0

+ _________________________ /proc/sys/net/ipv4/conf/star-rp_filter

+ cd /proc/sys/net/ipv4/conf

+ egrep '^' all/rp_filter default/rp_filter eth0/rp_filter
ipsec0/rp_filter lo/rp_filter

all/rp_filter:0

default/rp_filter:0

eth0/rp_filter:0

ipsec0/rp_filter:0

lo/rp_filter:0

+ _________________________ /proc/sys/net/ipv4/conf/star-rp_filter

+ cd /proc/sys/net/ipv4/conf

+ egrep '^' all/rp_filter default/rp_filter eth0/rp_filter
ipsec0/rp_filter lo/rp_filter

all/rp_filter:0

default/rp_filter:0

eth0/rp_filter:0

ipsec0/rp_filter:0

lo/rp_filter:0

+ _________________________ /proc/sys/net/ipv4/conf/star-star-redirects

+ cd /proc/sys/net/ipv4/conf

+ egrep '^' all/accept_redirects all/secure_redirects all/send_redirects
default/accept_redirects default/secure_redirects default/send_redirects
eth0/accept_redirects eth0/secure_redirects eth0/send_redirects
ipsec0/accept_redirects ipsec0/secure_redirects ipsec0/send_redirects
lo/accept_redirects lo/secure_redirects lo/send_redirects

all/accept_redirects:0

all/secure_redirects:1

all/send_redirects:0

default/accept_redirects:0

default/secure_redirects:1

default/send_redirects:0

eth0/accept_redirects:0

eth0/secure_redirects:1

eth0/send_redirects:0

ipsec0/accept_redirects:0

ipsec0/secure_redirects:1

ipsec0/send_redirects:0

lo/accept_redirects:1

lo/secure_redirects:1

lo/send_redirects:1

+ _________________________ /proc/sys/net/ipv4/tcp_window_scaling

+ cat /proc/sys/net/ipv4/tcp_window_scaling

1

+ _________________________ /proc/sys/net/ipv4/tcp_adv_win_scale

+ cat /proc/sys/net/ipv4/tcp_adv_win_scale

2

+ _________________________ uname-a

+ uname -a

Linux windu 2.6.19-smp #1 SMP Tue Dec 30 20:03:07 MST 2008 i686 Intel(R)
Xeon(R) CPU           E5335  @ 2.00GHz GenuineIntel GNU/Linux

+ _________________________ config-built-with

+ test -r /proc/config_built_with

+ _________________________ distro-release

+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release

+ test -f /etc/redhat-release

+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release

+ test -f /etc/debian-release

+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release

+ test -f /etc/SuSE-release

+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release

+ test -f /etc/mandrake-release

+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release

+ test -f /etc/mandriva-release

+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release

+ test -f /etc/gentoo-release

+ _________________________ /proc/net/ipsec_version

+ test -r /proc/net/ipsec_version

+ cat /proc/net/ipsec_version

Openswan version: 2.4.13

+ _________________________ ipfwadm

+ test -r /sbin/ipfwadm

+ 'no old-style linux 1.x/2.0 ipfwadm firewall support'

/usr/local/libexec/ipsec/barf: line 305: no old-style linux 1.x/2.0
ipfwadm firewall support: No such file or directory

+ _________________________ ipchains

+ test -r /sbin/ipchains

+ echo 'no old-style linux 2.0 ipchains firewall support'

no old-style linux 2.0 ipchains firewall support

+ _________________________ iptables

+ test -r /sbin/iptables

+ test -r /sbin/ipchains

+ _________________________ /proc/modules

+ test -f /proc/modules

+ cat /proc/modules

ipsec 351724 2 - Live 0xf90d2000

iptable_mangle 6144 0 - Live 0xf8ef4000

iptable_filter 6400 0 - Live 0xf8ef1000

ip_tables 15172 2 iptable_mangle,iptable_filter, Live 0xf8fe9000

x_tables 15492 1 ip_tables, Live 0xf8ef7000

ipv6 241184 10 - Live 0xf9030000

pcmcia 33836 0 - Live 0xf8fdf000

rsrc_nonstatic 14720 0 - Live 0xf8ed4000

pcmcia_core 36500 2 pcmcia,rsrc_nonstatic, Live 0xf8e91000

tun 12032 0 - Live 0xf8cdc000

lp 13480 0 - Live 0xf8cc1000

parport_pc 27300 1 - Live 0xf8e9c000

parport 34760 2 lp,parport_pc, Live 0xf8ec4000

fuse 41876 1 - Live 0xf8cf4000

intel_agp 24348 1 - Live 0xf8e8a000

agpgart 29256 1 intel_agp, Live 0xf8e81000

serio_raw 9220 0 - Live 0xf8ce0000

e1000 118976 0 - Live 0xf8ea5000

psmouse 38280 0 - Live 0xf8ce9000

pcspkr 6528 0 - Live 0xf8cd9000

i2c_piix4 11148 0 - Live 0xf8cd5000

evdev 11904 1 - Live 0xf8cc6000

sg 30108 0 - Live 0xf8ccc000

+ _________________________ /proc/meminfo

+ cat /proc/meminfo

MemTotal:      1031624 kB

MemFree:        810208 kB

Buffers:         41756 kB

Cached:         139820 kB

SwapCached:          0 kB

Active:         102840 kB

Inactive:        92460 kB

HighTotal:      131008 kB

HighFree:          264 kB

LowTotal:       900616 kB

LowFree:        809944 kB

SwapTotal:     1542232 kB

SwapFree:      1542232 kB

Dirty:             352 kB

Writeback:           0 kB

AnonPages:       13692 kB

Mapped:           7588 kB

Slab:            15772 kB

SReclaimable:     6892 kB

SUnreclaim:       8880 kB

PageTables:        564 kB

NFS_Unstable:        0 kB

Bounce:              0 kB

CommitLimit:   2058044 kB

Committed_AS:    43028 kB

VmallocTotal:   114680 kB

VmallocUsed:      8700 kB

VmallocChunk:   105300 kB

+ _________________________ /proc/net/ipsec-ls

+ test -f /proc/net/ipsec_version

+ ls -l /proc/net/ipsec_eroute /proc/net/ipsec_klipsdebug
/proc/net/ipsec_spi /proc/net/ipsec_spigrp /proc/net/ipsec_tncfg
/proc/net/ipsec_version

lrwxrwxrwx 1 root root 16 Dec 31 15:28 /proc/net/ipsec_eroute ->
ipsec/eroute/all

lrwxrwxrwx 1 root root 16 Dec 31 15:28 /proc/net/ipsec_klipsdebug ->
ipsec/klipsdebug

lrwxrwxrwx 1 root root 13 Dec 31 15:28 /proc/net/ipsec_spi ->
ipsec/spi/all

lrwxrwxrwx 1 root root 16 Dec 31 15:28 /proc/net/ipsec_spigrp ->
ipsec/spigrp/all

lrwxrwxrwx 1 root root 11 Dec 31 15:28 /proc/net/ipsec_tncfg ->
ipsec/tncfg

lrwxrwxrwx 1 root root 13 Dec 31 15:28 /proc/net/ipsec_version ->
ipsec/version

+ _________________________ usr/src/linux/.config

+ test -f /proc/config.gz

+ zcat /proc/config.gz

+ egrep
'CONFIG_IPSEC|CONFIG_KLIPS|CONFIG_NET_KEY|CONFIG_INET|CONFIG_IP|CONFIG_H
W_RANDOM|CONFIG_CRYPTO_DEV|_XFRM'

# CONFIG_IPC_NS is not set

CONFIG_XFRM=y

CONFIG_XFRM_USER=y

CONFIG_NET_KEY=m

CONFIG_INET=y

CONFIG_IP_MULTICAST=y

CONFIG_IP_ADVANCED_ROUTER=y

# CONFIG_IP_FIB_TRIE is not set

CONFIG_IP_FIB_HASH=y

CONFIG_IP_MULTIPLE_TABLES=y

# CONFIG_IP_ROUTE_FWMARK is not set

CONFIG_IP_ROUTE_MULTIPATH=y

# CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set

CONFIG_IP_ROUTE_VERBOSE=y

# CONFIG_IP_PNP is not set

CONFIG_IP_MROUTE=y

CONFIG_IP_PIMSM_V1=y

CONFIG_IP_PIMSM_V2=y

CONFIG_IPSEC_NAT_TRAVERSAL=y

CONFIG_INET_AH=m

CONFIG_INET_ESP=m

CONFIG_INET_IPCOMP=m

CONFIG_INET_XFRM_TUNNEL=m

CONFIG_INET_TUNNEL=m

CONFIG_INET_XFRM_MODE_TRANSPORT=m

CONFIG_INET_XFRM_MODE_TUNNEL=m

CONFIG_INET_XFRM_MODE_BEET=m

CONFIG_INET_DIAG=m

CONFIG_INET_TCP_DIAG=m

CONFIG_IP_VS=m

# CONFIG_IP_VS_DEBUG is not set

CONFIG_IP_VS_TAB_BITS=12

CONFIG_IP_VS_PROTO_TCP=y

CONFIG_IP_VS_PROTO_UDP=y

CONFIG_IP_VS_PROTO_ESP=y

CONFIG_IP_VS_PROTO_AH=y

CONFIG_IP_VS_RR=m

CONFIG_IP_VS_WRR=m

CONFIG_IP_VS_LC=m

CONFIG_IP_VS_WLC=m

CONFIG_IP_VS_LBLC=m

CONFIG_IP_VS_LBLCR=m

CONFIG_IP_VS_DH=m

CONFIG_IP_VS_SH=m

CONFIG_IP_VS_SED=m

CONFIG_IP_VS_NQ=m

CONFIG_IP_VS_FTP=m

CONFIG_IPV6=m

CONFIG_IPV6_PRIVACY=y

# CONFIG_IPV6_ROUTER_PREF is not set

CONFIG_INET6_AH=m

CONFIG_INET6_ESP=m

CONFIG_INET6_IPCOMP=m

CONFIG_INET6_XFRM_TUNNEL=m

CONFIG_INET6_TUNNEL=m

CONFIG_INET6_XFRM_MODE_TRANSPORT=m

CONFIG_INET6_XFRM_MODE_TUNNEL=m

CONFIG_INET6_XFRM_MODE_BEET=m

CONFIG_IPV6_SIT=m

CONFIG_IPV6_TUNNEL=m

# CONFIG_IP_NF_CONNTRACK is not set

CONFIG_IP_NF_QUEUE=m

CONFIG_IP_NF_IPTABLES=m

CONFIG_IP_NF_MATCH_IPRANGE=m

CONFIG_IP_NF_MATCH_TOS=m

CONFIG_IP_NF_MATCH_RECENT=m

CONFIG_IP_NF_MATCH_ECN=m

CONFIG_IP_NF_MATCH_AH=m

CONFIG_IP_NF_MATCH_TTL=m

CONFIG_IP_NF_MATCH_OWNER=m

CONFIG_IP_NF_MATCH_ADDRTYPE=m

# CONFIG_IP_NF_MATCH_HASHLIMIT is not set

CONFIG_IP_NF_FILTER=m

CONFIG_IP_NF_TARGET_REJECT=m

CONFIG_IP_NF_TARGET_LOG=m

CONFIG_IP_NF_TARGET_ULOG=m

# CONFIG_IP_NF_TARGET_TCPMSS is not set

CONFIG_IP_NF_MANGLE=m

CONFIG_IP_NF_TARGET_TOS=m

CONFIG_IP_NF_TARGET_ECN=m

CONFIG_IP_NF_TARGET_TTL=m

CONFIG_IP_NF_RAW=m

CONFIG_IP_NF_ARPTABLES=m

CONFIG_IP_NF_ARPFILTER=m

CONFIG_IP_NF_ARP_MANGLE=m

CONFIG_IPX=m

# CONFIG_IPX_INTERN is not set

CONFIG_IPDDP=m

CONFIG_IPDDP_ENCAP=y

CONFIG_IPDDP_DECAP=y

CONFIG_IPPP_FILTER=y

CONFIG_IPMI_HANDLER=m

# CONFIG_IPMI_PANIC_EVENT is not set

CONFIG_IPMI_DEVICE_INTERFACE=m

CONFIG_IPMI_SI=m

CONFIG_IPMI_WATCHDOG=m

CONFIG_IPMI_POWEROFF=m

CONFIG_HW_RANDOM=y

CONFIG_HW_RANDOM_INTEL=m

CONFIG_HW_RANDOM_AMD=m

CONFIG_HW_RANDOM_GEODE=m

CONFIG_HW_RANDOM_VIA=m

CONFIG_SECURITY_NETWORK_XFRM=y

CONFIG_CRYPTO_DEV_PADLOCK=m

CONFIG_CRYPTO_DEV_PADLOCK_AES=m

CONFIG_CRYPTO_DEV_PADLOCK_SHA=m

+ _________________________ etc/syslog.conf

+ cat /etc/syslog.conf

# /etc/syslog.conf

# For info about the format of this file, see "man syslog.conf"

# and /usr/doc/sysklogd/README.linux.  Note the '-' prefixing some

# of these entries;  this omits syncing the file after every logging.

# In the event of a crash, some log information might be lost, so

# if this is a concern to you then you might want to remove the '-'.

# Be advised this will cause a performation loss if you're using

# programs that do heavy logging.

 

# Uncomment this to see kernel messages on the console.

#kern.*
/dev/console

 

# Log anything 'info' or higher, but lower than 'warn'.

# Exclude authpriv, cron, mail, and news.  These are logged elsewhere.

*.info;*.!warn;\

                authpriv.none;cron.none;mail.none;news.none
-/var/log/messages

 

# Log anything 'warn' or higher.

# Exclude authpriv, cron, mail, and news.  These are logged elsewhere.

*.warn;\

                authpriv.none;cron.none;mail.none;news.none
-/var/log/syslog

 

# Debugging information is logged here.

*.=debug
-/var/log/debug

 

# Private authentication message logging:

authpriv.*
-/var/log/secure

 

# Cron related logs:

cron.*
-/var/log/cron

 

# Mail related logs:

mail.*
-/var/log/maillog

 

# Emergency level messages go to all users:

*.emerg
*

 

# This log is for news and uucp errors:

uucp,news.crit
-/var/log/spooler

 

# Uncomment these if you'd like INN to keep logs on everything.

# You won't need this if you don't run INN (the InterNetNews daemon).

#news.=crit
-/var/log/news/news.crit

#news.=err
-/var/log/news/news.err

#news.notice
-/var/log/news/news.notice

 

+ _________________________ etc/syslog-ng/syslog-ng.conf

+ cat /etc/syslog-ng/syslog-ng.conf

cat: /etc/syslog-ng/syslog-ng.conf: No such file or directory

+ _________________________ etc/resolv.conf

+ cat /etc/resolv.conf

search heartslc.com

nameserver 10.30.0.19

+ _________________________ lib/modules-ls

+ ls -ltr /lib/modules

total 16

drwxr-xr-x 3 root root 4096 Apr 30  2008 2.6.24.5

drwxr-xr-x 3 root root 4096 May 11  2008 2.6.24.5-smp

drwxr-xr-x 3 root root 4096 Dec 31 09:37 2.6.19.7-smp

drwxr-xr-x 3 root root 4096 Dec 31 09:40 2.6.19-smp

+ _________________________ /proc/ksyms-netif_rx

+ test -r /proc/ksyms

+ test -r /proc/kallsyms

+ egrep netif_rx /proc/kallsyms

c05b3420 T __netif_rx_schedule

c05b4920 T netif_rx

c05b5e10 T netif_rx_ni

c05b4920 U netif_rx        [ipsec]

c05b4920 U netif_rx        [ipv6]

c05b5e10 U netif_rx_ni [tun]

c05b3420 U __netif_rx_schedule             [e1000]

+ _________________________ lib/modules-netif_rx

+ modulegoo kernel/net/ipv4/ipip.o netif_rx

+ set +x

2.6.19-smp: 

2.6.19.7-smp: 

2.6.24.5: 

2.6.24.5-smp: 

+ _________________________ kern.debug

+ test -f /var/log/kern.debug

+ _________________________ klog

+ sed -n '2157,$p' /var/log/syslog

+ egrep -i 'ipsec|klips|pluto'

+ case "$1" in

+ cat

Dec 31 13:41:31 windu ipsec_setup: Starting Openswan IPsec 2.4.13...

Dec 31 13:41:33 windu ipsec__plutorun: ipsec_auto: fatal error in
"packetdefault": %defaultroute requested but not known

Dec 31 13:41:33 windu ipsec__plutorun: ipsec_auto: fatal error in
"block": %defaultroute requested but not known

Dec 31 13:41:34 windu ipsec__plutorun: ipsec_auto: fatal error in
"clear-or-private": %defaultroute requested but not known

Dec 31 13:41:34 windu ipsec__plutorun: ipsec_auto: fatal error in
"clear": %defaultroute requested but not known

Dec 31 13:41:35 windu ipsec__plutorun: ipsec_auto: fatal error in
"private-or-clear": %defaultroute requested but not known

Dec 31 13:41:35 windu ipsec__plutorun: ipsec_auto: fatal error in
"private": %defaultroute requested but not known

Dec 31 13:41:35 windu ipsec__plutorun: 021 no connection named
"packetdefault"

Dec 31 13:41:35 windu ipsec__plutorun: ...could not route conn
"packetdefault"

Dec 31 13:41:35 windu ipsec__plutorun: 021 no connection named "block"

Dec 31 13:41:35 windu ipsec__plutorun: ...could not route conn "block"

Dec 31 13:41:36 windu ipsec__plutorun: 021 no connection named
"clear-or-private"

Dec 31 13:41:36 windu ipsec__plutorun: ...could not route conn
"clear-or-private"

Dec 31 13:41:36 windu ipsec__plutorun: 021 no connection named "clear"

Dec 31 13:41:36 windu ipsec__plutorun: ...could not route conn "clear"

Dec 31 13:41:36 windu ipsec__plutorun: 021 no connection named
"private-or-clear"

Dec 31 13:41:36 windu ipsec__plutorun: ...could not route conn
"private-or-clear"

Dec 31 13:41:36 windu ipsec__plutorun: 021 no connection named "private"

Dec 31 13:41:36 windu ipsec__plutorun: ...could not route conn "private"

+ _________________________ plog

+ sed -n '13065,$p' /var/log/secure

+ egrep -i pluto

+ case "$1" in

+ cat

Dec 31 13:41:30 windu ipsec__plutorun: Starting Pluto subsystem...

Dec 31 13:41:31 windu pluto[31784]: Starting Pluto (Openswan Version
2.4.13 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR; Vendor ID OE`fijAufQMD)

Dec 31 13:41:31 windu pluto[31784]: Setting NAT-Traversal port-4500
floating to off

Dec 31 13:41:31 windu pluto[31784]:    port floating activation criteria
nat_t=0/port_fload=1

Dec 31 13:41:31 windu pluto[31784]:   including NAT-Traversal patch
(Version 0.6c) [disabled]

Dec 31 13:41:31 windu pluto[31784]: ike_alg_register_enc(): Activating
OAKLEY_AES_CBC: Ok (ret=0)

Dec 31 13:41:31 windu pluto[31784]: starting up 1 cryptographic helpers

Dec 31 13:41:31 windu pluto[31784]: started helper pid=31857 (fd:6)

Dec 31 13:41:31 windu pluto[31784]: Using KLIPS IPsec interface code on
2.6.19-smp

Dec 31 13:41:31 windu pluto[31784]: Changing to directory
'/etc/ipsec.d/cacerts'

Dec 31 13:41:31 windu pluto[31784]: Changing to directory
'/etc/ipsec.d/aacerts'

Dec 31 13:41:31 windu pluto[31784]: Changing to directory
'/etc/ipsec.d/ocspcerts'

Dec 31 13:41:31 windu pluto[31784]: Changing to directory
'/etc/ipsec.d/crls'

Dec 31 13:41:31 windu pluto[31784]:   Warning: empty directory

Dec 31 13:41:32 windu pluto[31784]: added connection description
"stmarks_pacs2"

Dec 31 13:41:33 windu pluto[31784]: added connection description
"stmarks_meditech"

Dec 31 13:41:33 windu pluto[31784]: added connection description
"stmarks_pacs"

Dec 31 13:41:34 windu pluto[31784]: added connection description
"stmarks_tracemaster"

Dec 31 13:41:35 windu pluto[31784]: listening for IKE messages

Dec 31 13:41:35 windu pluto[31784]: adding interface ipsec0/eth0
10.65.33.253:500

Dec 31 13:41:35 windu pluto[31784]: loading secrets from
"/etc/ipsec.secrets"

Dec 31 13:41:41 windu pluto[31784]: "stmarks_meditech" #1: initiating
Aggressive Mode #1, connection "stmarks_meditech"

Dec 31 13:41:41 windu pluto[31784]: "stmarks_meditech" #1: received
Vendor ID payload [Cisco-Unity]

Dec 31 13:41:41 windu pluto[31784]: "stmarks_meditech" #1: received
Vendor ID payload [XAUTH]

Dec 31 13:41:41 windu pluto[31784]: "stmarks_meditech" #1: received
Vendor ID payload [Dead Peer Detection]

Dec 31 13:41:41 windu pluto[31784]: "stmarks_meditech" #1: ignoring
Vendor ID payload [FRAGMENTATION c0000000]

Dec 31 13:41:41 windu pluto[31784]: "stmarks_meditech" #1: ignoring
Vendor ID payload [Cisco VPN 3000 Series]

Dec 31 13:41:41 windu pluto[31784]: "stmarks_meditech" #1: protocol/port
in Phase 1 ID Payload must be 0/0 or 17/500 but are 17/0

Dec 31 13:41:41 windu pluto[31784]: "stmarks_meditech" #1: Aggressive
mode peer ID is ID_IPV4_ADDR: '199.91.34.69'

Dec 31 13:41:41 windu pluto[31784]: "stmarks_meditech" #1: protocol/port
in Phase 1 ID Payload must be 0/0 or 17/500 but are 17/0

Dec 31 13:41:41 windu pluto[31784]: "stmarks_meditech" #1: Aggressive
mode peer ID is ID_IPV4_ADDR: '199.91.34.69'

Dec 31 13:41:41 windu pluto[31784]: "stmarks_meditech" #1: transition
from state STATE_AGGR_I1 to state STATE_AGGR_I2

Dec 31 13:41:41 windu pluto[31784]: "stmarks_meditech" #1:
STATE_AGGR_I2: sent AI2, ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
group=modp1024}

Dec 31 13:41:41 windu pluto[31784]: "stmarks_meditech" #2: initiating
Quick Mode PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE {using isakmp#1}

Dec 31 13:41:42 windu pluto[31784]: "stmarks_meditech" #2: transition
from state STATE_QUICK_I1 to state STATE_QUICK_I2

Dec 31 13:41:42 windu pluto[31784]: "stmarks_meditech" #2:
STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x00b50ac4
<0x0ada1635 xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}

Dec 31 13:41:50 windu pluto[31784]: "stmarks_pacs" #3: initiating Quick
Mode PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE {using isakmp#1}

Dec 31 13:41:50 windu pluto[31784]: "stmarks_pacs" #3: transition from
state STATE_QUICK_I1 to state STATE_QUICK_I2

Dec 31 13:41:50 windu pluto[31784]: "stmarks_pacs" #3: STATE_QUICK_I2:
sent QI2, IPsec SA established {ESP=>0x8f03a187 <0x0ada1636
xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}

Dec 31 13:41:56 windu pluto[31784]: "stmarks_tracemaster" #4: initiating
Quick Mode PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE {using isakmp#1}

Dec 31 13:41:57 windu pluto[31784]: "stmarks_tracemaster" #4: transition
from state STATE_QUICK_I1 to state STATE_QUICK_I2

Dec 31 13:41:57 windu pluto[31784]: "stmarks_tracemaster" #4:
STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0xe44b2b6f
<0x0ada1637 xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}

Dec 31 13:42:02 windu pluto[31784]: "stmarks_pacs2" #5: initiating Quick
Mode PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE {using isakmp#1}

Dec 31 13:42:02 windu pluto[31784]: "stmarks_pacs2" #5: transition from
state STATE_QUICK_I1 to state STATE_QUICK_I2

Dec 31 13:42:02 windu pluto[31784]: "stmarks_pacs2" #5: STATE_QUICK_I2:
sent QI2, IPsec SA established {ESP=>0xa15a3b3a <0x0ada1638
xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}

Dec 31 14:26:41 windu pluto[31784]: "stmarks_meditech" #6: initiating
Aggressive Mode #6 to replace #1, connection "stmarks_meditech"

Dec 31 14:26:41 windu pluto[31784]: "stmarks_meditech" #6: received
Vendor ID payload [Cisco-Unity]

Dec 31 14:26:41 windu pluto[31784]: "stmarks_meditech" #6: received
Vendor ID payload [XAUTH]

Dec 31 14:26:41 windu pluto[31784]: "stmarks_meditech" #6: received
Vendor ID payload [Dead Peer Detection]

Dec 31 14:26:41 windu pluto[31784]: "stmarks_meditech" #6: ignoring
Vendor ID payload [FRAGMENTATION c0000000]

Dec 31 14:26:41 windu pluto[31784]: "stmarks_meditech" #6: ignoring
Vendor ID payload [Cisco VPN 3000 Series]

Dec 31 14:26:41 windu pluto[31784]: "stmarks_meditech" #6: protocol/port
in Phase 1 ID Payload must be 0/0 or 17/500 but are 17/0

Dec 31 14:26:41 windu pluto[31784]: "stmarks_meditech" #6: Aggressive
mode peer ID is ID_IPV4_ADDR: '199.91.34.69'

Dec 31 14:26:41 windu pluto[31784]: "stmarks_meditech" #6: protocol/port
in Phase 1 ID Payload must be 0/0 or 17/500 but are 17/0

Dec 31 14:26:41 windu pluto[31784]: "stmarks_meditech" #6: Aggressive
mode peer ID is ID_IPV4_ADDR: '199.91.34.69'

Dec 31 14:26:41 windu pluto[31784]: "stmarks_meditech" #6: transition
from state STATE_AGGR_I1 to state STATE_AGGR_I2

Dec 31 14:26:41 windu pluto[31784]: "stmarks_meditech" #6:
STATE_AGGR_I2: sent AI2, ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
group=modp1024}

Dec 31 14:45:30 windu pluto[31784]: "stmarks_meditech" #6: received
Delete SA payload: replace IPSEC State #5 in 10 seconds

Dec 31 14:45:30 windu pluto[31784]: "stmarks_meditech" #6: received and
ignored informational message

Dec 31 14:45:30 windu pluto[31784]: "stmarks_meditech" #6: received
Delete SA payload: replace IPSEC State #2 in 10 seconds

Dec 31 14:45:30 windu pluto[31784]: "stmarks_meditech" #6: received and
ignored informational message

Dec 31 14:45:40 windu pluto[31784]: "stmarks_meditech" #7: initiating
Quick Mode PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE to replace #2 {using
isakmp#6}

Dec 31 14:45:40 windu pluto[31784]: "stmarks_pacs2" #8: initiating Quick
Mode PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE to replace #5 {using isakmp#6}

Dec 31 14:45:40 windu pluto[31784]: "stmarks_meditech" #7: transition
from state STATE_QUICK_I1 to state STATE_QUICK_I2

Dec 31 14:45:40 windu pluto[31784]: "stmarks_meditech" #7:
STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0xf3df6674
<0x0ada1639 xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}

Dec 31 14:45:40 windu pluto[31784]: "stmarks_pacs2" #8: transition from
state STATE_QUICK_I1 to state STATE_QUICK_I2

Dec 31 14:45:40 windu pluto[31784]: "stmarks_pacs2" #8: STATE_QUICK_I2:
sent QI2, IPsec SA established {ESP=>0x77377c44 <0x0ada163a
xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}

Dec 31 14:46:00 windu pluto[31784]: "stmarks_meditech" #6: received
Delete SA payload: replace IPSEC State #3 in 10 seconds

Dec 31 14:46:00 windu pluto[31784]: "stmarks_meditech" #6: received and
ignored informational message

Dec 31 14:46:10 windu pluto[31784]: "stmarks_pacs" #9: initiating Quick
Mode PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE to replace #3 {using isakmp#6}

Dec 31 14:46:10 windu pluto[31784]: "stmarks_pacs" #9: transition from
state STATE_QUICK_I1 to state STATE_QUICK_I2

Dec 31 14:46:10 windu pluto[31784]: "stmarks_pacs" #9: STATE_QUICK_I2:
sent QI2, IPsec SA established {ESP=>0xbea0f371 <0x0ada163b
xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}

Dec 31 14:54:00 windu pluto[31784]: "stmarks_meditech" #6: received
Delete SA payload: replace IPSEC State #4 in 10 seconds

Dec 31 14:54:00 windu pluto[31784]: "stmarks_meditech" #6: received and
ignored informational message

Dec 31 14:54:10 windu pluto[31784]: "stmarks_tracemaster" #10:
initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE to replace #4
{using isakmp#6}

Dec 31 14:54:10 windu pluto[31784]: "stmarks_tracemaster" #10:
transition from state STATE_QUICK_I1 to state STATE_QUICK_I2

Dec 31 14:54:10 windu pluto[31784]: "stmarks_tracemaster" #10:
STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x67efcd68
<0x0ada163c xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}

Dec 31 15:11:41 windu pluto[31784]: packet from 199.91.34.69:500:
received Vendor ID payload [Cisco-Unity]

Dec 31 15:11:41 windu pluto[31784]: packet from 199.91.34.69:500:
received Vendor ID payload [XAUTH]

Dec 31 15:11:41 windu pluto[31784]: packet from 199.91.34.69:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106,
but port floating is off

Dec 31 15:11:41 windu pluto[31784]: packet from 199.91.34.69:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but
port floating is off

Dec 31 15:11:41 windu pluto[31784]: packet from 199.91.34.69:500:
ignoring Vendor ID payload [FRAGMENTATION c0000000]

Dec 31 15:11:41 windu pluto[31784]: "stmarks_pacs2" #11: protocol/port
in Phase 1 ID Payload must be 0/0 or 17/500 but are 17/0

Dec 31 15:11:41 windu pluto[31784]: "stmarks_pacs2" #11: Aggressive mode
peer ID is ID_IPV4_ADDR: '199.91.34.69'

Dec 31 15:11:41 windu pluto[31784]: "stmarks_pacs2" #11: responding to
Aggressive Mode, state #11, connection "stmarks_pacs2" from 199.91.34.69

Dec 31 15:11:41 windu pluto[31784]: "stmarks_pacs2" #11: transition from
state STATE_AGGR_R0 to state STATE_AGGR_R1

Dec 31 15:11:41 windu pluto[31784]: "stmarks_pacs2" #11: STATE_AGGR_R1:
sent AR1, expecting AI2

Dec 31 15:11:41 windu pluto[31784]: "stmarks_pacs2" #11: received Vendor
ID payload [Dead Peer Detection]

Dec 31 15:11:41 windu pluto[31784]: "stmarks_pacs2" #11: ignoring Vendor
ID payload [Cisco VPN 3000 Series]

Dec 31 15:11:41 windu pluto[31784]: "stmarks_pacs2" #11: Aggressive mode
peer ID is ID_IPV4_ADDR: '199.91.34.69'

Dec 31 15:11:41 windu pluto[31784]: "stmarks_pacs2" #11: received Hash
Payload does not match computed value

Dec 31 15:11:41 windu pluto[31784]: "stmarks_pacs2" #11: sending
encrypted notification INVALID_HASH_INFORMATION to 199.91.34.69:500

Dec 31 15:12:15 windu pluto[31784]: "stmarks_meditech" #6: received
Delete SA payload: deleting ISAKMP State #6

Dec 31 15:12:15 windu pluto[31784]: packet from 199.91.34.69:500:
received and ignored informational message

Dec 31 15:12:25 windu pluto[31784]: "stmarks_pacs2" #11: next payload
type of ISAKMP Hash Payload has an unknown value: 69

Dec 31 15:12:25 windu pluto[31784]: "stmarks_pacs2" #11: malformed
payload in packet

Dec 31 15:12:25 windu pluto[31784]: | payload malformed after IV

Dec 31 15:12:25 windu pluto[31784]: |   34 d4 62 7e  3b 74 18 03  f7 e0
4d 4b  03 49 38 0e

Dec 31 15:12:25 windu pluto[31784]: |   10 5b 6e d2

Dec 31 15:12:25 windu pluto[31784]: "stmarks_pacs2" #11: sending
notification PAYLOAD_MALFORMED to 199.91.34.69:500

Dec 31 15:12:27 windu pluto[31784]: "stmarks_pacs2" #11: next payload
type of ISAKMP Hash Payload has an unknown value: 23

Dec 31 15:12:27 windu pluto[31784]: "stmarks_pacs2" #11: malformed
payload in packet

Dec 31 15:12:27 windu pluto[31784]: | payload malformed after IV

Dec 31 15:12:27 windu pluto[31784]: |   34 d4 62 7e  3b 74 18 03  f7 e0
4d 4b  03 49 38 0e

Dec 31 15:12:27 windu pluto[31784]: |   10 5b 6e d2

Dec 31 15:12:27 windu pluto[31784]: "stmarks_pacs2" #11: sending
notification PAYLOAD_MALFORMED to 199.91.34.69:500

Dec 31 15:12:29 windu pluto[31784]: "stmarks_pacs2" #11: next payload
type of ISAKMP Hash Payload has an unknown value: 251

Dec 31 15:12:29 windu pluto[31784]: "stmarks_pacs2" #11: malformed
payload in packet

Dec 31 15:12:29 windu pluto[31784]: | payload malformed after IV

Dec 31 15:12:29 windu pluto[31784]: |   34 d4 62 7e  3b 74 18 03  f7 e0
4d 4b  03 49 38 0e

Dec 31 15:12:29 windu pluto[31784]: |   10 5b 6e d2

Dec 31 15:12:29 windu pluto[31784]: "stmarks_pacs2" #11: sending
notification PAYLOAD_MALFORMED to 199.91.34.69:500

Dec 31 15:12:31 windu pluto[31784]: "stmarks_pacs2" #11: byte 2 of
ISAKMP Hash Payload must be zero, but is not

Dec 31 15:12:31 windu pluto[31784]: "stmarks_pacs2" #11: malformed
payload in packet

Dec 31 15:12:31 windu pluto[31784]: | payload malformed after IV

Dec 31 15:12:31 windu pluto[31784]: |   34 d4 62 7e  3b 74 18 03  f7 e0
4d 4b  03 49 38 0e

Dec 31 15:12:31 windu pluto[31784]: |   10 5b 6e d2

Dec 31 15:12:31 windu pluto[31784]: "stmarks_pacs2" #11: sending
notification PAYLOAD_MALFORMED to 199.91.34.69:500

Dec 31 15:12:31 windu pluto[31784]: "stmarks_pacs2" #11: next payload
type of ISAKMP Hash Payload has an unknown value: 100

Dec 31 15:12:31 windu pluto[31784]: "stmarks_pacs2" #11: malformed
payload in packet

Dec 31 15:12:31 windu pluto[31784]: "stmarks_pacs2" #11: next payload
type of ISAKMP Hash Payload has an unknown value: 223

Dec 31 15:12:31 windu pluto[31784]: "stmarks_pacs2" #11: malformed
payload in packet

Dec 31 15:12:31 windu pluto[31784]: "stmarks_pacs2" #11: next payload
type of ISAKMP Hash Payload has an unknown value: 95

Dec 31 15:12:31 windu pluto[31784]: "stmarks_pacs2" #11: malformed
payload in packet

Dec 31 15:12:31 windu pluto[31784]: "stmarks_pacs2" #11: next payload
type of ISAKMP Hash Payload has an unknown value: 108

Dec 31 15:12:31 windu pluto[31784]: "stmarks_pacs2" #11: malformed
payload in packet

Dec 31 15:12:51 windu pluto[31784]: "stmarks_pacs2" #11: max number of
retransmissions (2) reached STATE_AGGR_R1

+ _________________________ date

+ date

Wed Dec 31 15:28:58 MST 2008

windu

Mon Jan  5 10:12:37 MST 2009

+ _________________________ version

+ ipsec --version

Linux Openswan 2.4.13 (klips)

See `ipsec --copyright' for copyright information.

+ _________________________ /proc/version

+ cat /proc/version

Linux version 2.6.19-smp (root at windu) (gcc version 4.2.3) #1 SMP Tue Dec
30 20:03:07 MST 2008

+ _________________________ /proc/net/ipsec_eroute

+ test -r /proc/net/ipsec_eroute

+ sort -sg +3 /proc/net/ipsec_eroute

+ _________________________ netstat-rn

+ netstat -nr

+ head -n 100

Kernel IP routing table

Destination     Gateway         Genmask         Flags   MSS Window  irtt
Iface

10.65.33.252    0.0.0.0         255.255.255.252 U         0 0          0
eth0

10.65.33.252    0.0.0.0         255.255.255.252 U         0 0          0
ipsec0

127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0
lo

0.0.0.0         10.65.33.254    0.0.0.0         UG        0 0          0
eth0

+ _________________________ /proc/net/ipsec_spi

+ test -r /proc/net/ipsec_spi

+ cat /proc/net/ipsec_spi

+ _________________________ /proc/net/ipsec_spigrp

+ test -r /proc/net/ipsec_spigrp

+ cat /proc/net/ipsec_spigrp

+ _________________________ /proc/net/ipsec_tncfg

+ test -r /proc/net/ipsec_tncfg

+ cat /proc/net/ipsec_tncfg

ipsec0 -> eth0 mtu=16260(1500) -> 1500

ipsec1 -> eth0 mtu=16260(1500) -> 1500

ipsec2 -> NULL mtu=0(0) -> 0

ipsec3 -> NULL mtu=0(0) -> 0

+ _________________________ /proc/net/pfkey

+ test -r /proc/net/pfkey

+ _________________________ /proc/sys/net/ipsec-star

+ test -d /proc/sys/net/ipsec

+ cd /proc/sys/net/ipsec

+ egrep '^' debug_ah debug_eroute debug_esp debug_ipcomp debug_netlink
debug_pfkey debug_radij debug_rcv debug_spi debug_tunnel debug_verbose
debug_xform icmp inbound_policy_check pfkey_lossage tos

debug_ah:0

debug_eroute:0

debug_esp:0

debug_ipcomp:0

debug_netlink:0

debug_pfkey:0

debug_radij:0

debug_rcv:0

debug_spi:0

debug_tunnel:0

debug_verbose:0

debug_xform:0

icmp:1

inbound_policy_check:1

pfkey_lossage:0

tos:1

+ _________________________ ipsec/status

+ ipsec auto --status

000 interface ipsec0/eth0 10.65.33.253

000 interface ipsec0/eth0 10.65.33.253

000 interface ipsec1/eth0:0 65.121.183.8

000 interface ipsec1/eth0:0 65.121.183.8

000 %myid = (none)

000 debug none

000  

000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=64,
keysizemin=192, keysizemax=192

000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=128,
keysizemin=128, keysizemax=256

000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5,
keysizemin=128, keysizemax=128

000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1,
keysizemin=160, keysizemax=160

000  

000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8,
keydeflen=192

000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16,
keydeflen=128

000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16

000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20

000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024

000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536

000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048

000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072

000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096

000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144

000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192

000  

000 stats db_ops.c: {curr_cnt, total_cnt, maxsz} :context={0,0,0}
trans={0,0,0} attrs={0,0,0} 

000  

000 "stmarks_meditech":
10.65.33.252/30===65.121.183.8:17/500...199.91.34.69:17/500===170.229.48
.128/26; unrouted; eroute owner: #0

000 "stmarks_meditech":     srcip=unset; dstip=unset; srcup=ipsec
_updown; dstup=ipsec _updown;

000 "stmarks_meditech":   ike_life: 3600s; ipsec_life: 28800s;
rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3

000 "stmarks_meditech":   policy: PSK+ENCRYPT+TUNNEL+AGGRESSIVE; prio:
30,26; interface: eth0:0; encap: esp;

000 "stmarks_meditech":   newest ISAKMP SA: #0; newest IPsec SA: #0; 

000 "stmarks_meditech":   IKE algorithms wanted:
3DES_CBC(5)_000-SHA1(2)-MODP1024(2); flags=strict

000 "stmarks_meditech":   IKE algorithms found:
3DES_CBC(5)_192-SHA1(2)_160-MODP1024(2)

000 "stmarks_meditech":   ESP algorithms wanted: 3DES(3)_000-SHA1(2);
flags=strict

000 "stmarks_meditech":   ESP algorithms loaded: 3DES(3)_000-SHA1(2);
flags=strict

000 "stmarks_pacs":
10.65.33.252/30===10.65.33.253:17/500...199.91.34.69:17/500===10.162.187
.18/32; unrouted; eroute owner: #0

000 "stmarks_pacs":     srcip=unset; dstip=unset; srcup=ipsec _updown;
dstup=ipsec _updown;

000 "stmarks_pacs":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin:
540s; rekey_fuzz: 100%; keyingtries: 3

000 "stmarks_pacs":   policy: PSK+ENCRYPT+TUNNEL+AGGRESSIVE; prio:
30,32; interface: eth0; encap: esp;

000 "stmarks_pacs":   newest ISAKMP SA: #0; newest IPsec SA: #0; 

000 "stmarks_pacs":   IKE algorithms wanted:
3DES_CBC(5)_000-SHA1(2)-MODP1024(2); flags=strict

000 "stmarks_pacs":   IKE algorithms found:
3DES_CBC(5)_192-SHA1(2)_160-MODP1024(2)

000 "stmarks_pacs":   ESP algorithms wanted: 3DES(3)_000-SHA1(2);
flags=strict

000 "stmarks_pacs":   ESP algorithms loaded: 3DES(3)_000-SHA1(2);
flags=strict

000 "stmarks_pacs2":
10.65.33.252/30===10.65.33.253:17/500...199.91.34.69:17/500===10.163.173
.23/32; unrouted; eroute owner: #0

000 "stmarks_pacs2":     srcip=unset; dstip=unset; srcup=ipsec _updown;
dstup=ipsec _updown;

000 "stmarks_pacs2":   ike_life: 3600s; ipsec_life: 28800s;
rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3

000 "stmarks_pacs2":   policy: PSK+ENCRYPT+TUNNEL+AGGRESSIVE; prio:
30,32; interface: eth0; encap: esp;

000 "stmarks_pacs2":   newest ISAKMP SA: #0; newest IPsec SA: #0; 

000 "stmarks_pacs2":   IKE algorithms wanted:
3DES_CBC(5)_000-SHA1(2)-MODP1024(2); flags=strict

000 "stmarks_pacs2":   IKE algorithms found:
3DES_CBC(5)_192-SHA1(2)_160-MODP1024(2)

000 "stmarks_pacs2":   ESP algorithms wanted: 3DES(3)_000-SHA1(2);
flags=strict

000 "stmarks_pacs2":   ESP algorithms loaded: 3DES(3)_000-SHA1(2);
flags=strict

000 "stmarks_tracemaster":
10.65.33.252/30===10.65.33.253:17/500...199.91.34.69:17/500===10.163.173
.6/32; unrouted; eroute owner: #0

000 "stmarks_tracemaster":     srcip=unset; dstip=unset; srcup=ipsec
_updown; dstup=ipsec _updown;

000 "stmarks_tracemaster":   ike_life: 3600s; ipsec_life: 28800s;
rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3

000 "stmarks_tracemaster":   policy: PSK+ENCRYPT+TUNNEL+AGGRESSIVE;
prio: 30,32; interface: eth0; encap: esp;

000 "stmarks_tracemaster":   newest ISAKMP SA: #0; newest IPsec SA: #0; 

000 "stmarks_tracemaster":   IKE algorithms wanted:
3DES_CBC(5)_000-SHA1(2)-MODP1024(2); flags=strict

000 "stmarks_tracemaster":   IKE algorithms found:
3DES_CBC(5)_192-SHA1(2)_160-MODP1024(2)

000 "stmarks_tracemaster":   ESP algorithms wanted: 3DES(3)_000-SHA1(2);
flags=strict

000 "stmarks_tracemaster":   ESP algorithms loaded: 3DES(3)_000-SHA1(2);
flags=strict

000  

000  

+ _________________________ ifconfig-a

+ ifconfig -a

eth0      Link encap:Ethernet  HWaddr 00:0c:29:28:42:ff  

          inet addr:10.65.33.253  Bcast:10.65.33.255
Mask:255.255.255.252

          inet6 addr: fe80::20c:29ff:fe28:42ff/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:810581 errors:0 dropped:0 overruns:0 frame:0

          TX packets:385078 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:132790699 (126.6 MiB)  TX bytes:550396908 (524.8 MiB)

          Base address:0x1070 Memory:e8820000-e8840000 

 

eth0:0    Link encap:Ethernet  HWaddr 00:0c:29:28:42:ff  

          inet addr:65.121.183.8  Bcast:255.255.255.255  Mask:0.0.0.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          Base address:0x1070 Memory:e8820000-e8840000 

 

ipsec0    Link encap:Ethernet  HWaddr 00:0c:29:28:42:ff  

          inet addr:10.65.33.253  Mask:255.255.255.252

          inet6 addr: fe80::20c:29ff:fe28:42ff/64 Scope:Link

          UP RUNNING NOARP  MTU:16260  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:3 overruns:0 carrier:0

          collisions:0 txqueuelen:10 

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

 

ipsec1    Link encap:Ethernet  HWaddr 00:0c:29:28:42:ff  

          inet addr:65.121.183.8  Mask:0.0.0.0

          inet6 addr: fe80::20c:29ff:fe28:42ff/64 Scope:Link

          UP RUNNING NOARP  MTU:16260  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:3 overruns:0 carrier:0

          collisions:0 txqueuelen:10 

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

 

ipsec2    Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  

          NOARP  MTU:0  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:10 

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

 

ipsec3    Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  

          NOARP  MTU:0  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:10 

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

 

lo        Link encap:Local Loopback  

          inet addr:127.0.0.1  Mask:255.0.0.0

          inet6 addr: ::1/128 Scope:Host

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0 

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

 

+ _________________________ ip-addr-list

+ ip addr list

1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue 

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

    inet6 ::1/128 scope host 

       valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
1000

    link/ether 00:0c:29:28:42:ff brd ff:ff:ff:ff:ff:ff

    inet 10.65.33.253/30 brd 10.65.33.255 scope global eth0

    inet 65.121.183.8/0 brd 255.255.255.255 scope global eth0:0

    inet6 fe80::20c:29ff:fe28:42ff/64 scope link 

       valid_lft forever preferred_lft forever

27: ipsec0: <NOARP,UP,10000> mtu 16260 qdisc pfifo_fast qlen 10

    link/ether 00:0c:29:28:42:ff brd ff:ff:ff:ff:ff:ff

    inet 10.65.33.253/30 brd 10.65.33.255 scope global ipsec0

    inet6 fe80::20c:29ff:fe28:42ff/64 scope link 

       valid_lft forever preferred_lft forever

28: ipsec1: <NOARP,UP,10000> mtu 16260 qdisc pfifo_fast qlen 10

    link/ether 00:0c:29:28:42:ff brd ff:ff:ff:ff:ff:ff

    inet 65.121.183.8/0 brd 255.255.255.255 scope global ipsec1

    inet6 fe80::20c:29ff:fe28:42ff/64 scope link 

       valid_lft forever preferred_lft forever

29: ipsec2: <NOARP> mtu 0 qdisc noop qlen 10

    link/void 

30: ipsec3: <NOARP> mtu 0 qdisc noop qlen 10

    link/void 

+ _________________________ ip-route-list

+ ip route list

10.65.33.252/30 dev eth0  proto kernel  scope link  src 10.65.33.253 

10.65.33.252/30 dev ipsec0  proto kernel  scope link  src 10.65.33.253 

127.0.0.0/8 dev lo  scope link 

default via 10.65.33.254 dev eth0  metric 1 

+ _________________________ ip-rule-list

+ ip rule list

0:            from all lookup local 

32766:   from all lookup main 

32767:   from all lookup default 

+ _________________________ ipsec_verify

+ ipsec verify --nocolour

Checking your system to see if IPsec got installed and started
correctly:

Version check and ipsec on-path                             [OK]

Linux Openswan 2.4.13 (klips)

Checking for IPsec support in kernel
[OK]

KLIPS detected, checking for NAT Traversal support
[OK]

Checking for RSA private key (/etc/ipsec.d/hostkey.secrets)       [OK]

Checking that pluto is running                                    [OK]

Checking for 'ip' command                                           [OK]

Checking for 'iptables' command                             [OK]

 

Opportunistic Encryption DNS checks:

   Looking for TXT in forward dns zone: windu
[MISSING]

   Does the machine have at least one non-private address?        [OK]

   Looking for TXT in reverse dns zone: 8.183.121.65.in-addr.arpa.
[MISSING]

+ _________________________ mii-tool

+ '[' -x /sbin/mii-tool ']'

+ /sbin/mii-tool -v

eth0: negotiated 1000baseT-FD flow-control, link ok

  product info: Yukon 88E1011 rev 3

  basic mode:   autonegotiation enabled

  basic status: autonegotiation complete, link ok

  capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD
10baseT-HD

  advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD

  link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD
10baseT-HD

+ _________________________ ipsec/directory

+ ipsec --directory

/usr/local/lib/ipsec

+ _________________________ hostname/fqdn

+ hostname --fqdn

windu.heartslc.com

+ _________________________ hostname/ipaddress

+ hostname --ip-address

10.65.33.253 

+ _________________________ uptime

+ uptime

 10:12:39 up 2 days, 19:55,  1 user,  load average: 2.49, 2.07, 1.97

+ _________________________ ps

+ ps alxwf

+ egrep -i 'ppid|pluto|ipsec|klips'

F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME
COMMAND

0     0  2133 28099  17   0   2768  1380 -      R+   pts/0      0:00
\_ /bin/sh /usr/local/libexec/ipsec/barf

1     0   346     1  25   0   2344   432 wait   S    pts/0      0:00
/bin/sh /usr/local/lib/ipsec/_plutorun --debug  --uniqueids yes
--nocrsend  --strictcrlpolicy  --nat_traversal yes --keep_alive
--protostack auto --force_keepalive  --disable_port_floating
--virtual_private  --crlcheckinterval 0 --ocspuri  --nhelpers  --dump
--opts  --stderrlog  --wait no --pre  --post  --log daemon.error --pid
/var/run/pluto/pluto.pid

1     0   347   346  23   0   2344   608 wait   S    pts/0      0:00  \_
/bin/sh /usr/local/lib/ipsec/_plutorun --debug  --uniqueids yes
--nocrsend  --strictcrlpolicy  --nat_traversal yes --keep_alive
--protostack auto --force_keepalive  --disable_port_floating
--virtual_private  --crlcheckinterval 0 --ocspuri  --nhelpers  --dump
--opts  --stderrlog  --wait no --pre  --post  --log daemon.error --pid
/var/run/pluto/pluto.pid

4     0   348   347  15   0   2660  1156 -      S    pts/0      0:00  |
\_ /usr/local/libexec/ipsec/pluto --nofork --secretsfile
/etc/ipsec.secrets --ipsecdir /etc/ipsec.d --use-auto --uniqueids
--nat_traversal

1     0   385   348  35  10   2660   416 -      SN   pts/0      0:00  |
\_ pluto helper  #  0


0     0   395   348  25   0   1632   304 429496 S    pts/0      0:00  |
\_ _pluto_adns

0     0   349   346  18   0   2316  1060 pipe_w S    pts/0      0:00  \_
/bin/sh /usr/local/lib/ipsec/_plutoload --wait no --post 

0     0   350     1  18   0   1696   528 pipe_w S    pts/0      0:00
logger -s -p daemon.error -t ipsec__plutorun

+ _________________________ ipsec/showdefaults

+ ipsec showdefaults

# no default route

# no default route

+ _________________________ ipsec/conf

+ ipsec _include /etc/ipsec.conf

+ ipsec _keycensor

 

#< /etc/ipsec.conf 1

# /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

                forwardcontrol=yes

                interfaces="ipsec0=eth0 ipsec1=eth0:0"

                nat_traversal=yes

                plutowait=no

                uniqueids=yes

 

conn stmarks_meditech

                aggrmode=yes

                auth=esp

                authby=secret

                auto=add

                compress=no

                esp=3des-sha1

                ike=3des-sha1-modp1024

                keyexchange=ike

                keyingtries=3

                left=65.121.183.8

                leftsubnet=10.65.33.252/30

                pfs=no

                right=199.91.34.69

                rightsubnet=170.229.48.128/26

                type=tunnel

                leftprotoport=17/500

                rightprotoport=17/500

 

conn stmarks_pacs

                aggrmode=yes

                leftprotoport=17/500

                rightprotoport=17/500

                auth=esp

                authby=secret

                auto=add

                compress=no

                esp=3des-sha1

                ike=3des-sha1-modp1024

                keyexchange=ike

                keyingtries=3

                left=10.65.33.253

                leftsubnet=10.65.33.252/30

                pfs=no

                right=199.91.34.69

                rightsubnet=10.162.187.18/32

                type=tunnel

 

conn stmarks_tracemaster

                aggrmode=yes

                auth=esp

                authby=secret

                auto=add

                compress=no

                esp=3des-sha1

                ike=3des-sha1-modp1024

                keyexchange=ike

                keyingtries=3

                left=10.65.33.253

                leftsubnet=10.65.33.252/30

                pfs=no

                right=199.91.34.69

                rightsubnet=10.163.173.6/32

                type=tunnel

                leftprotoport=17/500

                rightprotoport=17/500

 

conn stmarks_pacs2

                aggrmode=yes

                auth=esp

                authby=secret

                auto=add

                compress=no

                esp=3des-sha1

                ike=3des-sha1-modp1024

                keyexchange=ike

                keyingtries=3

                left=10.65.33.253

                leftsubnet=10.65.33.252/30

                pfs=no

                right=199.91.34.69

                rightsubnet=10.163.173.23/32

                type=tunnel

                leftprotoport=17/500

                rightprotoport=17/500

+ _________________________ ipsec/secrets

+ ipsec _include /etc/ipsec.secrets

+ ipsec _secretcensor

 

#< /etc/ipsec.secrets 1

: RSA      {

                # RSA 2192 bits   windu   Tue Nov 25 18:56:50 2008

                # for signatures only, UNSAFE FOR ENCRYPTION

                #pubkey=[keyid AQNmyHZSA]

                Modulus: [...]

                PublicExponent: [...]

                # everything after this point is secret

                PrivateExponent: [...]

                Prime1: [...]

                Prime2: [...]

                Exponent1: [...]

                Exponent2: [...]

                Coefficient: [...]

                }

# do not change the indenting of that "[sums to 7d9d...]"

: PSK "[sums to 92d6...]"

+ _________________________ ipsec/listall

+ ipsec auto --listall

000  

000 List of Public Keys:

000  

+ '[' /etc/ipsec.d/policies ']'

+ for policy in '$POLICIES/*'

++ basename /etc/ipsec.d/policies/block

+ base=block

+ _________________________ ipsec/policies/block

+ cat /etc/ipsec.d/policies/block

# This file defines the set of CIDRs (network/mask-length) to which

# communication should never be allowed.

#

# See /usr/local/share/doc/openswan/policygroups.html for details.

#

# $Id: block.in,v 1.4 2003-02-17 02:22:15 mcr Exp $

#

 

+ for policy in '$POLICIES/*'

++ basename /etc/ipsec.d/policies/clear

+ base=clear

+ _________________________ ipsec/policies/clear

+ cat /etc/ipsec.d/policies/clear

# This file defines the set of CIDRs (network/mask-length) to which

# communication should always be in the clear.

#

# See /usr/local/share/doc/openswan/policygroups.html for details.

#

# $Id: clear.in,v 1.4.30.3 2006-11-21 19:49:51 paul Exp $

#

#

#             Michael's idea: Always have ROOT NAMESERVERS in the clear.

#             It will make OE work much better on machines running
caching

#             resolvers.

#

#             Based on: http://www.internic.net/zones/named.root

#       This file holds the information on root name servers needed to

#       last update:    Jan 29, 2004

#       related version of root zone:   2004012900

0.0.0.0/0

+ for policy in '$POLICIES/*'

++ basename /etc/ipsec.d/policies/clear-or-private

+ base=clear-or-private

+ _________________________ ipsec/policies/clear-or-private

+ cat /etc/ipsec.d/policies/clear-or-private

# This file defines the set of CIDRs (network/mask-length) to which

# we will communicate in the clear, or, if the other side initiates
IPSEC,

# using encryption.  This behaviour is also called "Opportunistic
Responder".

#

# See /usr/local/share/doc/openswan/policygroups.html for details.

#

# $Id: clear-or-private.in,v 1.4 2003-02-17 02:22:15 mcr Exp $

#

0.0.0.0/0

+ for policy in '$POLICIES/*'

++ basename /etc/ipsec.d/policies/private

+ base=private

+ _________________________ ipsec/policies/private

+ cat /etc/ipsec.d/policies/private

# This file defines the set of CIDRs (network/mask-length) to which

# communication should always be private (i.e. encrypted).

# See /usr/local/share/doc/openswan/policygroups.html for details.

#

# $Id: private.in,v 1.4 2003-02-17 02:22:15 mcr Exp $

#

0.0.0.0/0

+ for policy in '$POLICIES/*'

++ basename /etc/ipsec.d/policies/private-or-clear

+ base=private-or-clear

+ _________________________ ipsec/policies/private-or-clear

+ cat /etc/ipsec.d/policies/private-or-clear

# This file defines the set of CIDRs (network/mask-length) to which

# communication should be private, if possible, but in the clear
otherwise.

#

# If the target has a TXT (later IPSECKEY) record that specifies

# authentication material, we will require private (i.e. encrypted)

# communications.  If no such record is found, communications will be

# in the clear.

#

# See /usr/local/share/doc/openswan/policygroups.html for details.

#

# $Id: private-or-clear.in,v 1.5 2003-02-17 02:22:15 mcr Exp $

#

 

0.0.0.0/0

+ _________________________ ipsec/ls-libdir

+ ls -l /usr/local/lib/ipsec

total 116

-rwxr-xr-x 1 root root 15848 Dec 31 09:33 _confread

-rwxr-xr-x 1 root root 14289 Dec 31 09:33 _copyright

-rwxr-xr-x 1 root root  2379 Dec 31 09:33 _include

-rwxr-xr-x 1 root root  1475 Dec 31 09:33 _keycensor

-rwxr-xr-x 1 root root  3648 Dec 31 09:33 _plutoload

-rwxr-xr-x 1 root root  8069 Dec 31 09:33 _plutorun

-rwxr-xr-x 1 root root 12324 Dec 31 09:33 _realsetup

-rwxr-xr-x 1 root root  1975 Dec 31 09:33 _secretcensor

-rwxr-xr-x 1 root root 11102 Dec 31 09:33 _startklips

-rwxr-xr-x 1 root root 13918 Dec 31 09:33 _updown

-rwxr-xr-x 1 root root 15746 Dec 31 09:33 _updown_x509

+ _________________________ ipsec/ls-execdir

+ ls -l /usr/local/libexec/ipsec

total 4548

-rwxr-xr-x 1 root root   28489 Dec 31 09:32 _pluto_adns

-rwxr-xr-x 1 root root  375943 May 12  2008 addconn.old

-rwxr-xr-x 1 root root   18891 Dec 31 09:33 auto

-rwxr-xr-x 1 root root   11367 Dec 31 09:33 barf

-rwxr-xr-x 1 root root     816 Dec 31 09:33 calcgoo

-rwxr-xr-x 1 root root  199893 Dec 31 09:32 eroute

-rwxr-xr-x 1 root root   65085 Dec 31 09:33 ikeping

-rwxr-xr-x 1 root root  129819 Dec 31 09:32 klipsdebug

-rwxr-xr-x 1 root root    1836 Dec 31 09:33 livetest

-rwxr-xr-x 1 root root    2604 Dec 31 09:33 look

-rwxr-xr-x 1 root root  839794 May 12  2008 lwdnsq.old

-rwxr-xr-x 1 root root    7094 Dec 31 09:33 mailkey

-rwxr-xr-x 1 root root   16015 Dec 31 09:33 manual

-rwxr-xr-x 1 root root    1951 Dec 31 09:33 newhostkey

-rwxr-xr-x 1 root root  115216 Dec 31 09:32 pf_key

-rwxr-xr-x 1 root root 1914326 Dec 31 09:32 pluto

-rwxr-xr-x 1 root root   21174 Dec 31 09:33 ranbits

-rwxr-xr-x 1 root root   50625 Dec 31 09:33 rsasigkey

-rwxr-xr-x 1 root root     766 Dec 31 09:33 secrets

lrwxrwxrwx 1 root root      22 Dec 31 09:33 setup ->
/etc/rc.d/init.d/ipsec

-rwxr-xr-x 1 root root    1054 Dec 31 09:33 showdefaults

-rwxr-xr-x 1 root root    4845 Dec 31 09:33 showhostkey

-rwxr-xr-x 1 root root   60365 May 12  2008 showpolicy.old

-rwxr-xr-x 1 root root  325143 Dec 31 09:32 spi

-rwxr-xr-x 1 root root  164884 Dec 31 09:32 spigrp

-rwxr-xr-x 1 root root   24248 Dec 31 09:32 tncfg

-rwxr-xr-x 1 root root   13530 Dec 31 09:33 verify

-rwxr-xr-x 1 root root  159092 Dec 31 09:32 whack

+ _________________________ ipsec/updowns

++ ls /usr/local/libexec/ipsec

++ egrep updown

+ _________________________ /proc/net/dev

+ cat /proc/net/dev

Inter-|   Receive                                                |
Transmit

 face |bytes    packets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed

    lo:       0       0    0    0    0     0          0         0
0       0    0    0    0     0       0          0

  eth0:132793090  810603    0    0    0     0          0         0
550397446  385084    0    0    0     0       0          0

ipsec0:       0       0    0    0    0     0          0         0
0       0    0    3    0     0       0          0

ipsec1:       0       0    0    0    0     0          0         0
0       0    0    3    0     0       0          0

ipsec2:       0       0    0    0    0     0          0         0
0       0    0    0    0     0       0          0

ipsec3:       0       0    0    0    0     0          0         0
0       0    0    0    0     0       0          0

+ _________________________ /proc/net/route

+ cat /proc/net/route

Iface      Destination         Gateway              Flags      RefCnt
Use        Metric   Mask                     MTU      Window
IRTT                                                       

eth0       FC21410A            00000000             0001       0
0              0              FCFFFFFF             0              0
0


ipsec0   FC21410A            00000000             0001       0
0              0              FCFFFFFF             0              0
0


lo            0000007F             00000000             0001       0
0              0              000000FF             0              0
0


eth0       00000000             FE21410A             0003       0
0              1              00000000             0              0
0


+ _________________________ /proc/sys/net/ipv4/ip_forward

+ cat /proc/sys/net/ipv4/ip_forward

1

+ _________________________ /proc/sys/net/ipv4/tcp_ecn

+ cat /proc/sys/net/ipv4/tcp_ecn

0

+ _________________________ /proc/sys/net/ipv4/conf/star-rp_filter

+ cd /proc/sys/net/ipv4/conf

+ egrep '^' all/rp_filter default/rp_filter eth0/rp_filter
ipsec0/rp_filter ipsec1/rp_filter lo/rp_filter

all/rp_filter:0

default/rp_filter:0

eth0/rp_filter:0

ipsec0/rp_filter:0

ipsec1/rp_filter:0

lo/rp_filter:0

+ _________________________ /proc/sys/net/ipv4/conf/star-rp_filter

+ cd /proc/sys/net/ipv4/conf

+ egrep '^' all/rp_filter default/rp_filter eth0/rp_filter
ipsec0/rp_filter ipsec1/rp_filter lo/rp_filter

all/rp_filter:0

default/rp_filter:0

eth0/rp_filter:0

ipsec0/rp_filter:0

ipsec1/rp_filter:0

lo/rp_filter:0

+ _________________________ /proc/sys/net/ipv4/conf/star-star-redirects

+ cd /proc/sys/net/ipv4/conf

+ egrep '^' all/accept_redirects all/secure_redirects all/send_redirects
default/accept_redirects default/secure_redirects default/send_redirects
eth0/accept_redirects eth0/secure_redirects eth0/send_redirects
ipsec0/accept_redirects ipsec0/secure_redirects ipsec0/send_redirects
ipsec1/accept_redirects ipsec1/secure_redirects ipsec1/send_redirects
lo/accept_redirects lo/secure_redirects lo/send_redirects

all/accept_redirects:0

all/secure_redirects:1

all/send_redirects:0

default/accept_redirects:0

default/secure_redirects:1

default/send_redirects:0

eth0/accept_redirects:0

eth0/secure_redirects:1

eth0/send_redirects:0

ipsec0/accept_redirects:0

ipsec0/secure_redirects:1

ipsec0/send_redirects:0

ipsec1/accept_redirects:0

ipsec1/secure_redirects:1

ipsec1/send_redirects:0

lo/accept_redirects:1

lo/secure_redirects:1

lo/send_redirects:1

+ _________________________ /proc/sys/net/ipv4/tcp_window_scaling

+ cat /proc/sys/net/ipv4/tcp_window_scaling

1

+ _________________________ /proc/sys/net/ipv4/tcp_adv_win_scale

+ cat /proc/sys/net/ipv4/tcp_adv_win_scale

2

+ _________________________ uname-a

+ uname -a

Linux windu 2.6.19-smp #1 SMP Tue Dec 30 20:03:07 MST 2008 i686 Intel(R)
Xeon(R) CPU           E5335  @ 2.00GHz GenuineIntel GNU/Linux

+ _________________________ config-built-with

+ test -r /proc/config_built_with

+ _________________________ distro-release

+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release

+ test -f /etc/redhat-release

+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release

+ test -f /etc/debian-release

+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release

+ test -f /etc/SuSE-release

+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release

+ test -f /etc/mandrake-release

+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release

+ test -f /etc/mandriva-release

+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release

+ test -f /etc/gentoo-release

+ _________________________ /proc/net/ipsec_version

+ test -r /proc/net/ipsec_version

+ cat /proc/net/ipsec_version

Openswan version: 2.4.13

+ _________________________ ipfwadm

+ test -r /sbin/ipfwadm

+ 'no old-style linux 1.x/2.0 ipfwadm firewall support'

/usr/local/libexec/ipsec/barf: line 305: no old-style linux 1.x/2.0
ipfwadm firewall support: No such file or directory

+ _________________________ ipchains

+ test -r /sbin/ipchains

+ echo 'no old-style linux 2.0 ipchains firewall support'

no old-style linux 2.0 ipchains firewall support

+ _________________________ iptables

+ test -r /sbin/iptables

+ test -r /sbin/ipchains

+ _________________________ /proc/modules

+ test -f /proc/modules

+ cat /proc/modules

ipsec 351724 2 - Live 0xf90dd000

iptable_filter 6400 0 - Live 0xf8e93000

iptable_mangle 6144 0 - Live 0xf8cfd000

ip_tables 15172 2 iptable_filter,iptable_mangle, Live 0xf8fe4000

x_tables 15492 1 ip_tables, Live 0xf8fdf000

ipv6 241184 10 - Live 0xf903b000

pcmcia 33836 0 - Live 0xf8fea000

rsrc_nonstatic 14720 0 - Live 0xf8e8e000

pcmcia_core 36500 2 pcmcia,rsrc_nonstatic, Live 0xf8ed6000

tun 12032 0 - Live 0xf8cdc000

lp 13480 0 - Live 0xf8cc1000

parport_pc 27300 1 - Live 0xf8ece000

parport 34760 2 lp,parport_pc, Live 0xf8ec4000

fuse 41876 1 - Live 0xf8e96000

serio_raw 9220 0 - Live 0xf8ce0000

intel_agp 24348 1 - Live 0xf8e81000

e1000 118976 0 - Live 0xf8ea5000

agpgart 29256 1 intel_agp, Live 0xf8cf4000

psmouse 38280 0 - Live 0xf8ce9000

pcspkr 6528 0 - Live 0xf8cd9000

i2c_piix4 11148 0 - Live 0xf8cd5000

evdev 11904 1 - Live 0xf8cc6000

sg 30108 0 - Live 0xf8ccc000

+ _________________________ /proc/meminfo

+ cat /proc/meminfo

MemTotal:      1031624 kB

MemFree:         62884 kB

Buffers:        263800 kB

Cached:         644056 kB

SwapCached:          0 kB

Active:         340152 kB

Inactive:       578588 kB

HighTotal:      131008 kB

HighFree:          512 kB

LowTotal:       900616 kB

LowFree:         62372 kB

SwapTotal:     1542232 kB

SwapFree:      1542232 kB

Dirty:             508 kB

Writeback:           0 kB

AnonPages:       10920 kB

Mapped:           7200 kB

Slab:            39420 kB

SReclaimable:    28696 kB

SUnreclaim:      10724 kB

PageTables:        500 kB

NFS_Unstable:        0 kB

Bounce:              0 kB

CommitLimit:   2058044 kB

Committed_AS:    48792 kB

VmallocTotal:   114680 kB

VmallocUsed:      8660 kB

VmallocChunk:   105256 kB

+ _________________________ /proc/net/ipsec-ls

+ test -f /proc/net/ipsec_version

+ ls -l /proc/net/ipsec_eroute /proc/net/ipsec_klipsdebug
/proc/net/ipsec_spi /proc/net/ipsec_spigrp /proc/net/ipsec_tncfg
/proc/net/ipsec_version

lrwxrwxrwx 1 root root 16 Jan  5 10:12 /proc/net/ipsec_eroute ->
ipsec/eroute/all

lrwxrwxrwx 1 root root 16 Jan  5 10:12 /proc/net/ipsec_klipsdebug ->
ipsec/klipsdebug

lrwxrwxrwx 1 root root 13 Jan  5 10:12 /proc/net/ipsec_spi ->
ipsec/spi/all

lrwxrwxrwx 1 root root 16 Jan  5 10:12 /proc/net/ipsec_spigrp ->
ipsec/spigrp/all

lrwxrwxrwx 1 root root 11 Jan  5 10:12 /proc/net/ipsec_tncfg ->
ipsec/tncfg

lrwxrwxrwx 1 root root 13 Jan  5 10:12 /proc/net/ipsec_version ->
ipsec/version

+ _________________________ usr/src/linux/.config

+ test -f /proc/config.gz

+ zcat /proc/config.gz

+ egrep
'CONFIG_IPSEC|CONFIG_KLIPS|CONFIG_NET_KEY|CONFIG_INET|CONFIG_IP|CONFIG_H
W_RANDOM|CONFIG_CRYPTO_DEV|_XFRM'

# CONFIG_IPC_NS is not set

CONFIG_XFRM=y

CONFIG_XFRM_USER=y

CONFIG_NET_KEY=m

CONFIG_INET=y

CONFIG_IP_MULTICAST=y

CONFIG_IP_ADVANCED_ROUTER=y

# CONFIG_IP_FIB_TRIE is not set

CONFIG_IP_FIB_HASH=y

CONFIG_IP_MULTIPLE_TABLES=y

# CONFIG_IP_ROUTE_FWMARK is not set

CONFIG_IP_ROUTE_MULTIPATH=y

# CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set

CONFIG_IP_ROUTE_VERBOSE=y

# CONFIG_IP_PNP is not set

CONFIG_IP_MROUTE=y

CONFIG_IP_PIMSM_V1=y

CONFIG_IP_PIMSM_V2=y

CONFIG_IPSEC_NAT_TRAVERSAL=y

CONFIG_INET_AH=m

CONFIG_INET_ESP=m

CONFIG_INET_IPCOMP=m

CONFIG_INET_XFRM_TUNNEL=m

CONFIG_INET_TUNNEL=m

CONFIG_INET_XFRM_MODE_TRANSPORT=m

CONFIG_INET_XFRM_MODE_TUNNEL=m

CONFIG_INET_XFRM_MODE_BEET=m

CONFIG_INET_DIAG=m

CONFIG_INET_TCP_DIAG=m

CONFIG_IP_VS=m

# CONFIG_IP_VS_DEBUG is not set

CONFIG_IP_VS_TAB_BITS=12

CONFIG_IP_VS_PROTO_TCP=y

CONFIG_IP_VS_PROTO_UDP=y

CONFIG_IP_VS_PROTO_ESP=y

CONFIG_IP_VS_PROTO_AH=y

CONFIG_IP_VS_RR=m

CONFIG_IP_VS_WRR=m

CONFIG_IP_VS_LC=m

CONFIG_IP_VS_WLC=m

CONFIG_IP_VS_LBLC=m

CONFIG_IP_VS_LBLCR=m

CONFIG_IP_VS_DH=m

CONFIG_IP_VS_SH=m

CONFIG_IP_VS_SED=m

CONFIG_IP_VS_NQ=m

CONFIG_IP_VS_FTP=m

CONFIG_IPV6=m

CONFIG_IPV6_PRIVACY=y

# CONFIG_IPV6_ROUTER_PREF is not set

CONFIG_INET6_AH=m

CONFIG_INET6_ESP=m

CONFIG_INET6_IPCOMP=m

CONFIG_INET6_XFRM_TUNNEL=m

CONFIG_INET6_TUNNEL=m

CONFIG_INET6_XFRM_MODE_TRANSPORT=m

CONFIG_INET6_XFRM_MODE_TUNNEL=m

CONFIG_INET6_XFRM_MODE_BEET=m

CONFIG_IPV6_SIT=m

CONFIG_IPV6_TUNNEL=m

# CONFIG_IP_NF_CONNTRACK is not set

CONFIG_IP_NF_QUEUE=m

CONFIG_IP_NF_IPTABLES=m

CONFIG_IP_NF_MATCH_IPRANGE=m

CONFIG_IP_NF_MATCH_TOS=m

CONFIG_IP_NF_MATCH_RECENT=m

CONFIG_IP_NF_MATCH_ECN=m

CONFIG_IP_NF_MATCH_AH=m

CONFIG_IP_NF_MATCH_TTL=m

CONFIG_IP_NF_MATCH_OWNER=m

CONFIG_IP_NF_MATCH_ADDRTYPE=m

# CONFIG_IP_NF_MATCH_HASHLIMIT is not set

CONFIG_IP_NF_FILTER=m

CONFIG_IP_NF_TARGET_REJECT=m

CONFIG_IP_NF_TARGET_LOG=m

CONFIG_IP_NF_TARGET_ULOG=m

# CONFIG_IP_NF_TARGET_TCPMSS is not set

CONFIG_IP_NF_MANGLE=m

CONFIG_IP_NF_TARGET_TOS=m

CONFIG_IP_NF_TARGET_ECN=m

CONFIG_IP_NF_TARGET_TTL=m

CONFIG_IP_NF_RAW=m

CONFIG_IP_NF_ARPTABLES=m

CONFIG_IP_NF_ARPFILTER=m

CONFIG_IP_NF_ARP_MANGLE=m

CONFIG_IPX=m

# CONFIG_IPX_INTERN is not set

CONFIG_IPDDP=m

CONFIG_IPDDP_ENCAP=y

CONFIG_IPDDP_DECAP=y

CONFIG_IPPP_FILTER=y

CONFIG_IPMI_HANDLER=m

# CONFIG_IPMI_PANIC_EVENT is not set

CONFIG_IPMI_DEVICE_INTERFACE=m

CONFIG_IPMI_SI=m

CONFIG_IPMI_WATCHDOG=m

CONFIG_IPMI_POWEROFF=m

CONFIG_HW_RANDOM=y

CONFIG_HW_RANDOM_INTEL=m

CONFIG_HW_RANDOM_AMD=m

CONFIG_HW_RANDOM_GEODE=m

CONFIG_HW_RANDOM_VIA=m

CONFIG_SECURITY_NETWORK_XFRM=y

CONFIG_CRYPTO_DEV_PADLOCK=m

CONFIG_CRYPTO_DEV_PADLOCK_AES=m

CONFIG_CRYPTO_DEV_PADLOCK_SHA=m

+ _________________________ etc/syslog.conf

+ cat /etc/syslog.conf

# /etc/syslog.conf

# For info about the format of this file, see "man syslog.conf"

# and /usr/doc/sysklogd/README.linux.  Note the '-' prefixing some

# of these entries;  this omits syncing the file after every logging.

# In the event of a crash, some log information might be lost, so

# if this is a concern to you then you might want to remove the '-'.

# Be advised this will cause a performation loss if you're using

# programs that do heavy logging.

 

# Uncomment this to see kernel messages on the console.

#kern.*
/dev/console

 

# Log anything 'info' or higher, but lower than 'warn'.

# Exclude authpriv, cron, mail, and news.  These are logged elsewhere.

*.info;*.!warn;\

                authpriv.none;cron.none;mail.none;news.none
-/var/log/messages

 

# Log anything 'warn' or higher.

# Exclude authpriv, cron, mail, and news.  These are logged elsewhere.

*.warn;\

                authpriv.none;cron.none;mail.none;news.none
-/var/log/syslog

 

# Debugging information is logged here.

*.=debug
-/var/log/debug

 

# Private authentication message logging:

authpriv.*
-/var/log/secure

 

# Cron related logs:

cron.*
-/var/log/cron

 

# Mail related logs:

mail.*
-/var/log/maillog

 

# Emergency level messages go to all users:

*.emerg
*

 

# This log is for news and uucp errors:

uucp,news.crit
-/var/log/spooler

 

# Uncomment these if you'd like INN to keep logs on everything.

# You won't need this if you don't run INN (the InterNetNews daemon).

#news.=crit
-/var/log/news/news.crit

#news.=err
-/var/log/news/news.err

#news.notice
-/var/log/news/news.notice

 

+ _________________________ etc/syslog-ng/syslog-ng.conf

+ cat /etc/syslog-ng/syslog-ng.conf

cat: /etc/syslog-ng/syslog-ng.conf: No such file or directory

+ _________________________ etc/resolv.conf

+ cat /etc/resolv.conf

search heartslc.com

nameserver 10.30.0.19

+ _________________________ lib/modules-ls

+ ls -ltr /lib/modules

total 16

drwxr-xr-x 3 root root 4096 Apr 30  2008 2.6.24.5

drwxr-xr-x 3 root root 4096 May 11  2008 2.6.24.5-smp

drwxr-xr-x 3 root root 4096 Dec 31 09:37 2.6.19.7-smp

drwxr-xr-x 3 root root 4096 Dec 31 09:40 2.6.19-smp

+ _________________________ /proc/ksyms-netif_rx

+ test -r /proc/ksyms

+ test -r /proc/kallsyms

+ egrep netif_rx /proc/kallsyms

c05b3420 T __netif_rx_schedule

c05b4920 T netif_rx

c05b5e10 T netif_rx_ni

c05b4920 U netif_rx        [ipsec]

c05b4920 U netif_rx        [ipv6]

c05b5e10 U netif_rx_ni [tun]

c05b3420 U __netif_rx_schedule             [e1000]

+ _________________________ lib/modules-netif_rx

+ modulegoo kernel/net/ipv4/ipip.o netif_rx

+ set +x

2.6.19-smp: 

2.6.19.7-smp: 

2.6.24.5: 

2.6.24.5-smp: 

+ _________________________ kern.debug

+ test -f /var/log/kern.debug

+ _________________________ klog

+ sed -n '18,$p' /var/log/syslog

+ egrep -i 'ipsec|klips|pluto'

+ case "$1" in

+ cat

Jan  5 10:12:30 windu ipsec_setup: Starting Openswan IPsec 2.4.13...

Jan  5 10:12:31 windu ipsec__plutorun: ipsec_auto: fatal error in
"packetdefault": %defaultroute requested but not known

Jan  5 10:12:32 windu ipsec__plutorun: ipsec_auto: fatal error in
"block": %defaultroute requested but not known

Jan  5 10:12:33 windu ipsec__plutorun: ipsec_auto: fatal error in
"clear-or-private": %defaultroute requested but not known

Jan  5 10:12:33 windu ipsec__plutorun: ipsec_auto: fatal error in
"clear": %defaultroute requested but not known

Jan  5 10:12:33 windu ipsec__plutorun: ipsec_auto: fatal error in
"private-or-clear": %defaultroute requested but not known

Jan  5 10:12:33 windu ipsec__plutorun: ipsec_auto: fatal error in
"private": %defaultroute requested but not known

Jan  5 10:12:34 windu ipsec__plutorun: 021 no connection named
"packetdefault"

Jan  5 10:12:34 windu ipsec__plutorun: ...could not route conn
"packetdefault"

Jan  5 10:12:34 windu ipsec__plutorun: 021 no connection named "block"

Jan  5 10:12:34 windu ipsec__plutorun: ...could not route conn "block"

Jan  5 10:12:34 windu ipsec__plutorun: 021 no connection named
"clear-or-private"

Jan  5 10:12:34 windu ipsec__plutorun: ...could not route conn
"clear-or-private"

Jan  5 10:12:34 windu ipsec__plutorun: 021 no connection named "clear"

Jan  5 10:12:34 windu ipsec__plutorun: ...could not route conn "clear"

Jan  5 10:12:34 windu ipsec__plutorun: 021 no connection named
"private-or-clear"

Jan  5 10:12:34 windu ipsec__plutorun: ...could not route conn
"private-or-clear"

Jan  5 10:12:34 windu ipsec__plutorun: 021 no connection named "private"

Jan  5 10:12:34 windu ipsec__plutorun: ...could not route conn "private"

+ _________________________ plog

+ sed -n '11,$p' /var/log/secure

+ egrep -i pluto

+ case "$1" in

+ cat

Jan  5 10:12:29 windu ipsec__plutorun: Starting Pluto subsystem...

Jan  5 10:12:30 windu pluto[348]: Starting Pluto (Openswan Version
2.4.13 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR; Vendor ID OE`fijAufQMD)

Jan  5 10:12:30 windu pluto[348]: Setting NAT-Traversal port-4500
floating to on

Jan  5 10:12:30 windu pluto[348]:    port floating activation criteria
nat_t=1/port_fload=1

Jan  5 10:12:30 windu pluto[348]:   including NAT-Traversal patch
(Version 0.6c)

Jan  5 10:12:30 windu pluto[348]: ike_alg_register_enc(): Activating
OAKLEY_AES_CBC: Ok (ret=0)

Jan  5 10:12:30 windu pluto[348]: starting up 1 cryptographic helpers

Jan  5 10:12:30 windu pluto[348]: started helper pid=385 (fd:6)

Jan  5 10:12:30 windu pluto[348]: Using KLIPS IPsec interface code on
2.6.19-smp

Jan  5 10:12:30 windu pluto[348]: Changing to directory
'/etc/ipsec.d/cacerts'

Jan  5 10:12:30 windu pluto[348]: Changing to directory
'/etc/ipsec.d/aacerts'

Jan  5 10:12:30 windu pluto[348]: Changing to directory
'/etc/ipsec.d/ocspcerts'

Jan  5 10:12:30 windu pluto[348]: Changing to directory
'/etc/ipsec.d/crls'

Jan  5 10:12:30 windu pluto[348]:   Warning: empty directory

Jan  5 10:12:31 windu pluto[348]: added connection description
"stmarks_pacs2"

Jan  5 10:12:32 windu pluto[348]: added connection description
"stmarks_meditech"

Jan  5 10:12:32 windu pluto[348]: added connection description
"stmarks_pacs"

Jan  5 10:12:32 windu pluto[348]: added connection description
"stmarks_tracemaster"

Jan  5 10:12:33 windu pluto[348]: listening for IKE messages

Jan  5 10:12:33 windu pluto[348]: adding interface ipsec1/eth0:0
65.121.183.8:500

Jan  5 10:12:33 windu pluto[348]: adding interface ipsec1/eth0:0
65.121.183.8:4500

Jan  5 10:12:33 windu pluto[348]: adding interface ipsec0/eth0
10.65.33.253:500

Jan  5 10:12:33 windu pluto[348]: adding interface ipsec0/eth0
10.65.33.253:4500

Jan  5 10:12:33 windu pluto[348]: loading secrets from
"/etc/ipsec.secrets"

+ _________________________ date

+ date

Mon Jan  5 10:12:42 MST 2009

windu

Mon Jan  5 12:46:30 MST 2009

+ _________________________ version

+ ipsec --version

Linux Openswan 2.4.13 (klips)

See `ipsec --copyright' for copyright information.

+ _________________________ /proc/version

+ cat /proc/version

Linux version 2.6.19-smp (root at windu) (gcc version 4.2.3) #1 SMP Tue Dec
30 20:03:07 MST 2008

+ _________________________ /proc/net/ipsec_eroute

+ test -r /proc/net/ipsec_eroute

+ sort -sg +3 /proc/net/ipsec_eroute

22         10.65.33.252/30    -> 10.162.187.18/32   =>
tun0x100a at 199.91.34.69

117        10.65.33.252/30    -> 10.163.173.6/32    =>
tun0x100c at 199.91.34.69

0          10.65.33.252/30    -> 10.163.173.23/32   =>
tun0x100e at 199.91.34.69

271        10.65.33.252/30    -> 170.229.48.128/26  =>
tun0x1002 at 199.91.34.69

+ _________________________ netstat-rn

+ netstat -nr

+ head -n 100

Kernel IP routing table

Destination     Gateway         Genmask         Flags   MSS Window  irtt
Iface

10.163.173.23   0.0.0.0         255.255.255.255 UH        0 0          0
ipsec0

10.163.173.6    0.0.0.0         255.255.255.255 UH        0 0          0
ipsec0

10.162.187.18   0.0.0.0         255.255.255.255 UH        0 0          0
ipsec0

10.65.33.252    0.0.0.0         255.255.255.252 U         0 0          0
eth0

10.65.33.252    0.0.0.0         255.255.255.252 U         0 0          0
ipsec0

170.229.48.128  0.0.0.0         255.255.255.192 U         0 0          0
ipsec0

127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0
lo

0.0.0.0         10.65.33.254    0.0.0.0         UG        0 0          0
eth0

+ _________________________ /proc/net/ipsec_spi

+ test -r /proc/net/ipsec_spi

+ cat /proc/net/ipsec_spi

tun0x1001 at 10.65.33.253 IPIP: dir=in  src=199.91.34.69
policy=170.229.48.128/26->10.65.33.252/30 flags=0x8<>
life(c,s,h)=bytes(21572,0,0)addtime(6522,0,0)usetime(6083,0,0)packets(26
1,0,0) idle=2846 natencap=none natsport=0 natdport=0 refcount=4 ref=7

esp0xcc29b7a4 at 199.91.34.69 ESP_3DES_HMAC_SHA1: dir=out src=10.65.33.253
iv_bits=64bits iv=0xaa278564e8845690 ooowin=64 seq=117 alen=160
aklen=160 eklen=192
life(c,s,h)=bytes(25048,0,0)addtime(4703,0,0)usetime(4520,0,0)packets(11
7,0,0) idle=2815 natencap=none natsport=0 natdport=0 refcount=4 ref=63

tun0x100e at 199.91.34.69 IPIP: dir=out src=10.65.33.253
life(c,s,h)=addtime(2333,0,0) natencap=none natsport=0 natdport=0
refcount=4 ref=76

esp0x824bfd5f at 199.91.34.69 ESP_3DES_HMAC_SHA1: dir=out src=10.65.33.253
iv_bits=64bits iv=0xba525deff73b014b ooowin=64 seq=271 alen=160
aklen=160 eklen=192
life(c,s,h)=bytes(27464,0,0)addtime(6522,0,0)usetime(6083,0,0)packets(27
1,0,0) idle=163 natencap=none natsport=0 natdport=0 refcount=4 ref=13

tun0x100c at 199.91.34.69 IPIP: dir=out src=10.65.33.253
life(c,s,h)=bytes(20883,0,0)addtime(4703,0,0)usetime(4520,0,0)packets(11
7,0,0) idle=2815 natencap=none natsport=0 natdport=0 refcount=121 ref=62

tun0x100a at 199.91.34.69 IPIP: dir=out src=10.65.33.253
life(c,s,h)=bytes(4245,0,0)addtime(4703,0,0)usetime(4509,0,0)packets(22,
0,0) idle=2757 natencap=none natsport=0 natdport=0 refcount=26 ref=52

tun0x1002 at 199.91.34.69 IPIP: dir=out src=10.65.33.253
life(c,s,h)=bytes(18273,0,0)addtime(6522,0,0)usetime(6083,0,0)packets(27
1,0,0) idle=163 natencap=none natsport=0 natdport=0 refcount=275 ref=12

esp0xa1558956 at 10.65.33.253 ESP_3DES_HMAC_SHA1: dir=in  src=199.91.34.69
iv_bits=64bits iv=0x0cc0c86d5a941761 ooowin=64 alen=160 aklen=160
eklen=192 life(c,s,h)=addtime(2333,0,0) natencap=none natsport=0
natdport=0 refcount=4 ref=72

esp0xa1558955 at 10.65.33.253 ESP_3DES_HMAC_SHA1: dir=in  src=199.91.34.69
iv_bits=64bits iv=0x279d03338889537e ooowin=64 seq=158
bit=0xfffffffff7fffff7 max_seq_diff=1 alen=160 aklen=160 eklen=192
life(c,s,h)=bytes(164132,0,0)addtime(4703,0,0)usetime(4520,0,0)packets(1
55,0,0) idle=2815 natencap=none natsport=0 natdport=0 refcount=159
ref=58

esp0xa1558954 at 10.65.33.253 ESP_3DES_HMAC_SHA1: dir=in  src=199.91.34.69
iv_bits=64bits iv=0x2c26934fc1989d8f ooowin=64 seq=22 bit=0x3fffff
alen=160 aklen=160 eklen=192
life(c,s,h)=bytes(9057,0,0)addtime(4703,0,0)usetime(4509,0,0)packets(22,
0,0) idle=2628 natencap=none natsport=0 natdport=0 refcount=26 ref=48

esp0xa1558950 at 10.65.33.253 ESP_3DES_HMAC_SHA1: dir=in  src=199.91.34.69
iv_bits=64bits iv=0x2e09d794d3cb3b4f ooowin=64 seq=267
bit=0xffffebffffffffff max_seq_diff=1 alen=160 aklen=160 eklen=192
life(c,s,h)=bytes(21572,0,0)addtime(6522,0,0)usetime(6083,0,0)packets(26
1,0,0) idle=2846 natencap=none natsport=0 natdport=0 refcount=265 ref=8

esp0x3dce2648 at 199.91.34.69 ESP_3DES_HMAC_SHA1: dir=out src=10.65.33.253
iv_bits=64bits iv=0xc85d3b7a2741b9cd ooowin=64 seq=22 alen=160 aklen=160
eklen=192
life(c,s,h)=bytes(5024,0,0)addtime(4703,0,0)usetime(4509,0,0)packets(22,
0,0) idle=2757 natencap=none natsport=0 natdport=0 refcount=4 ref=53

esp0x8fe9e232 at 199.91.34.69 ESP_3DES_HMAC_SHA1: dir=out src=10.65.33.253
iv_bits=64bits iv=0x4b577a5a965036c5 ooowin=64 alen=160 aklen=160
eklen=192 life(c,s,h)=addtime(2333,0,0) natencap=none natsport=0
natdport=0 refcount=4 ref=77

tun0x100d at 10.65.33.253 IPIP: dir=in  src=199.91.34.69
policy=10.163.173.23/32->10.65.33.252/30 flags=0x8<>
life(c,s,h)=addtime(2333,0,0) natencap=none natsport=0 natdport=0
refcount=4 ref=71

tun0x100b at 10.65.33.253 IPIP: dir=in  src=199.91.34.69
policy=10.163.173.6/32->10.65.33.252/30 flags=0x8<>
life(c,s,h)=bytes(164132,0,0)addtime(4703,0,0)usetime(4520,0,0)packets(1
55,0,0) idle=2815 natencap=none natsport=0 natdport=0 refcount=4 ref=57

tun0x1009 at 10.65.33.253 IPIP: dir=in  src=199.91.34.69
policy=10.162.187.18/32->10.65.33.252/30 flags=0x8<>
life(c,s,h)=bytes(9057,0,0)addtime(4703,0,0)usetime(4509,0,0)packets(22,
0,0) idle=2628 natencap=none natsport=0 natdport=0 refcount=4 ref=47

+ _________________________ /proc/net/ipsec_spigrp

+ test -r /proc/net/ipsec_spigrp

+ cat /proc/net/ipsec_spigrp

tun0x1001 at 10.65.33.253 esp0xa1558950 at 10.65.33.253 

tun0x100e at 199.91.34.69 esp0x8fe9e232 at 199.91.34.69 

tun0x100c at 199.91.34.69 esp0xcc29b7a4 at 199.91.34.69 

tun0x100a at 199.91.34.69 esp0x3dce2648 at 199.91.34.69 

tun0x1002 at 199.91.34.69 esp0x824bfd5f at 199.91.34.69 

tun0x100d at 10.65.33.253 esp0xa1558956 at 10.65.33.253 

tun0x100b at 10.65.33.253 esp0xa1558955 at 10.65.33.253 

tun0x1009 at 10.65.33.253 esp0xa1558954 at 10.65.33.253 

+ _________________________ /proc/net/ipsec_tncfg

+ test -r /proc/net/ipsec_tncfg

+ cat /proc/net/ipsec_tncfg

ipsec0 -> eth0 mtu=16260(1500) -> 1500

ipsec1 -> NULL mtu=0(0) -> 0

ipsec2 -> NULL mtu=0(0) -> 0

ipsec3 -> NULL mtu=0(0) -> 0

+ _________________________ /proc/net/pfkey

+ test -r /proc/net/pfkey

+ _________________________ /proc/sys/net/ipsec-star

+ test -d /proc/sys/net/ipsec

+ cd /proc/sys/net/ipsec

+ egrep '^' debug_ah debug_eroute debug_esp debug_ipcomp debug_netlink
debug_pfkey debug_radij debug_rcv debug_spi debug_tunnel debug_verbose
debug_xform icmp inbound_policy_check pfkey_lossage tos

debug_ah:0

debug_eroute:0

debug_esp:0

debug_ipcomp:0

debug_netlink:0

debug_pfkey:0

debug_radij:0

debug_rcv:0

debug_spi:0

debug_tunnel:0

debug_verbose:0

debug_xform:0

icmp:1

inbound_policy_check:1

pfkey_lossage:0

tos:1

+ _________________________ ipsec/status

+ ipsec auto --status

000 interface ipsec0/eth0 10.65.33.253

000 %myid = (none)

000 debug none

000  

000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=64,
keysizemin=192, keysizemax=192

000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=128,
keysizemin=128, keysizemax=256

000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5,
keysizemin=128, keysizemax=128

000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1,
keysizemin=160, keysizemax=160

000  

000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8,
keydeflen=192

000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16,
keydeflen=128

000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16

000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20

000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024

000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536

000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048

000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072

000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096

000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144

000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192

000  

000 stats db_ops.c: {curr_cnt, total_cnt, maxsz} :context={0,11,36}
trans={0,11,72} attrs={0,11,48} 

000  

000 "stmarks_meditech":
10.65.33.252/30===10.65.33.253...199.91.34.69===170.229.48.128/26;
erouted; eroute owner: #2

000 "stmarks_meditech":     srcip=unset; dstip=unset; srcup=ipsec
_updown; dstup=ipsec _updown;

000 "stmarks_meditech":   ike_life: 3600s; ipsec_life: 28800s;
rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3

000 "stmarks_meditech":   policy: PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE;
prio: 30,26; interface: eth0; encap: esp;

000 "stmarks_meditech":   newest ISAKMP SA: #0; newest IPsec SA: #2; 

000 "stmarks_meditech":   IKE algorithms wanted:
3DES_CBC(5)_000-SHA1(2)-MODP1024(2); flags=strict

000 "stmarks_meditech":   IKE algorithms found:
3DES_CBC(5)_192-SHA1(2)_160-MODP1024(2)

000 "stmarks_meditech":   ESP algorithms wanted: 3DES(3)_000-SHA1(2);
flags=strict

000 "stmarks_meditech":   ESP algorithms loaded: 3DES(3)_000-SHA1(2);
flags=strict

000 "stmarks_meditech":   ESP algorithm newest: 3DES_0-HMAC_SHA1;
pfsgroup=<N/A>

000 "stmarks_pacs":
10.65.33.252/30===10.65.33.253...199.91.34.69===10.162.187.18/32;
erouted; eroute owner: #6

000 "stmarks_pacs":     srcip=unset; dstip=unset; srcup=ipsec _updown;
dstup=ipsec _updown;

000 "stmarks_pacs":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin:
540s; rekey_fuzz: 100%; keyingtries: 3

000 "stmarks_pacs":   policy: PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE; prio:
30,32; interface: eth0; encap: esp;

000 "stmarks_pacs":   newest ISAKMP SA: #0; newest IPsec SA: #6; 

000 "stmarks_pacs":   IKE algorithms wanted:
3DES_CBC(5)_000-SHA1(2)-MODP1024(2); flags=strict

000 "stmarks_pacs":   IKE algorithms found:
3DES_CBC(5)_192-SHA1(2)_160-MODP1024(2)

000 "stmarks_pacs":   ESP algorithms wanted: 3DES(3)_000-SHA1(2);
flags=strict

000 "stmarks_pacs":   ESP algorithms loaded: 3DES(3)_000-SHA1(2);
flags=strict

000 "stmarks_pacs":   ESP algorithm newest: 3DES_0-HMAC_SHA1;
pfsgroup=<N/A>

000 "stmarks_pacs2":
10.65.33.252/30===10.65.33.253...199.91.34.69===10.163.173.23/32;
erouted; eroute owner: #9

000 "stmarks_pacs2":     srcip=unset; dstip=unset; srcup=ipsec _updown;
dstup=ipsec _updown;

000 "stmarks_pacs2":   ike_life: 3600s; ipsec_life: 28800s;
rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3

000 "stmarks_pacs2":   policy: PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE; prio:
30,32; interface: eth0; encap: esp;

000 "stmarks_pacs2":   newest ISAKMP SA: #0; newest IPsec SA: #9; 

000 "stmarks_pacs2":   IKE algorithms wanted:
3DES_CBC(5)_000-SHA1(2)-MODP1024(2); flags=strict

000 "stmarks_pacs2":   IKE algorithms found:
3DES_CBC(5)_192-SHA1(2)_160-MODP1024(2)

000 "stmarks_pacs2":   ESP algorithms wanted: 3DES(3)_000-SHA1(2);
flags=strict

000 "stmarks_pacs2":   ESP algorithms loaded: 3DES(3)_000-SHA1(2);
flags=strict

000 "stmarks_pacs2":   ESP algorithm newest: 3DES_0-HMAC_SHA1;
pfsgroup=<N/A>

000 "stmarks_tracemaster":
10.65.33.252/30===10.65.33.253...199.91.34.69===10.163.173.6/32;
erouted; eroute owner: #7

000 "stmarks_tracemaster":     srcip=unset; dstip=unset; srcup=ipsec
_updown; dstup=ipsec _updown;

000 "stmarks_tracemaster":   ike_life: 3600s; ipsec_life: 28800s;
rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3

000 "stmarks_tracemaster":   policy: PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE;
prio: 30,32; interface: eth0; encap: esp;

000 "stmarks_tracemaster":   newest ISAKMP SA: #0; newest IPsec SA: #7; 

000 "stmarks_tracemaster":   IKE algorithms wanted:
3DES_CBC(5)_000-SHA1(2)-MODP1024(2); flags=strict

000 "stmarks_tracemaster":   IKE algorithms found:
3DES_CBC(5)_192-SHA1(2)_160-MODP1024(2)

000 "stmarks_tracemaster":   ESP algorithms wanted: 3DES(3)_000-SHA1(2);
flags=strict

000 "stmarks_tracemaster":   ESP algorithms loaded: 3DES(3)_000-SHA1(2);
flags=strict

000 "stmarks_tracemaster":   ESP algorithm newest: 3DES_0-HMAC_SHA1;
pfsgroup=<N/A>

000  

000 #2: "stmarks_meditech":500 STATE_QUICK_I2 (sent QI2, IPsec SA
established); EVENT_SA_REPLACE in 21635s; newest IPSEC; eroute owner

000 #2: "stmarks_meditech" used 56s ago; esp.824bfd5f at 199.91.34.69
esp.a1558950 at 10.65.33.253 tun.1002 at 199.91.34.69 tun.1001 at 10.65.33.253

000 #6: "stmarks_pacs":500 STATE_QUICK_I2 (sent QI2, IPsec SA
established); EVENT_SA_REPLACE in 23482s; newest IPSEC; eroute owner

000 #6: "stmarks_pacs" used 2696s ago; esp.3dce2648 at 199.91.34.69
esp.a1558954 at 10.65.33.253 tun.100a at 199.91.34.69 tun.1009 at 10.65.33.253

000 #9: "stmarks_pacs2":500 STATE_QUICK_I2 (sent QI2, IPsec SA
established); EVENT_SA_REPLACE in 25488s; newest IPSEC; eroute owner

000 #9: "stmarks_pacs2" esp.8fe9e232 at 199.91.34.69
esp.a1558956 at 10.65.33.253 tun.100e at 199.91.34.69 tun.100d at 10.65.33.253

000 #7: "stmarks_tracemaster":500 STATE_QUICK_I2 (sent QI2, IPsec SA
established); EVENT_SA_REPLACE in 23428s; newest IPSEC; eroute owner

000 #7: "stmarks_tracemaster" used 2696s ago; esp.cc29b7a4 at 199.91.34.69
esp.a1558955 at 10.65.33.253 tun.100c at 199.91.34.69 tun.100b at 10.65.33.253

000  

+ _________________________ ifconfig-a

+ ifconfig -a

eth0      Link encap:Ethernet  HWaddr 00:0c:29:28:42:ff  

          inet addr:10.65.33.253  Bcast:10.65.33.255
Mask:255.255.255.252

          inet6 addr: fe80::20c:29ff:fe28:42ff/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:25920 errors:0 dropped:0 overruns:0 frame:0

          TX packets:3329 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:3911234 (3.7 MiB)  TX bytes:588397 (574.6 KiB)

          Base address:0x1070 Memory:e8820000-e8840000 

 

ipsec0    Link encap:Ethernet  HWaddr 00:0c:29:28:42:ff  

          inet addr:10.65.33.253  Mask:255.255.255.252

          inet6 addr: fe80::20c:29ff:fe28:42ff/64 Scope:Link

          UP RUNNING NOARP  MTU:16260  Metric:1

          RX packets:457 errors:0 dropped:0 overruns:0 frame:0

          TX packets:432 errors:0 dropped:3 overruns:0 carrier:0

          collisions:0 txqueuelen:10 

          RX bytes:195933 (191.3 KiB)  TX bytes:67856 (66.2 KiB)

 

ipsec1    Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  

          NOARP  MTU:0  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:10 

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

 

ipsec2    Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  

          NOARP  MTU:0  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:10 

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

 

ipsec3    Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  

          NOARP  MTU:0  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:10 

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

 

lo        Link encap:Local Loopback  

          inet addr:127.0.0.1  Mask:255.0.0.0

          inet6 addr: ::1/128 Scope:Host

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0 

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

 

+ _________________________ ip-addr-list

+ ip addr list

1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue 

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

    inet6 ::1/128 scope host 

       valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
1000

    link/ether 00:0c:29:28:42:ff brd ff:ff:ff:ff:ff:ff

    inet 10.65.33.253/30 brd 10.65.33.255 scope global eth0

    inet6 fe80::20c:29ff:fe28:42ff/64 scope link 

       valid_lft forever preferred_lft forever

11: ipsec0: <NOARP,UP,10000> mtu 16260 qdisc pfifo_fast qlen 10

    link/ether 00:0c:29:28:42:ff brd ff:ff:ff:ff:ff:ff

    inet 10.65.33.253/30 brd 10.65.33.255 scope global ipsec0

    inet6 fe80::20c:29ff:fe28:42ff/64 scope link 

       valid_lft forever preferred_lft forever

12: ipsec1: <NOARP> mtu 0 qdisc noop qlen 10

    link/void 

13: ipsec2: <NOARP> mtu 0 qdisc noop qlen 10

    link/void 

14: ipsec3: <NOARP> mtu 0 qdisc noop qlen 10

    link/void 

+ _________________________ ip-route-list

+ ip route list

10.163.173.23 dev ipsec0  scope link 

10.163.173.6 dev ipsec0  scope link 

10.162.187.18 dev ipsec0  scope link 

10.65.33.252/30 dev eth0  proto kernel  scope link  src 10.65.33.253 

10.65.33.252/30 dev ipsec0  proto kernel  scope link  src 10.65.33.253 

170.229.48.128/26 dev ipsec0  scope link 

127.0.0.0/8 dev lo  scope link 

default via 10.65.33.254 dev eth0  metric 1 

+ _________________________ ip-rule-list

+ ip rule list

0:            from all lookup local 

32766:   from all lookup main 

32767:   from all lookup default 

+ _________________________ ipsec_verify

+ ipsec verify --nocolour

Checking your system to see if IPsec got installed and started
correctly:

Version check and ipsec on-path                             [OK]

Linux Openswan 2.4.13 (klips)

Checking for IPsec support in kernel
[OK]

KLIPS detected, checking for NAT Traversal support
[OK]

Checking for RSA private key (/etc/ipsec.d/hostkey.secrets)       [OK]

Checking that pluto is running                                    [OK]

Checking for 'ip' command                                           [OK]

Checking for 'iptables' command                             [OK]

 

Opportunistic Encryption DNS checks:

   Looking for TXT in forward dns zone: windu
[MISSING]

   Does the machine have at least one non-private address?
[FAILED]

+ _________________________ mii-tool

+ '[' -x /sbin/mii-tool ']'

+ /sbin/mii-tool -v

eth0: negotiated 1000baseT-FD flow-control, link ok

  product info: Yukon 88E1011 rev 3

  basic mode:   autonegotiation enabled

  basic status: autonegotiation complete, link ok

  capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD
10baseT-HD

  advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
10baseT-FD 10baseT-HD

  link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD
10baseT-HD

+ _________________________ ipsec/directory

+ ipsec --directory

/usr/local/lib/ipsec

+ _________________________ hostname/fqdn

+ hostname --fqdn

windu.heartslc.com

+ _________________________ hostname/ipaddress

+ hostname --ip-address

10.65.33.253 

+ _________________________ uptime

+ uptime

 12:46:33 up  2:03,  2 users,  load average: 1.96, 1.85, 1.83

+ _________________________ ps

+ ps alxwf

+ egrep -i 'ppid|pluto|ipsec|klips'

F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME
COMMAND

0     0  5979 24569  21   0   2772  1380 -      R+   pts/1      0:00
\_ /bin/sh /usr/local/libexec/ipsec/barf

1     0  4548     1  25   0   2344   436 wait   S    pts/1      0:00
/bin/sh /usr/local/lib/ipsec/_plutorun --debug  --uniqueids yes
--nocrsend  --strictcrlpolicy  --nat_traversal no --keep_alive
--protostack auto --force_keepalive  --disable_port_floating
--virtual_private  --crlcheckinterval 0 --ocspuri  --nhelpers  --dump
--opts  --stderrlog  --wait no --pre  --post  --log daemon.error --pid
/var/run/pluto/pluto.pid

1     0  4558  4548  25   0   2344   612 wait   S    pts/1      0:00  \_
/bin/sh /usr/local/lib/ipsec/_plutorun --debug  --uniqueids yes
--nocrsend  --strictcrlpolicy  --nat_traversal no --keep_alive
--protostack auto --force_keepalive  --disable_port_floating
--virtual_private  --crlcheckinterval 0 --ocspuri  --nhelpers  --dump
--opts  --stderrlog  --wait no --pre  --post  --log daemon.error --pid
/var/run/pluto/pluto.pid

4     0  4637  4558  15   0   2732  1388 -      S    pts/1      0:00  |
\_ /usr/local/libexec/ipsec/pluto --nofork --secretsfile
/etc/ipsec.secrets --ipsecdir /etc/ipsec.d --use-auto --uniqueids

1     0  4638  4637  26  10   2660   524 -      SN   pts/1      0:00  |
\_ pluto helper  #  0


0     0  4639  4637  25   0   1632   304 429496 S    pts/1      0:00  |
\_ _pluto_adns

0     0  4560  4548  17   0   2316  1060 pipe_w S    pts/1      0:00  \_
/bin/sh /usr/local/lib/ipsec/_plutoload --wait no --post 

0     0  4559     1  18   0   1692   532 pipe_w S    pts/1      0:00
logger -s -p daemon.error -t ipsec__plutorun

+ _________________________ ipsec/showdefaults

+ ipsec showdefaults

# no default route

+ _________________________ ipsec/conf

+ ipsec _include /etc/ipsec.conf

+ ipsec _keycensor

 

#< /etc/ipsec.conf 1

# /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

                forwardcontrol=yes

                interfaces="ipsec0=eth0"

                nat_traversal=no

                plutowait=no

                uniqueids=yes

 

conn stmarks_meditech

                aggrmode=yes

                auth=esp

                authby=secret

                auto=add

                compress=no

                esp=3des-sha1

                ike=3des-sha1-modp1024

                keyexchange=ike

                keyingtries=3

                left=10.65.33.253

                leftsubnet=10.65.33.252/30

                pfs=no

                right=199.91.34.69

                rightsubnet=170.229.48.128/26

                type=tunnel

                #leftprotoport=17/500

                #rightprotoport=17/500

 

conn stmarks_pacs

                aggrmode=yes

                #leftprotoport=17/500

                #rightprotoport=17/500

                auth=esp

                authby=secret

                auto=add

                compress=no

                esp=3des-sha1

                ike=3des-sha1-modp1024

                keyexchange=ike

                keyingtries=3

                left=10.65.33.253

                leftsubnet=10.65.33.252/30

                pfs=no

                right=199.91.34.69

                rightsubnet=10.162.187.18/32

                type=tunnel

 

conn stmarks_tracemaster

                aggrmode=yes

                auth=esp

                authby=secret

                auto=add

                compress=no

                esp=3des-sha1

                ike=3des-sha1-modp1024

                keyexchange=ike

                keyingtries=3

                left=10.65.33.253

                leftsubnet=10.65.33.252/30

                pfs=no

                right=199.91.34.69

                rightsubnet=10.163.173.6/32

                type=tunnel

                #leftprotoport=17/500

                #rightprotoport=17/500

 

conn stmarks_pacs2

                aggrmode=yes

                auth=esp

                authby=secret

                auto=add

                compress=no

                esp=3des-sha1

                ike=3des-sha1-modp1024

                keyexchange=ike

                keyingtries=3

                left=10.65.33.253

                leftsubnet=10.65.33.252/30

                pfs=no

                right=199.91.34.69

                rightsubnet=10.163.173.23/32

                type=tunnel

                #leftprotoport=17/500

                #rightprotoport=17/500

+ _________________________ ipsec/secrets

+ ipsec _include /etc/ipsec.secrets

+ ipsec _secretcensor

 

#< /etc/ipsec.secrets 1

: RSA      {

                # RSA 2192 bits   windu   Tue Nov 25 18:56:50 2008

                # for signatures only, UNSAFE FOR ENCRYPTION

                #pubkey=[keyid AQNmyHZSA]

                Modulus: [...]

                PublicExponent: [...]

                # everything after this point is secret

                PrivateExponent: [...]

                Prime1: [...]

                Prime2: [...]

                Exponent1: [...]

                Exponent2: [...]

                Coefficient: [...]

                }

# do not change the indenting of that "[sums to 7d9d...]"

: PSK "[sums to 92d6...]"

+ _________________________ ipsec/listall

+ ipsec auto --listall

000  

000 List of Public Keys:

000  

+ '[' /etc/ipsec.d/policies ']'

+ for policy in '$POLICIES/*'

++ basename /etc/ipsec.d/policies/block

+ base=block

+ _________________________ ipsec/policies/block

+ cat /etc/ipsec.d/policies/block

# This file defines the set of CIDRs (network/mask-length) to which

# communication should never be allowed.

#

# See /usr/local/share/doc/openswan/policygroups.html for details.

#

# $Id: block.in,v 1.4 2003-02-17 02:22:15 mcr Exp $

#

 

+ for policy in '$POLICIES/*'

++ basename /etc/ipsec.d/policies/clear

+ base=clear

+ _________________________ ipsec/policies/clear

+ cat /etc/ipsec.d/policies/clear

# This file defines the set of CIDRs (network/mask-length) to which

# communication should always be in the clear.

#

# See /usr/local/share/doc/openswan/policygroups.html for details.

#

# $Id: clear.in,v 1.4.30.3 2006-11-21 19:49:51 paul Exp $

#

#

#             Michael's idea: Always have ROOT NAMESERVERS in the clear.

#             It will make OE work much better on machines running
caching

#             resolvers.

#

#             Based on: http://www.internic.net/zones/named.root

#       This file holds the information on root name servers needed to

#       last update:    Jan 29, 2004

#       related version of root zone:   2004012900

0.0.0.0/0

+ for policy in '$POLICIES/*'

++ basename /etc/ipsec.d/policies/clear-or-private

+ base=clear-or-private

+ _________________________ ipsec/policies/clear-or-private

+ cat /etc/ipsec.d/policies/clear-or-private

# This file defines the set of CIDRs (network/mask-length) to which

# we will communicate in the clear, or, if the other side initiates
IPSEC,

# using encryption.  This behaviour is also called "Opportunistic
Responder".

#

# See /usr/local/share/doc/openswan/policygroups.html for details.

#

# $Id: clear-or-private.in,v 1.4 2003-02-17 02:22:15 mcr Exp $

#

0.0.0.0/0

+ for policy in '$POLICIES/*'

++ basename /etc/ipsec.d/policies/private

+ base=private

+ _________________________ ipsec/policies/private

+ cat /etc/ipsec.d/policies/private

# This file defines the set of CIDRs (network/mask-length) to which

# communication should always be private (i.e. encrypted).

# See /usr/local/share/doc/openswan/policygroups.html for details.

#

# $Id: private.in,v 1.4 2003-02-17 02:22:15 mcr Exp $

#

0.0.0.0/0

+ for policy in '$POLICIES/*'

++ basename /etc/ipsec.d/policies/private-or-clear

+ base=private-or-clear

+ _________________________ ipsec/policies/private-or-clear

+ cat /etc/ipsec.d/policies/private-or-clear

# This file defines the set of CIDRs (network/mask-length) to which

# communication should be private, if possible, but in the clear
otherwise.

#

# If the target has a TXT (later IPSECKEY) record that specifies

# authentication material, we will require private (i.e. encrypted)

# communications.  If no such record is found, communications will be

# in the clear.

#

# See /usr/local/share/doc/openswan/policygroups.html for details.

#

# $Id: private-or-clear.in,v 1.5 2003-02-17 02:22:15 mcr Exp $

#

 

0.0.0.0/0

+ _________________________ ipsec/ls-libdir

+ ls -l /usr/local/lib/ipsec

total 116

-rwxr-xr-x 1 root root 15848 Dec 31 09:33 _confread

-rwxr-xr-x 1 root root 14289 Dec 31 09:33 _copyright

-rwxr-xr-x 1 root root  2379 Dec 31 09:33 _include

-rwxr-xr-x 1 root root  1475 Dec 31 09:33 _keycensor

-rwxr-xr-x 1 root root  3648 Dec 31 09:33 _plutoload

-rwxr-xr-x 1 root root  8069 Dec 31 09:33 _plutorun

-rwxr-xr-x 1 root root 12324 Dec 31 09:33 _realsetup

-rwxr-xr-x 1 root root  1975 Dec 31 09:33 _secretcensor

-rwxr-xr-x 1 root root 11102 Dec 31 09:33 _startklips

-rwxr-xr-x 1 root root 13918 Dec 31 09:33 _updown

-rwxr-xr-x 1 root root 15746 Dec 31 09:33 _updown_x509

+ _________________________ ipsec/ls-execdir

+ ls -l /usr/local/libexec/ipsec

total 4548

-rwxr-xr-x 1 root root   28489 Dec 31 09:32 _pluto_adns

-rwxr-xr-x 1 root root  375943 May 12  2008 addconn.old

-rwxr-xr-x 1 root root   18891 Dec 31 09:33 auto

-rwxr-xr-x 1 root root   11367 Dec 31 09:33 barf

-rwxr-xr-x 1 root root     816 Dec 31 09:33 calcgoo

-rwxr-xr-x 1 root root  199893 Dec 31 09:32 eroute

-rwxr-xr-x 1 root root   65085 Dec 31 09:33 ikeping

-rwxr-xr-x 1 root root  129819 Dec 31 09:32 klipsdebug

-rwxr-xr-x 1 root root    1836 Dec 31 09:33 livetest

-rwxr-xr-x 1 root root    2604 Dec 31 09:33 look

-rwxr-xr-x 1 root root  839794 May 12  2008 lwdnsq.old

-rwxr-xr-x 1 root root    7094 Dec 31 09:33 mailkey

-rwxr-xr-x 1 root root   16015 Dec 31 09:33 manual

-rwxr-xr-x 1 root root    1951 Dec 31 09:33 newhostkey

-rwxr-xr-x 1 root root  115216 Dec 31 09:32 pf_key

-rwxr-xr-x 1 root root 1914326 Dec 31 09:32 pluto

-rwxr-xr-x 1 root root   21174 Dec 31 09:33 ranbits

-rwxr-xr-x 1 root root   50625 Dec 31 09:33 rsasigkey

-rwxr-xr-x 1 root root     766 Dec 31 09:33 secrets

lrwxrwxrwx 1 root root      22 Dec 31 09:33 setup ->
/etc/rc.d/init.d/ipsec

-rwxr-xr-x 1 root root    1054 Dec 31 09:33 showdefaults

-rwxr-xr-x 1 root root    4845 Dec 31 09:33 showhostkey

-rwxr-xr-x 1 root root   60365 May 12  2008 showpolicy.old

-rwxr-xr-x 1 root root  325143 Dec 31 09:32 spi

-rwxr-xr-x 1 root root  164884 Dec 31 09:32 spigrp

-rwxr-xr-x 1 root root   24248 Dec 31 09:32 tncfg

-rwxr-xr-x 1 root root   13530 Dec 31 09:33 verify

-rwxr-xr-x 1 root root  159092 Dec 31 09:32 whack

+ _________________________ ipsec/updowns

++ ls /usr/local/libexec/ipsec

++ egrep updown

+ _________________________ /proc/net/dev

+ cat /proc/net/dev

Inter-|   Receive                                                |
Transmit

 face |bytes    packets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed

    lo:       0       0    0    0    0     0          0         0
0       0    0    0    0     0       0          0

  eth0: 3912857   25935    0    0    0     0          0         0
588765    3333    0    0    0     0       0          0

ipsec0:  195933     457    0    0    0     0          0         0
67856     432    0    3    0     0       0          0

ipsec1:       0       0    0    0    0     0          0         0
0       0    0    0    0     0       0          0

ipsec2:       0       0    0    0    0     0          0         0
0       0    0    0    0     0       0          0

ipsec3:       0       0    0    0    0     0          0         0
0       0    0    0    0     0       0          0

+ _________________________ /proc/net/route

+ cat /proc/net/route

Iface      Destination         Gateway              Flags      RefCnt
Use        Metric   Mask                     MTU      Window
IRTT                                                       

ipsec0   17ADA30A           00000000             0005       0
0              0              FFFFFFFF             0              0
0


ipsec0   06ADA30A           00000000             0005       0
0              0              FFFFFFFF             0              0
0


ipsec0   12BBA20A           00000000             0005       0
0              0              FFFFFFFF             0              0
0


eth0       FC21410A            00000000             0001       0
0              0              FCFFFFFF             0              0
0


ipsec0   FC21410A            00000000             0001       0
0              0              FCFFFFFF             0              0
0


ipsec0   8030E5AA            00000000             0001       0
0              0              C0FFFFFF             0              0
0


lo            0000007F             00000000             0001       0
0              0              000000FF             0              0
0


eth0       00000000             FE21410A             0003       0
0              1              00000000             0              0
0


+ _________________________ /proc/sys/net/ipv4/ip_forward

+ cat /proc/sys/net/ipv4/ip_forward

1

+ _________________________ /proc/sys/net/ipv4/tcp_ecn

+ cat /proc/sys/net/ipv4/tcp_ecn

0

+ _________________________ /proc/sys/net/ipv4/conf/star-rp_filter

+ cd /proc/sys/net/ipv4/conf

+ egrep '^' all/rp_filter default/rp_filter eth0/rp_filter
ipsec0/rp_filter lo/rp_filter

all/rp_filter:0

default/rp_filter:0

eth0/rp_filter:0

ipsec0/rp_filter:0

lo/rp_filter:0

+ _________________________ /proc/sys/net/ipv4/conf/star-rp_filter

+ cd /proc/sys/net/ipv4/conf

+ egrep '^' all/rp_filter default/rp_filter eth0/rp_filter
ipsec0/rp_filter lo/rp_filter

all/rp_filter:0

default/rp_filter:0

eth0/rp_filter:0

ipsec0/rp_filter:0

lo/rp_filter:0

+ _________________________ /proc/sys/net/ipv4/conf/star-star-redirects

+ cd /proc/sys/net/ipv4/conf

+ egrep '^' all/accept_redirects all/secure_redirects all/send_redirects
default/accept_redirects default/secure_redirects default/send_redirects
eth0/accept_redirects eth0/secure_redirects eth0/send_redirects
ipsec0/accept_redirects ipsec0/secure_redirects ipsec0/send_redirects
lo/accept_redirects lo/secure_redirects lo/send_redirects

all/accept_redirects:0

all/secure_redirects:1

all/send_redirects:0

default/accept_redirects:0

default/secure_redirects:1

default/send_redirects:0

eth0/accept_redirects:0

eth0/secure_redirects:1

eth0/send_redirects:0

ipsec0/accept_redirects:0

ipsec0/secure_redirects:1

ipsec0/send_redirects:0

lo/accept_redirects:1

lo/secure_redirects:1

lo/send_redirects:1

+ _________________________ /proc/sys/net/ipv4/tcp_window_scaling

+ cat /proc/sys/net/ipv4/tcp_window_scaling

1

+ _________________________ /proc/sys/net/ipv4/tcp_adv_win_scale

+ cat /proc/sys/net/ipv4/tcp_adv_win_scale

2

+ _________________________ uname-a

+ uname -a

Linux windu 2.6.19-smp #1 SMP Tue Dec 30 20:03:07 MST 2008 i686 Intel(R)
Xeon(R) CPU           E5335  @ 2.00GHz GenuineIntel GNU/Linux

+ _________________________ config-built-with

+ test -r /proc/config_built_with

+ _________________________ distro-release

+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release

+ test -f /etc/redhat-release

+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release

+ test -f /etc/debian-release

+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release

+ test -f /etc/SuSE-release

+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release

+ test -f /etc/mandrake-release

+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release

+ test -f /etc/mandriva-release

+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release

+ test -f /etc/gentoo-release

+ _________________________ /proc/net/ipsec_version

+ test -r /proc/net/ipsec_version

+ cat /proc/net/ipsec_version

Openswan version: 2.4.13

+ _________________________ ipfwadm

+ test -r /sbin/ipfwadm

+ 'no old-style linux 1.x/2.0 ipfwadm firewall support'

/usr/local/libexec/ipsec/barf: line 305: no old-style linux 1.x/2.0
ipfwadm firewall support: No such file or directory

+ _________________________ ipchains

+ test -r /sbin/ipchains

+ echo 'no old-style linux 2.0 ipchains firewall support'

no old-style linux 2.0 ipchains firewall support

+ _________________________ iptables

+ test -r /sbin/iptables

+ test -r /sbin/ipchains

+ _________________________ /proc/modules

+ test -f /proc/modules

+ cat /proc/modules

ipsec 351724 2 - Live 0xf90d3000

iptable_mangle 6144 0 - Live 0xf8fea000

iptable_filter 6400 0 - Live 0xf8fa9000

ip_tables 15172 2 iptable_mangle,iptable_filter, Live 0xf8fdb000

x_tables 15492 1 ip_tables, Live 0xf8cfb000

ipv6 241184 10 - Live 0xf9031000

pcmcia 33836 0 - Live 0xf8fe0000

rsrc_nonstatic 14720 0 - Live 0xf8f9f000

pcmcia_core 36500 2 pcmcia,rsrc_nonstatic, Live 0xf8fcb000

tun 12032 0 - Live 0xf8cf1000

lp 13480 0 - Live 0xf8cc1000

parport_pc 27300 1 - Live 0xf8fc3000

parport 34760 2 lp,parport_pc, Live 0xf8fb9000

fuse 41876 1 - Live 0xf8fad000

serio_raw 9220 0 - Live 0xf8cf5000

psmouse 38280 0 - Live 0xf8eb1000

e1000 118976 0 - Live 0xf8e81000

intel_agp 24348 1 - Live 0xf8cdc000

pcspkr 6528 0 - Live 0xf8cd9000

agpgart 29256 1 intel_agp, Live 0xf8ce3000

i2c_piix4 11148 0 - Live 0xf8cd5000

evdev 11904 1 - Live 0xf8cc6000

sg 30108 0 - Live 0xf8ccc000

+ _________________________ /proc/meminfo

+ cat /proc/meminfo

MemTotal:      1031624 kB

MemFree:        870924 kB

Buffers:         21524 kB

Cached:         103788 kB

SwapCached:          0 kB

Active:          91300 kB

Inactive:        45720 kB

HighTotal:      131008 kB

HighFree:         8156 kB

LowTotal:       900616 kB

LowFree:        862768 kB

SwapTotal:     1542232 kB

SwapFree:      1542232 kB

Dirty:             380 kB

Writeback:           0 kB

AnonPages:       11720 kB

Mapped:           7268 kB

Slab:            13672 kB

SReclaimable:     6240 kB

SUnreclaim:       7432 kB

PageTables:        504 kB

NFS_Unstable:        0 kB

Bounce:              0 kB

CommitLimit:   2058044 kB

Committed_AS:    36596 kB

VmallocTotal:   114680 kB

VmallocUsed:      8660 kB

VmallocChunk:   105296 kB

+ _________________________ /proc/net/ipsec-ls

+ test -f /proc/net/ipsec_version

+ ls -l /proc/net/ipsec_eroute /proc/net/ipsec_klipsdebug
/proc/net/ipsec_spi /proc/net/ipsec_spigrp /proc/net/ipsec_tncfg
/proc/net/ipsec_version

lrwxrwxrwx 1 root root 16 Jan  5 12:46 /proc/net/ipsec_eroute ->
ipsec/eroute/all

lrwxrwxrwx 1 root root 16 Jan  5 12:46 /proc/net/ipsec_klipsdebug ->
ipsec/klipsdebug

lrwxrwxrwx 1 root root 13 Jan  5 12:46 /proc/net/ipsec_spi ->
ipsec/spi/all

lrwxrwxrwx 1 root root 16 Jan  5 12:46 /proc/net/ipsec_spigrp ->
ipsec/spigrp/all

lrwxrwxrwx 1 root root 11 Jan  5 12:46 /proc/net/ipsec_tncfg ->
ipsec/tncfg

lrwxrwxrwx 1 root root 13 Jan  5 12:46 /proc/net/ipsec_version ->
ipsec/version

+ _________________________ usr/src/linux/.config

+ test -f /proc/config.gz

+ zcat /proc/config.gz

+ egrep
'CONFIG_IPSEC|CONFIG_KLIPS|CONFIG_NET_KEY|CONFIG_INET|CONFIG_IP|CONFIG_H
W_RANDOM|CONFIG_CRYPTO_DEV|_XFRM'

# CONFIG_IPC_NS is not set

CONFIG_XFRM=y

CONFIG_XFRM_USER=y

CONFIG_NET_KEY=m

CONFIG_INET=y

CONFIG_IP_MULTICAST=y

CONFIG_IP_ADVANCED_ROUTER=y

# CONFIG_IP_FIB_TRIE is not set

CONFIG_IP_FIB_HASH=y

CONFIG_IP_MULTIPLE_TABLES=y

# CONFIG_IP_ROUTE_FWMARK is not set

CONFIG_IP_ROUTE_MULTIPATH=y

# CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set

CONFIG_IP_ROUTE_VERBOSE=y

# CONFIG_IP_PNP is not set

CONFIG_IP_MROUTE=y

CONFIG_IP_PIMSM_V1=y

CONFIG_IP_PIMSM_V2=y

CONFIG_IPSEC_NAT_TRAVERSAL=y

CONFIG_INET_AH=m

CONFIG_INET_ESP=m

CONFIG_INET_IPCOMP=m

CONFIG_INET_XFRM_TUNNEL=m

CONFIG_INET_TUNNEL=m

CONFIG_INET_XFRM_MODE_TRANSPORT=m

CONFIG_INET_XFRM_MODE_TUNNEL=m

CONFIG_INET_XFRM_MODE_BEET=m

CONFIG_INET_DIAG=m

CONFIG_INET_TCP_DIAG=m

CONFIG_IP_VS=m

# CONFIG_IP_VS_DEBUG is not set

CONFIG_IP_VS_TAB_BITS=12

CONFIG_IP_VS_PROTO_TCP=y

CONFIG_IP_VS_PROTO_UDP=y

CONFIG_IP_VS_PROTO_ESP=y

CONFIG_IP_VS_PROTO_AH=y

CONFIG_IP_VS_RR=m

CONFIG_IP_VS_WRR=m

CONFIG_IP_VS_LC=m

CONFIG_IP_VS_WLC=m

CONFIG_IP_VS_LBLC=m

CONFIG_IP_VS_LBLCR=m

CONFIG_IP_VS_DH=m

CONFIG_IP_VS_SH=m

CONFIG_IP_VS_SED=m

CONFIG_IP_VS_NQ=m

CONFIG_IP_VS_FTP=m

CONFIG_IPV6=m

CONFIG_IPV6_PRIVACY=y

# CONFIG_IPV6_ROUTER_PREF is not set

CONFIG_INET6_AH=m

CONFIG_INET6_ESP=m

CONFIG_INET6_IPCOMP=m

CONFIG_INET6_XFRM_TUNNEL=m

CONFIG_INET6_TUNNEL=m

CONFIG_INET6_XFRM_MODE_TRANSPORT=m

CONFIG_INET6_XFRM_MODE_TUNNEL=m

CONFIG_INET6_XFRM_MODE_BEET=m

CONFIG_IPV6_SIT=m

CONFIG_IPV6_TUNNEL=m

# CONFIG_IP_NF_CONNTRACK is not set

CONFIG_IP_NF_QUEUE=m

CONFIG_IP_NF_IPTABLES=m

CONFIG_IP_NF_MATCH_IPRANGE=m

CONFIG_IP_NF_MATCH_TOS=m

CONFIG_IP_NF_MATCH_RECENT=m

CONFIG_IP_NF_MATCH_ECN=m

CONFIG_IP_NF_MATCH_AH=m

CONFIG_IP_NF_MATCH_TTL=m

CONFIG_IP_NF_MATCH_OWNER=m

CONFIG_IP_NF_MATCH_ADDRTYPE=m

# CONFIG_IP_NF_MATCH_HASHLIMIT is not set

CONFIG_IP_NF_FILTER=m

CONFIG_IP_NF_TARGET_REJECT=m

CONFIG_IP_NF_TARGET_LOG=m

CONFIG_IP_NF_TARGET_ULOG=m

# CONFIG_IP_NF_TARGET_TCPMSS is not set

CONFIG_IP_NF_MANGLE=m

CONFIG_IP_NF_TARGET_TOS=m

CONFIG_IP_NF_TARGET_ECN=m

CONFIG_IP_NF_TARGET_TTL=m

CONFIG_IP_NF_RAW=m

CONFIG_IP_NF_ARPTABLES=m

CONFIG_IP_NF_ARPFILTER=m

CONFIG_IP_NF_ARP_MANGLE=m

CONFIG_IPX=m

# CONFIG_IPX_INTERN is not set

CONFIG_IPDDP=m

CONFIG_IPDDP_ENCAP=y

CONFIG_IPDDP_DECAP=y

CONFIG_IPPP_FILTER=y

CONFIG_IPMI_HANDLER=m

# CONFIG_IPMI_PANIC_EVENT is not set

CONFIG_IPMI_DEVICE_INTERFACE=m

CONFIG_IPMI_SI=m

CONFIG_IPMI_WATCHDOG=m

CONFIG_IPMI_POWEROFF=m

CONFIG_HW_RANDOM=y

CONFIG_HW_RANDOM_INTEL=m

CONFIG_HW_RANDOM_AMD=m

CONFIG_HW_RANDOM_GEODE=m

CONFIG_HW_RANDOM_VIA=m

CONFIG_SECURITY_NETWORK_XFRM=y

CONFIG_CRYPTO_DEV_PADLOCK=m

CONFIG_CRYPTO_DEV_PADLOCK_AES=m

CONFIG_CRYPTO_DEV_PADLOCK_SHA=m

+ _________________________ etc/syslog.conf

+ cat /etc/syslog.conf

# /etc/syslog.conf

# For info about the format of this file, see "man syslog.conf"

# and /usr/doc/sysklogd/README.linux.  Note the '-' prefixing some

# of these entries;  this omits syncing the file after every logging.

# In the event of a crash, some log information might be lost, so

# if this is a concern to you then you might want to remove the '-'.

# Be advised this will cause a performation loss if you're using

# programs that do heavy logging.

 

# Uncomment this to see kernel messages on the console.

#kern.*
/dev/console

 

# Log anything 'info' or higher, but lower than 'warn'.

# Exclude authpriv, cron, mail, and news.  These are logged elsewhere.

*.info;*.!warn;\

                authpriv.none;cron.none;mail.none;news.none
-/var/log/messages

 

# Log anything 'warn' or higher.

# Exclude authpriv, cron, mail, and news.  These are logged elsewhere.

*.warn;\

                authpriv.none;cron.none;mail.none;news.none
-/var/log/syslog

 

# Debugging information is logged here.

*.=debug
-/var/log/debug

 

# Private authentication message logging:

authpriv.*
-/var/log/secure

 

# Cron related logs:

cron.*
-/var/log/cron

 

# Mail related logs:

mail.*
-/var/log/maillog

 

# Emergency level messages go to all users:

*.emerg
*

 

# This log is for news and uucp errors:

uucp,news.crit
-/var/log/spooler

 

# Uncomment these if you'd like INN to keep logs on everything.

# You won't need this if you don't run INN (the InterNetNews daemon).

#news.=crit
-/var/log/news/news.crit

#news.=err
-/var/log/news/news.err

#news.notice
-/var/log/news/news.notice

 

+ _________________________ etc/syslog-ng/syslog-ng.conf

+ cat /etc/syslog-ng/syslog-ng.conf

cat: /etc/syslog-ng/syslog-ng.conf: No such file or directory

+ _________________________ etc/resolv.conf

+ cat /etc/resolv.conf

search heartslc.com

nameserver 10.30.0.19

+ _________________________ lib/modules-ls

+ ls -ltr /lib/modules

total 16

drwxr-xr-x 3 root root 4096 Apr 30  2008 2.6.24.5

drwxr-xr-x 3 root root 4096 May 11  2008 2.6.24.5-smp

drwxr-xr-x 3 root root 4096 Dec 31 09:37 2.6.19.7-smp

drwxr-xr-x 3 root root 4096 Dec 31 09:40 2.6.19-smp

+ _________________________ /proc/ksyms-netif_rx

+ test -r /proc/ksyms

+ test -r /proc/kallsyms

+ egrep netif_rx /proc/kallsyms

c05b3420 T __netif_rx_schedule

c05b4920 T netif_rx

c05b5e10 T netif_rx_ni

c05b4920 U netif_rx        [ipsec]

c05b4920 U netif_rx        [ipv6]

c05b5e10 U netif_rx_ni [tun]

c05b3420 U __netif_rx_schedule             [e1000]

+ _________________________ lib/modules-netif_rx

+ modulegoo kernel/net/ipv4/ipip.o netif_rx

+ set +x

2.6.19-smp: 

2.6.19.7-smp: 

2.6.24.5: 

2.6.24.5-smp: 

+ _________________________ kern.debug

+ test -f /var/log/kern.debug

+ _________________________ klog

+ sed -n '280,$p' /var/log/syslog

+ egrep -i 'ipsec|klips|pluto'

+ case "$1" in

+ cat

Jan  5 10:57:35 windu ipsec_setup: Starting Openswan IPsec 2.4.13...

Jan  5 10:57:36 windu ipsec__plutorun: ipsec_auto: fatal error in
"packetdefault": %defaultroute requested but not known

Jan  5 10:57:36 windu ipsec__plutorun: ipsec_auto: fatal error in
"block": %defaultroute requested but not known

Jan  5 10:57:37 windu ipsec__plutorun: ipsec_auto: fatal error in
"clear-or-private": %defaultroute requested but not known

Jan  5 10:57:38 windu ipsec__plutorun: ipsec_auto: fatal error in
"clear": %defaultroute requested but not known

Jan  5 10:57:38 windu ipsec__plutorun: ipsec_auto: fatal error in
"private-or-clear": %defaultroute requested but not known

Jan  5 10:57:38 windu ipsec__plutorun: ipsec_auto: fatal error in
"private": %defaultroute requested but not known

Jan  5 10:57:38 windu ipsec__plutorun: 021 no connection named
"packetdefault"

Jan  5 10:57:38 windu ipsec__plutorun: ...could not route conn
"packetdefault"

Jan  5 10:57:38 windu ipsec__plutorun: 021 no connection named "block"

Jan  5 10:57:38 windu ipsec__plutorun: ...could not route conn "block"

Jan  5 10:57:38 windu ipsec__plutorun: 021 no connection named
"clear-or-private"

Jan  5 10:57:39 windu ipsec__plutorun: ...could not route conn
"clear-or-private"

Jan  5 10:57:39 windu ipsec__plutorun: 021 no connection named "clear"

Jan  5 10:57:39 windu ipsec__plutorun: ...could not route conn "clear"

Jan  5 10:57:39 windu ipsec__plutorun: 021 no connection named
"private-or-clear"

Jan  5 10:57:39 windu ipsec__plutorun: ...could not route conn
"private-or-clear"

Jan  5 10:57:39 windu ipsec__plutorun: 021 no connection named "private"

Jan  5 10:57:39 windu ipsec__plutorun: ...could not route conn "private"

+ _________________________ plog

+ sed -n '265,$p' /var/log/secure

+ egrep -i pluto

+ case "$1" in

+ cat

Jan  5 10:57:34 windu ipsec__plutorun: Starting Pluto subsystem...

Jan  5 10:57:35 windu pluto[4637]: Starting Pluto (Openswan Version
2.4.13 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR; Vendor ID OE`fijAufQMD)

Jan  5 10:57:35 windu pluto[4637]: Setting NAT-Traversal port-4500
floating to off

Jan  5 10:57:35 windu pluto[4637]:    port floating activation criteria
nat_t=0/port_fload=1

Jan  5 10:57:35 windu pluto[4637]:   including NAT-Traversal patch
(Version 0.6c) [disabled]

Jan  5 10:57:35 windu pluto[4637]: ike_alg_register_enc(): Activating
OAKLEY_AES_CBC: Ok (ret=0)

Jan  5 10:57:35 windu pluto[4637]: starting up 1 cryptographic helpers

Jan  5 10:57:35 windu pluto[4637]: started helper pid=4638 (fd:6)

Jan  5 10:57:35 windu pluto[4637]: Using KLIPS IPsec interface code on
2.6.19-smp

Jan  5 10:57:35 windu pluto[4637]: Changing to directory
'/etc/ipsec.d/cacerts'

Jan  5 10:57:35 windu pluto[4637]: Changing to directory
'/etc/ipsec.d/aacerts'

Jan  5 10:57:35 windu pluto[4637]: Changing to directory
'/etc/ipsec.d/ocspcerts'

Jan  5 10:57:35 windu pluto[4637]: Changing to directory
'/etc/ipsec.d/crls'

Jan  5 10:57:35 windu pluto[4637]:   Warning: empty directory

Jan  5 10:57:35 windu pluto[4637]: added connection description
"stmarks_pacs2"

Jan  5 10:57:37 windu pluto[4637]: added connection description
"stmarks_meditech"

Jan  5 10:57:37 windu pluto[4637]: added connection description
"stmarks_pacs"

Jan  5 10:57:37 windu pluto[4637]: added connection description
"stmarks_tracemaster"

Jan  5 10:57:38 windu pluto[4637]: listening for IKE messages

Jan  5 10:57:38 windu pluto[4637]: adding interface ipsec0/eth0
10.65.33.253:500

Jan  5 10:57:38 windu pluto[4637]: loading secrets from
"/etc/ipsec.secrets"

Jan  5 10:57:47 windu pluto[4637]: "stmarks_meditech" #1: initiating
Aggressive Mode #1, connection "stmarks_meditech"

Jan  5 10:57:47 windu pluto[4637]: "stmarks_meditech" #1: received
Vendor ID payload [Cisco-Unity]

Jan  5 10:57:47 windu pluto[4637]: "stmarks_meditech" #1: received
Vendor ID payload [XAUTH]

Jan  5 10:57:47 windu pluto[4637]: "stmarks_meditech" #1: received
Vendor ID payload [Dead Peer Detection]

Jan  5 10:57:47 windu pluto[4637]: "stmarks_meditech" #1: ignoring
Vendor ID payload [FRAGMENTATION c0000000]

Jan  5 10:57:47 windu pluto[4637]: "stmarks_meditech" #1: ignoring
Vendor ID payload [Cisco VPN 3000 Series]

Jan  5 10:57:47 windu pluto[4637]: "stmarks_meditech" #1: protocol/port
in Phase 1 ID Payload must be 0/0 or 17/500 but are 17/0

Jan  5 10:57:47 windu pluto[4637]: "stmarks_meditech" #1: Aggressive
mode peer ID is ID_IPV4_ADDR: '199.91.34.69'

Jan  5 10:57:47 windu pluto[4637]: "stmarks_meditech" #1: protocol/port
in Phase 1 ID Payload must be 0/0 or 17/500 but are 17/0

Jan  5 10:57:47 windu pluto[4637]: "stmarks_meditech" #1: Aggressive
mode peer ID is ID_IPV4_ADDR: '199.91.34.69'

Jan  5 10:57:47 windu pluto[4637]: "stmarks_meditech" #1: transition
from state STATE_AGGR_I1 to state STATE_AGGR_I2

Jan  5 10:57:47 windu pluto[4637]: "stmarks_meditech" #1: STATE_AGGR_I2:
sent AI2, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY
cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}

Jan  5 10:57:47 windu pluto[4637]: "stmarks_meditech" #2: initiating
Quick Mode PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE {using isakmp#1}

Jan  5 10:57:48 windu pluto[4637]: "stmarks_meditech" #2: transition
from state STATE_QUICK_I1 to state STATE_QUICK_I2

Jan  5 10:57:48 windu pluto[4637]: "stmarks_meditech" #2:
STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x824bfd5f
<0xa1558950 xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}

Jan  5 10:57:49 windu pluto[4637]: "stmarks_pacs" #3: initiating Quick
Mode PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE {using isakmp#1}

Jan  5 10:57:50 windu pluto[4637]: "stmarks_pacs" #3: transition from
state STATE_QUICK_I1 to state STATE_QUICK_I2

Jan  5 10:57:50 windu pluto[4637]: "stmarks_pacs" #3: STATE_QUICK_I2:
sent QI2, IPsec SA established {ESP=>0xdf4e67d5 <0xa1558951
xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}

Jan  5 10:57:51 windu pluto[4637]: "stmarks_tracemaster" #4: initiating
Quick Mode PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE {using isakmp#1}

Jan  5 10:57:52 windu pluto[4637]: "stmarks_tracemaster" #4: transition
from state STATE_QUICK_I1 to state STATE_QUICK_I2

Jan  5 10:57:52 windu pluto[4637]: "stmarks_tracemaster" #4:
STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x2811a7fb
<0xa1558952 xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}

Jan  5 10:57:53 windu pluto[4637]: "stmarks_pacs2" #5: initiating Quick
Mode PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE {using isakmp#1}

Jan  5 10:57:53 windu pluto[4637]: "stmarks_pacs2" #5: transition from
state STATE_QUICK_I1 to state STATE_QUICK_I2

Jan  5 10:57:53 windu pluto[4637]: "stmarks_pacs2" #5: STATE_QUICK_I2:
sent QI2, IPsec SA established {ESP=>0x8cbcff6f <0xa1558953
xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}

Jan  5 11:27:57 windu pluto[4637]: "stmarks_meditech" #1: received
Delete SA payload: replace IPSEC State #4 in 10 seconds

Jan  5 11:27:57 windu pluto[4637]: "stmarks_meditech" #1: received and
ignored informational message

Jan  5 11:27:57 windu pluto[4637]: "stmarks_meditech" #1: received
Delete SA payload: replace IPSEC State #3 in 10 seconds

Jan  5 11:27:57 windu pluto[4637]: "stmarks_meditech" #1: received and
ignored informational message

Jan  5 11:28:07 windu pluto[4637]: "stmarks_pacs" #6: initiating Quick
Mode PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE to replace #3 {using isakmp#1}

Jan  5 11:28:07 windu pluto[4637]: "stmarks_tracemaster" #7: initiating
Quick Mode PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE to replace #4 {using
isakmp#1}

Jan  5 11:28:07 windu pluto[4637]: "stmarks_pacs" #6: transition from
state STATE_QUICK_I1 to state STATE_QUICK_I2

Jan  5 11:28:07 windu pluto[4637]: "stmarks_pacs" #6: STATE_QUICK_I2:
sent QI2, IPsec SA established {ESP=>0x3dce2648 <0xa1558954
xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}

Jan  5 11:28:07 windu pluto[4637]: "stmarks_tracemaster" #7: transition
from state STATE_QUICK_I1 to state STATE_QUICK_I2

Jan  5 11:28:07 windu pluto[4637]: "stmarks_tracemaster" #7:
STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0xcc29b7a4
<0xa1558955 xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}

Jan  5 11:40:14 windu pluto[4637]: "stmarks_meditech" #8: initiating
Aggressive Mode #8 to replace #1, connection "stmarks_meditech"

Jan  5 11:40:14 windu pluto[4637]: "stmarks_meditech" #8: received
Vendor ID payload [Cisco-Unity]

Jan  5 11:40:14 windu pluto[4637]: "stmarks_meditech" #8: received
Vendor ID payload [XAUTH]

Jan  5 11:40:14 windu pluto[4637]: "stmarks_meditech" #8: received
Vendor ID payload [Dead Peer Detection]

Jan  5 11:40:14 windu pluto[4637]: "stmarks_meditech" #8: ignoring
Vendor ID payload [FRAGMENTATION c0000000]

Jan  5 11:40:14 windu pluto[4637]: "stmarks_meditech" #8: ignoring
Vendor ID payload [Cisco VPN 3000 Series]

Jan  5 11:40:14 windu pluto[4637]: "stmarks_meditech" #8: protocol/port
in Phase 1 ID Payload must be 0/0 or 17/500 but are 17/0

Jan  5 11:40:14 windu pluto[4637]: "stmarks_meditech" #8: Aggressive
mode peer ID is ID_IPV4_ADDR: '199.91.34.69'

Jan  5 11:40:14 windu pluto[4637]: "stmarks_meditech" #8: protocol/port
in Phase 1 ID Payload must be 0/0 or 17/500 but are 17/0

Jan  5 11:40:14 windu pluto[4637]: "stmarks_meditech" #8: Aggressive
mode peer ID is ID_IPV4_ADDR: '199.91.34.69'

Jan  5 11:40:14 windu pluto[4637]: "stmarks_meditech" #8: transition
from state STATE_AGGR_I1 to state STATE_AGGR_I2

Jan  5 11:40:14 windu pluto[4637]: "stmarks_meditech" #8: STATE_AGGR_I2:
sent AI2, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY
cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}

Jan  5 12:07:27 windu pluto[4637]: "stmarks_meditech" #8: received
Delete SA payload: replace IPSEC State #5 in 10 seconds

Jan  5 12:07:27 windu pluto[4637]: "stmarks_meditech" #8: received and
ignored informational message

Jan  5 12:07:37 windu pluto[4637]: "stmarks_pacs2" #9: initiating Quick
Mode PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE to replace #5 {using isakmp#8}

Jan  5 12:07:37 windu pluto[4637]: "stmarks_pacs2" #9: transition from
state STATE_QUICK_I1 to state STATE_QUICK_I2

Jan  5 12:07:37 windu pluto[4637]: "stmarks_pacs2" #9: STATE_QUICK_I2:
sent QI2, IPsec SA established {ESP=>0x8fe9e232 <0xa1558956
xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}

Jan  5 12:25:14 windu pluto[4637]: packet from 199.91.34.69:500:
received Vendor ID payload [Cisco-Unity]

Jan  5 12:25:14 windu pluto[4637]: packet from 199.91.34.69:500:
received Vendor ID payload [XAUTH]

Jan  5 12:25:14 windu pluto[4637]: packet from 199.91.34.69:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106,
but port floating is off

Jan  5 12:25:14 windu pluto[4637]: packet from 199.91.34.69:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but
port floating is off

Jan  5 12:25:14 windu pluto[4637]: packet from 199.91.34.69:500:
ignoring Vendor ID payload [FRAGMENTATION c0000000]

Jan  5 12:25:14 windu pluto[4637]: "stmarks_pacs2" #10: protocol/port in
Phase 1 ID Payload must be 0/0 or 17/500 but are 17/0

Jan  5 12:25:14 windu pluto[4637]: "stmarks_pacs2" #10: Aggressive mode
peer ID is ID_IPV4_ADDR: '199.91.34.69'

Jan  5 12:25:14 windu pluto[4637]: "stmarks_pacs2" #10: responding to
Aggressive Mode, state #10, connection "stmarks_pacs2" from 199.91.34.69

Jan  5 12:25:14 windu pluto[4637]: "stmarks_pacs2" #10: transition from
state STATE_AGGR_R0 to state STATE_AGGR_R1

Jan  5 12:25:14 windu pluto[4637]: "stmarks_pacs2" #10: STATE_AGGR_R1:
sent AR1, expecting AI2

Jan  5 12:25:14 windu pluto[4637]: "stmarks_pacs2" #10: received Vendor
ID payload [Dead Peer Detection]

Jan  5 12:25:14 windu pluto[4637]: "stmarks_pacs2" #10: ignoring Vendor
ID payload [Cisco VPN 3000 Series]

Jan  5 12:25:14 windu pluto[4637]: "stmarks_pacs2" #10: Aggressive mode
peer ID is ID_IPV4_ADDR: '199.91.34.69'

Jan  5 12:25:14 windu pluto[4637]: "stmarks_pacs2" #10: received Hash
Payload does not match computed value

Jan  5 12:25:14 windu pluto[4637]: "stmarks_pacs2" #10: sending
encrypted notification INVALID_HASH_INFORMATION to 199.91.34.69:500

Jan  5 12:25:52 windu pluto[4637]: "stmarks_meditech" #8: received
Delete SA payload: deleting ISAKMP State #8

Jan  5 12:25:52 windu pluto[4637]: packet from 199.91.34.69:500:
received and ignored informational message

Jan  5 12:26:03 windu pluto[4637]: "stmarks_pacs2" #10: next payload
type of ISAKMP Hash Payload has an unknown value: 180

Jan  5 12:26:03 windu pluto[4637]: "stmarks_pacs2" #10: malformed
payload in packet

Jan  5 12:26:03 windu pluto[4637]: | payload malformed after IV

Jan  5 12:26:03 windu pluto[4637]: |   41 77 8e 33  c5 40 5a a5  94 33
84 f2  7f fe f8 eb

Jan  5 12:26:03 windu pluto[4637]: |   ce e3 99 33

Jan  5 12:26:03 windu pluto[4637]: "stmarks_pacs2" #10: sending
notification PAYLOAD_MALFORMED to 199.91.34.69:500

Jan  5 12:26:05 windu pluto[4637]: "stmarks_pacs2" #10: next payload
type of ISAKMP Hash Payload has an unknown value: 250

Jan  5 12:26:05 windu pluto[4637]: "stmarks_pacs2" #10: malformed
payload in packet

Jan  5 12:26:05 windu pluto[4637]: | payload malformed after IV

Jan  5 12:26:05 windu pluto[4637]: |   41 77 8e 33  c5 40 5a a5  94 33
84 f2  7f fe f8 eb

Jan  5 12:26:05 windu pluto[4637]: |   ce e3 99 33

Jan  5 12:26:05 windu pluto[4637]: "stmarks_pacs2" #10: sending
notification PAYLOAD_MALFORMED to 199.91.34.69:500

Jan  5 12:26:07 windu pluto[4637]: "stmarks_pacs2" #10: next payload
type of ISAKMP Hash Payload has an unknown value: 209

Jan  5 12:26:07 windu pluto[4637]: "stmarks_pacs2" #10: malformed
payload in packet

Jan  5 12:26:07 windu pluto[4637]: | payload malformed after IV

Jan  5 12:26:07 windu pluto[4637]: |   41 77 8e 33  c5 40 5a a5  94 33
84 f2  7f fe f8 eb

Jan  5 12:26:07 windu pluto[4637]: |   ce e3 99 33

Jan  5 12:26:07 windu pluto[4637]: "stmarks_pacs2" #10: sending
notification PAYLOAD_MALFORMED to 199.91.34.69:500

Jan  5 12:26:09 windu pluto[4637]: "stmarks_pacs2" #10: next payload
type of ISAKMP Hash Payload has an unknown value: 163

Jan  5 12:26:09 windu pluto[4637]: "stmarks_pacs2" #10: malformed
payload in packet

Jan  5 12:26:09 windu pluto[4637]: | payload malformed after IV

Jan  5 12:26:09 windu pluto[4637]: |   41 77 8e 33  c5 40 5a a5  94 33
84 f2  7f fe f8 eb

Jan  5 12:26:09 windu pluto[4637]: |   ce e3 99 33

Jan  5 12:26:09 windu pluto[4637]: "stmarks_pacs2" #10: sending
notification PAYLOAD_MALFORMED to 199.91.34.69:500

Jan  5 12:26:09 windu pluto[4637]: "stmarks_pacs2" #10: next payload
type of ISAKMP Hash Payload has an unknown value: 120

Jan  5 12:26:09 windu pluto[4637]: "stmarks_pacs2" #10: malformed
payload in packet

Jan  5 12:26:09 windu pluto[4637]: "stmarks_pacs2" #10: next payload
type of ISAKMP Hash Payload has an unknown value: 25

Jan  5 12:26:09 windu pluto[4637]: "stmarks_pacs2" #10: malformed
payload in packet

Jan  5 12:26:09 windu pluto[4637]: "stmarks_pacs2" #10: next payload
type of ISAKMP Hash Payload has an unknown value: 229

Jan  5 12:26:09 windu pluto[4637]: "stmarks_pacs2" #10: malformed
payload in packet

Jan  5 12:26:09 windu pluto[4637]: "stmarks_pacs2" #10: next payload
type of ISAKMP Hash Payload has an unknown value: 226

Jan  5 12:26:09 windu pluto[4637]: "stmarks_pacs2" #10: malformed
payload in packet

Jan  5 12:26:24 windu pluto[4637]: "stmarks_pacs2" #10: max number of
retransmissions (2) reached STATE_AGGR_R1

+ _________________________ date

+ date

Mon Jan  5 12:46:36 MST 2009 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090105/d1fa3cad/attachment-0001.html 

From richard at mdr.co.uk  Tue Jan  6 01:45:19 2009
From: richard at mdr.co.uk (Richard de Rivaz)
Date: Tue, 6 Jan 2009 06:45:19 +0000
Subject: [Openswan Users] Openswan on Ubuntu 8.10
In-Reply-To: <49626038.1e068e0a.3dbf.ffff903d@mx.google.com>
References: <1230572347383031500@mdr.co.uk> <1231153425871598500@mdr.co.uk>
	<49626038.1e068e0a.3dbf.ffff903d@mx.google.com>
Message-ID: <1231224319885861500@mdr.co.uk>

Hi Aaron

Thanks for your helpful email. I am still stuck early in the process!

1. sudo apt-get ?purge remove openswanipsec-tools raccoon vpnc

does not appear to like purge and remove in the same command line.

2. sudo sysctl -a | grep 'ip4.conf.*redirect'

gives the following errors:

error: "Invalid argument" reading key "fs.binfmt_misc.register"
error: permission denied on key 'net.ipv4.route.flush'

So I cannot progress beyond the 'ipsec verify' stage.

The config file is currently:

#
# /etc/sysctl.conf - Configuration file for setting system variables
# See /etc/sysctl.d/ for additional system variables.
# See sysctl.conf (5) for information.
#

#kernel.domainname = example.com

# Uncomment the following to stop low-level messages on console
#kernel.printk = 4 4 1 7

##############################################################3
# Functions previously found in netbase
#

# Uncomment the next two lines to enable Spoof protection (reverse-path filter)
# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks
net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1

# Uncomment the next line to enable TCP/IP SYN cookies
# This disables TCP Window Scaling (http://lkml.org/lkml/2008/2/5/167),
# and is not recommended.
#net.ipv4.tcp_syncookies=1

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=0

# Uncomment the next line to enable packet forwarding for IPv6
net.ipv6.conf.all.forwarding=0


###################################################################
# Additional settings - these settings can improve the network
# security of the host and prevent against some network attacks
# including spoofing attacks and man in the middle attacks through
# redirection. Some network environments, however, require that these
# settings are disabled so review and enable them as needed.
#
# Ignore ICMP broadcasts
net.ipv4.icmp_echo_ignore_broadcasts = 1
#
# Ignore bogus ICMP errors
net.ipv4.icmp_ignore_bogus_error_responses = 1
# 
# Do not accept ICMP redirects (prevent MITM attacks)
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
# _or_
# Accept ICMP redirects only for gateways listed in our default
# gateway list (enabled by default)
# net.ipv4.conf.all.secure_redirects = 1
#
# Do not send ICMP redirects (we are not a router)
net.ipv4.conf.all.send_redirects = 0
#
# Do not accept IP source route packets (we are not a router)
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
#
# Log Martian Packets
net.ipv4.conf.all.log_martians = 1
#
# The contents of /proc/<pid>/maps and smaps files are only visible to 
# readers that are allowed to ptrace() the process
# sys.kernel.maps_protect = 1


Regards Richard
-- 

Richard de Rivaz
MDR Interfaces Ltd
Computer Control Specialists

Tel: +44(0)1825 790294  Fax: +44(0)1825 790119
Reg in England No. 1577056 Directors: R de Rivaz   Z de Rivaz
Reg Address: Little Bridge House, Danehill, Sussex RH17 7JD

http://www.mdr.co.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090106/593f6efb/attachment.html 

From p.isajew at telecommedia.pl  Tue Jan  6 05:13:47 2009
From: p.isajew at telecommedia.pl (Piotr Isajew)
Date: Tue, 6 Jan 2009 11:13:47 +0100
Subject: [Openswan Users] Tunnel up but packets not forwarded to internal
	iface. Please help.
Message-ID: <20090106101347.GB3052@uglyrabbit.telecommedia.pl>

Hi,

I'm trying to set up an ipsec connection using openswan (linux 2.6 on
one gateway linux 2.4 on another).

The goal is to have something like this:

192.168.3.0/24===62.89.67.100---62.89.67.97...217.8.185.140===192.168.1.0/24

		      ^				^
		      |				|
		      fw2			fw1

I've configured the left side of that, so it connects to the right
side. It looks like the tunnel is established, routing and iptables configured
correctly. Outgoing packets go to the other side, reply packets are
received and decrypted, but not forwarded to internal interface. 

The same machine serves as a firewall and nat for local network. Now,
if I try to ping a host in 192.168.1.0/24 from a client in
192.168.3.0/24 it does not receive any reply. Running tcpdump on fw2
shows both outgoing ICMP Echo Requests on fw2's internal interface,
and ICMP Echo Responses on it's external interface, so it looks like
the tunnel is working. The problem is I do not receive any ICMP
Replies on the host, from which I ping the other side.

I thought that this may be nat related issue, but if I simplify
iptables (i.e. set default policy to accept and flush any nat rules)
the result is the same. I will appreciate any help as I ran out of
ideas what can cause this behaviour. Configuration and diagnostic
output for this case is included below.


Regards,

Piotr



ipsec auto --status shows that connection is established:

000 "biuro-gts":
192.168.3.0/24===62.89.67.100---62.89.67.97...217.8.185.140===192.168.1.0/24;
erouted; eroute owner: #4
000 "biuro-gts":     srcip=unset; dstip=unset; srcup=ipsec _updown;
dstup=ipsec _updown;
000 "biuro-gts":   ike_life: 28800s; ipsec_life: 28800s; rekey_margin:
540s; rekey_fuzz: 100%; keyingtries: 0
000 "biuro-gts":   policy:
PSK+ENCRYPT+TUNNEL+PFS+DISABLEARRIVALCHECK+UP; prio: 24,24; interface:
eth1:2; encap: esp;
000 "biuro-gts":   dpd: action:hold; delay:30; timeout:1200;
000 "biuro-gts":   newest ISAKMP SA: #1; newest IPsec SA: #4;
000 "biuro-gts":   IKE algorithms wanted:
3DES_CBC(5)_000-SHA1(2)-MODP1024(2); flags=strict
000 "biuro-gts":   IKE algorithms found:
3DES_CBC(5)_192-SHA1(2)_160-MODP1024(2)
000 "biuro-gts":   IKE algorithm newest: 3DES_CBC_192-SHA1-MODP1024
000 "biuro-gts":   ESP algorithms wanted: 3DES(3)_000-MD5(1);
pfsgroup=MODP1024(2); flags=strict
000 "biuro-gts":   ESP algorithms loaded: 3DES(3)_000-MD5(1);
pfsgroup=MODP1024(2); flags=strict
000 "biuro-gts":   ESP algorithm newest: 3DES_0-HMAC_MD5;
pfsgroup=MODP1024
000
000 #4: "biuro-gts":500 STATE_QUICK_R2 (IPsec SA established);
EVENT_SA_REPLACE in 18810s; newest IPSEC; eroute owner
000 #4: "biuro-gts" esp.73237bc6 at 217.8.185.140
esp.5fc61f2d at 62.89.67.100 tun.0 at 217.8.185.140 tun.0 at 62.89.67.100
000 #3: "biuro-gts":500 STATE_QUICK_I2 (sent QI2, IPsec SA
established); EVENT_SA_REPLACE in 18333s
000 #3: "biuro-gts" esp.73237bc7 at 217.8.185.140
esp.f856c776 at 62.89.67.100 tun.0 at 217.8.185.140 tun.0 at 62.89.67.100
000 #2: "biuro-gts":500 STATE_QUICK_I2 (sent QI2, IPsec SA
established); EVENT_SA_REPLACE in 18003s
000 #2: "biuro-gts" esp.73237bc5 at 217.8.185.140
esp.bcfbfb91 at 62.89.67.100 tun.0 at 217.8.185.140 tun.0 at 62.89.67.100
000 #1: "biuro-gts":500 STATE_MAIN_I4 (ISAKMP SA established); none in
-1s; newest ISAKMP; lastdpd=1s(seq in:14762 out:0)

If I try to ping remote side from a host in my local network it looks
like below:

mbp:~ pki$ ping -c 3 192.168.1.200
PING 192.168.1.200 (192.168.1.200): 56 data bytes

--- 192.168.1.200 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

tcpdump on fw2's internal interface shows that packets are going out:

tcpdump -i eth0 -n host 192.168.1.200
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
09:58:06.987232 IP 192.168.3.254 > 192.168.1.200: ICMP echo request, id 10006, seq 0, length 64
09:58:07.986826 IP 192.168.3.254 > 192.168.1.200: ICMP echo request, id 10006, seq 1, length 64
09:58:08.987121 IP 192.168.3.254 > 192.168.1.200: ICMP echo request, id 10006, seq 2, length 64


and it's external interface shows the incoming replies:

tcpdump -i eth1 -n host 192.168.1.200
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
09:58:07.006507 IP 192.168.1.200 > 192.168.3.254: ICMP echo reply, id 10006, seq 0, length 64
09:58:07.997158 IP 192.168.1.200 > 192.168.3.254: ICMP echo reply, id 10006, seq 1, length 64
09:58:08.996905 IP 192.168.1.200 > 192.168.3.254: ICMP echo reply, id 10006, seq 2, length 64


Some diagnostic output and config are included below:

sh-3.2$ sudo ipsec auto --version
Linux Openswan U2.4.12/K2.6.24.7-grsec (netkey)
See `ipsec --copyright' for copyright information.

sh-3.2$ sudo 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.12/K2.6.24.7-grsec (netkey)
Checking for IPsec support in kernel                        	[OK]
NETKEY detected, testing for disabled ICMP send_redirects   	[OK]
NETKEY detected, testing for disabled ICMP accept_redirects 	[OK]
Checking for RSA private key (/etc/ipsec.secrets)           	[DISABLED]
  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]
Opportunistic Encryption Support                            	[DISABLED]


sh-3.2$ cat /etc/ipsec.conf
version	2.0	# conforms to second version of ipsec.conf specification
config setup
	# plutodebug / klipsdebug = "all", "none" or a combation from below:
	klipsdebug = "all"
	plutodebug = "all"
	uniqueids = "yes"
#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf

conn biuro-gts
       left=62.89.67.100
       leftsubnet=192.168.3.0/24
       leftnexthop=62.89.67.97
       right=217.8.185.140
       rightsubnet=192.168.1.0/24
       authby=secret
       auth=esp
       pfs=yes
       pfsgroup=modp1024
       auto=start
       ikelifetime=28800
       keylife=28800
       disablearrivalcheck=yes
       ike=3des-sha-modp1024
       esp=3des-md5
       dpdtimeout=200
       keyingtries=0

sh-3.2$ cat /proc/sys/net/ipv4/ip_forward
1

sh-3.2$ sudo iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  192.168.3.0/24       192.168.3.1         
ACCEPT     all  --  172.17.86.0/24       0.0.0.0/0           
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp spts:1024:65535 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp spts:1024:65535 
ACCEPT     esp  --  217.8.185.140        62.89.67.100        
ACCEPT     udp  --  217.8.185.140        62.89.67.100        udp spt:500 dpt:500 
DROP       udp  --  0.0.0.0/0            0.0.0.0/0           udp dpts:137:138 
LOG        all  --  0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 
DROP       all  --  0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
ACCEPT     tcp  --  0.0.0.0/0            192.168.3.5         tcp dpt:53 
ACCEPT     udp  --  0.0.0.0/0            192.168.3.5         udp dpt:53 
ACCEPT     tcp  --  0.0.0.0/0            172.17.86.5         tcp dpt:25 
ACCEPT     tcp  --  0.0.0.0/0            172.17.86.5         tcp dpt:110 
DROP       udp  --  0.0.0.0/0            0.0.0.0/0           udp dpts:137:138 
LOG        all  --  0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 
DROP       all  --  0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  192.168.3.1          192.168.3.0/24      
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp spts:1024:65535 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp spts:1024:65535 
ACCEPT     esp  --  62.89.67.100         217.8.185.140       
ACCEPT     udp  --  62.89.67.100         217.8.185.140       udp spt:500 dpt:500 
sh-3.2$ sudo iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DNAT       tcp  --  0.0.0.0/0            62.89.67.98         tcp dpt:110 to:172.17.86.5 
DNAT       tcp  --  0.0.0.0/0            62.89.67.98         tcp dpt:25 to:172.17.86.5 
DNAT       tcp  --  0.0.0.0/0            62.89.88.188        tcp dpt:53 to:192.168.3.5 
DNAT       udp  --  0.0.0.0/0            62.89.88.188        udp dpt:53 to:192.168.3.5 

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
SNAT       tcp  --  192.168.3.5          0.0.0.0/0           to:62.89.88.188 
SNAT       udp  --  192.168.3.5          0.0.0.0/0           to:62.89.88.188 
SNAT       all  --  192.168.3.0/24      !192.168.1.0/24      to:62.89.67.98 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Btw. iptables logging doesn't show any packets related to my problem
to be dropped.


From david at craigon.co.uk  Tue Jan  6 06:50:42 2009
From: david at craigon.co.uk (David J Craigon)
Date: Tue, 6 Jan 2009 11:50:42 +0000
Subject: [Openswan Users] Can't get NAT traversal to work
In-Reply-To: <c1ace6860901041434o1bbb042bgfa0b87272ea3a7c7@mail.gmail.com>
References: <c1ace6860901010320y44268a18sacf85f2ebab7157e@mail.gmail.com>
	<Pine.LNX.4.64.0901011955230.6849@newtla.xelerance.com>
	<c1ace6860901041434o1bbb042bgfa0b87272ea3a7c7@mail.gmail.com>
Message-ID: <c1ace6860901060350t141f5379q29cfc6c1f280b388@mail.gmail.com>

Could anyone help me with this? Just to summarise- I'm using PSK, and

2009/1/4 David J Craigon <david at craigon.co.uk>

> Hi,
>
> Thanks for the reply, but it still doesn't work for me. I'm not totally
> sure what the difference is between the config you've given me, and the one
> I'm using- as far as I can tell I _am_ using PSK- I got the codes from ipsec
> showhost key.
>
> Thanks,
>
> David
>
> 2009/1/2 Paul Wouters <paul at xelerance.com>
>
> On Thu, 1 Jan 2009, David J Craigon wrote:
>>
>> > Anyway, I cannot get NAT traversal to work. My setup is as follows- I
>> want
>> > to get a VPN running between two hosts both running Openswan. One is on
>> the
>> > internet and has a public IP address, and is running Fedora 9. The other
>> is
>> > my laptop sat at home behind a NAT running Fedora 10.
>>
>> I have a similar setup on my laptop, where I tunnel my own /29 onto my
>> laptop.
>>
>> > conn host-to-host
>> >     left=192.168.2.34
>> >     leftid=81.76.68.138
>> >     leftnexthop=192.168.2.1
>> >     leftsubnet=192.168.2.0/24
>> >  leftrsasigkey=blah blah blah
>> >     right=94.102.146.99               # Remote vitals
>> >     rightid=94.102.146.99
>> >     rightsubnet=94.102.146.96/29
>> >     rightrsasigkey=blah blah blah
>> >     rightnexthop=94.102.146.97     # correct in many situations
>> >     auto=add                       # authorizes but doesn't start this
>> >                                    # connection at startup
>>
>> With both ends being openswan, ditch PSK and use raw RSA. eg:
>>
>>        authby=rsasig
>>        leftrsasigkey=XXXX
>>        rightrsasigkey=YYY
>>        leftid=@laptop
>>        rightid=@server
>>        left=%defaultroute
>>
>> get the rsasigkey lines using: ipsec showhostkey --left (--right) on the
>> two machines. This will avoid PSK authentication by IP while having other
>> IP's due to NAT.
>>
>> >
>> > When I do on the box behind the NAT I get:
>> >
>> > [root at localhost log]# ipsec auto --up host-to-host
>> > 104 "host-to-host" #1: STATE_MAIN_I1: initiate
>> > 010 "host-to-host" #1: STATE_MAIN_I1: retransmission; will wait 20s for
>> > response
>> >
>> >
>> > and I see in /etc/secure on the remote box:
>> > Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500:
>> ignoring
>> > unknown Vendor ID payload [4f457d5a765a404d5b4f5744]
>> > Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500:
>> received
>> > Vendor ID payload [Dead Peer Detection]
>> > Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500:
>> received
>> > Vendor ID payload [RFC 3947] method set to=109
>> > Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500:
>> received
>> > Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already
>> > using method 109
>> > Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500:
>> received
>> > Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but
>> already
>> > using method 109
>> > Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500:
>> received
>> > Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already
>> > using method 109
>> > Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500:
>> initial
>> > Main Mode message received on 94.102.146.99:500 but no connection has
>> been
>> > authorized with policy=RSASIG
>>
>> You are missing authby=secret to use PSK's on the laptop.
>>
>> Paul
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090106/08532e88/attachment-0001.html 

From david at craigon.co.uk  Tue Jan  6 06:51:34 2009
From: david at craigon.co.uk (David J Craigon)
Date: Tue, 6 Jan 2009 11:51:34 +0000
Subject: [Openswan Users] Can't get NAT traversal to work
In-Reply-To: <c1ace6860901060350t141f5379q29cfc6c1f280b388@mail.gmail.com>
References: <c1ace6860901010320y44268a18sacf85f2ebab7157e@mail.gmail.com>
	<Pine.LNX.4.64.0901011955230.6849@newtla.xelerance.com>
	<c1ace6860901041434o1bbb042bgfa0b87272ea3a7c7@mail.gmail.com>
	<c1ace6860901060350t141f5379q29cfc6c1f280b388@mail.gmail.com>
Message-ID: <c1ace6860901060351l7c6ef4bw6134f6fb4ef219c5@mail.gmail.com>

Sorry- lent on the send button :-(. So to summarise, I'm using PSK and NAT
traversal isn't working- see my original error logs at the end.

Any help would be much appreciated.

2009/1/6 David J Craigon <david at craigon.co.uk>

> Could anyone help me with this? Just to summarise- I'm using PSK, and
>
> 2009/1/4 David J Craigon <david at craigon.co.uk>
>
> Hi,
>>
>> Thanks for the reply, but it still doesn't work for me. I'm not totally
>> sure what the difference is between the config you've given me, and the one
>> I'm using- as far as I can tell I _am_ using PSK- I got the codes from ipsec
>> showhost key.
>>
>> Thanks,
>>
>> David
>>
>> 2009/1/2 Paul Wouters <paul at xelerance.com>
>>
>> On Thu, 1 Jan 2009, David J Craigon wrote:
>>>
>>> > Anyway, I cannot get NAT traversal to work. My setup is as follows- I
>>> want
>>> > to get a VPN running between two hosts both running Openswan. One is on
>>> the
>>> > internet and has a public IP address, and is running Fedora 9. The
>>> other is
>>> > my laptop sat at home behind a NAT running Fedora 10.
>>>
>>> I have a similar setup on my laptop, where I tunnel my own /29 onto my
>>> laptop.
>>>
>>> > conn host-to-host
>>> >     left=192.168.2.34
>>> >     leftid=81.76.68.138
>>> >     leftnexthop=192.168.2.1
>>> >     leftsubnet=192.168.2.0/24
>>> >  leftrsasigkey=blah blah blah
>>> >     right=94.102.146.99               # Remote vitals
>>> >     rightid=94.102.146.99
>>> >     rightsubnet=94.102.146.96/29
>>> >     rightrsasigkey=blah blah blah
>>> >     rightnexthop=94.102.146.97     # correct in many situations
>>> >     auto=add                       # authorizes but doesn't start this
>>> >                                    # connection at startup
>>>
>>> With both ends being openswan, ditch PSK and use raw RSA. eg:
>>>
>>>        authby=rsasig
>>>        leftrsasigkey=XXXX
>>>        rightrsasigkey=YYY
>>>        leftid=@laptop
>>>        rightid=@server
>>>        left=%defaultroute
>>>
>>> get the rsasigkey lines using: ipsec showhostkey --left (--right) on the
>>> two machines. This will avoid PSK authentication by IP while having other
>>> IP's due to NAT.
>>>
>>> >
>>> > When I do on the box behind the NAT I get:
>>> >
>>> > [root at localhost log]# ipsec auto --up host-to-host
>>> > 104 "host-to-host" #1: STATE_MAIN_I1: initiate
>>> > 010 "host-to-host" #1: STATE_MAIN_I1: retransmission; will wait 20s for
>>> > response
>>> >
>>> >
>>> > and I see in /etc/secure on the remote box:
>>> > Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500:
>>> ignoring
>>> > unknown Vendor ID payload [4f457d5a765a404d5b4f5744]
>>> > Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500:
>>> received
>>> > Vendor ID payload [Dead Peer Detection]
>>> > Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500:
>>> received
>>> > Vendor ID payload [RFC 3947] method set to=109
>>> > Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500:
>>> received
>>> > Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already
>>> > using method 109
>>> > Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500:
>>> received
>>> > Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but
>>> already
>>> > using method 109
>>> > Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500:
>>> received
>>> > Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already
>>> > using method 109
>>> > Jan  1 11:14:57 server pluto[17123]: packet from 81.76.68.138:500:
>>> initial
>>> > Main Mode message received on 94.102.146.99:500 but no connection has
>>> been
>>> > authorized with policy=RSASIG
>>>
>>> You are missing authby=secret to use PSK's on the laptop.
>>>
>>> Paul
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090106/e425bb15/attachment.html 

From p.isajew at telecommedia.pl  Tue Jan  6 10:33:15 2009
From: p.isajew at telecommedia.pl (Piotr Isajew)
Date: Tue, 6 Jan 2009 16:33:15 +0100
Subject: [Openswan Users] Tunnel up but packets not forwarded
	to	internal iface. Please help.
In-Reply-To: <20090106101347.GB3052@uglyrabbit.telecommedia.pl>
References: <20090106101347.GB3052@uglyrabbit.telecommedia.pl>
Message-ID: <20090106153315.GD5417@uglyrabbit.telecommedia.pl>

Hi,

After digging through the archives I've finally found that this was a
setkey related issue.

Regards,

Piotr

From hutx at yahoo.com  Tue Jan  6 18:06:30 2009
From: hutx at yahoo.com (hutx)
Date: Tue, 6 Jan 2009 15:06:30 -0800 (PST)
Subject: [Openswan Users] I can not make KLIPS install.
Message-ID: <108127.96163.qm@web65409.mail.ac4.yahoo.com>

I want to build KLIPS kernel module on 2.6.
My linux is Fedoral core 6.
Openswan is openswan-2.6.20rc1

When I run make KERNELSRC=/lib/modules/`uname
-r`/build module minstall, I got an error as below:
make[3]:
/usr/src/kernels/2.6.18-1.2798.fc6-i686/Documentation/DocBook/Makefile:
No such file or directory
make[3]: *** No rule to make target
`/usr/src/kernels/2.6.18-1.2798.fc6-i686/Documentation/DocBook/Makefile'.
 Stop.
make[2]: *** [help] Error 2
+ mkdir -p
/lib/modules/2.6.18-1.2798.fc6/kernel/net/ipsec
+ cp /tmp/openswan-2.6.20rc1/modobj26/ipsec.ko
/lib/modules/2.6.18-1.2798.fc6/kernel/net/ipsec
+ '[' -f /sbin/depmod ']'
+ depmod -a
+ '[' -n net/ipsec ']'
+ mkdir -p
/lib/modules/2.6.18-1.2798.fc6/kernel/net/ipsec
+ '[' -f
/lib/modules/2.6.18-1.2798.fc6/kernel/ipsec.ko -a -f
/lib/modules/2.6.18-1.2798.fc6/kernel/net/ipsec/ipsec.ko
']'
+ set -x
make[1]: Leaving directory `/tmp/openswan-2.6.20rc1'

I check the directory 
/usr/src/kernels/2.6.18-1.2798.fc6-i686/Documentation/DocBook/Makefile.
It does not exist. But I do not know how to install
this direcotory in Kernels.

Please help me. Thanks in advance.




      

From jon at heartslc.com  Tue Jan  6 18:18:59 2009
From: jon at heartslc.com (Jonathan Larsen)
Date: Tue, 6 Jan 2009 16:18:59 -0700
Subject: [Openswan Users] I can not make KLIPS install.
Message-ID: <E80B65F27529BB409F833498BB79F84E4913B2@r2d2.heartslc.com>

Do you have your Kernel source installed?  Do you have a dir called
/usr/src/kernels/2.6.18-1.2798.fc6-i686 ?
Are you use you need KLIPS?

Also, KERNELSRC should = your kernel source dir. IE,
/usr/src/linux-kernel-2.6.xxxxx

Jonathan
Systems Administrator
801.270.4108
IT at heartslc.com


-----Original Message-----
From: users-bounces at openswan.org [mailto:users-bounces at openswan.org] On
Behalf Of hutx
Sent: Tuesday, January 06, 2009 4:07 PM
To: users at openswan.org
Subject: [Openswan Users] I can not make KLIPS install.

I want to build KLIPS kernel module on 2.6.
My linux is Fedoral core 6.
Openswan is openswan-2.6.20rc1

When I run make KERNELSRC=/lib/modules/`uname
-r`/build module minstall, I got an error as below:
make[3]:
/usr/src/kernels/2.6.18-1.2798.fc6-i686/Documentation/DocBook/Makefile:
No such file or directory
make[3]: *** No rule to make target
`/usr/src/kernels/2.6.18-1.2798.fc6-i686/Documentation/DocBook/Makefile'
.
 Stop.
make[2]: *** [help] Error 2
+ mkdir -p
/lib/modules/2.6.18-1.2798.fc6/kernel/net/ipsec
+ cp /tmp/openswan-2.6.20rc1/modobj26/ipsec.ko
/lib/modules/2.6.18-1.2798.fc6/kernel/net/ipsec
+ '[' -f /sbin/depmod ']'
+ depmod -a
+ '[' -n net/ipsec ']'
+ mkdir -p
/lib/modules/2.6.18-1.2798.fc6/kernel/net/ipsec
+ '[' -f
/lib/modules/2.6.18-1.2798.fc6/kernel/ipsec.ko -a -f
/lib/modules/2.6.18-1.2798.fc6/kernel/net/ipsec/ipsec.ko
']'
+ set -x
make[1]: Leaving directory `/tmp/openswan-2.6.20rc1'

I check the directory 
/usr/src/kernels/2.6.18-1.2798.fc6-i686/Documentation/DocBook/Makefile.
It does not exist. But I do not know how to install
this direcotory in Kernels.

Please help me. Thanks in advance.




      
_______________________________________________
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=283155


From aaron.hicks at servicesphere.com  Tue Jan  6 18:52:43 2009
From: aaron.hicks at servicesphere.com (Aaron Hicks)
Date: Wed, 7 Jan 2009 12:52:43 +1300
Subject: [Openswan Users] Openswan on Ubuntu 8.10
In-Reply-To: <1231224319885861500@mdr.co.uk>
References: <1230572347383031500@mdr.co.uk> <1231153425871598500@mdr.co.uk>
	<49626038.1e068e0a.3dbf.ffff903d@mx.google.com>
	<1231224319885861500@mdr.co.uk>
Message-ID: <4963eea4.1c078e0a.79f8.ffffeed7@mx.google.com>

1.       Ah, stupid word or outlook have converted a double dash to some other character. It should be ?--purge"

2.       Hmm sounds like permissions error, do you really have superuser access? Alternatively pipe the output from sysctl to  a text file and search it some other way.

 

From: Richard de Rivaz [mailto:richard at mdr.co.uk] 
Sent: Tuesday, 6 January 2009 7:45 p.m.
To: Aaron Hicks
Cc: users at lists.openswan.org
Subject: Re: [Openswan Users] Openswan on Ubuntu 8.10

 

Hi Aaron

Thanks for your helpful email. I am still stuck early in the process!

1. sudo apt-get ?purge remove openswan ipsec-tools raccoon vpnc

does not appear to like purge and remove in the same command line.

2. sudo sysctl -a | grep 'ip4.conf.*redirect'

gives the following errors:

error: "Invalid argument" reading key "fs.binfmt_misc.register"
error: permission denied on key 'net.ipv4.route.flush'

So I cannot progress beyond the 'ipsec verify' stage.

The config file is currently:

#
# /etc/sysctl.conf - Configuration file for setting system variables
# See /etc/sysctl.d/ for additional system variables.
# See sysctl.conf (5) for information.
#

#kernel.domainname = example.com

# Uncomment the following to stop low-level messages on console
#kernel.printk = 4 4 1 7

##############################################################3
# Functions previously found in netbase
#

# Uncomment the next two lines to enable Spoof protection (reverse-path filter)
# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks
net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1

# Uncomment the next line to enable TCP/IP SYN cookies
# This disables TCP Window Scaling (http://lkml.org/lkml/2008/2/5/167),
# and is not recommended.
#net.ipv4.tcp_syncookies=1

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=0

# Uncomment the next line to enable packet forwarding for IPv6
net.ipv6.conf.all.forwarding=0


###################################################################
# Additional settings - these settings can improve the network
# security of the host and prevent against some network attacks
# including spoofing attacks and man in the middle attacks through
# redirection. Some network environments, however, require that these
# settings are disabled so review and enable them as needed.
#
# Ignore ICMP broadcasts
net.ipv4.icmp_echo_ignore_broadcasts = 1
#
# Ignore bogus ICMP errors
net.ipv4.icmp_ignore_bogus_error_responses = 1
# 
# Do not accept ICMP redirects (prevent MITM attacks)
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
# _or_
# Accept ICMP redirects only for gateways listed in our default
# gateway list (enabled by default)
# net.ipv4.conf.all.secure_redirects = 1
#
# Do not send ICMP redirects (we are not a router)
net.ipv4.conf.all.send_redirects = 0
#
# Do not accept IP source route packets (we are not a router)
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
#
# Log Martian Packets
net.ipv4.conf.all.log_martians = 1
#
# The contents of /proc/<pid>/maps and smaps files are only visible to 
# readers that are allowed to ptrace() the process
# sys.kernel.maps_protect = 1


Regards Richard
-- 

Richard de Rivaz
MDR Interfaces Ltd
Computer Control Specialists

Tel: +44(0)1825 790294 Fax: +44(0)1825 790119
Reg in England No. 1577056 Directors: R de Rivaz  Z de Rivaz
Reg Address: Little Bridge House, Danehill, Sussex RH17 7JD

http://www.mdr.co.uk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090107/dc97abbe/attachment.html 

From jon at heartslc.com  Tue Jan  6 19:14:16 2009
From: jon at heartslc.com (Jonathan Larsen)
Date: Tue, 6 Jan 2009 17:14:16 -0700
Subject: [Openswan Users] I can not make KLIPS install.
Message-ID: <E80B65F27529BB409F833498BB79F84E4913C3@r2d2.heartslc.com>

You may want to hit up the Fedora forums and ask what rpm you would need
to install to have the complete source.  I don't use fedora, so I
couldn't tell you.  Sorry.

Jonathan
Systems Administrator
801.270.4108
IT at heartslc.com


-----Original Message-----
From: hutx [mailto:hutx at yahoo.com] 
Sent: Tuesday, January 06, 2009 4:30 PM
To: Jonathan Larsen
Subject: Re: [Openswan Users] I can not make KLIPS install.


Thank Jonathan for quick reply.

Yes, I do have the dir
/usr/src/kernels/2.6.18-1.2798.fc6-i686.
But, I do not have the dir Documentation/DocBook. I do
not know how to install it by make menucofig.

As for KLIPS, I try to solve an error "has no Non-ESP
marker". Somebody in the mailling list said he/she
solved this problem by switching from NETKEY to KLIPS.
So I want to try KLIPS.



--- Jonathan Larsen <jon at heartslc.com> wrote:

> Do you have your Kernel source installed?  Do you
> have a dir called
> /usr/src/kernels/2.6.18-1.2798.fc6-i686 ?
> Are you use you need KLIPS?
> 
> Also, KERNELSRC should = your kernel source dir. IE,
> /usr/src/linux-kernel-2.6.xxxxx
> 
> Jonathan
> Systems Administrator
> 801.270.4108
> IT at heartslc.com
> 
> 
> -----Original Message-----
> From: users-bounces at openswan.org
> [mailto:users-bounces at openswan.org] On
> Behalf Of hutx
> Sent: Tuesday, January 06, 2009 4:07 PM
> To: users at openswan.org
> Subject: [Openswan Users] I can not make KLIPS
> install.
> 
> I want to build KLIPS kernel module on 2.6.
> My linux is Fedoral core 6.
> Openswan is openswan-2.6.20rc1
> 
> When I run make KERNELSRC=/lib/modules/`uname
> -r`/build module minstall, I got an error as below:
> make[3]:
>
/usr/src/kernels/2.6.18-1.2798.fc6-i686/Documentation/DocBook/Makefile:
> No such file or directory
> make[3]: *** No rule to make target
>
`/usr/src/kernels/2.6.18-1.2798.fc6-i686/Documentation/DocBook/Makefile'
> .
>  Stop.
> make[2]: *** [help] Error 2
> + mkdir -p
> /lib/modules/2.6.18-1.2798.fc6/kernel/net/ipsec
> + cp /tmp/openswan-2.6.20rc1/modobj26/ipsec.ko
> /lib/modules/2.6.18-1.2798.fc6/kernel/net/ipsec
> + '[' -f /sbin/depmod ']'
> + depmod -a
> + '[' -n net/ipsec ']'
> + mkdir -p
> /lib/modules/2.6.18-1.2798.fc6/kernel/net/ipsec
> + '[' -f
> /lib/modules/2.6.18-1.2798.fc6/kernel/ipsec.ko -a -f
>
/lib/modules/2.6.18-1.2798.fc6/kernel/net/ipsec/ipsec.ko
> ']'
> + set -x
> make[1]: Leaving directory `/tmp/openswan-2.6.20rc1'
> 
> I check the directory 
>
/usr/src/kernels/2.6.18-1.2798.fc6-i686/Documentation/DocBook/Makefile.
> It does not exist. But I do not know how to install
> this direcotory in Kernels.
> 
> Please help me. Thanks in advance.
> 
> 
> 
> 
>       
> _______________________________________________
> 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=283155
> 
> _______________________________________________
> 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=283155
> 



      


From tis at foobar.fi  Wed Jan  7 04:20:08 2009
From: tis at foobar.fi (Tuomo Soini)
Date: Wed, 07 Jan 2009 11:20:08 +0200
Subject: [Openswan Users] Keylife and ikelifetime
In-Reply-To: <Pine.LNX.4.64.0812231258050.32702@newtla.xelerance.com>
References: <Pine.LNX.4.64.0812231355150.32131@fedex.thefeds.net>	<Pine.LNX.4.64.0812231059100.32291@newtla.xelerance.com>	<Pine.LNX.4.64.0812231825100.32131@fedex.thefeds.net>	<Pine.LNX.4.64.0812231200240.32702@newtla.xelerance.com>	<Pine.LNX.4.64.0812231923060.32131@fedex.thefeds.net>
	<Pine.LNX.4.64.0812231258050.32702@newtla.xelerance.com>
Message-ID: <496473C8.30204@foobar.fi>

Paul Wouters wrote:
> On Tue, 23 Dec 2008, openswan at thefeds.net wrote:
> 
>> Both ends have the same lifetimes defined. I noticed after I sent my last mail
>> that the default rekeyfuzz was 100%. This explains why the end that recieved a
>> proposal would sometimes set EVENT_SA_REKEY to be around 2500 seconds when the
>> default lifetime is around 8000 seconds. I have now explicitly set rekeyfuzz
>> to 0% on one of my connections and it is keeping SAs in step much better.
> 
> 100% sounds wrong. I'll look into that.
> 
> using fuzz of 0 is dangerous. If a busy server crashes and restarts, all the
> connections will rekey all at the same time at uptime == lifetime.
> 
>> I don't think the last version of openswan that I used had rekeyfuzz at all,
>> thus I wasn't expecting it to have such a large default.
> 
> It's been in there forever, but the default might have changed accidentally.

I checked and 100% seems to ver only really valid value. From
ipsec_pluto manpage:

Rekeying

When an SA that was initiated by pluto has only a bit of lifetime left,
pluto will initiate the creation of a new SA. This applies to ISAKMP and
IPsec SAs. The rekeying will be initiated when the SA?s remaining
lifetime is less than the rekeymargin plus a random percentage, between
0 and rekeyfuzz, of the rekeymargin.

Similarly, when an SA that was initiated by the peer has only a bit of
lifetime left, pluto will try to initiate the creation of a replacement.
To give preference to the initiator, this rekeying will only be
initiated when the SA?s remaining lifetime is half of rekeymargin. If
rekeying is done by the responder, the roles will be reversed: the
responder for the old SA will be the initiator for the replacement. The
former initiator might also initiate rekeying, so there may be redundant
SAs created. To avoid these complications, make sure that rekeymargin is
generous.

One risk of having the former responder initiate is that perhaps none of
its proposals is acceptable to the former initiator (they have not been
used in a successful negotiation). To reduce the chances of this
happening, and to prevent loss of security, the policy settings are
taken from the old SA (this is the case even if the former initiator is
initiating). These may be stricter than those of the connection.

pluto will not rekey an SA if that SA is not the most recent of its type
(IPsec or ISAKMP) for its potential connection. This avoids creating
redundant SAs.

The random component in the rekeying time (rekeyfuzz) is intended to
make certain pathological patterns of rekeying unstable. If both sides
decide to rekey at the same time, twice as many SAs as necessary are
created. This could become a stable pattern without the randomness.

Another more important case occurs when a security gateway has SAs with
many other security gateways. Each of these connections might need to be
rekeyed at the same time. This would cause a high peek requirement for
resources (network bandwidth, CPU time, entropy for random numbers). The
rekeyfuzz can be used to stagger the rekeying times.

Once a new set of SAs has been negotiated, pluto will never send traffic
on a superseded one. Traffic will be accepted on an old SA until it expires.

rekeymargin defaults to 540 seconds which means you can't have that
early rekeying with default values.

Only if you have tweaked rekeymargin to much longer value you can see
that early renegotiation.

-- 
Tuomo Soini <tis at foobar.fi>
Foobar Linux services
+358 40 5240030
Foobar Oy <http://foobar.fi/>

From opsenswan at thefeds.net  Mon Jan  5 08:40:25 2009
From: opsenswan at thefeds.net (opsenswan at thefeds.net)
Date: Mon, 5 Jan 2009 13:40:25 +0000 (GMT)
Subject: [Openswan Users] IPSEC SA only being installed on one side
In-Reply-To: <Pine.LNX.4.64.0901011950550.6849@newtla.xelerance.com>
References: <Pine.LNX.4.64.0812301739240.4268@fedex.thefeds.net>
	<Pine.LNX.4.64.0901011950550.6849@newtla.xelerance.com>
Message-ID: <Pine.LNX.4.64.0901051334450.15158@fedex.thefeds.net>

2.6.20rc1 has been running for three days and is much better.

I would say it is perfect for phase 2 rekeying but there are two incidents 
I am still investigating.

My monitoring is still picking up quite a few incidents where I have no 
phase 1 SA but this could be because I only have a 60 second rekeying 
margin (to mitigate the effects of the rekeying problems). I will push out 
new configs with a higher rekeying margin and see what happens.

Thanks
Tim

On Thu, 1 Jan 2009, Paul Wouters wrote:

> On Tue, 30 Dec 2008, openswan at thefeds.net wrote:
>
> There have been some fixes to rekeying lately. Please try the latest
> test release (2.6.20rc1). Though this bug might still exist.
>
> Paul
>
>> Date: Tue, 30 Dec 2008 18:35:42 +0000 (GMT)
>> From:  <openswan at thefeds.net>
>> To:  <users at openswan.org>
>> Subject: [Openswan Users] IPSEC SA only being installed on one side
>>
>> I am trying to track down a problem I am having quite frequently where my
>> phase 1 SA is fine (and thus DPD doesn't see any problems) but my phase 2
>> SAs aren't in step and thus traffic can't get through.
>>
>> The problem appears to be that sometimes when a new phase 2 SA is
>> negotiated one side is happy and installs the SA, but the other side
>> (never the initiator) doesn't install the SA. The side with the newer SA
>> then sends packets encrypted with the new SPI which the other side cannot
>> understand.
>>
>> I have the following extracts from /var/log/secure:
>>
>> The initiator:
>> Dec 30 12:40:04 vpn01d pluto[4943]: "tun02a01d" #442: STATE_MAIN_I4:
>> ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256
>> prf=oakley_sha group=modp1536}
>> Dec 30 12:40:04 vpn01d pluto[4943]: "tun02a01d" #442: Dead Peer Detection
>> (RFC 3706): enabled
>> Dec 30 14:32:40 vpn01d pluto[4943]: "tun02a01d" #455: initiating Quick
>> Mode PSK+ENCRYPT+PFS+UP+IKEv2ALLOW to replace #428 {using isakmp#442
>> msgid:1ff67d30 proposal=AES(12)_256-SHA1(2)_160
>> pfsgroup=OAKLEY_GROUP_MODP1536}
>> Dec 30 14:32:40 vpn01d pluto[4943]: "tun02a01d" #455: Dead Peer Detection
>> (RFC 3706): enabled
>> Dec 30 14:32:40 vpn01d pluto[4943]: "tun02a01d" #455: transition from
>> state STATE_QUICK_I1 to state STATE_QUICK_I2
>> Dec 30 14:32:40 vpn01d pluto[4943]: "tun02a01d" #455: STATE_QUICK_I2: sent
>> QI2, IPsec SA established transport mode {ESP=>0x0f2d2e3a <0x36134870
>> xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=none DPD=enabled}
>> Dec 30 14:32:50 vpn01d pluto[4943]: "tun02a01d" #455: message ignored
>> because it contains an unexpected payload type (ISAKMP_NEXT_HASH)
>> Dec 30 14:32:50 vpn01d pluto[4943]: "tun02a01d" #455: sending encrypted
>> notification INVALID_PAYLOAD_TYPE to <vpn02a ip>:500
>>
>> The reciever:
>> Dec 30 12:40:04 vpn02a pluto[547]: "tun02a01d" #480: STATE_MAIN_R3: sent
>> MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256
>> prf=oakley_sha group=modp1536}
>> Dec 30 12:40:04 vpn02a pluto[547]: "tun02a01d" #480: Dead Peer Detection
>> (RFC 3706): enabled
>> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #480: the peer proposed:
>> <vpn02a ip>/32:0/0 -> <vpn02d ip>/32:0/0
>> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515: responding to Quick
>> Mode proposal {msgid:1ff67d30}
>> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515:     us:
>> <vpn02a ip><<vpn02a ip>>[+S=C]---<vpn02a nh>
>> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515:   them:
>> <vpn01d nh>---<vpn01d ip><<vpn01d ip>>[+S=C]
>> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515: keeping
>> refhim=4294901761 during rekey
>> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515: transition from state
>> STATE_QUICK_R0 to state STATE_QUICK_R1
>> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515: STATE_QUICK_R1: sent
>> QR1, inbound IPsec SA installed, expecting QI2
>> Dec 30 14:32:40 vpn02a pluto[547]: packet from <vpn01d ip>:500:
>> Informational Exchange is for an unknown (expired?) SA
>> Dec 30 14:32:50 vpn02a pluto[547]: "tun02a01d" #480: ignoring
>> informational payload, type INVALID_PAYLOAD_TYPE msgid=00000000
>> Dec 30 14:32:50 vpn02a pluto[547]: "tun02a01d" #480: received and ignored
>> informational message
>>
>> I then end up with the following SAs on vpn02a:
>> 000 #523: "tun02a01d":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established);
>> EVENT_SA_REPLACE in 9590s; newest ISAKMP; lastdpd=2s(seq in:24780 out:0);
>> idle; import:not set
>> 000 #480: "tun02a01d":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established);
>> EVENT_SA_REPLACE in 2449s; lastdpd=1210s(seq in:7855 out:0); idle;
>> import:not set
>> 000 #470: "tun02a01d":500 STATE_QUICK_R2 (IPsec SA established);
>> EVENT_SA_REPLACE in 2026s; newest IPSEC; eroute owner; isakmp#454; idle;
>> import:not set
>> 000 #470: "tun02a01d" esp.f2d777e3@<vpn01d ip> esp.8ca1e089@<vpn02a ip>
>> ref=0 refhim=4294901761
>>
>> and vpn01d:
>> 000 #466: "tun02a01d":500 STATE_MAIN_I4 (ISAKMP SA established);
>> EVENT_SA_REPLACE in 5934s; newest ISAKMP; lastdpd=1s(seq in:3752 out:0);
>> idle; import:admin initiate
>> 000 #455: "tun02a01d":500 STATE_QUICK_I2 (sent QI2, IPsec SA established);
>> EVENT_SA_REPLACE in 5593s; newest IPSEC; eroute owner; isakmp#442; idle;
>> import:admin initiate
>> 000 #455: "tun02a01d" esp.f2d2e3a@<vpn02a ip> esp.36134870@<vpn01d ip>
>> ref=0 refhim=4294901761
>> 000 #442: "tun02a01d":500 STATE_MAIN_I4 (ISAKMP SA established);
>> EVENT_SA_EXPIRE in 6050s; lastdpd=1209s(seq in:17036 out:0); idle;
>> import:admin initiate
>> 000 #428: "tun02a01d":500 STATE_QUICK_I2 (sent QI2, IPsec SA established);
>> EVENT_SA_EXPIRE in 5627s; isakmp#411; idle; import:admin initiate
>> 000 #428: "tun02a01d" esp.8ca1e089@<vpn02a ip> esp.f2d777e3@<vpn01d ip>
>> ref=0 refhim=4294901761
>>
>> So you can see that vpn02a does have esp.36134870@<vpn01d ip>
>> esp.f2d2e3a@<vpn02a ip> installed and as that is newest on vpn01d that is
>> what it is using for all traffic to vpn02a.
>>
>> I am guessing that the log entry of:
>> Dec 30 14:32:40 vpn02a pluto[547]: packet from <vpn01d ip>:500:
>> Informational Exchange is for an unknown (expired?) SA
>> May be the QI2 packet from vpn01d that vpn01d doesn't understand? I
>> thought at one time that the phase 1 SA may be expiring at this point, but
>> I am seeing this happen far too often for that. Plus as the logs show the
>> phase 1 SA was renegotiated 112 minutes and 48 seconds earlier and I have
>> a key life of 240 minutes with a rekeying margin of 120 minutes and a
>> rekeying fuzz of 1% so the next phase 1 rekeying isn't due for another 6
>> minutes to 7 minutes 12 seconds. I do see the phase 1 rekey happen in the
>> logs 6 minutes and 25 seconds later.
>>
>> Does anyone have any idea how I can go about finding out why the recieving
>> end sometimes doesn't install the new phase 2 SA?
>>
>> Thanks in advance for any help
>> Tim
>> _______________________________________________
>> 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=283155
>>
>

From etrillaud at ntsys.fr  Wed Jan  7 09:36:25 2009
From: etrillaud at ntsys.fr (emmanuel trillaud)
Date: Wed, 07 Jan 2009 15:36:25 +0100
Subject: [Openswan Users] connection problem
Message-ID: <4964BDE9.6050001@ntsys.fr>

Hello,
I'm trying to configure a VPN and I have somme problem during connexion.

--- conf file

# basic configuration
config setup
	plutodebug="all"
	# klipsdebug="crypt pfkey natt"
 	klipsdebug="all"
 	#
 	# Only enable klipsdebug=all if you are a developer
 	#
 	interfaces="ipsec0=eth0"
	protostack=netkey
 	# NAT-TRAVERSAL support, see README.NAT-Traversal
 	nat_traversal=no
 	#virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,!%v4:10.1.0.0/24,!%v4:192.168.0.0/24,!%v4:10.114.6.248/249
 	#
	# enable this if you see "failed to find any available worker"
	nhelpers=0
 	myid=91.xxx.xxx.xxx															
# Add connections here
#
#connection DGFIP
conn dgfip
	type=tunnel
	pfs=no
	keyingtries=3
	#disablearrivalcheck=no
	# preference : cipher=3des hash=md5 DH group 2
	#ike=aes-sha1,aes-md5,3des-sha1,3des-md5,3des-sha1-modp1024,3des-md5-modp1024,aes-sha1-modp1536,aes-md5-modp1536,3des-sha1-modp1536,3des-md5-modp1536
        ike=3des-sha1-modp1024,3des-md5-modp1024,3des-sha1-modp1536,3des-md5-modp1536,aes-sha1-modp1024,aes-sha1-modp1536
	esp=aes-sha1,aes-md5,3des-sha1,3des-md5
	authby=secret
	left=91.xxx.xxx.xxx	
	leftsourceip=10.1.0.1
	leftsubnet=10.1.0.0/24
	#leftnexthop=91.xxx.xxx.xxx
	right=83.xxx.xxx.xxx
	rightsubnet=10.114.6.248/29
 	rightsourceip=10.114.6.249
	auto=start
#
# sample VPN connections, see /etc/ipsec.d/examples/
#
#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf
#

---Log file

000 interface lo/lo 127.0.0.1
000 interface eth0/eth0 91.xxx.xxx.xxx
000 interface eth0:0/eth0:0 91.xxx.xxx.xxx
000 interface eth0/eth0 192.168.1.1
000 interface eth0/eth0 10.1.0.1
000 interface eth0/eth0 10.1.0.2
000 interface eth0:1/eth0:1 91.xxx.xxx.xxx
000 interface eth0:2/eth0:2 91.xxx.xxx.xxx
000 interface eth0:3/eth0:3 91.xxx.xxx.xxx
000 %myid = 91.xxx.xxx.xxx
000 debug raw+crypt+parsing+emitting+control+lifecycle+klips+dns+oppo+controlmore+pfkey+nattraversal+x509
000  
000 algorithm ESP encrypt: id=2, name=ESP_DES, ivlen=8, keysizemin=64, keysizemax=64
000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, keysizemin=192, keysizemax=192
000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5, keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1, keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=5, name=AUTH_ALGORITHM_HMAC_SHA2_256, keysizemin=256, keysizemax=256
000  
000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8, keydeflen=192
000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16, keydeflen=128
000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192
000  
000 stats db_ops.c: {curr_cnt, total_cnt, maxsz} :context={0,1,36} trans={0,1,108} attrs={0,1,72} 
000  
000 "dgfip": 10.1.0.0/24===91.x.x.x...83.x.x.x===10.114.6.248/29; prospective erouted; eroute owner: #0
000 "dgfip":     srcip=10.1.0.1; dstip=10.114.6.249; srcup=ipsec _updown; dstup=ipsec _updown;
000 "dgfip":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3
000 "dgfip":   policy: PSK+ENCRYPT+TUNNEL+UP; prio: 24,29; interface: eth0; encap: esp;
000 "dgfip":   newest ISAKMP SA: #0; newest IPsec SA: #0; 
000 "dgfip":   IKE algorithms wanted: 3DES_CBC(5)_000-SHA1(2)-MODP1024(2), 3DES_CBC(5)_000-MD5(1)-MODP1024(2), 3DES_CBC(5)_000-SHA1(2)-MODP1536(5), 3DES_CBC(5)_000-MD5(1)-MODP1536(5); flags=strict
000 "dgfip":   IKE algorithms found: 3DES_CBC(5)_192-SHA1(2)_160-MODP1024(2), 3DES_CBC(5)_192-MD5(1)_128-MODP1024(2), 3DES_CBC(5)_192-SHA1(2)_160-MODP1536(5), 3DES_CBC(5)_192-MD5(1)_128-MODP1536(5)
000 "dgfip":   ESP algorithms wanted: AES(12)_000-SHA1(2), AES(12)_000-MD5(1), 3DES(3)_000-SHA1(2), 3DES(3)_000-MD5(1); flags=strict
000 "dgfip":   ESP algorithms loaded: AES(12)_000-SHA1(2), AES(12)_000-MD5(1), 3DES(3)_000-SHA1(2), 3DES(3)_000-MD5(1); flags=strict
000  
000 #1: "dgfip":500 STATE_MAIN_I3 (sent MI3, expecting MR3); none in -1s; lastdpd=-1s(seq in:0 out:0)
000 #1: pending Phase 2 for "dgfip" replacing #0



I don't really understand what means the "000" in 3DES_CBC(5)_000(2) and 
why it seams to be problematic with
3DES_CBC(5)_192-SHA1(2)_160-MODP1024(2).
I don't understand the last 2 lines which seems to be a problem.

I will appreciate your insight here.

Best regards

-- 
Emmanuel Trillaud
mel : etrillaud at ntsys.fr


From tonisaco at gmail.com  Wed Jan  7 12:19:58 2009
From: tonisaco at gmail.com (TC)
Date: Wed, 7 Jan 2009 19:19:58 +0200
Subject: [Openswan Users] net-to-net - openswan 2.6.18 on k.2.6.24.7
Message-ID: <ebc7cfa10901070919l59c3ee09id8a9c04d8b285016@mail.gmail.com>

Hi all,

I have installed kernel 2.6.24.7 + klips patch + openswan 2.6.18
I have made a net-to-net config. The connection start but I cannot
ping the end of the tunnel.

ping 192.168.23.1 -I eth1 not working
ping 192.168.10.254 -I eth1 not working

ping 192.168.10.254 -I eth1
PING 192.168.10.254 (192.168.10.254) from 192.168.23.1 eth1: 56(84) bytes of
data.
>From 192.168.23.1 icmp_seq=2 Destination Host Unreachable
>From 192.168.23.1 icmp_seq=3 Destination Host Unreachable
>From 192.168.23.1 icmp_seq=4 Destination Host Unreachable


A config(and same config to B but different ipsec.secrets)

version 2.0

config setup
    interfaces="ipsec0=eth0"
    protostack=klips

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

conn A-B
    left=WAN_IP_FROM_A
    leftnexthop=GATEWAY_FROM_A
    leftsubnet=192.168.10.0/24
    right=WAN_IP_FROM_B
    rightnexthop=GATEWAY_FROM_B
    rightsubnet=192.168.23.0/24
    type=tunnel
    auth=esp
    leftrsasigkey=0sAQOY...
    rightrsasigkey=0sAQNqB...
    auto=start

in /var/log/syslog I have:
   Jan  7 19:13:12 vpn ipsec_setup: Starting Openswan IPsec 2.6.18...
   Jan  7 19:13:12 vpn ipsec__plutorun: 002 added connection description
"A-B"
   Jan  7 19:13:12 vpn ipsec__plutorun: 104 "A-B" #1: STATE_MAIN_I1:
initiate

in /var/log.secure I have:
Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: STATE_MAIN_I2: sent MI2,
expecting MR2
Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: transition from state
STATE_MAIN_I2 to state STATE_MAIN_I3
Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: STATE_MAIN_I3: sent MI3,
expecting MR3
Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: received Vendor ID payload
[CAN-IKEv2]
Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: Main mode peer ID is
ID_IPV4_ADDR: '82.79.83.23'
Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: transition from state
STATE_MAIN_I3 to state STATE_MAIN_I4
Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: STATE_MAIN_I4: ISAKMP SA
established {auth=OAKLEY_RSA_SIG cipher=aes_128 prf=oakley_sha
group=modp2048}
Jan  7 19:15:57 vpn pluto[10094]: "A-B" #2: initiating Quick Mode
RSASIG+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW {using isakmp#1 msgid:beed36ed
proposal=defaults pfsgroup=OAKLEY_GROUP_MODP2048}
Jan  7 19:15:57 vpn pluto[10094]: "A-B" #2: transition from state
STATE_QUICK_I1 to state STATE_QUICK_I2
Jan  7 19:15:57 vpn pluto[10094]: "A-B" #2: STATE_QUICK_I2: sent QI2, IPsec
SA established tunnel mode {ESP=>0x45d84918 <0x892b2f5a
xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=none}
Jan  7 19:16:16 vpn pluto[10094]: "A-B" #1: ignoring Delete SA payload:
PROTO_IPSEC_ESP SA(0x45d84917) not found (maybe expired)
Jan  7 19:16:16 vpn pluto[10094]: "A-B" #1: received and ignored
informational message


Thx for Help.

--
TC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090107/2a9e1140/attachment.html 

From petermcgill at goco.net  Wed Jan  7 14:06:48 2009
From: petermcgill at goco.net (Peter McGill)
Date: Wed, 7 Jan 2009 14:06:48 -0500
Subject: [Openswan Users] connection problem
In-Reply-To: <4964BDE9.6050001@ntsys.fr>
References: <4964BDE9.6050001@ntsys.fr>
Message-ID: <23DD1A54637A47D4B7AC321315AC9F78@peter>

> -----Original Message-----
> From: users-bounces at openswan.org 
> [mailto:users-bounces at openswan.org] On Behalf Of emmanuel trillaud
> Sent: January 7, 2009 9:36 AM
> To: users at openswan.org
> Subject: [Openswan Users] connection problem
> 
> I'm trying to configure a VPN and I have somme problem during 
> connexion.
> 
> --- conf file
> 
> # basic configuration
> config setup
> 	plutodebug="all"
> 	# klipsdebug="crypt pfkey natt"
>  	klipsdebug="all"
>  	#
>  	# Only enable klipsdebug=all if you are a developer
>  	#

This comment is serious, turn off pluto and klips debug, they just clutter the logs. Only turn on if asked by a developer.
Makes finding the real error in the logs, like finding a needle in a haystack, and fills your hard drive with logs.
	#plutodebug=none
	#klipsdebug=none

>  	interfaces="ipsec0=eth0"
> 	protostack=netkey
>  	# NAT-TRAVERSAL support, see README.NAT-Traversal
>  	nat_traversal=no
>  	
> #virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.
> 0.0/12,!%v4:10.1.0.0/24,!%v4:192.168.0.0/24,!%v4:10.114.6.248/249
>  	#
> 	# enable this if you see "failed to find any available worker"
> 	nhelpers=0
>  	myid=91.xxx.xxx.xxx					
> 		
> # Add connections here
> #
> #connection DGFIP
> conn dgfip
> 	type=tunnel
> 	pfs=no
> 	keyingtries=3
> 	#disablearrivalcheck=no
> 	# preference : cipher=3des hash=md5 DH group 2
> 	
> #ike=aes-sha1,aes-md5,3des-sha1,3des-md5,3des-sha1-modp1024,3d
> es-md5-modp1024,aes-sha1-modp1536,aes-md5-modp1536,3des-sha1-m
> odp1536,3des-md5-modp1536
>         
> ike=3des-sha1-modp1024,3des-md5-modp1024,3des-sha1-modp1536,3d
> es-md5-modp1536,aes-sha1-modp1024,aes-sha1-modp1536
> 	esp=aes-sha1,aes-md5,3des-sha1,3des-md5
> 	authby=secret

What are you connecting to? If another openswan use RSA keys following the examples.
If your not connecting to openswan make your ike and esp settings match the other end.
Otherwise leave them default and don't set them.
For example, if the other end is configured to use 3des md5 dh group 2 (1024 bit):
	ike=3des-md5-modp1024
	esp=3des-md5
Configure the other end to just use these as well.

> 	left=91.xxx.xxx.xxx	
> 	leftsourceip=10.1.0.1
> 	leftsubnet=10.1.0.0/24
> 	#leftnexthop=91.xxx.xxx.xxx
> 	right=83.xxx.xxx.xxx
> 	rightsubnet=10.114.6.248/29
>  	rightsourceip=10.114.6.249
> 	auto=start
> #
> # sample VPN connections, see /etc/ipsec.d/examples/
> #
> #Disable Opportunistic Encryption
> include /etc/ipsec.d/examples/no_oe.conf
> #
> 
> ---Log file
> 
> 000 interface lo/lo 127.0.0.1
> 000 interface eth0/eth0 91.xxx.xxx.xxx
> 000 interface eth0:0/eth0:0 91.xxx.xxx.xxx
> 000 interface eth0/eth0 192.168.1.1
> 000 interface eth0/eth0 10.1.0.1
> 000 interface eth0/eth0 10.1.0.2
> 000 interface eth0:1/eth0:1 91.xxx.xxx.xxx
> 000 interface eth0:2/eth0:2 91.xxx.xxx.xxx
> 000 interface eth0:3/eth0:3 91.xxx.xxx.xxx
> 000 %myid = 91.xxx.xxx.xxx
> 000 debug 
> raw+crypt+parsing+emitting+control+lifecycle+klips+dns+oppo+co
> ntrolmore+pfkey+nattraversal+x509
> 000  
> 000 algorithm ESP encrypt: id=2, name=ESP_DES, ivlen=8, 
> keysizemin=64, keysizemax=64
> 000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, 
> keysizemin=192, keysizemax=192
> 000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=8, 
> keysizemin=128, keysizemax=256
> 000 algorithm ESP auth attr: id=1, 
> name=AUTH_ALGORITHM_HMAC_MD5, keysizemin=128, keysizemax=128
> 000 algorithm ESP auth attr: id=2, 
> name=AUTH_ALGORITHM_HMAC_SHA1, keysizemin=160, keysizemax=160
> 000 algorithm ESP auth attr: id=5, 
> name=AUTH_ALGORITHM_HMAC_SHA2_256, keysizemin=256, keysizemax=256
> 000  
> 000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, 
> blocksize=8, keydeflen=192
> 000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, 
> blocksize=16, keydeflen=128
> 000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
> 000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
> 000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, 
> bits=1024
> 000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, 
> bits=1536
> 000 algorithm IKE dh group: id=14, 
> name=OAKLEY_GROUP_MODP2048, bits=2048
> 000 algorithm IKE dh group: id=15, 
> name=OAKLEY_GROUP_MODP3072, bits=3072
> 000 algorithm IKE dh group: id=16, 
> name=OAKLEY_GROUP_MODP4096, bits=4096
> 000 algorithm IKE dh group: id=17, 
> name=OAKLEY_GROUP_MODP6144, bits=6144
> 000 algorithm IKE dh group: id=18, 
> name=OAKLEY_GROUP_MODP8192, bits=8192
> 000  
> 000 stats db_ops.c: {curr_cnt, total_cnt, maxsz} 
> :context={0,1,36} trans={0,1,108} attrs={0,1,72} 
> 000  
> 000 "dgfip": 
> 10.1.0.0/24===91.x.x.x...83.x.x.x===10.114.6.248/29; 
> prospective erouted; eroute owner: #0
> 000 "dgfip":     srcip=10.1.0.1; dstip=10.114.6.249; 
> srcup=ipsec _updown; dstup=ipsec _updown;
> 000 "dgfip":   ike_life: 3600s; ipsec_life: 28800s; 
> rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3
> 000 "dgfip":   policy: PSK+ENCRYPT+TUNNEL+UP; prio: 24,29; 
> interface: eth0; encap: esp;
> 000 "dgfip":   newest ISAKMP SA: #0; newest IPsec SA: #0; 
> 000 "dgfip":   IKE algorithms wanted: 
> 3DES_CBC(5)_000-SHA1(2)-MODP1024(2), 
> 3DES_CBC(5)_000-MD5(1)-MODP1024(2), 
> 3DES_CBC(5)_000-SHA1(2)-MODP1536(5), 
> 3DES_CBC(5)_000-MD5(1)-MODP1536(5); flags=strict
> 000 "dgfip":   IKE algorithms found: 
> 3DES_CBC(5)_192-SHA1(2)_160-MODP1024(2), 
> 3DES_CBC(5)_192-MD5(1)_128-MODP1024(2), 
> 3DES_CBC(5)_192-SHA1(2)_160-MODP1536(5), 
> 3DES_CBC(5)_192-MD5(1)_128-MODP1536(5)
> 000 "dgfip":   ESP algorithms wanted: AES(12)_000-SHA1(2), 
> AES(12)_000-MD5(1), 3DES(3)_000-SHA1(2), 3DES(3)_000-MD5(1); 
> flags=strict
> 000 "dgfip":   ESP algorithms loaded: AES(12)_000-SHA1(2), 
> AES(12)_000-MD5(1), 3DES(3)_000-SHA1(2), 3DES(3)_000-MD5(1); 
> flags=strict
> 000  
> 000 #1: "dgfip":500 STATE_MAIN_I3 (sent MI3, expecting MR3); 
> none in -1s; lastdpd=-1s(seq in:0 out:0)
> 000 #1: pending Phase 2 for "dgfip" replacing #0
> 
> I don't really understand what means the "000" in 
> 3DES_CBC(5)_000(2) and 
> why it seams to be problematic with
> 3DES_CBC(5)_192-SHA1(2)_160-MODP1024(2).
> I don't understand the last 2 lines which seems to be a problem.

This is not an error, nothing in your logs here shows any error.
It's just reporting that it is searching for any 3des sha1 modp1024,
And that it found a specific one. Not an error, normal log.

> Emmanuel Trillaud
> mel : etrillaud at ntsys.fr

Change debug options like specified above then, restart openswan and send us the new logs.

Peter


From petermcgill at goco.net  Wed Jan  7 14:13:27 2009
From: petermcgill at goco.net (Peter McGill)
Date: Wed, 7 Jan 2009 14:13:27 -0500
Subject: [Openswan Users] net-to-net - openswan 2.6.18 on k.2.6.24.7
In-Reply-To: <ebc7cfa10901070919l59c3ee09id8a9c04d8b285016@mail.gmail.com>
References: <ebc7cfa10901070919l59c3ee09id8a9c04d8b285016@mail.gmail.com>
Message-ID: <49D3CA8FC3E94ACBB8C96536EC448844@peter>

This is not uncommon, -I doesn't always work, try adding the following to your conf.
	leftsourceip=192.168.10.254
	rightsourceip=192.168.23.1
Also check that your firewall isn't blocking tunnel traffic.
You need to allow communication between 192.168.10.0/24 and 192.168.23.0/24 on ipsec0.
Not sure what that Delete SA message is about, what ipsec device is on the other end of tunnel?

Peter McGill
IT Systems Analyst
Gra Ham Energy Limited 

> -----Original Message-----
> From: users-bounces at openswan.org 
> [mailto:users-bounces at openswan.org] On Behalf Of TC
> Sent: January 7, 2009 12:20 PM
> To: users at openswan.org
> Subject: [Openswan Users] net-to-net - openswan 2.6.18 on k.2.6.24.7
> 
> Hi all,
> 
> I have installed kernel 2.6.24.7 + klips patch + openswan 2.6.18
> I have made a net-to-net config. The connection start but I cannot
> ping the end of the tunnel.
> 
> ping 192.168.23.1 -I eth1 not working
> ping 192.168.10.254 -I eth1 not working
> 
> ping 192.168.10.254 -I eth1
> PING 192.168.10.254 (192.168.10.254) from 192.168.23.1 eth1: 
> 56(84) bytes of data.
> From 192.168.23.1 icmp_seq=2 Destination Host Unreachable
> >From 192.168.23.1 icmp_seq=3 Destination Host Unreachable
> From 192.168.23.1 icmp_seq=4 Destination Host Unreachable
> 
> 
> A config(and same config to B but different ipsec.secrets)
> 
> version 2.0
> 
> config setup
>     interfaces="ipsec0=eth0"
>     protostack=klips
> 
> 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
> 
> conn A-B
>     left=WAN_IP_FROM_A
>     leftnexthop=GATEWAY_FROM_A
>     leftsubnet=192.168.10.0/24
>     right=WAN_IP_FROM_B
>     rightnexthop=GATEWAY_FROM_B
>     rightsubnet=192.168.23.0/24
>     type=tunnel
>     auth=esp
>     leftrsasigkey=0sAQOY...
>     rightrsasigkey=0sAQNqB...
>     auto=start
> 
> in /var/log/syslog I have:
>    Jan  7 19:13:12 vpn ipsec_setup: Starting Openswan IPsec 2.6.18...
>    Jan  7 19:13:12 vpn ipsec__plutorun: 002 added connection 
> description "A-B"  
>    Jan  7 19:13:12 vpn ipsec__plutorun: 104 "A-B" #1: 
> STATE_MAIN_I1: initiate
> 
> in /var/log.secure I have:
> Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: STATE_MAIN_I2: 
> sent MI2, expecting MR2
> Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: transition from 
> state STATE_MAIN_I2 to state STATE_MAIN_I3
> Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: STATE_MAIN_I3: 
> sent MI3, expecting MR3
> Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: received Vendor 
> ID payload [CAN-IKEv2]
> Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: Main mode peer ID 
> is ID_IPV4_ADDR: '82.79.83.23'
> Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: transition from 
> state STATE_MAIN_I3 to state STATE_MAIN_I4
> Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: STATE_MAIN_I4: 
> ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=aes_128 
> prf=oakley_sha group=modp2048}
> Jan  7 19:15:57 vpn pluto[10094]: "A-B" #2: initiating Quick 
> Mode RSASIG+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW {using isakmp#1 
> msgid:beed36ed proposal=defaults pfsgroup=OAKLEY_GROUP_MODP2048}
> Jan  7 19:15:57 vpn pluto[10094]: "A-B" #2: transition from 
> state STATE_QUICK_I1 to state STATE_QUICK_I2
> Jan  7 19:15:57 vpn pluto[10094]: "A-B" #2: STATE_QUICK_I2: 
> sent QI2, IPsec SA established tunnel mode {ESP=>0x45d84918 
> <0x892b2f5a xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=none}
> Jan  7 19:16:16 vpn pluto[10094]: "A-B" #1: ignoring Delete 
> SA payload: PROTO_IPSEC_ESP SA(0x45d84917) not found (maybe expired)
> Jan  7 19:16:16 vpn pluto[10094]: "A-B" #1: received and 
> ignored informational message
> 
> 
> Thx for Help.
> 
> --
> TC
> 
> 


From tonisaco at gmail.com  Wed Jan  7 15:15:27 2009
From: tonisaco at gmail.com (TC)
Date: Wed, 7 Jan 2009 22:15:27 +0200
Subject: [Openswan Users] net-to-net - openswan 2.6.18 on k.2.6.24.7
In-Reply-To: <49D3CA8FC3E94ACBB8C96536EC448844@peter>
References: <ebc7cfa10901070919l59c3ee09id8a9c04d8b285016@mail.gmail.com>
	<49D3CA8FC3E94ACBB8C96536EC448844@peter>
Message-ID: <ebc7cfa10901071215v1441e6a8rc02e66247fb04b74@mail.gmail.com>

Hi,

on both sides run pc based routers with slackware 12.1
on both sides firewall is down. iptables -F
I added leftsource and rightsource but same result.
here is the ipsec auto --status output:

root at vpn:/usr/src/linux# *ipsec auto --status
000 using kernel interface: klips
000 interface ipsec0/eth0 82.79.77.xy
000 %myid = (none)
000 debug none
000
000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=64, keysizemin=192,
keysizemax=192
000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=128, keysizemin=128,
keysizemax=256
000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5,
keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1,
keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=9, name=AUTH_ALGORITHM_AES_CBC,
keysizemin=128, keysizemax=128
000
000 algorithm IKE encrypt: id=3, name=OAKLEY_BLOWFISH_CBC, blocksize=8,
keydeflen=128
000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8,
keydeflen=192
000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16,
keydeflen=128
000 algorithm IKE encrypt: id=65004, name=OAKLEY_SERPENT_CBC, blocksize=16,
keydeflen=128
000 algorithm IKE encrypt: id=65005, name=OAKLEY_TWOFISH_CBC, blocksize=16,
keydeflen=128
000 algorithm IKE encrypt: id=65289, name=OAKLEY_TWOFISH_CBC_SSH,
blocksize=16, keydeflen=128
000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
000 algorithm IKE hash: id=4, name=OAKLEY_SHA2_256, hashsize=32
000 algorithm IKE hash: id=6, name=OAKLEY_SHA2_512, hashsize=64
000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192
000
000 stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,0,0}
trans={0,0,0} attrs={0,0,0}
000
000 "baiamare-negresti": 192.168.10.0/24===82.79.77.xy
<82.79.77.xy>[+S=C]---82.79.77.65...82.79.83.1---82.79.83.nm<82.79.83.nm>[+S=C]===
192.168.23.0/24; erouted; eroute owner: #4
000 "baiamare-negresti":     myip=192.168.10.254; hisip=192.168.23.1;
000 "baiamare-negresti":   ike_life: 3600s; ipsec_life: 28800s;
rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3
000 "baiamare-negresti":   policy: RSASIG+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW;
prio: 24,24; interface: eth0;
000 "baiamare-negresti":   newest ISAKMP SA: #3; newest IPsec SA: #4;
000 "baiamare-negresti":   IKE algorithm newest: AES_CBC_128-SHA1-MODP2048
000
000 #4: "baiamare-negresti":500 STATE_QUICK_R2 (IPsec SA established);
EVENT_SA_REPLACE in 28205s; newest IPSEC; eroute owner; isakmp#3; idle;
import:not set
000 #4: "baiamare-negresti"
esp.572de5cb at 82.79.83.nmesp.f718f73e@82.79.77.xytun.1004 at 82.79.83.nmtun.1003@82.79.77.xyref=13
refhim=9
000 #3: "baiamare-negresti":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA
established); EVENT_SA_REPLACE in 3005s; newest ISAKMP; lastdpd=-1s(seq in:0
out:0); idle; import:not set
000 #2: "baiamare-negresti":500 STATE_QUICK_I2 (sent QI2, IPsec SA
established); EVENT_SA_REPLACE in 27647s; isakmp#1; idle; import:admin
initiate
000 #2: "baiamare-negresti"
esp.f7140fdc at 82.79.83.nmesp.f718f73d@82.79.77.xytun.1001 at 82.79.83.nmtun.1002@82.79.77.xyref=11
refhim=9
000 #1: "baiamare-negresti":500 STATE_MAIN_I4 (ISAKMP SA established);
EVENT_SA_REPLACE in 2555s; lastdpd=-1s(seq in:0 out:0); idle; import:admin
initiate*


On Wed, Jan 7, 2009 at 9:13 PM, Peter McGill <petermcgill at goco.net> wrote:

> This is not uncommon, -I doesn't always work, try adding the following to
> your conf.
>        leftsourceip=192.168.10.254
>        rightsourceip=192.168.23.1
> Also check that your firewall isn't blocking tunnel traffic.
> You need to allow communication between 192.168.10.0/24 and
> 192.168.23.0/24 on ipsec0.
> Not sure what that Delete SA message is about, what ipsec device is on the
> other end of tunnel?
>
> Peter McGill
> IT Systems Analyst
> Gra Ham Energy Limited
>
> > -----Original Message-----
> > From: users-bounces at openswan.org
> > [mailto:users-bounces at openswan.org] On Behalf Of TC
> > Sent: January 7, 2009 12:20 PM
> > To: users at openswan.org
> > Subject: [Openswan Users] net-to-net - openswan 2.6.18 on k.2.6.24.7
> >
> > Hi all,
> >
> > I have installed kernel 2.6.24.7 + klips patch + openswan 2.6.18
> > I have made a net-to-net config. The connection start but I cannot
> > ping the end of the tunnel.
> >
> > ping 192.168.23.1 -I eth1 not working
> > ping 192.168.10.254 -I eth1 not working
> >
> > ping 192.168.10.254 -I eth1
> > PING 192.168.10.254 (192.168.10.254) from 192.168.23.1 eth1:
> > 56(84) bytes of data.
> > From 192.168.23.1 icmp_seq=2 Destination Host Unreachable
> > >From 192.168.23.1 icmp_seq=3 Destination Host Unreachable
> > From 192.168.23.1 icmp_seq=4 Destination Host Unreachable
> >
> >
> > A config(and same config to B but different ipsec.secrets)
> >
> > version 2.0
> >
> > config setup
> >     interfaces="ipsec0=eth0"
> >     protostack=klips
> >
> > 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
> >
> > conn A-B
> >     left=WAN_IP_FROM_A
> >     leftnexthop=GATEWAY_FROM_A
> >     leftsubnet=192.168.10.0/24
> >     right=WAN_IP_FROM_B
> >     rightnexthop=GATEWAY_FROM_B
> >     rightsubnet=192.168.23.0/24
> >     type=tunnel
> >     auth=esp
> >     leftrsasigkey=0sAQOY...
> >     rightrsasigkey=0sAQNqB...
> >     auto=start
> >
> > in /var/log/syslog I have:
> >    Jan  7 19:13:12 vpn ipsec_setup: Starting Openswan IPsec 2.6.18...
> >    Jan  7 19:13:12 vpn ipsec__plutorun: 002 added connection
> > description "A-B"
> >    Jan  7 19:13:12 vpn ipsec__plutorun: 104 "A-B" #1:
> > STATE_MAIN_I1: initiate
> >
> > in /var/log.secure I have:
> > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: STATE_MAIN_I2:
> > sent MI2, expecting MR2
> > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: transition from
> > state STATE_MAIN_I2 to state STATE_MAIN_I3
> > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: STATE_MAIN_I3:
> > sent MI3, expecting MR3
> > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: received Vendor
> > ID payload [CAN-IKEv2]
> > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: Main mode peer ID
> > is ID_IPV4_ADDR: '82.79.83.23'
> > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: transition from
> > state STATE_MAIN_I3 to state STATE_MAIN_I4
> > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: STATE_MAIN_I4:
> > ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=aes_128
> > prf=oakley_sha group=modp2048}
> > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #2: initiating Quick
> > Mode RSASIG+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW {using isakmp#1
> > msgid:beed36ed proposal=defaults pfsgroup=OAKLEY_GROUP_MODP2048}
> > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #2: transition from
> > state STATE_QUICK_I1 to state STATE_QUICK_I2
> > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #2: STATE_QUICK_I2:
> > sent QI2, IPsec SA established tunnel mode {ESP=>0x45d84918
> > <0x892b2f5a xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=none}
> > Jan  7 19:16:16 vpn pluto[10094]: "A-B" #1: ignoring Delete
> > SA payload: PROTO_IPSEC_ESP SA(0x45d84917) not found (maybe expired)
> > Jan  7 19:16:16 vpn pluto[10094]: "A-B" #1: received and
> > ignored informational message
> >
> >
> > Thx for Help.
> >
> > --
> > TC
> >
> >
>
>


-- 
--
TC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090107/91deab4e/attachment-0001.html 

From petermcgill at goco.net  Wed Jan  7 15:43:01 2009
From: petermcgill at goco.net (Peter McGill)
Date: Wed, 7 Jan 2009 15:43:01 -0500
Subject: [Openswan Users] net-to-net - openswan 2.6.18 on k.2.6.24.7
In-Reply-To: <ebc7cfa10901071215v1441e6a8rc02e66247fb04b74@mail.gmail.com>
References: <ebc7cfa10901070919l59c3ee09id8a9c04d8b285016@mail.gmail.com>
	<49D3CA8FC3E94ACBB8C96536EC448844@peter>
	<ebc7cfa10901071215v1441e6a8rc02e66247fb04b74@mail.gmail.com>
Message-ID: <4733464FD2EF4EF1A3F5F8006D6C52D9@peter>

I also run slackware.
Your logs indicate the tunnel is up and working.
Have you enabled forwarding on your openswan hosts?
cat /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/ip_forward
Have you tested the tunnel by pinging from a host in one subnet
to a host in the other subnet. Instead of server to server?
Have you done a tcpdump during a test to see what's happening?
What is the output of ipsec verify?
Can you send an ipsec barf? It will contain useful debugging info,
that will speed up the troubleshooting process.
ipsec barf > ipsec_barf.txt
Note a barf will contain the status of ip_forward, ipsec logs
and ipsec verify, ipsec.conf and network info, so if you send a
barf, you don't need to repeat the other information. Barf will
contain your ip addresses and a checksum of your keys to verify
they match, but not your actual keys. A barf is very large so
please send it privately, not on the list.
Barf does not do a tcpdump or ping tests so doing those is still
usefull.

Peter McGill
IT Systems Analyst
Gra Ham Energy Limited 

> -----Original Message-----
> From: TC [mailto:tonisaco at gmail.com] 
> Sent: January 7, 2009 3:15 PM
> To: petermcgill at goco.net
> Cc: users at openswan.org
> Subject: Re: [Openswan Users] net-to-net - openswan 2.6.18 on 
> k.2.6.24.7
> 
> Hi,
> 
> on both sides run pc based routers with slackware 12.1
> on both sides firewall is down. iptables -F
> I added leftsource and rightsource but same result.
> here is the ipsec auto --status output:
> 
> root at vpn:/usr/src/linux# ipsec auto --status
> 000 using kernel interface: klips
> 000 interface ipsec0/eth0 82.79.77.xy
> 000 %myid = (none)
> 000 debug none
> 000
> 000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=64, 
> keysizemin=192, keysizemax=192
> 000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=128, 
> keysizemin=128, keysizemax=256
> 000 algorithm ESP auth attr: id=1, 
> name=AUTH_ALGORITHM_HMAC_MD5, keysizemin=128, keysizemax=128
> 000 algorithm ESP auth attr: id=2, 
> name=AUTH_ALGORITHM_HMAC_SHA1, keysizemin=160, keysizemax=160
> 000 algorithm ESP auth attr: id=9, 
> name=AUTH_ALGORITHM_AES_CBC, keysizemin=128, keysizemax=128
> 000
> 000 algorithm IKE encrypt: id=3, name=OAKLEY_BLOWFISH_CBC, 
> blocksize=8, keydeflen=128
> 000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, 
> blocksize=8, keydeflen=192
> 000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, 
> blocksize=16, keydeflen=128
> 000 algorithm IKE encrypt: id=65004, name=OAKLEY_SERPENT_CBC, 
> blocksize=16, keydeflen=128
> 000 algorithm IKE encrypt: id=65005, name=OAKLEY_TWOFISH_CBC, 
> blocksize=16, keydeflen=128
> 000 algorithm IKE encrypt: id=65289, 
> name=OAKLEY_TWOFISH_CBC_SSH, blocksize=16, keydeflen=128
> 000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
> 000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
> 000 algorithm IKE hash: id=4, name=OAKLEY_SHA2_256, hashsize=32
> 000 algorithm IKE hash: id=6, name=OAKLEY_SHA2_512, hashsize=64
> 000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, 
> bits=1024
> 000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, 
> bits=1536
> 000 algorithm IKE dh group: id=14, 
> name=OAKLEY_GROUP_MODP2048, bits=2048
> 000 algorithm IKE dh group: id=15, 
> name=OAKLEY_GROUP_MODP3072, bits=3072
> 000 algorithm IKE dh group: id=16, 
> name=OAKLEY_GROUP_MODP4096, bits=4096
> 000 algorithm IKE dh group: id=17, 
> name=OAKLEY_GROUP_MODP6144, bits=6144
> 000 algorithm IKE dh group: id=18, 
> name=OAKLEY_GROUP_MODP8192, bits=8192
> 000
> 000 stats db_ops: {curr_cnt, total_cnt, maxsz} 
> :context={0,0,0} trans={0,0,0} attrs={0,0,0}
> 000
> 000 "baiamare-negresti": 
> 192.168.10.0/24===82.79.77.xy<82.79.77.xy>[+S=C]---82.79.77.65
> ...82.79.83.1---82.79.83.nm<82.79.83.nm>[+S=C]===192.168.23.0/
> 24; erouted; eroute owner: #4
> 000 "baiamare-negresti":     myip=192.168.10.254; hisip=192.168.23.1;
> 000 "baiamare-negresti":   ike_life: 3600s; ipsec_life: 
> 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3
> 000 "baiamare-negresti":   policy: 
> RSASIG+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW; prio: 24,24; interface: eth0;
> 000 "baiamare-negresti":   newest ISAKMP SA: #3; newest IPsec SA: #4;
> 000 "baiamare-negresti":   IKE algorithm newest: 
> AES_CBC_128-SHA1-MODP2048
> 000
> 000 #4: "baiamare-negresti":500 STATE_QUICK_R2 (IPsec SA 
> established); EVENT_SA_REPLACE in 28205s; newest IPSEC; 
> eroute owner; isakmp#3; idle; import:not set
> 000 #4: "baiamare-negresti" esp.572de5cb at 82.79.83.nm 
> esp.f718f73e at 82.79.77.xy tun.1004 at 82.79.83.nm 
> tun.1003 at 82.79.77.xy ref=13 refhim=9
> 000 #3: "baiamare-negresti":500 STATE_MAIN_R3 (sent MR3, 
> ISAKMP SA established); EVENT_SA_REPLACE in 3005s; newest 
> ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:not set
> 000 #2: "baiamare-negresti":500 STATE_QUICK_I2 (sent QI2, 
> IPsec SA established); EVENT_SA_REPLACE in 27647s; isakmp#1; 
> idle; import:admin initiate
> 000 #2: "baiamare-negresti" esp.f7140fdc at 82.79.83.nm 
> esp.f718f73d at 82.79.77.xy tun.1001 at 82.79.83.nm 
> tun.1002 at 82.79.77.xy ref=11 refhim=9
> 000 #1: "baiamare-negresti":500 STATE_MAIN_I4 (ISAKMP SA 
> established); EVENT_SA_REPLACE in 2555s; lastdpd=-1s(seq in:0 
> out:0); idle; import:admin initiate
> 
> 
> 
> On Wed, Jan 7, 2009 at 9:13 PM, Peter McGill 
> <petermcgill at goco.net> wrote:
> 
> 
> 	This is not uncommon, -I doesn't always work, try 
> adding the following to your conf.
> 	       leftsourceip=192.168.10.254
> 	       rightsourceip=192.168.23.1
> 	Also check that your firewall isn't blocking tunnel traffic.
> 	You need to allow communication between 192.168.10.0/24 
> and 192.168.23.0/24 on ipsec0.
> 	Not sure what that Delete SA message is about, what 
> ipsec device is on the other end of tunnel?
> 	
> 	Peter McGill
> 	IT Systems Analyst
> 	Gra Ham Energy Limited
> 	
> 
> 	> -----Original Message-----
> 	> From: users-bounces at openswan.org
> 	> [mailto:users-bounces at openswan.org] On Behalf Of TC
> 	> Sent: January 7, 2009 12:20 PM
> 	> To: users at openswan.org
> 	> Subject: [Openswan Users] net-to-net - openswan 
> 2.6.18 on k.2.6.24.7
> 	>
> 	> Hi all,
> 	>
> 	> I have installed kernel 2.6.24.7 + klips patch + 
> openswan 2.6.18
> 	> I have made a net-to-net config. The connection start 
> but I cannot
> 	> ping the end of the tunnel.
> 	>
> 	> ping 192.168.23.1 -I eth1 not working
> 	> ping 192.168.10.254 -I eth1 not working
> 	>
> 	> ping 192.168.10.254 -I eth1
> 	> PING 192.168.10.254 (192.168.10.254) from 192.168.23.1 eth1:
> 	> 56(84) bytes of data.
> 	> From 192.168.23.1 icmp_seq=2 Destination Host Unreachable
> 	> >From 192.168.23.1 icmp_seq=3 Destination Host Unreachable
> 	> From 192.168.23.1 icmp_seq=4 Destination Host Unreachable
> 	>
> 	>
> 	> A config(and same config to B but different ipsec.secrets)
> 	>
> 	> version 2.0
> 	>
> 	> config setup
> 	>     interfaces="ipsec0=eth0"
> 	>     protostack=klips
> 	>
> 	> 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
> 	>
> 	> conn A-B
> 	>     left=WAN_IP_FROM_A
> 	>     leftnexthop=GATEWAY_FROM_A
> 	>     leftsubnet=192.168.10.0/24
> 	>     right=WAN_IP_FROM_B
> 	>     rightnexthop=GATEWAY_FROM_B
> 	>     rightsubnet=192.168.23.0/24
> 	>     type=tunnel
> 	>     auth=esp
> 	>     leftrsasigkey=0sAQOY...
> 	>     rightrsasigkey=0sAQNqB...
> 	>     auto=start
> 	>
> 	> in /var/log/syslog I have:
> 	>    Jan  7 19:13:12 vpn ipsec_setup: Starting Openswan 
> IPsec 2.6.18...
> 	>    Jan  7 19:13:12 vpn ipsec__plutorun: 002 added connection
> 	> description "A-B"
> 	>    Jan  7 19:13:12 vpn ipsec__plutorun: 104 "A-B" #1:
> 	> STATE_MAIN_I1: initiate
> 	>
> 	> in /var/log.secure I have:
> 	> Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: STATE_MAIN_I2:
> 	> sent MI2, expecting MR2
> 	> Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: transition from
> 	> state STATE_MAIN_I2 to state STATE_MAIN_I3
> 	> Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: STATE_MAIN_I3:
> 	> sent MI3, expecting MR3
> 	> Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: received Vendor
> 	> ID payload [CAN-IKEv2]
> 	> Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: Main mode peer ID
> 	> is ID_IPV4_ADDR: '82.79.83.23'
> 	> Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: transition from
> 	> state STATE_MAIN_I3 to state STATE_MAIN_I4
> 	> Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: STATE_MAIN_I4:
> 	> ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=aes_128
> 	> prf=oakley_sha group=modp2048}
> 	> Jan  7 19:15:57 vpn pluto[10094]: "A-B" #2: initiating Quick
> 	> Mode RSASIG+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW {using isakmp#1
> 	> msgid:beed36ed proposal=defaults 
> pfsgroup=OAKLEY_GROUP_MODP2048}
> 	> Jan  7 19:15:57 vpn pluto[10094]: "A-B" #2: transition from
> 	> state STATE_QUICK_I1 to state STATE_QUICK_I2
> 	> Jan  7 19:15:57 vpn pluto[10094]: "A-B" #2: STATE_QUICK_I2:
> 	> sent QI2, IPsec SA established tunnel mode {ESP=>0x45d84918
> 	> <0x892b2f5a xfrm=AES_128-HMAC_SHA1 NATOA=none 
> NATD=none DPD=none}
> 	> Jan  7 19:16:16 vpn pluto[10094]: "A-B" #1: ignoring Delete
> 	> SA payload: PROTO_IPSEC_ESP SA(0x45d84917) not found 
> (maybe expired)
> 	> Jan  7 19:16:16 vpn pluto[10094]: "A-B" #1: received and
> 	> ignored informational message
> 	>
> 	>
> 	> Thx for Help.
> 	>
> 	> --
> 	> TC
> 	>
> 	>
> 	
> 	
> 
> 
> 
> 
> -- 
> --
> TC
> 
> 


From petermcgill at goco.net  Wed Jan  7 17:28:01 2009
From: petermcgill at goco.net (Peter McGill)
Date: Wed, 7 Jan 2009 17:28:01 -0500
Subject: [Openswan Users] net-to-net - openswan 2.6.18 on k.2.6.24.7
In-Reply-To: <ebc7cfa10901071307h6de5b07ds66fc2c29de14c73c@mail.gmail.com>
References: <ebc7cfa10901070919l59c3ee09id8a9c04d8b285016@mail.gmail.com>
	<49D3CA8FC3E94ACBB8C96536EC448844@peter>
	<ebc7cfa10901071215v1441e6a8rc02e66247fb04b74@mail.gmail.com>
	<4733464FD2EF4EF1A3F5F8006D6C52D9@peter>
	<ebc7cfa10901071307h6de5b07ds66fc2c29de14c73c@mail.gmail.com>
Message-ID: <D1DE2863E42E4744A2D055461F37543F@peter>

TC,

Your config, status and logs look good.

> on both sides firewall is down. iptables -F
-F doesn't necessarily completely disable the firewall.

ipsec0    Link encap:Ethernet  HWaddr 00:d0:b7:52:8c:a1  
          inet addr:82.79.83.23  Mask:255.255.255.0
          UP RUNNING NOARP  MTU:16260  Metric:1
          RX packets:51 errors:0 dropped:51 overruns:0 frame:0
          TX packets:0 errors:0 dropped:6 overruns:0 carrier:0
          collisions:0 txqueuelen:10 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
Something is causing packets to be dropped.

Could you double-check firewall for me with:
iptables -t filter -n -L -v
iptables -t nat -n -L -v
iptables -t mangle -n -L -v
It didn't show in the barf.

Can you try ping/traceroute to/from different hosts, ie 192.168.23.2 & 192.168.10.253?

You have a strange route in your table.
+ _________________________ netstat-rn
+ netstat -nr
+ head -n 100
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.23.0    0.0.0.0         255.255.255.0   U         0 0          0 eth1
***
192.168.23.0    0.0.0.0         255.255.255.0   U         0 0          0 ipsec0
The above route looks wrong/strange to me, not sure why it's there.
***
82.79.83.0      0.0.0.0         255.255.255.0   U         0 0          0 eth0
82.79.83.0      0.0.0.0         255.255.255.0   U         0 0          0 ipsec0
192.168.10.0    0.0.0.0         255.255.255.0   U         0 0          0 ipsec0
127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo
0.0.0.0         82.79.83.1      0.0.0.0         UG        0 0          0 eth0
Not sure what effect this might have.
Perhaps someone else on the list has seen this before?

You also have some netkey code still built as modules, you should stick with either klips or netkey.
+ _________________________ usr/src/linux/.config
+ test -f /proc/config.gz
++ uname -r
+ test -f /lib/modules/2.6.24.7/build/.config
++ uname -r
+ egrep 'CONFIG_IPSEC|CONFIG_KLIPS|CONFIG_NET_KEY|CONFIG_INET|CONFIG_IP|CONFIG_HW_RANDOM|CONFIG_CRYPTO_DEV|_XFRM'
+ cat /lib/modules/2.6.24.7/build/.config
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
*** CONFIG_NET_KEY=m disable this ***
CONFIG_INET=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
CONFIG_INET_TUNNEL=m
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
CONFIG_KLIPS=y
CONFIG_KLIPS_ESP=y
CONFIG_KLIPS_AH=y
CONFIG_KLIPS_AUTH_HMAC_MD5=y
CONFIG_KLIPS_AUTH_HMAC_SHA1=y
CONFIG_KLIPS_ALG=y
# CONFIG_KLIPS_ENC_CRYPTOAPI is not set
CONFIG_KLIPS_ENC_3DES=y
CONFIG_KLIPS_ENC_AES=y
CONFIG_KLIPS_IPCOMP=y
# CONFIG_KLIPS_OCF is not set
CONFIG_KLIPS_DEBUG=y
CONFIG_KLIPS_IF_MAX=64

Peter McGill
IT Systems Analyst
Gra Ham Energy Limited 

> -----Original Message-----
> From: TC [mailto:tonisaco at gmail.com] 
> Sent: January 7, 2009 4:07 PM
> To: petermcgill at goco.net
> Subject: Re: [Openswan Users] net-to-net - openswan 2.6.18 on 
> k.2.6.24.7
> 
> hi peter,
> and thank you for your time
> 
> here is my ipsec_barf
> i've made the ping test
> 
> ping 192.168.10.254 -I eth1
> PING 192.168.10.254 (192.168.10.254) from 192.168.23.1 eth1: 
> 56(84) bytes of data.
> >From 192.168.23.1 icmp_seq=2 Destination Host Unreachable
> From 192.168.23.1 icmp_seq=3 Destination Host Unreachable
> From 192.168.23.1 icmp_seq=4 Destination Host Unreachable
> 
> ping 192.168.23.1 -I eth1
> PING 192.168.23.1 (192.168.83.1) from 192.168.10.254 eth1: 
> 56(84) bytes of data.
> >From 192.168.10.254 icmp_seq=1 Destination Host Unreachable
> From 192.168.10.254 icmp_seq=2 Destination Host Unreachable
> From 192.168.10.254 icmp_seq=3 Destination Host Unreachable
> 
> --- 192.168.83.1 ping statistics ---
> 4 packets transmitted, 0 received, +3 errors, 100% packet 
> loss, time 3012ms
> , pipe 3
> 
> with tcpdump on other side but no packets are arriveing
> 
> 
> On Wed, Jan 7, 2009 at 10:43 PM, Peter McGill 
> <petermcgill at goco.net> wrote:
> 
> 
> 	I also run slackware.
> 	Your logs indicate the tunnel is up and working.
> 	Have you enabled forwarding on your openswan hosts?
> 	cat /proc/sys/net/ipv4/ip_forward
> 	echo "1" > /proc/sys/net/ipv4/ip_forward
> 	Have you tested the tunnel by pinging from a host in one subnet
> 	to a host in the other subnet. Instead of server to server?
> 	Have you done a tcpdump during a test to see what's happening?
> 	What is the output of ipsec verify?
> 	Can you send an ipsec barf? It will contain useful 
> debugging info,
> 	that will speed up the troubleshooting process.
> 	ipsec barf > ipsec_barf.txt
> 	Note a barf will contain the status of ip_forward, ipsec logs
> 	and ipsec verify, ipsec.conf and network info, so if you send a
> 	barf, you don't need to repeat the other information. Barf will
> 	contain your ip addresses and a checksum of your keys to verify
> 	they match, but not your actual keys. A barf is very large so
> 	please send it privately, not on the list.
> 	Barf does not do a tcpdump or ping tests so doing those is still
> 	usefull.
> 	
> 
> 	Peter McGill
> 	IT Systems Analyst
> 	Gra Ham Energy Limited
> 	
> 	> -----Original Message-----
> 	
> 	> From: TC [mailto:tonisaco at gmail.com]
> 	> Sent: January 7, 2009 3:15 PM
> 	> To: petermcgill at goco.net
> 	> Cc: users at openswan.org
> 	> Subject: Re: [Openswan Users] net-to-net - openswan 2.6.18 on
> 	> k.2.6.24.7
> 	>
> 	> Hi,
> 	>
> 	> on both sides run pc based routers with slackware 12.1
> 	> on both sides firewall is down. iptables -F
> 	> I added leftsource and rightsource but same result.
> 	> here is the ipsec auto --status output:
> 	>
> 	> root at vpn:/usr/src/linux# ipsec auto --status
> 	> 000 using kernel interface: klips
> 	> 000 interface ipsec0/eth0 82.79.77.xy
> 	> 000 %myid = (none)
> 	> 000 debug none
> 	> 000
> 	> 000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=64,
> 	> keysizemin=192, keysizemax=192
> 	> 000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=128,
> 	> keysizemin=128, keysizemax=256
> 	> 000 algorithm ESP auth attr: id=1,
> 	> name=AUTH_ALGORITHM_HMAC_MD5, keysizemin=128, keysizemax=128
> 	> 000 algorithm ESP auth attr: id=2,
> 	> name=AUTH_ALGORITHM_HMAC_SHA1, keysizemin=160, keysizemax=160
> 	> 000 algorithm ESP auth attr: id=9,
> 	> name=AUTH_ALGORITHM_AES_CBC, keysizemin=128, keysizemax=128
> 	> 000
> 	> 000 algorithm IKE encrypt: id=3, name=OAKLEY_BLOWFISH_CBC,
> 	> blocksize=8, keydeflen=128
> 	> 000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC,
> 	> blocksize=8, keydeflen=192
> 	> 000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC,
> 	> blocksize=16, keydeflen=128
> 	> 000 algorithm IKE encrypt: id=65004, name=OAKLEY_SERPENT_CBC,
> 	> blocksize=16, keydeflen=128
> 	> 000 algorithm IKE encrypt: id=65005, name=OAKLEY_TWOFISH_CBC,
> 	> blocksize=16, keydeflen=128
> 	> 000 algorithm IKE encrypt: id=65289,
> 	> name=OAKLEY_TWOFISH_CBC_SSH, blocksize=16, keydeflen=128
> 	> 000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
> 	> 000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
> 	> 000 algorithm IKE hash: id=4, name=OAKLEY_SHA2_256, 
> hashsize=32
> 	> 000 algorithm IKE hash: id=6, name=OAKLEY_SHA2_512, 
> hashsize=64
> 	> 000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024,
> 	> bits=1024
> 	> 000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536,
> 	> bits=1536
> 	> 000 algorithm IKE dh group: id=14,
> 	> name=OAKLEY_GROUP_MODP2048, bits=2048
> 	> 000 algorithm IKE dh group: id=15,
> 	> name=OAKLEY_GROUP_MODP3072, bits=3072
> 	> 000 algorithm IKE dh group: id=16,
> 	> name=OAKLEY_GROUP_MODP4096, bits=4096
> 	> 000 algorithm IKE dh group: id=17,
> 	> name=OAKLEY_GROUP_MODP6144, bits=6144
> 	> 000 algorithm IKE dh group: id=18,
> 	> name=OAKLEY_GROUP_MODP8192, bits=8192
> 	> 000
> 	> 000 stats db_ops: {curr_cnt, total_cnt, maxsz}
> 	> :context={0,0,0} trans={0,0,0} attrs={0,0,0}
> 	> 000
> 	> 000 "baiamare-negresti":
> 	> 192.168.10.0/24===82.79.77.xy<82.79.77.xy>[+S=C]---82.79.77.65
> 	> ...82.79.83.1---82.79.83.nm<82.79.83.nm>[+S=C]===192.168.23.0/
> 	> 24; erouted; eroute owner: #4
> 	> 000 "baiamare-negresti":     myip=192.168.10.254; 
> hisip=192.168.23.1;
> 	> 000 "baiamare-negresti":   ike_life: 3600s; ipsec_life:
> 	> 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3
> 	> 000 "baiamare-negresti":   policy:
> 	> RSASIG+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW; prio: 24,24; 
> interface: eth0;
> 	> 000 "baiamare-negresti":   newest ISAKMP SA: #3; 
> newest IPsec SA: #4;
> 	> 000 "baiamare-negresti":   IKE algorithm newest:
> 	> AES_CBC_128-SHA1-MODP2048
> 	> 000
> 	> 000 #4: "baiamare-negresti":500 STATE_QUICK_R2 (IPsec SA
> 	> established); EVENT_SA_REPLACE in 28205s; newest IPSEC;
> 	> eroute owner; isakmp#3; idle; import:not set
> 	> 000 #4: "baiamare-negresti" esp.572de5cb at 82.79.83.nm
> 	> esp.f718f73e at 82.79.77.xy tun.1004 at 82.79.83.nm
> 	> tun.1003 at 82.79.77.xy ref=13 refhim=9
> 	> 000 #3: "baiamare-negresti":500 STATE_MAIN_R3 (sent MR3,
> 	> ISAKMP SA established); EVENT_SA_REPLACE in 3005s; newest
> 	> ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:not set
> 	> 000 #2: "baiamare-negresti":500 STATE_QUICK_I2 (sent QI2,
> 	> IPsec SA established); EVENT_SA_REPLACE in 27647s; isakmp#1;
> 	> idle; import:admin initiate
> 	> 000 #2: "baiamare-negresti" esp.f7140fdc at 82.79.83.nm
> 	> esp.f718f73d at 82.79.77.xy tun.1001 at 82.79.83.nm
> 	> tun.1002 at 82.79.77.xy ref=11 refhim=9
> 	> 000 #1: "baiamare-negresti":500 STATE_MAIN_I4 (ISAKMP SA
> 	> established); EVENT_SA_REPLACE in 2555s; lastdpd=-1s(seq in:0
> 	> out:0); idle; import:admin initiate
> 	>
> 	>
> 	>
> 	> On Wed, Jan 7, 2009 at 9:13 PM, Peter McGill
> 	> <petermcgill at goco.net> wrote:
> 	>
> 	>
> 	>       This is not uncommon, -I doesn't always work, try
> 	> adding the following to your conf.
> 	>              leftsourceip=192.168.10.254
> 	>              rightsourceip=192.168.23.1
> 	>       Also check that your firewall isn't blocking 
> tunnel traffic.
> 	>       You need to allow communication between 192.168.10.0/24
> 	> and 192.168.23.0/24 on ipsec0.
> 	>       Not sure what that Delete SA message is about, what
> 	> ipsec device is on the other end of tunnel?
> 	>
> 	>       Peter McGill
> 	>       IT Systems Analyst
> 	>       Gra Ham Energy Limited
> 	>
> 	>
> 	>       > -----Original Message-----
> 	>       > From: users-bounces at openswan.org
> 	>       > [mailto:users-bounces at openswan.org] On Behalf Of TC
> 	>       > Sent: January 7, 2009 12:20 PM
> 	>       > To: users at openswan.org
> 	>       > Subject: [Openswan Users] net-to-net - openswan
> 	> 2.6.18 on k.2.6.24.7
> 	>       >
> 	>       > Hi all,
> 	>       >
> 	>       > I have installed kernel 2.6.24.7 + klips patch +
> 	> openswan 2.6.18
> 	>       > I have made a net-to-net config. The connection start
> 	> but I cannot
> 	>       > ping the end of the tunnel.
> 	>       >
> 	>       > ping 192.168.23.1 -I eth1 not working
> 	>       > ping 192.168.10.254 -I eth1 not working
> 	>       >
> 	>       > ping 192.168.10.254 -I eth1
> 	>       > PING 192.168.10.254 (192.168.10.254) from 
> 192.168.23.1 eth1:
> 	>       > 56(84) bytes of data.
> 	>       > From 192.168.23.1 icmp_seq=2 Destination Host 
> Unreachable
> 	>       > >From 192.168.23.1 icmp_seq=3 Destination 
> Host Unreachable
> 	>       > From 192.168.23.1 icmp_seq=4 Destination Host 
> Unreachable
> 	>       >
> 	>       >
> 	>       > A config(and same config to B but different 
> ipsec.secrets)
> 	>       >
> 	>       > version 2.0
> 	>       >
> 	>       > config setup
> 	>       >     interfaces="ipsec0=eth0"
> 	>       >     protostack=klips
> 	>       >
> 	>       > 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
> 	>       >
> 	>       > conn A-B
> 	>       >     left=WAN_IP_FROM_A
> 	>       >     leftnexthop=GATEWAY_FROM_A
> 	>       >     leftsubnet=192.168.10.0/24
> 	>       >     right=WAN_IP_FROM_B
> 	>       >     rightnexthop=GATEWAY_FROM_B
> 	>       >     rightsubnet=192.168.23.0/24
> 	>       >     type=tunnel
> 	>       >     auth=esp
> 	>       >     leftrsasigkey=0sAQOY...
> 	>       >     rightrsasigkey=0sAQNqB...
> 	>       >     auto=start
> 	>       >
> 	>       > in /var/log/syslog I have:
> 	>       >    Jan  7 19:13:12 vpn ipsec_setup: Starting Openswan
> 	> IPsec 2.6.18...
> 	>       >    Jan  7 19:13:12 vpn ipsec__plutorun: 002 
> added connection
> 	>       > description "A-B"
> 	>       >    Jan  7 19:13:12 vpn ipsec__plutorun: 104 "A-B" #1:
> 	>       > STATE_MAIN_I1: initiate
> 	>       >
> 	>       > in /var/log.secure I have:
> 	>       > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: 
> STATE_MAIN_I2:
> 	>       > sent MI2, expecting MR2
> 	>       > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: 
> transition from
> 	>       > state STATE_MAIN_I2 to state STATE_MAIN_I3
> 	>       > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: 
> STATE_MAIN_I3:
> 	>       > sent MI3, expecting MR3
> 	>       > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: 
> received Vendor
> 	>       > ID payload [CAN-IKEv2]
> 	>       > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: 
> Main mode peer ID
> 	>       > is ID_IPV4_ADDR: '82.79.83.23'
> 	>       > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: 
> transition from
> 	>       > state STATE_MAIN_I3 to state STATE_MAIN_I4
> 	>       > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1: 
> STATE_MAIN_I4:
> 	>       > ISAKMP SA established {auth=OAKLEY_RSA_SIG 
> cipher=aes_128
> 	>       > prf=oakley_sha group=modp2048}
> 	>       > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #2: 
> initiating Quick
> 	>       > Mode RSASIG+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW 
> {using isakmp#1
> 	>       > msgid:beed36ed proposal=defaults
> 	> pfsgroup=OAKLEY_GROUP_MODP2048}
> 	>       > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #2: 
> transition from
> 	>       > state STATE_QUICK_I1 to state STATE_QUICK_I2
> 	>       > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #2: 
> STATE_QUICK_I2:
> 	>       > sent QI2, IPsec SA established tunnel mode 
> {ESP=>0x45d84918
> 	>       > <0x892b2f5a xfrm=AES_128-HMAC_SHA1 NATOA=none
> 	> NATD=none DPD=none}
> 	>       > Jan  7 19:16:16 vpn pluto[10094]: "A-B" #1: 
> ignoring Delete
> 	>       > SA payload: PROTO_IPSEC_ESP SA(0x45d84917) not found
> 	> (maybe expired)
> 	>       > Jan  7 19:16:16 vpn pluto[10094]: "A-B" #1: 
> received and
> 	>       > ignored informational message
> 	>       >
> 	>       >
> 	>       > Thx for Help.
> 	>       >
> 	>       > --
> 	>       > TC
> 	>       >
> 	>       >
> 	>
> 	>
> 	>
> 	>
> 	>
> 	>
> 	> --
> 	> --
> 	> TC
> 	>
> 	>
> 	
> 	
> 
> 
> 
> 
> -- 
> --
> TC
> 
> 


From alfonso.viso at selftrade.com  Thu Jan  8 07:46:57 2009
From: alfonso.viso at selftrade.com (Alfonso Viso)
Date: Thu, 8 Jan 2009 13:46:57 +0100
Subject: [Openswan Users] upgrade version openswan
Message-ID: <515251629957C542816307570516B86D630920@BSRSPCLE001.boursorama.fr>

Hello all,
 
we have configured Openswan U2.4.13 in a Fedora Cora 4 server Kernel 2.6.17 and now we want to upgrade the version to 2.6.18 , my question is if this version is compatible with fedora 4 or we have to upgrade the version of server.
 
thanks in advanced
regards

Alfonso Viso 



___________________________________

Ce message contient des informations confidentielles ou appartenant ?
Boursorama et est ?tabli ? l'intention exclusive de ses destinataires. Toute
divulgation, utilisation, diffusion ou reproduction (totale ou partielle) de ce
message, ou des informations qu'il contient, doit ?tre pr?alablement
autoris?e. Tout message ?lectronique est susceptible d'alt?ration et son
int?grit? ne peut ?tre assur?e. Boursorama d?cline toute responsabilit? au
titre de ce message s'il a ?t? modifi? ou falsifi?. Si vous n'?tes pas
destinataire de ce message, merci de le d?truire imm?diatement et d'avertir
l'exp?diteur de l'erreur de distribution et de la destruction du message.
___________________________________

This e-mail contains confidential information or information belonging to
Boursorama and is intended solely for the addressees. The unauthorised
disclosure, use, dissemination or copying (either whole or partial) of this
e-mail, or any information it contains, is prohibited. E-mails are susceptible
to alteration and their integrity cannot be guaranteed. Boursorama shall not be
liable for this e-mail if modified or falsified. If you are not the intended
recipient of this e-mail, please delete it immediately from your system and
notify the sender of the wrong delivery and the mail deletion.
___________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090108/49f677e3/attachment.html 

From sybille.ebert at gmx.net  Thu Jan  8 10:01:34 2009
From: sybille.ebert at gmx.net (Sybille Ebert)
Date: Thu, 08 Jan 2009 16:01:34 +0100
Subject: [Openswan Users] KLIPS not working with CentOS 5.2
Message-ID: <4966154E.7070006@gmx.net>

Has anybody had any luck with KLIPS on CentOS 5.2?

I am using a patched kernel-2.6.18-92.1.22.el5.src.rpm with
openswan-2.6.20rc1. When I ping the remote side, ping is seen entering
ipsec0 tunnel, but there is no encrypted (ESP) traffic following on eth0.

Klips debug log is attached below.

I have also tried several other combinations of kernels and OpenSwan,
but I cannot make it work. Using protostack=netkey works (ESP packets
leave the box).

S

## begin klips debug log

Jan  6 12:41:27 centos kernel: klips_debug:ipsec_tunnel_hard_header:
skb->dev=ipsec0 dev=ipsec0.
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_tunnel_hard_header:
Revectored 0p00000000->0pe4952e28 len=84 type=2048 dev=ipsec0->eth0
dev_addr=00:0c:29:dd:65:bb ip=0a010001->0a020001
Jan  6 12:41:27 centos kernel:
Jan  6 12:41:27 centos kernel:
Jan  6 12:41:27 centos kernel: ipsec_tunnel_start_xmit:
STARTING<6>klips_debug:ipsec_xmit_strip_hard_header: >>> skb->len=98
hard_header_len:14 00:0c:29:dd:65:bb:00:0c:29:dd:65:bb:08:00
Jan  6 12:41:27 centos kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:84 id:0 DF frag_off:0 ttl:64 proto:1 (ICMP) chk:9893 saddr:10.1.0.1
daddr:10.2.0.1 type:code=8:0
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_xmit_strip_hard_header:
Original head,tailroom: 2,28
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_findroute:
10.1.0.1:0->10.2.0.1:0 1
Jan  6 12:41:27 centos kernel: klips_debug:rj_match: * See if we match
exactly as a host destination
Jan  6 12:41:27 centos kernel: klips_debug:rj_match: ** try to match a
leaf, t=0pdc04ea80
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_xmit_SAlookup: checking
for local udp/500 IKE packet saddr=a010001, er=0pdc04ea80,
daddr=a020001, er_dst=c0a8012a, proto=1 sport=0 dport=0
Jan  6 12:41:27 centos kernel: ipsec_sa_getbyid: linked entry in
ipsec_sa table for hash=2 of SA:tun.1001 at 192.168.1.42 requested.
Jan  6 12:41:27 centos kernel: ipsec_sa_get: ipsec_sa e2351c00
SA:tun.1001 at 192.168.1.42, ref:1 reference count (2++) incremented by
ipsec_sa_getbyid:552.
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_xmit_init2: found
ipsec_sa -- SA:<IPIP> tun.1001 at 192.168.1.42
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_xmit_init2: calling
room for <IPIP>, SA:tun.1001 at 192.168.1.42
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_xmit_init2: Required
head,tailroom: 20,0
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_xmit_init2: calling
room for <ESP_AES_HMAC_SHA1>, SA:esp.a2beb5dc at 192.168.1.42
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_xmit_init2: Required
head,tailroom: 24,24
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_xmit_init2: existing
head,tailroom: 2,28 before applying xforms with head,tailroom: 44,24 .
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_xmit_init2: mtu:1500
physmtu:1500 tothr:44 tottr:24 mtudiff:68 ippkttotlen:84
Jan  6 12:41:27 centos kernel: klips_info:ipsec_xmit_init2: dev ipsec0
mtu of 1500 decreased by 73 to 1427
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_xmit_init2: allocating
14 bytes for hardheader.
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_xmit_init2:
head,tailroom: 16,28 after hard_header stripped.
Jan  6 12:41:27 centos kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:84 id:0 DF frag_off:0 ttl:64 proto:1 (ICMP) chk:9893 saddr:10.1.0.1
daddr:10.2.0.1 type:code=8:0
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_xmit_init2:
head,tailroom: 76,96 after allocation
Jan  6 12:41:27 centos kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:84 id:0 DF frag_off:0 ttl:64 proto:1 (ICMP) chk:9893 saddr:10.1.0.1
daddr:10.2.0.1 type:code=8:0
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_xmit_encap_once:
calling output for <IPIP>, SA:tun.1001 at 192.168.1.42
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_xmit_encap_once:
pushing 20 bytes, putting 0, proto 4.
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_xmit_encap_once:
head,tailroom: 56,96 before xform.
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_xmit_encap_once: after
<IPIP>, SA:tun.1001 at 192.168.1.42:
Jan  6 12:41:27 centos kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:104 id:30378 frag_off:0 ttl:64 proto:4 chk:32837 saddr:192.168.1.40
daddr:192.168.1.42
Jan  6 12:41:27 centos kernel: ipsec_sa_put: ipsec_sa e2351c00
SA:tun.1001 at 192.168.1.42, ref:1 reference count (3--) decremented by
ipsec_xmit_cont:1096.
Jan  6 12:41:27 centos kernel: ipsec_sa_get: ipsec_sa e386b800
SA:esp.a2beb5dc at 192.168.1.42, ref:2 reference count (3++) incremented by
ipsec_xmit_cont:1101.
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_xmit_encap_once:
calling output for <ESP_AES_HMAC_SHA1>, SA:esp.a2beb5dc at 192.168.1.42
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_xmit_encap_once:
pushing 24 bytes, putting 24, proto 50.
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_xmit_encap_once:
head,tailroom: 32,72 before xform.
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_alg_esp_encrypt:
entering with encalg=12, ixt_e=e8ef1440
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_alg_esp_encrypt:
calling cbc_encrypt encalg=12 ips_key_e=d901a800 idat=c1696a4c ilen=96
iv=c1696a3c, encrypt=1
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_alg_esp_encrypt:
returned ret=96
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_xmit_encap_once: after
<ESP_AES_HMAC_SHA1>, SA:esp.a2beb5dc at 192.168.1.42:
Jan  6 12:41:27 centos kernel: klips_debug:   IP: ihl:20 ver:4 tos:0
tlen:152 id:30378 frag_off:0 ttl:64 proto:50 (ESP) chk:32743
saddr:192.168.1.40 daddr:192.168.1.42
Jan  6 12:41:27 centos kernel: ipsec_sa_put: ipsec_sa e386b800
SA:esp.a2beb5dc at 192.168.1.42, ref:2 reference count (4--) decremented by
ipsec_xmit_cont:1096.
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_findroute:
192.168.1.40:0->192.168.1.42:0 50
Jan  6 12:41:27 centos kernel: klips_debug:rj_match: * See if we match
exactly as a host destination
Jan  6 12:41:27 centos kernel: klips_debug:rj_match: ** try to match a
leaf, t=0pdc04ea80
Jan  6 12:41:27 centos kernel: klips_debug:rj_match: *** start searching
up the tree, t=0pdc04ea80
Jan  6 12:41:27 centos kernel: klips_debug:rj_match: **** t=0pdc04ea98
Jan  6 12:41:27 centos kernel: klips_debug:rj_match: **** t=0pe5be5c00
Jan  6 12:41:27 centos kernel: klips_debug:rj_match: *****
cp2=0pde223ce8 cp3=0pdf05a670
Jan  6 12:41:27 centos kernel: klips_debug:rj_match: ***** not found.
Jan  6 12:41:27 centos kernel:
klips_debug:ipsec_xmit_restore_hard_header: After recursive xforms --
head,tailroom: 32,72
Jan  6 12:41:27 centos kernel:
klips_debug:ipsec_xmit_restore_hard_header: With hard_header, final
head,tailroom: 18,72
Jan  6 12:41:27 centos kernel: klips_debug:ipsec_xmit_send:
ip_route_output failed with error code -22, dropped

## end klips debug log

(Previously, I posted about this to the dev mailinglist, but the
bug I was suspecting had already been fixed by then. I hope this is not
considered as double-posting.)

From r.laban at ism.nl  Thu Jan  8 10:21:36 2009
From: r.laban at ism.nl (Ruben Laban)
Date: Thu, 8 Jan 2009 16:21:36 +0100
Subject: [Openswan Users] KLIPS not working with CentOS 5.2
In-Reply-To: <4966154E.7070006@gmx.net>
References: <4966154E.7070006@gmx.net>
Message-ID: <200901081621.36551.r.laban@ism.nl>

On Thursday 08 January 2009 at 16:01 (CET), Sybille Ebert wrote:
> (Previously, I posted about this to the dev mailinglist, but the
> bug I was suspecting had already been fixed by then. I hope this is not
> considered as double-posting.)

Not sure which bug you relate to (didn't check -dev emails), but it sounds 
like you're being bitten by this bug: 
http://bugs.xelerance.com/view.php?id=985
Which is, as of yet, still not fixed.

-- 
Ruben

From cioban at gmail.com  Thu Jan  8 11:28:39 2009
From: cioban at gmail.com (Sergio Cioban Filho)
Date: Thu, 8 Jan 2009 14:28:39 -0200
Subject: [Openswan Users] KLIPS not working with CentOS 5.2
In-Reply-To: <200901081621.36551.r.laban@ism.nl>
References: <4966154E.7070006@gmx.net> <200901081621.36551.r.laban@ism.nl>
Message-ID: <f18571170901080828k19345455h71992c0665fdfc21@mail.gmail.com>

Hi,

I get same problem on CentOS 5.1 with Openswan 2.6.18 and 2.6.19 .
Netkey works fine but klips no.
On my server, the TX error count of ipsec0 interface is increased .
Only Openswan-2.4.13 worked with KLIPS on my Centos5.1

I think this is a BUG.

Regards,
---
S?rgio Cioban Filho
| Tecn?logo em Gest?o de TI
| Linux Professional Institute Certified - Level 1
------------------------------------------------------------
| Linux - Servidores - Firewall - VPN
| Virtualiza??o - VoIP - ShellScript - C - PHP
| http://cioban.googlepages.com
| +55 48 9989-8733
------------------------------------------------------------
..:: Seja livre, use LiNuX!! ::..



On Thu, Jan 8, 2009 at 13:21, Ruben Laban <r.laban at ism.nl> wrote:

> On Thursday 08 January 2009 at 16:01 (CET), Sybille Ebert wrote:
> > (Previously, I posted about this to the dev mailinglist, but the
> > bug I was suspecting had already been fixed by then. I hope this is not
> > considered as double-posting.)
>
> Not sure which bug you relate to (didn't check -dev emails), but it sounds
> like you're being bitten by this bug:
> http://bugs.xelerance.com/view.php?id=985
> Which is, as of yet, still not fixed.
>
> --
> Ruben
> _______________________________________________
> 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=283155
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090108/226da73f/attachment.html 

From petermcgill at goco.net  Thu Jan  8 12:14:36 2009
From: petermcgill at goco.net (Peter McGill)
Date: Thu, 8 Jan 2009 12:14:36 -0500
Subject: [Openswan Users] net-to-net - openswan 2.6.18 on k.2.6.24.7
In-Reply-To: <ebc7cfa10901072248l4bc6cff5w2f224bf4ca4509a1@mail.gmail.com>
References: <ebc7cfa10901070919l59c3ee09id8a9c04d8b285016@mail.gmail.com>
	<49D3CA8FC3E94ACBB8C96536EC448844@peter>
	<ebc7cfa10901071215v1441e6a8rc02e66247fb04b74@mail.gmail.com>
	<4733464FD2EF4EF1A3F5F8006D6C52D9@peter>
	<ebc7cfa10901071307h6de5b07ds66fc2c29de14c73c@mail.gmail.com>
	<D1DE2863E42E4744A2D055461F37543F@peter>
	<ebc7cfa10901072248l4bc6cff5w2f224bf4ca4509a1@mail.gmail.com>
Message-ID: <C61F80ACC46F438689EEBE275E7F71DB@peter>

TC,

It looks like you've encountered the following bug:
http://bugs.xelerance.com/view.php?id=985
Options:
Switch from klips to netkey (you won't have ipsec0).
Drop to a pre 2.6.24 kernel.
Wait for the bug to be fixed.

Paul,

Is it normal for newer openswan's to include a route to the lan on ipsec0 or is that part of the bug?

+ _________________________ netstat-rn
+ netstat -nr
+ head -n 100
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.23.0    0.0.0.0         255.255.255.0   U         0 0          0 eth1
192.168.23.0    0.0.0.0         255.255.255.0   U         0 0          0 ipsec0 ***************
82.79.83.0      0.0.0.0         255.255.255.0   U         0 0          0 eth0
82.79.83.0      0.0.0.0         255.255.255.0   U         0 0          0 ipsec0
192.168.10.0    0.0.0.0         255.255.255.0   U         0 0          0 ipsec0
127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo
0.0.0.0         82.79.83.1      0.0.0.0         UG        0 0          0 eth0

Peter McGill
IT Systems Analyst
Gra Ham Energy Limited 

> -----Original Message-----
> From: TC [mailto:tonisaco at gmail.com] 
> Sent: January 8, 2009 1:48 AM
> To: petermcgill at goco.net
> Subject: Re: [Openswan Users] net-to-net - openswan 2.6.18 on 
> k.2.6.24.7
> 
> Hi Peter,
> 
> I think is something strange with the routeing table:
> 
> the table from point A:
> 
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric 
> Ref    Use Iface
> 82.79.77.64     0.0.0.0         255.255.255.224 U     0      
> 0        0 eth0
> 82.79.77.64     0.0.0.0         255.255.255.224 U     0      
> 0        0 ipsec0
> 192.168.23.0    82.79.77.65     255.255.255.0   UG    0      
> 0        0 ipsec0
> 192.168.10.0    0.0.0.0         255.255.255.0   U     0      
> 0        0 eth1
> 127.0.0.0       0.0.0.0         255.0.0.0       U     0      
> 0        0 lo
> 0.0.0.0         82.79.77.65     0.0.0.0         UG    1      
> 0        0 eth0
> 
> 
> the table from B:
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric 
> Ref    Use Iface
> 192.168.23.0    0.0.0.0         255.255.255.0   U     0      
> 0        0 eth1
> 192.168.23.0    0.0.0.0         255.255.255.0   U     0      
> 0        0 ipsec0
> 82.79.83.0      0.0.0.0         255.255.255.0   U     0      
> 0        0 eth0
> 82.79.83.0      0.0.0.0         255.255.255.0   U     0      
> 0        0 ipsec0
> 192.168.10.0    0.0.0.0         255.255.255.0   U     0      
> 0        0 ipsec0
> 127.0.0.0       0.0.0.0         255.0.0.0       U     0      
> 0        0 lo
> 0.0.0.0         82.79.83.1      0.0.0.0         UG    1      
> 0        0 eth0
> 
> 
> 
> On Thu, Jan 8, 2009 at 12:28 AM, Peter McGill 
> <petermcgill at goco.net> wrote:
> 
> 
> 	TC,
> 	
> 	Your config, status and logs look good.
> 	
> 
> 	> on both sides firewall is down. iptables -F
> 	
> 	-F doesn't necessarily completely disable the firewall.
> 	
> 	ipsec0    Link encap:Ethernet  HWaddr 00:d0:b7:52:8c:a1
> 	         inet addr:82.79.83.23  Mask:255.255.255.0
> 	         UP RUNNING NOARP  MTU:16260  Metric:1
> 	         RX packets:51 errors:0 dropped:51 overruns:0 frame:0
> 	         TX packets:0 errors:0 dropped:6 overruns:0 carrier:0
> 	         collisions:0 txqueuelen:10
> 	         RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
> 	Something is causing packets to be dropped.
> 	
> 	Could you double-check firewall for me with:
> 	iptables -t filter -n -L -v
> 	iptables -t nat -n -L -v
> 	iptables -t mangle -n -L -v
> 	It didn't show in the barf.
> 	
> 	Can you try ping/traceroute to/from different hosts, ie 
> 192.168.23.2 & 192.168.10.253?
> 	
> 	You have a strange route in your table.
> 	+ _________________________ netstat-rn
> 	+ netstat -nr
> 	+ head -n 100
> 	Kernel IP routing table
> 	Destination     Gateway         Genmask         Flags   
> MSS Window  irtt Iface
> 	192.168.23.0    0.0.0.0         255.255.255.0   U       
>   0 0          0 eth1
> 	***
> 	192.168.23.0    0.0.0.0         255.255.255.0   U       
>   0 0          0 ipsec0
> 	The above route looks wrong/strange to me, not sure why 
> it's there.
> 	***
> 	82.79.83.0      0.0.0.0         255.255.255.0   U       
>   0 0          0 eth0
> 	82.79.83.0      0.0.0.0         255.255.255.0   U       
>   0 0          0 ipsec0
> 	192.168.10.0    0.0.0.0         255.255.255.0   U       
>   0 0          0 ipsec0
> 	127.0.0.0       0.0.0.0         255.0.0.0       U       
>   0 0          0 lo
> 	0.0.0.0         82.79.83.1      0.0.0.0         UG      
>   0 0          0 eth0
> 	Not sure what effect this might have.
> 	Perhaps someone else on the list has seen this before?
> 	
> 	You also have some netkey code still built as modules, 
> you should stick with either klips or netkey.
> 	+ _________________________ usr/src/linux/.config
> 	+ test -f /proc/config.gz
> 	++ uname -r
> 	+ test -f /lib/modules/2.6.24.7/build/.config
> 	++ uname -r
> 	+ egrep 
> 'CONFIG_IPSEC|CONFIG_KLIPS|CONFIG_NET_KEY|CONFIG_INET|CONFIG_I
> P|CONFIG_HW_RANDOM|CONFIG_CRYPTO_DEV|_XFRM'
> 	+ cat /lib/modules/2.6.24.7/build/.config
> 	CONFIG_XFRM=y <http://2.6.24.7/build/.configCONFIG_XFRM=y> 
> 	# CONFIG_XFRM_USER is not set
> 	*** CONFIG_NET_KEY=m disable this ***
> 	CONFIG_INET=y
> 	# CONFIG_INET_AH is not set
> 	# CONFIG_INET_ESP is not set
> 	# CONFIG_INET_IPCOMP is not set
> 	# CONFIG_INET_XFRM_TUNNEL is not set
> 	CONFIG_INET_TUNNEL=m
> 	# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
> 	# CONFIG_INET_XFRM_MODE_TUNNEL is not set
> 	# CONFIG_INET_XFRM_MODE_BEET is not set
> 	# CONFIG_INET_LRO is not set
> 	CONFIG_INET_DIAG=y
> 	CONFIG_INET_TCP_DIAG=y
> 	CONFIG_KLIPS=y
> 	CONFIG_KLIPS_ESP=y
> 	CONFIG_KLIPS_AH=y
> 	CONFIG_KLIPS_AUTH_HMAC_MD5=y
> 	CONFIG_KLIPS_AUTH_HMAC_SHA1=y
> 	CONFIG_KLIPS_ALG=y
> 	# CONFIG_KLIPS_ENC_CRYPTOAPI is not set
> 	CONFIG_KLIPS_ENC_3DES=y
> 	CONFIG_KLIPS_ENC_AES=y
> 	CONFIG_KLIPS_IPCOMP=y
> 	# CONFIG_KLIPS_OCF is not set
> 	CONFIG_KLIPS_DEBUG=y
> 	CONFIG_KLIPS_IF_MAX=64
> 	
> 
> 	Peter McGill
> 	IT Systems Analyst
> 	Gra Ham Energy Limited
> 	
> 	> -----Original Message-----
> 	> From: TC [mailto:tonisaco at gmail.com]
> 	
> 	> Sent: January 7, 2009 4:07 PM
> 	> To: petermcgill at goco.net
> 	
> 	> Subject: Re: [Openswan Users] net-to-net - openswan 2.6.18 on
> 	> k.2.6.24.7
> 	>
> 	> hi peter,
> 	> and thank you for your time
> 	>
> 	> here is my ipsec_barf
> 	> i've made the ping test
> 	>
> 	> ping 192.168.10.254 -I eth1
> 	> PING 192.168.10.254 (192.168.10.254) from 192.168.23.1 eth1:
> 	> 56(84) bytes of data.
> 	> >From 192.168.23.1 icmp_seq=2 Destination Host Unreachable
> 	> From 192.168.23.1 icmp_seq=3 Destination Host Unreachable
> 	> From 192.168.23.1 icmp_seq=4 Destination Host Unreachable
> 	>
> 	> ping 192.168.23.1 -I eth1
> 	> PING 192.168.23.1 (192.168.83.1) from 192.168.10.254 eth1:
> 	> 56(84) bytes of data.
> 	> >From 192.168.10.254 icmp_seq=1 Destination Host Unreachable
> 	> From 192.168.10.254 icmp_seq=2 Destination Host Unreachable
> 	> From 192.168.10.254 icmp_seq=3 Destination Host Unreachable
> 	>
> 	> --- 192.168.83.1 ping statistics ---
> 	> 4 packets transmitted, 0 received, +3 errors, 100% packet
> 	> loss, time 3012ms
> 	> , pipe 3
> 	>
> 	> with tcpdump on other side but no packets are arriveing
> 	>
> 	>
> 	> On Wed, Jan 7, 2009 at 10:43 PM, Peter McGill
> 	> <petermcgill at goco.net> wrote:
> 	>
> 	>
> 	>       I also run slackware.
> 	>       Your logs indicate the tunnel is up and working.
> 	>       Have you enabled forwarding on your openswan hosts?
> 	>       cat /proc/sys/net/ipv4/ip_forward
> 	>       echo "1" > /proc/sys/net/ipv4/ip_forward
> 	>       Have you tested the tunnel by pinging from a 
> host in one subnet
> 	>       to a host in the other subnet. Instead of 
> server to server?
> 	>       Have you done a tcpdump during a test to see 
> what's happening?
> 	>       What is the output of ipsec verify?
> 	>       Can you send an ipsec barf? It will contain useful
> 	> debugging info,
> 	>       that will speed up the troubleshooting process.
> 	>       ipsec barf > ipsec_barf.txt
> 	>       Note a barf will contain the status of 
> ip_forward, ipsec logs
> 	>       and ipsec verify, ipsec.conf and network info, 
> so if you send a
> 	>       barf, you don't need to repeat the other 
> information. Barf will
> 	>       contain your ip addresses and a checksum of 
> your keys to verify
> 	>       they match, but not your actual keys. A barf is 
> very large so
> 	>       please send it privately, not on the list.
> 	>       Barf does not do a tcpdump or ping tests so 
> doing those is still
> 	>       usefull.
> 	>
> 	>
> 	>       Peter McGill
> 	>       IT Systems Analyst
> 	>       Gra Ham Energy Limited
> 	>
> 	>       > -----Original Message-----
> 	>
> 	>       > From: TC [mailto:tonisaco at gmail.com]
> 	>       > Sent: January 7, 2009 3:15 PM
> 	>       > To: petermcgill at goco.net
> 	>       > Cc: users at openswan.org
> 	>       > Subject: Re: [Openswan Users] net-to-net - 
> openswan 2.6.18 on
> 	>       > k.2.6.24.7
> 	>       >
> 	>       > Hi,
> 	>       >
> 	>       > on both sides run pc based routers with slackware 12.1
> 	>       > on both sides firewall is down. iptables -F
> 	>       > I added leftsource and rightsource but same result.
> 	>       > here is the ipsec auto --status output:
> 	>       >
> 	>       > root at vpn:/usr/src/linux# ipsec auto --status
> 	>       > 000 using kernel interface: klips
> 	>       > 000 interface ipsec0/eth0 82.79.77.xy
> 	>       > 000 %myid = (none)
> 	>       > 000 debug none
> 	>       > 000
> 	>       > 000 algorithm ESP encrypt: id=3, 
> name=ESP_3DES, ivlen=64,
> 	>       > keysizemin=192, keysizemax=192
> 	>       > 000 algorithm ESP encrypt: id=12, 
> name=ESP_AES, ivlen=128,
> 	>       > keysizemin=128, keysizemax=256
> 	>       > 000 algorithm ESP auth attr: id=1,
> 	>       > name=AUTH_ALGORITHM_HMAC_MD5, keysizemin=128, 
> keysizemax=128
> 	>       > 000 algorithm ESP auth attr: id=2,
> 	>       > name=AUTH_ALGORITHM_HMAC_SHA1, 
> keysizemin=160, keysizemax=160
> 	>       > 000 algorithm ESP auth attr: id=9,
> 	>       > name=AUTH_ALGORITHM_AES_CBC, keysizemin=128, 
> keysizemax=128
> 	>       > 000
> 	>       > 000 algorithm IKE encrypt: id=3, 
> name=OAKLEY_BLOWFISH_CBC,
> 	>       > blocksize=8, keydeflen=128
> 	>       > 000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC,
> 	>       > blocksize=8, keydeflen=192
> 	>       > 000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC,
> 	>       > blocksize=16, keydeflen=128
> 	>       > 000 algorithm IKE encrypt: id=65004, 
> name=OAKLEY_SERPENT_CBC,
> 	>       > blocksize=16, keydeflen=128
> 	>       > 000 algorithm IKE encrypt: id=65005, 
> name=OAKLEY_TWOFISH_CBC,
> 	>       > blocksize=16, keydeflen=128
> 	>       > 000 algorithm IKE encrypt: id=65289,
> 	>       > name=OAKLEY_TWOFISH_CBC_SSH, blocksize=16, 
> keydeflen=128
> 	>       > 000 algorithm IKE hash: id=1, 
> name=OAKLEY_MD5, hashsize=16
> 	>       > 000 algorithm IKE hash: id=2, 
> name=OAKLEY_SHA1, hashsize=20
> 	>       > 000 algorithm IKE hash: id=4, name=OAKLEY_SHA2_256,
> 	> hashsize=32
> 	>       > 000 algorithm IKE hash: id=6, name=OAKLEY_SHA2_512,
> 	> hashsize=64
> 	>       > 000 algorithm IKE dh group: id=2, 
> name=OAKLEY_GROUP_MODP1024,
> 	>       > bits=1024
> 	>       > 000 algorithm IKE dh group: id=5, 
> name=OAKLEY_GROUP_MODP1536,
> 	>       > bits=1536
> 	>       > 000 algorithm IKE dh group: id=14,
> 	>       > name=OAKLEY_GROUP_MODP2048, bits=2048
> 	>       > 000 algorithm IKE dh group: id=15,
> 	>       > name=OAKLEY_GROUP_MODP3072, bits=3072
> 	>       > 000 algorithm IKE dh group: id=16,
> 	>       > name=OAKLEY_GROUP_MODP4096, bits=4096
> 	>       > 000 algorithm IKE dh group: id=17,
> 	>       > name=OAKLEY_GROUP_MODP6144, bits=6144
> 	>       > 000 algorithm IKE dh group: id=18,
> 	>       > name=OAKLEY_GROUP_MODP8192, bits=8192
> 	>       > 000
> 	>       > 000 stats db_ops: {curr_cnt, total_cnt, maxsz}
> 	>       > :context={0,0,0} trans={0,0,0} attrs={0,0,0}
> 	>       > 000
> 	>       > 000 "baiamare-negresti":
> 	>       > 
> 192.168.10.0/24===82.79.77.xy<82.79.77.xy>[+S=C]---82.79.77.65
> 	>       > 
> ...82.79.83.1---82.79.83.nm<82.79.83.nm>[+S=C]===192.168.23.0/
> 	>       > 24; erouted; eroute owner: #4
> 	>       > 000 "baiamare-negresti":     myip=192.168.10.254;
> 	> hisip=192.168.23.1;
> 	>       > 000 "baiamare-negresti":   ike_life: 3600s; 
> ipsec_life:
> 	>       > 28800s; rekey_margin: 540s; rekey_fuzz: 100%; 
> keyingtries: 3
> 	>       > 000 "baiamare-negresti":   policy:
> 	>       > RSASIG+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW; prio: 24,24;
> 	> interface: eth0;
> 	>       > 000 "baiamare-negresti":   newest ISAKMP SA: #3;
> 	> newest IPsec SA: #4;
> 	>       > 000 "baiamare-negresti":   IKE algorithm newest:
> 	>       > AES_CBC_128-SHA1-MODP2048
> 	>       > 000
> 	>       > 000 #4: "baiamare-negresti":500 
> STATE_QUICK_R2 (IPsec SA
> 	>       > established); EVENT_SA_REPLACE in 28205s; 
> newest IPSEC;
> 	>       > eroute owner; isakmp#3; idle; import:not set
> 	>       > 000 #4: "baiamare-negresti" esp.572de5cb at 82.79.83.nm
> 	>       > esp.f718f73e at 82.79.77.xy tun.1004 at 82.79.83.nm
> 	>       > tun.1003 at 82.79.77.xy ref=13 refhim=9
> 	>       > 000 #3: "baiamare-negresti":500 STATE_MAIN_R3 
> (sent MR3,
> 	>       > ISAKMP SA established); EVENT_SA_REPLACE in 
> 3005s; newest
> 	>       > ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; 
> import:not set
> 	>       > 000 #2: "baiamare-negresti":500 
> STATE_QUICK_I2 (sent QI2,
> 	>       > IPsec SA established); EVENT_SA_REPLACE in 
> 27647s; isakmp#1;
> 	>       > idle; import:admin initiate
> 	>       > 000 #2: "baiamare-negresti" esp.f7140fdc at 82.79.83.nm
> 	>       > esp.f718f73d at 82.79.77.xy tun.1001 at 82.79.83.nm
> 	>       > tun.1002 at 82.79.77.xy ref=11 refhim=9
> 	>       > 000 #1: "baiamare-negresti":500 STATE_MAIN_I4 
> (ISAKMP SA
> 	>       > established); EVENT_SA_REPLACE in 2555s; 
> lastdpd=-1s(seq in:0
> 	>       > out:0); idle; import:admin initiate
> 	>       >
> 	>       >
> 	>       >
> 	>       > On Wed, Jan 7, 2009 at 9:13 PM, Peter McGill
> 	>       > <petermcgill at goco.net> wrote:
> 	>       >
> 	>       >
> 	>       >       This is not uncommon, -I doesn't always 
> work, try
> 	>       > adding the following to your conf.
> 	>       >              leftsourceip=192.168.10.254
> 	>       >              rightsourceip=192.168.23.1
> 	>       >       Also check that your firewall isn't blocking
> 	> tunnel traffic.
> 	>       >       You need to allow communication between 
> 192.168.10.0/24
> 	>       > and 192.168.23.0/24 on ipsec0.
> 	>       >       Not sure what that Delete SA message is 
> about, what
> 	>       > ipsec device is on the other end of tunnel?
> 	>       >
> 	>       >       Peter McGill
> 	>       >       IT Systems Analyst
> 	>       >       Gra Ham Energy Limited
> 	>       >
> 	>       >
> 	>       >       > -----Original Message-----
> 	>       >       > From: users-bounces at openswan.org
> 	>       >       > [mailto:users-bounces at openswan.org] 
> On Behalf Of TC
> 	>       >       > Sent: January 7, 2009 12:20 PM
> 	>       >       > To: users at openswan.org
> 	>       >       > Subject: [Openswan Users] net-to-net 
> - openswan
> 	>       > 2.6.18 on k.2.6.24.7
> 	>       >       >
> 	>       >       > Hi all,
> 	>       >       >
> 	>       >       > I have installed kernel 2.6.24.7 + 
> klips patch +
> 	>       > openswan 2.6.18
> 	>       >       > I have made a net-to-net config. The 
> connection start
> 	>       > but I cannot
> 	>       >       > ping the end of the tunnel.
> 	>       >       >
> 	>       >       > ping 192.168.23.1 -I eth1 not working
> 	>       >       > ping 192.168.10.254 -I eth1 not working
> 	>       >       >
> 	>       >       > ping 192.168.10.254 -I eth1
> 	>       >       > PING 192.168.10.254 (192.168.10.254) from
> 	> 192.168.23.1 eth1:
> 	>       >       > 56(84) bytes of data.
> 	>       >       > From 192.168.23.1 icmp_seq=2 Destination Host
> 	> Unreachable
> 	>       >       > >From 192.168.23.1 icmp_seq=3 Destination
> 	> Host Unreachable
> 	>       >       > From 192.168.23.1 icmp_seq=4 Destination Host
> 	> Unreachable
> 	>       >       >
> 	>       >       >
> 	>       >       > A config(and same config to B but different
> 	> ipsec.secrets)
> 	>       >       >
> 	>       >       > version 2.0
> 	>       >       >
> 	>       >       > config setup
> 	>       >       >     interfaces="ipsec0=eth0"
> 	>       >       >     protostack=klips
> 	>       >       >
> 	>       >       > 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
> 	>       >       >
> 	>       >       > conn A-B
> 	>       >       >     left=WAN_IP_FROM_A
> 	>       >       >     leftnexthop=GATEWAY_FROM_A
> 	>       >       >     leftsubnet=192.168.10.0/24
> 	>       >       >     right=WAN_IP_FROM_B
> 	>       >       >     rightnexthop=GATEWAY_FROM_B
> 	>       >       >     rightsubnet=192.168.23.0/24
> 	>       >       >     type=tunnel
> 	>       >       >     auth=esp
> 	>       >       >     leftrsasigkey=0sAQOY...
> 	>       >       >     rightrsasigkey=0sAQNqB...
> 	>       >       >     auto=start
> 	>       >       >
> 	>       >       > in /var/log/syslog I have:
> 	>       >       >    Jan  7 19:13:12 vpn ipsec_setup: 
> Starting Openswan
> 	>       > IPsec 2.6.18...
> 	>       >       >    Jan  7 19:13:12 vpn ipsec__plutorun: 002
> 	> added connection
> 	>       >       > description "A-B"
> 	>       >       >    Jan  7 19:13:12 vpn 
> ipsec__plutorun: 104 "A-B" #1:
> 	>       >       > STATE_MAIN_I1: initiate
> 	>       >       >
> 	>       >       > in /var/log.secure I have:
> 	>       >       > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1:
> 	> STATE_MAIN_I2:
> 	>       >       > sent MI2, expecting MR2
> 	>       >       > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1:
> 	> transition from
> 	>       >       > state STATE_MAIN_I2 to state STATE_MAIN_I3
> 	>       >       > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1:
> 	> STATE_MAIN_I3:
> 	>       >       > sent MI3, expecting MR3
> 	>       >       > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1:
> 	> received Vendor
> 	>       >       > ID payload [CAN-IKEv2]
> 	>       >       > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1:
> 	> Main mode peer ID
> 	>       >       > is ID_IPV4_ADDR: '82.79.83.23'
> 	>       >       > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1:
> 	> transition from
> 	>       >       > state STATE_MAIN_I3 to state STATE_MAIN_I4
> 	>       >       > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #1:
> 	> STATE_MAIN_I4:
> 	>       >       > ISAKMP SA established {auth=OAKLEY_RSA_SIG
> 	> cipher=aes_128
> 	>       >       > prf=oakley_sha group=modp2048}
> 	>       >       > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #2:
> 	> initiating Quick
> 	>       >       > Mode RSASIG+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW
> 	> {using isakmp#1
> 	>       >       > msgid:beed36ed proposal=defaults
> 	>       > pfsgroup=OAKLEY_GROUP_MODP2048}
> 	>       >       > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #2:
> 	> transition from
> 	>       >       > state STATE_QUICK_I1 to state STATE_QUICK_I2
> 	>       >       > Jan  7 19:15:57 vpn pluto[10094]: "A-B" #2:
> 	> STATE_QUICK_I2:
> 	>       >       > sent QI2, IPsec SA established tunnel mode
> 	> {ESP=>0x45d84918
> 	>       >       > <0x892b2f5a xfrm=AES_128-HMAC_SHA1 NATOA=none
> 	>       > NATD=none DPD=none}
> 	>       >       > Jan  7 19:16:16 vpn pluto[10094]: "A-B" #1:
> 	> ignoring Delete
> 	>       >       > SA payload: PROTO_IPSEC_ESP 
> SA(0x45d84917) not found
> 	>       > (maybe expired)
> 	>       >       > Jan  7 19:16:16 vpn pluto[10094]: "A-B" #1:
> 	> received and
> 	>       >       > ignored informational message
> 	>       >       >
> 	>       >       >
> 	>       >       > Thx for Help.
> 	>       >       >
> 	>       >       > --
> 	>       >       > TC
> 	>       >       >
> 	>       >       >
> 	>       >
> 	>       >
> 	>       >
> 	>       >
> 	>       >
> 	>       >
> 	>       > --
> 	>       > --
> 	>       > TC
> 	>       >
> 	>       >
> 	>
> 	>
> 	>
> 	>
> 	>
> 	>
> 	> --
> 	> --
> 	> TC
> 	>
> 	>
> 	
> 	
> 
> 
> 
> 
> -- 
> --
> TC
> 
> 


From hutx at yahoo.com  Thu Jan  8 12:29:07 2009
From: hutx at yahoo.com (hutx)
Date: Thu, 8 Jan 2009 09:29:07 -0800 (PST)
Subject: [Openswan Users] openswan-nokia: gateway not responding
Message-ID: <393750.78898.qm@web65404.mail.ac4.yahoo.com>

I met a problem when I tried to build a VPN between
Nokia client and Openswan. This problem has been
posted in Openswan lists by Fredo Sartori last May.
But no body replied it. I post it again. Please help
us.

//////////////////////////////////////////////
ello,

am trying to set up a vpn gateway for Nokia (S60)
clients. Using XAUTH I am able to authenticate and an
ISAKMP SA is established.
After that one more UDP packet is sent to the phone.
Some seconds later the phone throws the error message
"Web: gateway
does not respond" and the connection dies ...

Using an openswan client, a VPN tunnel can be
established.

Logfile of openswan

May 23 11:55:07 spd-1145h ipsec_setup: Stopping
Openswan IPsec...
May 23 11:55:07 spd-1145h kernel: [347455.206150]
klips_info:ipsec_init: KLIPS startup, Openswan KLIPS
IPsec stack version: 2.4.12
May 23 11:55:07 spd-1145h kernel: [347455.206213] NET:
Registered protocol family 15
May 23 11:55:07 spd-1145h kernel: [347455.206652]
klips_info:ipsec_alg_init: KLIPS alg v=0.8.1-0
(EALG_MAX=255, AALG_MAX=251)
May 23 11:55:07 spd-1145h kernel: [347455.206658]
klips_info:ipsec_alg_init: calling
ipsec_alg_static_init()
May 23 11:55:07 spd-1145h kernel: [347455.206667]
ipsec_aes_init(alg_type=15 alg_id=12 name=aes): ret=0
May 23 11:55:07 spd-1145h kernel: [347455.206672]
klips_debug: experimental ipsec_alg_AES_MAC not
registered [Ok] (auth_id=0)
May 23 11:55:07 spd-1145h kernel: [347455.206679]
ipsec_3des_init(alg_type=15 alg_id=3 name=3des): ret=0
May 23 11:55:07 spd-1145h ipsec_setup: KLIPS debug
`none'
May 23 11:55:07 spd-1145h kernel: [347455.363691]
May 23 11:55:07 spd-1145h ipsec_setup: KLIPS ipsec0 on
eth1 172.16.81.120/255.255.252.0 broadcast
172.16.83.255
May 23 11:55:07 spd-1145h ipsec__plutorun: Starting
Pluto subsystem...
May 23 11:55:07 spd-1145h ipsec__plutorun: Unknown
default RSA hostkey scheme, not generating a default
hostkey
May 23 11:55:07 spd-1145h pluto[4704]: Starting Pluto
(Openswan Version 2.4.12 PLUTO_SENDS_VENDORID
PLUTO_USES_KEYRR; Vendor ID OEKBzdY{wM]@)
May 23 11:55:07 spd-1145h pluto[4704]: Setting
NAT-Traversal port-4500 floating to on
May 23 11:55:07 spd-1145h pluto[4704]:    port
floating activation criteria nat_t=1/port_fload=1
May 23 11:55:07 spd-1145h pluto[4704]:   including
NAT-Traversal patch (Version 0.6c)
May 23 11:55:07 spd-1145h pluto[4704]:
ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok
(ret=0)
May 23 11:55:07 spd-1145h pluto[4704]: no helpers will
be started, all cryptographic operations will be done
inline
May 23 11:55:07 spd-1145h pluto[4704]: Using KLIPS
IPsec interface code on 2.6.23.16-2.6.23.16-with-natt
May 23 11:55:07 spd-1145h pluto[4704]: Changing to
directory '/etc/ipsec.d/cacerts'
May 23 11:55:07 spd-1145h pluto[4704]:   loaded CA
cert file 'ca.pem' (2378 bytes)
May 23 11:55:07 spd-1145h pluto[4704]: Changing to
directory '/etc/ipsec.d/aacerts'
May 23 11:55:07 spd-1145h pluto[4704]: Changing to
directory '/etc/ipsec.d/ocspcerts'
May 23 11:55:07 spd-1145h pluto[4704]: Changing to
directory '/etc/ipsec.d/crls'
May 23 11:55:07 spd-1145h pluto[4704]:   Warning:
empty directory
May 23 11:55:07 spd-1145h ipsec_setup: ...Openswan
IPsec started
May 23 11:55:07 spd-1145h ipsec_setup: Starting
Openswan IPsec 2.4.12...
May 23 11:55:07 spd-1145h pluto[4704]: loading secrets
from "/etc/ipsec.secrets"
May 23 11:55:07 spd-1145h pluto[4704]: added
connection description "fredos-phone"
May 23 11:55:07 spd-1145h pluto[4704]: added
connection description "psk-client"
May 23 11:55:07 spd-1145h pluto[4704]: listening for
IKE messages
May 23 11:55:07 spd-1145h pluto[4704]: adding
interface ipsec0/eth1 172.16.81.120:500
May 23 11:55:07 spd-1145h pluto[4704]: adding
interface ipsec0/eth1 172.16.81.120:4500
May 23 11:55:07 spd-1145h pluto[4704]: forgetting
secrets
May 23 11:55:07 spd-1145h pluto[4704]: loading secrets
from "/etc/ipsec.secrets"
....
May 23 11:55:29 spd-1145h pluto[4704]: packet from
77.24.7.233:500: received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-03] method set to=108
May 23 11:55:29 spd-1145h pluto[4704]: packet from
77.24.7.233:500: received Vendor ID payload [XAUTH]
May 23 11:55:29 spd-1145h pluto[4704]: packet from
77.24.7.233:500: received Vendor ID payload
[Cisco-Unity]
May 23 11:55:29 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: responding to Main
Mode from unknown peer 77.24.7.233
May 23 11:55:29 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: transition from
state STATE_MAIN_R0 to state STATE_MAIN_R1
May 23 11:55:29 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: STATE_MAIN_R1: sent
MR1, expecting MI2
May 23 11:55:31 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: ignoring unknown
Vendor ID payload [10f3a692cc78612f7e5b7ededd1d2391]
May 23 11:55:31 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: NAT-Traversal:
Result using draft-ietf-ipsec-nat-t-ike-02/03: i am
NATed
May 23 11:55:31 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: transition from
state STATE_MAIN_R1 to state STATE_MAIN_R2
May 23 11:55:31 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: STATE_MAIN_R2: sent
MR2, expecting MI3
May 23 11:55:33 spd-1145h pluto[4704]: | protocol/port
in Phase 1 ID Payload is 17/0. accepted with
port_floating NAT-T
May 23 11:55:33 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: Main mode peer ID is
ID_KEY_ID: '@#0x4d6f62696c6547726f7570'
May 23 11:55:33 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: I did not send a
certificate because I do not have one.
May 23 11:55:33 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: transition from
state STATE_MAIN_R2 to state STATE_MAIN_R3
May 23 11:55:33 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: STATE_MAIN_R3: sent
MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY
cipher=aes_256 prf=oakley_sha group=modp1536}
May 23 11:55:33 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: XAUTH: Sending XAUTH
Login/Password Request
May 23 11:55:33 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: XAUTH: Sending
Username/Password request (XAUTH_R0)
May 23 11:55:53 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: XAUTH:  Unsupported
XAUTH parameter XAUTH-TYPE received.
May 23 11:55:53 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: XAUTH: User fredo:
Attempting to login
May 23 11:55:53 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: XAUTH: md5
authentication being called to authenticate user fredo
May 23 11:55:53 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: XAUTH: password file
(/etc/ipsec.d/passwd) open.
May 23 11:55:53 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: XAUTH: checking
user(fredo:fredos-phone)
May 23 11:55:53 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: XAUTH: User fredo:
Authentication Successful
May 23 11:55:57 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: XAUTH:
xauth_inR1(STF_OK)
May 23 11:55:57 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: transition from
state STATE_XAUTH_R1 to state STATE_MAIN_R3
May 23 11:55:57 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: STATE_MAIN_R3: sent
MR3, ISAKMP SA established
May 23 11:55:57 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: modecfg_inR0(STF_OK)
May 23 11:55:57 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: transition from
state STATE_MODE_CFG_R0 to state STATE_MODE_CFG_R1
May 23 11:55:57 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: STATE_MODE_CFG_R1:
ModeCfg Set sent, expecting Ack
May 23 11:56:23 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233 #1: received Delete SA
payload: deleting ISAKMP State #1
May 23 11:56:23 spd-1145h pluto[4704]:
"fredos-phone"[1] 77.24.7.233: deleting connection
"fredos-phone" instance with peer 77.24.7.233
{isakmp=#0/ipsec=#0}
May 23 11:56:23 spd-1145h pluto[4704]: packet from
77.24.7.233:4500: received and ignored informational
message


When running openswan with plutodebug="control" I find
the following messages after ISAKMP SA is established:

May 23 12:26:55 spd-1145h pluto[5017]:
"fredos-phone"[1] 77.25.6.104 #1: STATE_MAIN_R3: sent
MR3, ISAKMP SA established
May 23 12:26:55 spd-1145h pluto[5017]: | modecfg pull:
quirk-poll policy:pull not-client
May 23 12:26:55 spd-1145h pluto[5017]: | phase 1 is
done, looking for phase 1 to unpend
May 23 12:26:55 spd-1145h pluto[5017]: | next event
EVENT_NAT_T_KEEPALIVE in 5 seconds
May 23 12:26:55 spd-1145h pluto[5017]: |
May 23 12:26:55 spd-1145h pluto[5017]: | *received 76
bytes from 77.25.6.104:4500 on eth1 (port=4500)
May 23 12:26:55 spd-1145h pluto[5017]: |  processing
packet with exchange type=ISAKMP_XCHG_MODE_CFG (6)
May 23 12:26:55 spd-1145h pluto[5017]: | ICOOKIE:  a0
6d 05 c6  1d 83 85 92
May 23 12:26:55 spd-1145h pluto[5017]: | RCOOKIE:  6d
10 9b 14  d9 42 f7 84
May 23 12:26:55 spd-1145h pluto[5017]: | peer:  4d 19
06 68
May 23 12:26:55 spd-1145h pluto[5017]: | state hash
entry 11
May 23 12:26:55 spd-1145h pluto[5017]: | peer and
cookies match on #1, provided msgid 6b08d850 vs
00000000/00000000
May 23 12:26:55 spd-1145h pluto[5017]: | p15 state
object not found
May 23 12:26:55 spd-1145h pluto[5017]: | ICOOKIE:  a0
6d 05 c6  1d 83 85 92
May 23 12:26:55 spd-1145h pluto[5017]: | RCOOKIE:  6d
10 9b 14  d9 42 f7 84
May 23 12:26:55 spd-1145h pluto[5017]: | peer:  4d 19
06 68
May 23 12:26:55 spd-1145h pluto[5017]: | state hash
entry 11
May 23 12:26:55 spd-1145h pluto[5017]: | peer and
cookies match on #1, provided msgid 00000000 vs
00000000
May 23 12:26:55 spd-1145h pluto[5017]: | state object
#1 found, in STATE_MAIN_R3
May 23 12:26:55 spd-1145h pluto[5017]: | processing
connection fredos-phone[1] 77.25.6.104
May 23 12:26:55 spd-1145h pluto[5017]:
"fredos-phone"[1] 77.25.6.104 #1: modecfg_inR0(STF_OK)
May 23 12:26:55 spd-1145h pluto[5017]: | complete
state transition with STF_OK
May 23 12:26:55 spd-1145h pluto[5017]:
"fredos-phone"[1] 77.25.6.104 #1: transition from
state STATE_MODE_CFG_R0 to state STATE_MODE_CFG_R1
May 23 12:26:55 spd-1145h pluto[5017]: | sending reply
packet to 77.25.6.104:4500 (from port=4500)
May 23 12:26:55 spd-1145h pluto[5017]: | sending 76
bytes for STATE_MODE_CFG_R0 through eth1:4500 to
77.25.6.104:4500:
May 23 12:26:55 spd-1145h pluto[5017]: | inserting
event EVENT_SA_REPLACE, timeout in 28530 seconds for
#1
May 23 12:26:55 spd-1145h pluto[5017]:
"fredos-phone"[1] 77.25.6.104 #1: STATE_MODE_CFG_R1:
ModeCfg Set sent, expecting Ack
May 23 12:26:55 spd-1145h pluto[5017]: | modecfg pull:
quirk-poll policy:pull not-client
May 23 12:26:55 spd-1145h pluto[5017]: | phase 1 is
done, looking for phase 1 to unpend
May 23 12:26:55 spd-1145h pluto[5017]: | next event
EVENT_NAT_T_KEEPALIVE in 5 seconds
May 23 12:27:00 spd-1145h pluto[5017]: |
May 23 12:27:00 spd-1145h pluto[5017]: | *time to
handle event
May 23 12:27:00 spd-1145h pluto[5017]: | handling
event EVENT_NAT_T_KEEPALIVE
May 23 12:27:00 spd-1145h pluto[5017]: | event after
this is EVENT_SHUNT_SCAN in 73 seconds
May 23 12:27:00 spd-1145h pluto[5017]: | processing
connection fredos-phone[1] 77.25.6.104
May 23 12:27:00 spd-1145h pluto[5017]: | next event
EVENT_SHUNT_SCAN in 73 seconds


This is what tcpdump sees:

11:54:17.502672 IP
ip-77-24-228-150.web.vodafone.de.isakmp >
172.16.81.120.isakmp: isakmp: phase 1 I ident
11:54:27.517566 IP
ip-77-24-228-150.web.vodafone.de.isakmp >
172.16.81.120.isakmp: isakmp: phase 1 I ident
11:54:32.476650 IP
ip-77-24-228-150.web.vodafone.de.isakmp >
172.16.81.120.isakmp: isakmp: phase 1 I ident
11:54:37.496655 IP
ip-77-24-228-150.web.vodafone.de.isakmp >
172.16.81.120.isakmp: isakmp: phase 1 I ident
11:54:42.537554 IP
ip-77-24-228-150.web.vodafone.de.isakmp >
172.16.81.120.isakmp: isakmp: phase 1 I ident
11:54:47.579248 IP
ip-77-24-228-150.web.vodafone.de.isakmp >
172.16.81.120.isakmp: isakmp: phase 1 I ident
11:54:52.759233 IP
ip-77-24-228-150.web.vodafone.de.isakmp >
172.16.81.120.isakmp: isakmp: phase 1 I ident
11:54:57.636374 IP
ip-77-24-228-150.web.vodafone.de.isakmp >
172.16.81.120.isakmp: isakmp: phase 1 I ident
11:55:02.695506 IP
ip-77-24-228-150.web.vodafone.de.isakmp >
172.16.81.120.isakmp: isakmp: phase 1 I ident
11:55:07.636073 IP
ip-77-24-228-150.web.vodafone.de.isakmp >
172.16.81.120.isakmp: isakmp: phase 1 I inf
11:55:07.636147 IP 172.16.81.120 >
ip-77-24-228-150.web.vodafone.de: ICMP 172.16.81.120
udp port isakmp unreachable, length 92
11:55:12.627445 arp who-has 172.16.81.2 tell
172.16.81.120
11:55:12.627534 arp reply 172.16.81.2 is-at
00:50:c2:2d:ac:08 (oui Unknown)
11:55:29.997976 IP
ip-77-24-7-233.web.vodafone.de.isakmp >
172.16.81.120.isakmp: isakmp: phase 1 I ident
11:55:29.998434 IP 172.16.81.120.isakmp >
ip-77-24-7-233.web.vodafone.de.isakmp: isakmp: phase 1
R ident
11:55:31.557871 IP
ip-77-24-7-233.web.vodafone.de.isakmp >
172.16.81.120.isakmp: isakmp: phase 1 I ident
11:55:31.564328 IP 172.16.81.120.isakmp >
ip-77-24-7-233.web.vodafone.de.isakmp: isakmp: phase 1
R ident
11:55:33.035821 IP ip-77-24-7-233.web.vodafone.de.4500
> 172.16.81.120.4500: NONESP-encap: isakmp: phase 1 I
ident[E]
11:55:33.036127 IP 172.16.81.120.4500 >
ip-77-24-7-233.web.vodafone.de.4500: NONESP-encap:
isakmp: phase 1 R ident[E]
11:55:33.036381 IP 172.16.81.120.4500 >
ip-77-24-7-233.web.vodafone.de.4500: NONESP-encap:
isakmp: phase 2/others R #6[E]
11:55:34.997449 arp who-has 172.16.81.2 tell
172.16.81.120
11:55:34.997540 arp reply 172.16.81.2 is-at
00:50:c2:2d:ac:08 (oui Unknown)
11:55:53.892679 IP ip-77-24-7-233.web.vodafone.de.4500
> 172.16.81.120.4500: NONESP-encap: isakmp: phase
2/others I #6[E]
11:55:53.893229 IP 172.16.81.120.4500 >
ip-77-24-7-233.web.vodafone.de.4500: NONESP-encap:
isakmp: phase 2/others R #6[E]
11:55:57.615469 IP ip-77-24-7-233.web.vodafone.de.4500
> 172.16.81.120.4500: NONESP-encap: isakmp: phase
2/others I #6[E]
11:55:57.692826 IP ip-77-24-7-233.web.vodafone.de.4500
> 172.16.81.120.4500: NONESP-encap: isakmp: phase
2/others I #6[E]
11:55:57.693031 IP 172.16.81.120.4500 >
ip-77-24-7-233.web.vodafone.de.4500: NONESP-encap:
isakmp: phase 2/others R #6[E]
11:55:58.887444 arp who-has 172.16.81.2 tell
172.16.81.120
11:55:58.887535 arp reply 172.16.81.2 is-at
00:50:c2:2d:ac:08 (oui Unknown)
11:56:23.309781 IP ip-77-24-7-233.web.vodafone.de.4500
> 172.16.81.120.4500: NONESP-encap: isakmp: phase
2/others I inf[E]
11:56:23.310051 IP 172.16.81.120.4500 >
ip-77-24-7-233.web.vodafone.de.4500: NONESP-encap:
isakmp: phase 2/others R inf[E]




Here are the details of my setup:

Topology:

-------------
|  Client   |
-------------
     |
     |
-------------  1.2.3.4
| NAT dev.  |
-------------  172.16.81.2
     |
     |
-------------  172.16.81.120
|  VPN gw   |
-------------  172.26.100.101
     |


Setup of gateway:

Ubuntu 8.04
Kernel:     2.6.23.16 from kernel.org
NATT patch: openswan-2.4.x.kernel-2.6.23-natt.patch
(from openswan.org)
openswan:   2.4.12


Config openswan gateway:

# /etc/ipsec.conf - Openswan IPsec configuration file
version 2.0

# basic configuration
config setup
        #
        plutodebug="none"
        klipsdebug="none"
        #
        fragicmp=no
        #
        # NAT-TRAVERSAL support
        nat_traversal=yes
        forwardcontrol=yes

virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:!172.16.0.0/12
        #
        nhelpers=0
        interfaces="ipsec0=eth1"

# Connections start here

conn fredos-phone
        # use xauth
        leftxauthserver=yes
        rightxauthclient=yes
        # modecfg setting
        leftmodecfgserver=yes
        rightmodecfgclient=yes
        modecfgpull=yes
        #
        [EMAIL PROTECTED]
        also=psk-client

conn psk-client
        # Key exchange
        ike=aes256-sha1-modp1536
        # Data exchange
        esp=aes256-sha1
        # Authentication method PSK
        authby=secret
        keyingtries=3
        pfs=no
        rekey=no
        #
        leftid=1.2.3.4
        left=172.16.81.120
        leftsubnet=0.0.0.0/0
        #
        right=%any
        rightsubnet=vhost:%no,%priv
        auto=start
#


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


Config of phone

a vpn.pkg

;
; VPN Policy Fraktion mit PSK
;

; LANGUAGES
; - None (English only by default)

; INSTALLATION HEADER
; - Only one component name is needed to support
English only
; - UID is the UID of the VPN Policy Installer
application
#{"VPN-Policy Fraktion"},(0x1000597E), 1, 0, 0,
TYPE=SA

;Localised Vendor name
%{"pip-EN"}

;Unique Vendor name
:"pip"

; LIST OF FILES

; Policy file
"vpn.pol"-"C:\System\Data\Security\Install\vpn.pol"

; Policy-information file
; - NOTE: The policy-information file MUST be the last
file in this list!
; - FM (FILEMIME) passes the file to the respective
MIME handler
; (in this case, the VPN Policy Installer
application).
"vpn.pin"-"C:\System\Data\Security\Install\vpn.pin",
 FM, "application/x-ipsec-policy-info"

; REQUIRED FILES
;  - The VPN Policy Installer application
(0x1000597E), 1, 0, 0, {"VPN Policy Installer"}
;  - S60 3rd Edition ID
[0x101F7961], 0, 0, 0, {"S60ProductID"}


b. vpn.pin

[POLICYNAME]
VPN 1.0,7
[POLICYDESCRIPTION]
VPN SPD-Fraktion USE_MOD_CFG FALSE
[POLICYVERSION]
1.1.0
[ISSUERNAME]
Do not edit
[CONTACTINFO]
Do not edit


c. vpn.pol

SECURITY_FILE_VERSION: 3
[INFO]
VPN-Policy for Nokia Mobile VPN Client v3.0.
[POLICY]
sa ipsec_1 = {
esp
encrypt_alg 12
max_encrypt_bits 256
auth_alg 3
identity_remote 0.0.0.0/0
src_specific
hard_lifetime_bytes 0
hard_lifetime_addtime 3600
hard_lifetime_usetime 3600
soft_lifetime_bytes 0
soft_lifetime_addtime 3600
soft_lifetime_usetime 3600
}

remote 0.0.0.0 0.0.0.0 = { ipsec_1(1.2.3.4) }
inbound = { }
outbound = { }

[IKE]
ADDR: 1.2.3.4 255.255.255.255
MODE: Main
SEND_NOTIFICATION: TRUE
ID_TYPE: 11
FQDN: MobileGroup
GROUP_DESCRIPTION_II: MODP_1536
USE_COMMIT: FALSE
IPSEC_EXPIRE: FALSE
SEND_CERT: FALSE
INITIAL_CONTACT: FALSE
RESPONDER_LIFETIME: TRUE
REPLAY_STATUS: TRUE
USE_INTERNAL_ADDR: FALSE
USE_NAT_PROBE: FALSE
ESP_UDP_PORT: 0
NAT_KEEPALIVE: 60
USE_XAUTH: TRUE
USE_MODE_CFG: TRUE
REKEYING_THRESHOLD: 90
PROPOSALS: 1
ENC_ALG: AES256-CBC
AUTH_METHOD: PRE-SHARED
HASH_ALG: SHA1
GROUP_DESCRIPTION: MODP_1536
GROUP_TYPE: DEFAULT
LIFETIME_KBYTES: 0
LIFETIME_SECONDS: 28800
PRF: NONE
PRESHARED_KEYS:
FORMAT: STRING_FORMAT
KEY: 8 lt.spock



At this point I am rather clueless, so any help is
greatly appreciated

Fredo

///////////////////////////////////////////////


      

From tonisaco at gmail.com  Thu Jan  8 14:02:34 2009
From: tonisaco at gmail.com (TC)
Date: Thu, 8 Jan 2009 21:02:34 +0200
Subject: [Openswan Users] kernel-openswan - compatibility
Message-ID: <ebc7cfa10901081102i46807485we678dd383c46c8de@mail.gmail.com>

Hi list,

What is the last stable kernel that you used with openswan 2.6.18 or
openswan 2.6.19 ?


Thx

--
TC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090108/f28da3af/attachment.html 

From paul at xelerance.com  Fri Jan  9 09:53:51 2009
From: paul at xelerance.com (Paul Wouters)
Date: Fri, 9 Jan 2009 09:53:51 -0500 (EST)
Subject: [Openswan Users] Tunnel up but packets not forwarded to
 internal iface. Please help.
In-Reply-To: <20090106153315.GD5417@uglyrabbit.telecommedia.pl>
References: <20090106101347.GB3052@uglyrabbit.telecommedia.pl>
	<20090106153315.GD5417@uglyrabbit.telecommedia.pl>
Message-ID: <alpine.LFD.1.10.0901090953240.15656@newtla.xelerance.com>

On Tue, 6 Jan 2009, Piotr Isajew wrote:

> After digging through the archives I've finally found that this was a
> setkey related issue.

You should not need to use 'setkey' for ANYTHING when using openswan.

Paul

From paul at xelerance.com  Fri Jan  9 09:55:52 2009
From: paul at xelerance.com (Paul Wouters)
Date: Fri, 9 Jan 2009 09:55:52 -0500 (EST)
Subject: [Openswan Users] I can not make KLIPS install.
In-Reply-To: <E80B65F27529BB409F833498BB79F84E4913C3@r2d2.heartslc.com>
References: <E80B65F27529BB409F833498BB79F84E4913C3@r2d2.heartslc.com>
Message-ID: <alpine.LFD.1.10.0901090955010.15656@newtla.xelerance.com>

On Tue, 6 Jan 2009, Jonathan Larsen wrote:

> You may want to hit up the Fedora forums and ask what rpm you would need
> to install to have the complete source.  I don't use fedora, so I
> couldn't tell you.  Sorry.

you do not need the full source to build modules. And building with
KERNELSRC=/lib/modules/`uname -r`/build should work. Verify the build
symlink leads to some kernel headers.

I am not sure why there is a DocBook error. I haven't seen that happen.

Paul

> Jonathan
> Systems Administrator
> 801.270.4108
> IT at heartslc.com
>
>
> -----Original Message-----
> From: hutx [mailto:hutx at yahoo.com]
> Sent: Tuesday, January 06, 2009 4:30 PM
> To: Jonathan Larsen
> Subject: Re: [Openswan Users] I can not make KLIPS install.
>
>
> Thank Jonathan for quick reply.
>
> Yes, I do have the dir
> /usr/src/kernels/2.6.18-1.2798.fc6-i686.
> But, I do not have the dir Documentation/DocBook. I do
> not know how to install it by make menucofig.
>
> As for KLIPS, I try to solve an error "has no Non-ESP
> marker". Somebody in the mailling list said he/she
> solved this problem by switching from NETKEY to KLIPS.
> So I want to try KLIPS.
>
>
>
> --- Jonathan Larsen <jon at heartslc.com> wrote:
>
>> Do you have your Kernel source installed?  Do you
>> have a dir called
>> /usr/src/kernels/2.6.18-1.2798.fc6-i686 ?
>> Are you use you need KLIPS?
>>
>> Also, KERNELSRC should = your kernel source dir. IE,
>> /usr/src/linux-kernel-2.6.xxxxx
>>
>> Jonathan
>> Systems Administrator
>> 801.270.4108
>> IT at heartslc.com
>>
>>
>> -----Original Message-----
>> From: users-bounces at openswan.org
>> [mailto:users-bounces at openswan.org] On
>> Behalf Of hutx
>> Sent: Tuesday, January 06, 2009 4:07 PM
>> To: users at openswan.org
>> Subject: [Openswan Users] I can not make KLIPS
>> install.
>>
>> I want to build KLIPS kernel module on 2.6.
>> My linux is Fedoral core 6.
>> Openswan is openswan-2.6.20rc1
>>
>> When I run make KERNELSRC=/lib/modules/`uname
>> -r`/build module minstall, I got an error as below:
>> make[3]:
>>
> /usr/src/kernels/2.6.18-1.2798.fc6-i686/Documentation/DocBook/Makefile:
>> No such file or directory
>> make[3]: *** No rule to make target
>>
> `/usr/src/kernels/2.6.18-1.2798.fc6-i686/Documentation/DocBook/Makefile'
>> .
>>  Stop.
>> make[2]: *** [help] Error 2
>> + mkdir -p
>> /lib/modules/2.6.18-1.2798.fc6/kernel/net/ipsec
>> + cp /tmp/openswan-2.6.20rc1/modobj26/ipsec.ko
>> /lib/modules/2.6.18-1.2798.fc6/kernel/net/ipsec
>> + '[' -f /sbin/depmod ']'
>> + depmod -a
>> + '[' -n net/ipsec ']'
>> + mkdir -p
>> /lib/modules/2.6.18-1.2798.fc6/kernel/net/ipsec
>> + '[' -f
>> /lib/modules/2.6.18-1.2798.fc6/kernel/ipsec.ko -a -f
>>
> /lib/modules/2.6.18-1.2798.fc6/kernel/net/ipsec/ipsec.ko
>> ']'
>> + set -x
>> make[1]: Leaving directory `/tmp/openswan-2.6.20rc1'
>>
>> I check the directory
>>
> /usr/src/kernels/2.6.18-1.2798.fc6-i686/Documentation/DocBook/Makefile.
>> It does not exist. But I do not know how to install
>> this direcotory in Kernels.
>>
>> Please help me. Thanks in advance.
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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=283155
>>
>> _______________________________________________
>> 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=283155
>>
>
>
>
>
>
> _______________________________________________
> 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=283155
>

From paul at xelerance.com  Fri Jan  9 10:02:31 2009
From: paul at xelerance.com (Paul Wouters)
Date: Fri, 9 Jan 2009 10:02:31 -0500 (EST)
Subject: [Openswan Users] upgrade version openswan
In-Reply-To: <515251629957C542816307570516B86D630920@BSRSPCLE001.boursorama.fr>
References: <515251629957C542816307570516B86D630920@BSRSPCLE001.boursorama.fr>
Message-ID: <alpine.LFD.1.10.0901091001200.15656@newtla.xelerance.com>

On Thu, 8 Jan 2009, Alfonso Viso wrote:

> we have configured Openswan U2.4.13 in a Fedora Cora 4 server Kernel 2.6.17 and now we want to upgrade the version to
> 2.6.18 , my question is if this version is compatible with fedora 4 or we have to upgrade the version of server.

It's your choice. If you had used KLIPS, you should compile the latest klips on the latest FC4 kernel.
If using netkey, then you should not need to recompile anything (except openswan userland)

Paul

From paul at xelerance.com  Fri Jan  9 10:07:24 2009
From: paul at xelerance.com (Paul Wouters)
Date: Fri, 9 Jan 2009 10:07:24 -0500 (EST)
Subject: [Openswan Users] openswan-nokia: gateway not responding
In-Reply-To: <393750.78898.qm@web65404.mail.ac4.yahoo.com>
References: <393750.78898.qm@web65404.mail.ac4.yahoo.com>
Message-ID: <alpine.LFD.1.10.0901091005040.15656@newtla.xelerance.com>

On Thu, 8 Jan 2009, hutx wrote:

> "fredos-phone"[1] 77.24.7.233 #1: Main mode peer ID is
> ID_KEY_ID: '@#0x4d6f62696c6547726f7570'
> May 23 11:55:33 spd-1145h pluto[4704]:
> "fredos-phone"[1] 77.24.7.233 #1: I did not send a
> certificate because I do not have one.
> May 23 11:55:33 spd-1145h pluto[4704]:
> "fredos-phone"[1] 77.24.7.233 #1: transition from
> state STATE_MAIN_R2 to state STATE_MAIN_R3
> May 23 11:55:33 spd-1145h pluto[4704]:
> "fredos-phone"[1] 77.24.7.233 #1: STATE_MAIN_R3: sent
> MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY
> cipher=aes_256 prf=oakley_sha group=modp1536}

phase 1 is up.

> May 23 11:55:33 spd-1145h pluto[4704]:
> "fredos-phone"[1] 77.24.7.233 #1: XAUTH: Sending XAUTH
> Login/Password Request
> May 23 11:55:33 spd-1145h pluto[4704]:
> "fredos-phone"[1] 77.24.7.233 #1: XAUTH: Sending
> Username/Password request (XAUTH_R0)
> May 23 11:55:53 spd-1145h pluto[4704]:
> "fredos-phone"[1] 77.24.7.233 #1: XAUTH:  Unsupported
> XAUTH parameter XAUTH-TYPE received.
> May 23 11:55:53 spd-1145h pluto[4704]:
> "fredos-phone"[1] 77.24.7.233 #1: XAUTH: User fredo:
> Attempting to login
> May 23 11:55:53 spd-1145h pluto[4704]:
> "fredos-phone"[1] 77.24.7.233 #1: XAUTH: md5
> authentication being called to authenticate user fredo
> May 23 11:55:53 spd-1145h pluto[4704]:
> "fredos-phone"[1] 77.24.7.233 #1: XAUTH: password file
> (/etc/ipsec.d/passwd) open.
> May 23 11:55:53 spd-1145h pluto[4704]:
> "fredos-phone"[1] 77.24.7.233 #1: XAUTH: checking
> user(fredo:fredos-phone)
> May 23 11:55:53 spd-1145h pluto[4704]:
> "fredos-phone"[1] 77.24.7.233 #1: XAUTH: User fredo:
> Authentication Successful

XAUTH worked.

> May 23 11:55:57 spd-1145h pluto[4704]:
> "fredos-phone"[1] 77.24.7.233 #1: XAUTH:
> xauth_inR1(STF_OK)
> May 23 11:55:57 spd-1145h pluto[4704]:
> "fredos-phone"[1] 77.24.7.233 #1: transition from
> state STATE_XAUTH_R1 to state STATE_MAIN_R3
> May 23 11:55:57 spd-1145h pluto[4704]:
> "fredos-phone"[1] 77.24.7.233 #1: STATE_MAIN_R3: sent
> MR3, ISAKMP SA established
> May 23 11:55:57 spd-1145h pluto[4704]:
> "fredos-phone"[1] 77.24.7.233 #1: modecfg_inR0(STF_OK)
> May 23 11:55:57 spd-1145h pluto[4704]:
> "fredos-phone"[1] 77.24.7.233 #1: transition from
> state STATE_MODE_CFG_R0 to state STATE_MODE_CFG_R1
> May 23 11:55:57 spd-1145h pluto[4704]:
> "fredos-phone"[1] 77.24.7.233 #1: STATE_MODE_CFG_R1:
> ModeCfg Set sent, expecting Ack

Mode Config attempted, but

> May 23 11:56:23 spd-1145h pluto[4704]:
> "fredos-phone"[1] 77.24.7.233 #1: received Delete SA

The other end decided to hang up. This might be because of the
modeconfig paramters being wrong. Check the logs on the other end.

I am not sure how that translates into your vodaphone paramters.

Paul

From p.isajew at telecommedia.pl  Fri Jan  9 10:12:43 2009
From: p.isajew at telecommedia.pl (Piotr Isajew)
Date: Fri, 9 Jan 2009 16:12:43 +0100
Subject: [Openswan Users] Tunnel up but packets not forwarded
	to	internal iface. Please help.
In-Reply-To: <alpine.LFD.1.10.0901090953240.15656@newtla.xelerance.com>
References: <20090106101347.GB3052@uglyrabbit.telecommedia.pl>
	<20090106153315.GD5417@uglyrabbit.telecommedia.pl>
	<alpine.LFD.1.10.0901090953240.15656@newtla.xelerance.com>
Message-ID: <20090109151243.GA16228@mbp.local>

On Fri, Jan 09, 2009 at 09:53:51AM -0500, Paul Wouters wrote:
> You should not need to use 'setkey' for ANYTHING when using openswan.

Hi Paul,

that's strange. I noticed that setkey -DP originally showed that only
"out" policy was defined (as if openswan would define it implicitly):

192.168.3.0/24[any] 192.168.1.0/24[any] any
        out ipsec
        esp/tunnel/62.89.67.100-217.8.185.140/unique#16389
        created: Jan  9 14:41:40 2009  lastused: Jan  9 15:59:54 2009
        lifetime: 0(s) validtime: 0(s)
        spid=1865 seq=3 pid=17005
        refcnt=6


and the result was as I described previously, so outgoing packets from
my network were received at the destination host, reply received on my
external interface but not on internal. 

When I defined "in" policy by hand, setkey -DP showed all of "in",
"out", and "fwd" policies defined, and source host started to receive
response packets. Maybe it's something not directly related to
openswan, but rather NETKEY, or some oddities of the distro I use... I
don't know. For me the most important is that it works now.

Kind regards,

Piotr

From richard at mdr.co.uk  Fri Jan  9 16:08:00 2009
From: richard at mdr.co.uk (Richard de Rivaz)
Date: Fri, 9 Jan 2009 21:08:00 +0000
Subject: [Openswan Users] Openswan on Ubuntu 8.10
In-Reply-To: <4963b343.16048e0a.4e2b.44de@mx.google.com>
References: <4963b343.16048e0a.4e2b.44de@mx.google.com>
Message-ID: <1231535280183033500@mdr.co.uk>

An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.openswan.org/pipermail/users/attachments/20090109/50839999/attachment.pl 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090109/50839999/attachment.html 

From allen.miller at lymanrichey.com  Fri Jan  9 16:26:34 2009
From: allen.miller at lymanrichey.com (Allen Miller)
Date: Fri, 9 Jan 2009 15:26:34 -0600
Subject: [Openswan Users] OpenSwan on Fedora 9 Live
Message-ID: <2AC378B575F52F4BBCFA6085EFE854C0011901F970@LRCMAIL1.LRCORP.PRV>

Has anyone tried running OpenSwan on Fedora 9 Live? I have it installed with a persistent overlay, but when I try running ipsec, I get the following logged in messages:

Pluto is not running (no /var/run/pluto/pluto.ctl)

There is no pluto.ctl at this location. It does exist on a functioning machine.

Any ideas, anyone?

Regards,

Al Miller

From muir.james.a at gmail.com  Sat Jan 10 15:19:53 2009
From: muir.james.a at gmail.com (James Muir)
Date: Sat, 10 Jan 2009 15:19:53 -0500
Subject: [Openswan Users] mtu problems
In-Reply-To: <496111F9.6090906@gmail.com>
References: <49579F5A.80004@gmail.com> <495ECC00.9040306@gmail.com>
	<Pine.LNX.4.64.0901030857460.19783@newtla.xelerance.com>
	<4960279F.30607@gmail.com>
	<Pine.LNX.4.64.0901040150250.22158@newtla.xelerance.com>
	<496111F9.6090906@gmail.com>
Message-ID: <496902E9.1050406@gmail.com>

> However, this doesn't seem to solve my problem.  There is still a 
> threshold packet-size beyond which my ip packets do not make it into the 
> private network (e.g. "ping -s 1410" works but "ping -s 1411" does not).

Problem solved.

It turned out that my router was using an mtu of 1400 while eth0 was 
using an mtu of 1500.  Changing the router's mtu to 1500 fixed things. 
My guess is that openswan with netkey does not do path MTU discovery (or 
at least it does not do it correctly).

btw, I discovered that the command  ping -s SIZE  is not the most 
reliable way to determine if your tunnel has icmp fragmentation 
problems.  many machines will not reply to an icmp echo command that is 
fragmented (e.g. ping -c 2 -s 1600 yahoo.com  works, but ping -c 2 -s 
1600 google.com  does not.)

It is possible that  ifconfig eth0 mtu 1400  would also have fixed my 
problem -- if it did, I didn't notice because the machine I was trying 
to ping doesn't respond to fragmented icmp echo commands.

-James

From ml at as-support.com  Mon Jan 12 07:34:22 2009
From: ml at as-support.com (Markus Locher)
Date: Mon, 12 Jan 2009 13:34:22 +0100
Subject: [Openswan Users] IPSEC(epa_des_crypt): decrypted packet failed
 SA	identity
In-Reply-To: <494A1B74.4010808@as-support.com>
References: <494A1B74.4010808@as-support.com>
Message-ID: <496B38CE.1080307@as-support.com>

Thanx Paul.

Could it be that there  is still a configuration error on the client?
What can be the reason the CISCO couldn't get the right SA?
I see that there are no more error messages, because the client does
nothing wrong as far as I can see.

Any packet that is transported with ipsec to the CISCO fails with that
SA identity check. From traceroute, ping or some else.

lg markus

From ml at as-support.com  Mon Jan 12 09:05:15 2009
From: ml at as-support.com (Markus Locher)
Date: Mon, 12 Jan 2009 15:05:15 +0100
Subject: [Openswan Users] IPSEC(epa_des_crypt): decrypted packet failed
 SA	identity
In-Reply-To: <496B38CE.1080307@as-support.com>
References: <494A1B74.4010808@as-support.com> <496B38CE.1080307@as-support.com>
Message-ID: <496B4E1B.9000709@as-support.com>

Maybe something is wrong with the 3des loaded : see lines in "ipsec
whack --status" output:

+++++++++++++++++++++++++
000 "L2TPPSKCLIENT":   IKE algorithms wanted:
3DES_CBC(5)_000-SHA1(2)-MODP1024(2); flags=-strict
000 "L2TPPSKCLIENT":   IKE algorithms found: 
3DES_CBC(5)_192-SHA1(2)_160-2,
000 "L2TPPSKCLIENT":   IKE algorithm newest: 3DES_CBC_192-SHA1-MODP1024
000 "L2TPPSKCLIENT":   ESP algorithms wanted: 3DES(3)_000-SHA1(2);
flags=-strict
000 "L2TPPSKCLIENT":   ESP algorithms loaded: 3DES(3)_192-SHA1(2)_160
000 "L2TPPSKCLIENT":   ESP algorithm newest: 3DES_0-HMAC_SHA1;
pfsgroup=<N/A>
000 
++++++++++++++++++++++++++

------------------------------------------------
# ipsec whack --status
000 using kernel interface: netkey
000 interface lo/lo ::1
000 interface lo/lo 127.0.0.1
000 interface eth0/eth0 87.106.244.79
000 %myid = (none)
000 debug none
000 
000 virtual_private (%priv):
000 - allowed 1 subnet: 192.168.0.0/24
000 - disallowed 0 subnets:
000 WARNING: Either virtual_private= was not specified, or there was a
syntax
000          error in that line. 'left/rightsubnet=%priv' will not work!
000 
000 algorithm ESP encrypt: id=2, name=ESP_DES, ivlen=8, keysizemin=64,
keysizemax=64
000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, keysizemin=192,
keysizemax=192
000 algorithm ESP encrypt: id=7, name=ESP_BLOWFISH, ivlen=8,
keysizemin=40, keysizemax=448
000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=8, keysizemin=128,
keysizemax=256
000 algorithm ESP encrypt: id=13, name=ESP_AES_CTR, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=14, name=ESP_AES_CCM_A, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=15, name=ESP_AES_CCM_B, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=16, name=ESP_AES_CCM_C, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=18, name=ESP_AES_GCM_A, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=19, name=ESP_AES_GCM_B, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=20, name=ESP_AES_GCM_C, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=22, name=ESP_CAMELLIA, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5,
keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1,
keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=5, name=AUTH_ALGORITHM_HMAC_SHA2_256,
keysizemin=256, keysizemax=256
000 algorithm ESP auth attr: id=8, name=AUTH_ALGORITHM_HMAC_RIPEMD,
keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=9, name=AUTH_ALGORITHM_AES_CBC,
keysizemin=128, keysizemax=128
000 
000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=131
000 algorithm IKE encrypt: id=3, name=OAKLEY_BLOWFISH_CBC, blocksize=8,
keydeflen=128
000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8,
keydeflen=192
000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16,
keydeflen=128
000 algorithm IKE encrypt: id=65004, name=OAKLEY_SERPENT_CBC,
blocksize=16, keydeflen=128
000 algorithm IKE encrypt: id=65005, name=OAKLEY_TWOFISH_CBC,
blocksize=16, keydeflen=128
000 algorithm IKE encrypt: id=65289, name=OAKLEY_TWOFISH_CBC_SSH,
blocksize=16, keydeflen=128
000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
000 algorithm IKE hash: id=4, name=OAKLEY_SHA2_256, hashsize=32
000 algorithm IKE hash: id=6, name=OAKLEY_SHA2_512, hashsize=64
000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192
000 
000 stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,2,64}
trans={0,2,1440} attrs={0,2,960}
000 
000 "L2TPPSKCLIENT":
87.106.244.79<87.106.244.79>[%myid,+S=C]:17/1701...217.91.16.223<217.91.16.223>[+S=C]:17/1701;
erouted; eroute owner: #2
000 "L2TPPSKCLIENT":     myip=unset; hisip=unset;
000 "L2TPPSKCLIENT":   ike_life: 3600s; ipsec_life: 600s; rekey_margin:
540s; rekey_fuzz: 100%; keyingtries: 3
000 "L2TPPSKCLIENT":   policy: PSK+ENCRYPT+UP+IKEv2ALLOW+lKOD+rKOD;
prio: 32,32; interface: eth0;
000 "L2TPPSKCLIENT":   dpd: action:clear; delay:30; timeout:120;
000 "L2TPPSKCLIENT":   newest ISAKMP SA: #1; newest IPsec SA: #2;
000 "L2TPPSKCLIENT":   IKE algorithms wanted:
3DES_CBC(5)_000-SHA1(2)-MODP1024(2); flags=-strict
000 "L2TPPSKCLIENT":   IKE algorithms found: 
3DES_CBC(5)_192-SHA1(2)_160-2,
000 "L2TPPSKCLIENT":   IKE algorithm newest: 3DES_CBC_192-SHA1-MODP1024
000 "L2TPPSKCLIENT":   ESP algorithms wanted: 3DES(3)_000-SHA1(2);
flags=-strict
000 "L2TPPSKCLIENT":   ESP algorithms loaded: 3DES(3)_192-SHA1(2)_160
000 "L2TPPSKCLIENT":   ESP algorithm newest: 3DES_0-HMAC_SHA1;
pfsgroup=<N/A>
000 
000 #2: "L2TPPSKCLIENT":500 STATE_QUICK_I2 (sent QI2, IPsec SA
established); EVENT_SA_EXPIRE in 444s; newest IPSEC; eroute owner;
isakmp#1; idle; import:admin initiate
000 #2: "L2TPPSKCLIENT" esp.993286ec at 217.91.16.223
esp.b5f40357 at 87.106.244.79 ref=0 refhim=4294901761
000 #1: "L2TPPSKCLIENT":500 STATE_MAIN_I4 (ISAKMP SA established);
EVENT_SA_REPLACE in 2730s; newest ISAKMP; lastdpd=6s(seq in:10152
out:0); idle; import:admin initiate
000 
---------------------------------------

markus

From philipp.bundschuh at comit-gmbh.de  Mon Jan 12 14:34:28 2009
From: philipp.bundschuh at comit-gmbh.de (Bundschuh, Philipp)
Date: Mon, 12 Jan 2009 20:34:28 +0100
Subject: [Openswan Users] openswan & NPC Secure Client with dynamic IP
Message-ID: <36A230C77F55834D8B2215A258779E6C080348@COMIT-EXCHANGE.comit-gmbh.local>

Hello openswan-list,

has anybody yet configured an openswan-server (fixed ip) with the "NCP
Secure Client" and dynamic ip with PSK?
I could't find any information about this constillation.

Regards,

Philipp


From P.Freitag at kellergrundbau.at  Tue Jan 13 04:45:21 2009
From: P.Freitag at kellergrundbau.at (P.Freitag at kellergrundbau.at)
Date: Tue, 13 Jan 2009 10:45:21 +0100
Subject: [Openswan Users] Status of NAT-T
Message-ID: <OFC80FE048.C2A9875C-ONC125753D.00319EB1-C125753D.003596EF@kellergrundbau.at>

Hello Everybody!

Beforehand I  want to apologize if this question has been aked before - 
please point me to the relevant texts in that case, as I was not able to 
find anything about it.

The question is:

Up to which kernel-version does the nat-t patch work? 
(make nattpatch | (cd /usr/src/linux/ && patch -p1)) produces 5 failed 
hunks in udp.c (2.6.24.5 and openswan 2.6.20rc1)
I would like to use KLIPS, but have to use a kernel higher then 2.6.24.5 
due to some driver issues - and sadly wasn't able to find a natt-t patch 
which works with it or any other higher kernel-version, so i have to stick 
to netkey which I don't like.

I've also read some hints about future development which will make the 
natt patches obsolete? Is there some sort of roadmap available about it?


Thanks im advance
Yours
Peter

Angaben gem. HaR?G/ data in accordance with commercial law :
Keller Grundbau Ges.m.b.H.
Mariahilfer Strasse 127a, 1150 Wien
Handelsgericht Wien / FN 88 174 V
ATU14489506
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090113/0cce20ae/attachment.html 

From David_Mccullough at securecomputing.com  Tue Jan 13 05:37:44 2009
From: David_Mccullough at securecomputing.com (David McCullough)
Date: Tue, 13 Jan 2009 20:37:44 +1000
Subject: [Openswan Users] Status of NAT-T
In-Reply-To: <OFC80FE048.C2A9875C-ONC125753D.00319EB1-C125753D.003596EF@kellergrundbau.at>
References: <OFC80FE048.C2A9875C-ONC125753D.00319EB1-C125753D.003596EF@kellergrundbau.at>
Message-ID: <20090113103744.GB28895@securecomputing.com>


Jivin P.Freitag at kellergrundbau.at lays it down ...
> Hello Everybody!
> 
> Beforehand I  want to apologize if this question has been aked before - 
> please point me to the relevant texts in that case, as I was not able to 
> find anything about it.
> 
> The question is:
> 
> Up to which kernel-version does the nat-t patch work? 
> (make nattpatch | (cd /usr/src/linux/ && patch -p1)) produces 5 failed 
> hunks in udp.c (2.6.24.5 and openswan 2.6.20rc1)
> I would like to use KLIPS, but have to use a kernel higher then 2.6.24.5 
> due to some driver issues - and sadly wasn't able to find a natt-t patch 
> which works with it or any other higher kernel-version, so i have to stick 
> to netkey which I don't like.
> 
> I've also read some hints about future development which will make the 
> natt patches obsolete? Is there some sort of roadmap available about it?

I am running openswan with nat-t on linux-2.6.26 ok.  I think I have pushed the
updated nat-t patch stuff to paul.  It's may not be the ideal way to do
the nat-t support but it works ok as far as I have tested it.

I am not sure how you should create the patch though. I thought you no
longer needed to do the 'make nattpatch' bit,  but I could be wrong.

Either way.  if there are no better ideas I can generate a linux-2.6.26
patch for use with openswan-2.6.20dr2 (and some earlier ones) without
too much problem.

Cheers,
Davidm

-- 
David McCullough,  david_mccullough at securecomputing.com,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com

From paul at xelerance.com  Tue Jan 13 11:43:20 2009
From: paul at xelerance.com (Paul Wouters)
Date: Tue, 13 Jan 2009 11:43:20 -0500 (EST)
Subject: [Openswan Users] Status of NAT-T
In-Reply-To: <20090113103744.GB28895@securecomputing.com>
References: <OFC80FE048.C2A9875C-ONC125753D.00319EB1-C125753D.003596EF@kellergrundbau.at>
	<20090113103744.GB28895@securecomputing.com>
Message-ID: <Pine.LNX.4.64.0901131140490.10101@newtla.xelerance.com>

On Tue, 13 Jan 2009, David McCullough wrote:

> Either way.  if there are no better ideas I can generate a linux-2.6.26
> patch for use with openswan-2.6.20dr2 (and some earlier ones) without
> too much problem.

That would be nice.

Also, people might want to test this patch, which still needs some work, but
will remove the need to patch udp.c on recent kernels:

ftp://ftp.openswan.org/openswan/testing/nat-t/

Paul

From m.muenz at spam-fetish.org  Tue Jan 13 11:54:45 2009
From: m.muenz at spam-fetish.org (Muenz, Michael)
Date: Tue, 13 Jan 2009 17:54:45 +0100
Subject: [Openswan Users] Status of NAT-T
In-Reply-To: <Pine.LNX.4.64.0901131140490.10101@newtla.xelerance.com>
References: <OFC80FE048.C2A9875C-ONC125753D.00319EB1-C125753D.003596EF@kellergrundbau.at>	<20090113103744.GB28895@securecomputing.com>
	<Pine.LNX.4.64.0901131140490.10101@newtla.xelerance.com>
Message-ID: <496CC755.6030602@spam-fetish.org>

Paul Wouters schrieb:
> On Tue, 13 Jan 2009, David McCullough wrote:
>
>   
>> Either way.  if there are no better ideas I can generate a linux-2.6.26
>> patch for use with openswan-2.6.20dr2 (and some earlier ones) without
>> too much problem.
>>     
>
> That would be nice.
>
> Also, people might want to test this patch, which still needs some work, but
> will remove the need to patch udp.c on recent kernels:
>
> ftp://ftp.openswan.org/openswan/testing/nat-t/
>
> Paul
>   

What about KLIPS? I use NAT and KLIPS with 2.6.23.12 and 2.4.13 but I 
want to update OpenSWAN to 2.6.20. Will I have to patch the kernel again?

Michael

From paul at xelerance.com  Tue Jan 13 12:56:39 2009
From: paul at xelerance.com (Paul Wouters)
Date: Tue, 13 Jan 2009 12:56:39 -0500 (EST)
Subject: [Openswan Users] Status of NAT-T
In-Reply-To: <496CC755.6030602@spam-fetish.org>
References: <OFC80FE048.C2A9875C-ONC125753D.00319EB1-C125753D.003596EF@kellergrundbau.at>
	<20090113103744.GB28895@securecomputing.com>
	<Pine.LNX.4.64.0901131140490.10101@newtla.xelerance.com>
	<496CC755.6030602@spam-fetish.org>
Message-ID: <Pine.LNX.4.64.0901131254210.10101@newtla.xelerance.com>

On Tue, 13 Jan 2009, Muenz, Michael wrote:

> > Also, people might want to test this patch, which still needs some work, but
> > will remove the need to patch udp.c on recent kernels:
> >
> > ftp://ftp.openswan.org/openswan/testing/nat-t/
> >
> > Paul
> >   
> 
> What about KLIPS? I use NAT and KLIPS with 2.6.23.12 and 2.4.13 but I want to
> update OpenSWAN to 2.6.20. Will I have to patch the kernel again?

That patch should support both old and new style nat-t.

btw. the patch was written by Harald Jenny.

Paul

From David_Mccullough at securecomputing.com  Tue Jan 13 18:38:48 2009
From: David_Mccullough at securecomputing.com (David McCullough)
Date: Wed, 14 Jan 2009 09:38:48 +1000
Subject: [Openswan Users] Status of NAT-T
In-Reply-To: <Pine.LNX.4.64.0901131140490.10101@newtla.xelerance.com>
References: <OFC80FE048.C2A9875C-ONC125753D.00319EB1-C125753D.003596EF@kellergrundbau.at>
	<20090113103744.GB28895@securecomputing.com>
	<Pine.LNX.4.64.0901131140490.10101@newtla.xelerance.com>
Message-ID: <20090113233848.GA30390@securecomputing.com>


Jivin Paul Wouters lays it down ...
> On Tue, 13 Jan 2009, David McCullough wrote:
> 
> > Either way.  if there are no better ideas I can generate a linux-2.6.26
> > patch for use with openswan-2.6.20dr2 (and some earlier ones) without
> > too much problem.
> 
> That would be nice.

Ok, here is what I amusing,  but it isn't going to work out of the box
for anyone else.

I am not sure how openswan normally does the Kconfig and build system
updates,  so the very first part of the patch for linux/net/Kconfig
will almost certainly be wrong.

The rest will be OK I think.  This patch is against vanilla linux-2.6.26.
I am fairly sure a different patch is needed for older kernels (and I
probably have those if needed).

> Also, people might want to test this patch, which still needs some work, but
> will remove the need to patch udp.c on recent kernels:
> 
> ftp://ftp.openswan.org/openswan/testing/nat-t/

Any idea what work it still needed or is it pretty much expected to work ?

Cheers,
Davidm

-- 
David McCullough,  david_mccullough at securecomputing.com,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openswan-2.6.20dr2-nat-t.patch
Type: text/x-diff
Size: 7287 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/users/attachments/20090114/0b3120c8/attachment.bin 

From paul at xelerance.com  Tue Jan 13 19:22:17 2009
From: paul at xelerance.com (Paul Wouters)
Date: Tue, 13 Jan 2009 19:22:17 -0500 (EST)
Subject: [Openswan Users] Status of NAT-T
In-Reply-To: <20090113233848.GA30390@securecomputing.com>
References: <OFC80FE048.C2A9875C-ONC125753D.00319EB1-C125753D.003596EF@kellergrundbau.at>
	<20090113103744.GB28895@securecomputing.com>
	<Pine.LNX.4.64.0901131140490.10101@newtla.xelerance.com>
	<20090113233848.GA30390@securecomputing.com>
Message-ID: <Pine.LNX.4.64.0901131920340.21083@newtla.xelerance.com>

On Wed, 14 Jan 2009, David McCullough wrote:

> > ftp://ftp.openswan.org/openswan/testing/nat-t/
> 
> Any idea what work it still needed or is it pretty much expected to work ?

It works, but there are some issues:

- Cleanup the #ifdef's (eliminates half the patch)
- Rewrite a hardcoded "ipsec0" to the proper device
- Instead of using code moved in from our "udp.c" nat-t patch,
  use the xfrm decap hooks instead - less maintenance in the future

Paul

From bfoddy at visi.com  Tue Jan 13 23:42:29 2009
From: bfoddy at visi.com (Brian Foddy)
Date: Tue, 13 Jan 2009 22:42:29 -0600
Subject: [Openswan Users] Nasty MTU problem - Please Help
Message-ID: <200901132242.29608.bfoddy@visi.com>

I have a simple 2-net Openswan setup, both running 2.6.19 on recent Mandriva 
distros and kernels (2009/2008 on 2.6.27/2.6.22).  I've been a long-time user 
of Openswan with few problems, but recently made ISP changes that forced some 
changes.


NetA --------> G1 --> internet <-- G2 <----- NetB

NetA Host=10.20.0.10 (one of several)
G1 (eth1 internal 10.20.0.1, ppp0 external (using eth0))
G2 (eth1 inernal 10.20.1.1, eth0 external via dhcp)
NetB Host=10.20.1.10 (one of several)

          
Both G1 and G2 have DSL services, but G1 is using PPPoE (Roaring Pengiun 
3.8.5) through a Motorola 3347 DSL modem in bridging mode.  G2 has a standard 
DSL modem with standard network gateway settings (no PPP).  Both networks 
work fine by themselves. 

The pppoe command options on G1 are:
pppoe -m 1412 -I eth0

Sending files from a NetA host to NetB host works fine with scp.  Sending a 
file via scp from the same NetB host back to NetA always hangs (or long ssh 
output).  If I wireshark the transfer on the G2 internal eth1 I see the 
following packets:
10.20.1.10 -> 10.20.0.10 SSHv2 packet len=1448
10.20.1.1  -> 10.20.1.10 ICMP Destination unreachable (Fragmentation needed)
10.20.1.10 -> 10.20.1.10 SSHv2 packet len-1448
10.20.1.1  -> 10.20.1.10 ICMP Destination unreachable (Fragmentation needed)
10.20.1.10 -> 10.20.0.10 SSHV2 [TCP Out-of-order] len=1386
10.20.1.10 -> 10.20.0.10 SSHv2 [TCP Out-of-order] len=62

10.20.1.10 -> 10.20.0.10 SSHV2 [TCP Out-of-order] len=1386
10.20.1.10 -> 10.20.0.10 SSHv2 [TCP Out-of-order] len=62
10.20.0.10 -> 10.20.0.10 TCP   [TCP Dup ACK]

(I have saved the whole capture and can include if its needed).
then similar repeating patterns of 1386 length packets that never make it.  
The ssh packets are flags with don't fragment.  Its clear ssh is seeing the 
attempted mtu discovery, but it doesn't seem to be low enough.

If I ping from 10.20.1.10 to 10.20.0.10, a "ping -s 1394" will get through, 
but a "ping -s 1395" wont.  Reversing the pings (from 10.20.0.10 to 
10.20.1.10), anything over 1394 will produce 
From murdock.foddy.home (10.20.0.1) icmp_seq=1 Frag needed and DF set (mtu = 
1422)
before the pings start getting through.  Interestingly, if I ssh to G2 then to 
NetB host outside the VPN (normal internet SSH), the transfers never hang.  
So it seems to only be the vpn connections having the problem.

My ipsec.conf file is below (comments and non-critical sections removed)

========================================================================
version 2.0 

# basic configuration
config setup
       nat_traversal=no
        overridemtu=1440
        protostack=netkey

conn foddy
        left=216.160.0.218  
        leftsubnet=10.20.0.0/24
        leftid=@bfoddy.homeip.net
        leftrsasigkey=0sAQNd...
        leftnexthop=%defaultroute
        leftsourceip=10.20.0.1

        right=199.120.114.184
        rightsubnet=10.20.1.0/24
        rightid=@hfoddy.homeip.net
        rightrsasigkey=0sAQN...
        rightnexthop=%defaultroute
        rightsourceip=10.20.1.1
        auto=start     
==========================================================================

I thought I found the solution with the overridemtu, but a message on startup 
says its ignored with netkey configs.

Other tidbits, G1 has 2 Intel ePro100 cards.  I found references saying the 
eepro100 module was buggy and so I forced it to use the e100 driver, no help.  
G1 has 3 nic cards, eth0 (the ppp0), eth1 (internal), and eth2 connected to a 
vlan partition on the 3347 router for 2 separate wireless nets.
Both (G1 and G2) are running Shorewall,
G1 = 4.0.13
G2 = 3.4.4

On G1, I have set /etc/shorewall/shorewall.conf CLAMPSS=Yes as suggested by 
that documentation.

How can I get this working, short of forcing all G2 traffic to a smaller MTU 
that would affect a lot more traffic than just the VPN?

Thanks,
Brian
 



From openswan at thefeds.net  Wed Jan 14 08:48:20 2009
From: openswan at thefeds.net (openswan at thefeds.net)
Date: Wed, 14 Jan 2009 13:48:20 +0000 (GMT)
Subject: [Openswan Users] Nasty MTU problem - Please Help
In-Reply-To: <200901132242.29608.bfoddy@visi.com>
References: <200901132242.29608.bfoddy@visi.com>
Message-ID: <Pine.LNX.4.64.0901141344200.30613@fedex.thefeds.net>

One option is to run a GRE tunnel between the two hosts, the GRE tunnel is 
then encrypted by openswan. This gives you an interface on which you can 
set a lower MTU.

Tim


On Tue, 13 Jan 2009, Brian Foddy wrote:

> I have a simple 2-net Openswan setup, both running 2.6.19 on recent Mandriva
> distros and kernels (2009/2008 on 2.6.27/2.6.22).  I've been a long-time user
> of Openswan with few problems, but recently made ISP changes that forced some
> changes.
>
>
> NetA --------> G1 --> internet <-- G2 <----- NetB
>
> NetA Host=10.20.0.10 (one of several)
> G1 (eth1 internal 10.20.0.1, ppp0 external (using eth0))
> G2 (eth1 inernal 10.20.1.1, eth0 external via dhcp)
> NetB Host=10.20.1.10 (one of several)
>
>
> Both G1 and G2 have DSL services, but G1 is using PPPoE (Roaring Pengiun
> 3.8.5) through a Motorola 3347 DSL modem in bridging mode.  G2 has a standard
> DSL modem with standard network gateway settings (no PPP).  Both networks
> work fine by themselves.
>
> The pppoe command options on G1 are:
> pppoe -m 1412 -I eth0
>
> Sending files from a NetA host to NetB host works fine with scp.  Sending a
> file via scp from the same NetB host back to NetA always hangs (or long ssh
> output).  If I wireshark the transfer on the G2 internal eth1 I see the
> following packets:
> 10.20.1.10 -> 10.20.0.10 SSHv2 packet len=1448
> 10.20.1.1  -> 10.20.1.10 ICMP Destination unreachable (Fragmentation needed)
> 10.20.1.10 -> 10.20.1.10 SSHv2 packet len-1448
> 10.20.1.1  -> 10.20.1.10 ICMP Destination unreachable (Fragmentation needed)
> 10.20.1.10 -> 10.20.0.10 SSHV2 [TCP Out-of-order] len=1386
> 10.20.1.10 -> 10.20.0.10 SSHv2 [TCP Out-of-order] len=62
>
> 10.20.1.10 -> 10.20.0.10 SSHV2 [TCP Out-of-order] len=1386
> 10.20.1.10 -> 10.20.0.10 SSHv2 [TCP Out-of-order] len=62
> 10.20.0.10 -> 10.20.0.10 TCP   [TCP Dup ACK]
>
> (I have saved the whole capture and can include if its needed).
> then similar repeating patterns of 1386 length packets that never make it.
> The ssh packets are flags with don't fragment.  Its clear ssh is seeing the
> attempted mtu discovery, but it doesn't seem to be low enough.
>
> If I ping from 10.20.1.10 to 10.20.0.10, a "ping -s 1394" will get through,
> but a "ping -s 1395" wont.  Reversing the pings (from 10.20.0.10 to
> 10.20.1.10), anything over 1394 will produce
>> From murdock.foddy.home (10.20.0.1) icmp_seq=1 Frag needed and DF set (mtu =
> 1422)
> before the pings start getting through.  Interestingly, if I ssh to G2 then to
> NetB host outside the VPN (normal internet SSH), the transfers never hang.
> So it seems to only be the vpn connections having the problem.
>
> My ipsec.conf file is below (comments and non-critical sections removed)
>
> ========================================================================
> version 2.0
>
> # basic configuration
> config setup
>       nat_traversal=no
>        overridemtu=1440
>        protostack=netkey
>
> conn foddy
>        left=216.160.0.218
>        leftsubnet=10.20.0.0/24
>        leftid=@bfoddy.homeip.net
>        leftrsasigkey=0sAQNd...
>        leftnexthop=%defaultroute
>        leftsourceip=10.20.0.1
>
>        right=199.120.114.184
>        rightsubnet=10.20.1.0/24
>        rightid=@hfoddy.homeip.net
>        rightrsasigkey=0sAQN...
>        rightnexthop=%defaultroute
>        rightsourceip=10.20.1.1
>        auto=start
> ==========================================================================
>
> I thought I found the solution with the overridemtu, but a message on startup
> says its ignored with netkey configs.
>
> Other tidbits, G1 has 2 Intel ePro100 cards.  I found references saying the
> eepro100 module was buggy and so I forced it to use the e100 driver, no help.
> G1 has 3 nic cards, eth0 (the ppp0), eth1 (internal), and eth2 connected to a
> vlan partition on the 3347 router for 2 separate wireless nets.
> Both (G1 and G2) are running Shorewall,
> G1 = 4.0.13
> G2 = 3.4.4
>
> On G1, I have set /etc/shorewall/shorewall.conf CLAMPSS=Yes as suggested by
> that documentation.
>
> How can I get this working, short of forcing all G2 traffic to a smaller MTU
> that would affect a lot more traffic than just the VPN?
>
> Thanks,
> Brian
>
>
>
> _______________________________________________
> 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=283155
>

From cioban at gmail.com  Wed Jan 14 07:50:32 2009
From: cioban at gmail.com (Sergio Cioban Filho)
Date: Wed, 14 Jan 2009 10:50:32 -0200
Subject: [Openswan Users] "Promisc" trafic over tunnel
Message-ID: <f18571170901140450k5289d2e2n906d2d8c086ed0ae@mail.gmail.com>

Hi all,

I'm trying redirect all "promisc" trafic captured on eth2 interface over
ipsec tunnel.
That is my scenario:

(HUB)<------>(eth2:Server:eth0=ipsec0)<---------->(eth0=ipsec0:Client)

I want redirect (or mirroring) all traffic (sniffed) on eth2 server
interface to client ipsec0 interface.
When I run tcpdump on ipsec0 client interface, the result must be same of
the eth2 server interface.

Any idea?

Thanks,
Regards,
---
S?rgio Cioban Filho
| Tecn?logo em Gest?o de TI
| Linux Professional Institute Certified - Level 1
------------------------------------------------------------
| Linux - Servidores - Firewall - VPN
| Virtualiza??o - VoIP - ShellScript - C - PHP
| http://cioban.googlepages.com
| +55 48 9989-8733
------------------------------------------------------------
..:: Seja livre, use LiNuX!! ::..
------------------------------------------------------------
Vendo GOL G3 PLUS 1.0 8V - 4 P - 2002 - Branco - COMPLET?SSIMO - R$ 20.200
http://cioban.googlepages.com/vendogolg38v
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090114/e51841df/attachment.html 

From bach.johannes at googlemail.com  Wed Jan 14 09:48:17 2009
From: bach.johannes at googlemail.com (Johannes Bach)
Date: Wed, 14 Jan 2009 15:48:17 +0100
Subject: [Openswan Users] point-to-point vpn-ipsec-connection
Message-ID: <1458694d0901140648v634df80eg5529b627b2cb5e50@mail.gmail.com>

Hello list,

I have a problem with creating a connection as shown as follows:

host1.1
-------------------
-------------------------- host1.2

|                                                         |
                              |---- UBUNTU-VPN-SERVER  ---------------|
                              |     virual-LAN1, virtual-LAN2
  |
host2.1 -------------------
-------------------------- host2.2


I want to configure an UBUNTU-VPN-Server (with only one network-hardware
---> i use virtual interfaces/lans) so that host1.1 can log in via vpn and
host 1.2 can log in via vpn.
Both hosts should meat each other in the Servers virtual LAN1. Host2.1 and
host 2.2 should meat each other in the virtual LAN2. The 1.x hosts should
not be able to ping the 2.x hosts.

I wanted to solve that probleme with interface-forwarding. when host1.1 logs
in he gets ipsec0 when host1.2 logs in he gets ipsec1 BUT there is only one
interface for both connections.and neither host1.1 nor host1.2 are getting
an ip from the vpn-server. there are only the entries in the routing-table.
But what if the subnet of host1.1 and host 1.2 have the same netadress?
there will be adressconflicts in the routing-table.... Thats because I
wanted to solve that problem via interface-forwarding BUT as already
mentioned ipsec with openswan does not build extra interfaces for each
connection.

Has anybody who understood what i want (sorry for my bad english.. :) an
idea how reach the assembly above?



thanx for ya help,

with best regards from germany bavaria (OKTOBERFEST),



joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090114/057df504/attachment.html 

From petermcgill at goco.net  Wed Jan 14 10:03:42 2009
From: petermcgill at goco.net (Peter McGill)
Date: Wed, 14 Jan 2009 10:03:42 -0500
Subject: [Openswan Users] "Promisc" trafic over tunnel
In-Reply-To: <f18571170901140450k5289d2e2n906d2d8c086ed0ae@mail.gmail.com>
References: <f18571170901140450k5289d2e2n906d2d8c086ed0ae@mail.gmail.com>
Message-ID: <496DFECE.1090405@goco.net>

Well IPSec (not just Openswan but the protocol in general) won't let you 
do that. It only transfers packets over the tunnels which match the 
tunnels source & dest subnets, and works with normal routing methods to 
do it. What your suggesting won't work with that. You could instead use 
tcpdump to capture the packets to a file, then periodically rotate the 
file and send it to the other host over the tunnel. Where you could then 
use tcpdump again to view the packets in the file. What you transfer the 
file with is up to you, sftp, ftps, ftp, etc...

Peter

Sergio Cioban Filho wrote:
> Hi all,
> 
> I'm trying redirect all "promisc" trafic captured on eth2 interface over 
> ipsec tunnel.
> That is my scenario:
> 
> (HUB)<------>(eth2:Server:eth0=ipsec0)<---------->(eth0=ipsec0:Client)
> 
> I want redirect (or mirroring) all traffic (sniffed) on eth2 server 
> interface to client ipsec0 interface.
> When I run tcpdump on ipsec0 client interface, the result must be same 
> of the eth2 server interface.
> 
> Any idea?
> 
> Thanks,
> Regards,
> ---
> S?rgio Cioban Filho
> | Tecn?logo em Gest?o de TI
> | Linux Professional Institute Certified - Level 1
> ------------------------------------------------------------
> | Linux - Servidores - Firewall - VPN
> | Virtualiza??o - VoIP - ShellScript - C - PHP
> | http://cioban.googlepages.com
> | +55 48 9989-8733
> ------------------------------------------------------------
> ..:: Seja livre, use LiNuX!! ::..
> ------------------------------------------------------------
> Vendo GOL G3 PLUS 1.0 8V - 4 P - 2002 - Branco - COMPLET?SSIMO - R$ 20.200
> http://cioban.googlepages.com/vendogolg38v
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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=283155

From muir.james.a at gmail.com  Wed Jan 14 10:33:26 2009
From: muir.james.a at gmail.com (James Muir)
Date: Wed, 14 Jan 2009 10:33:26 -0500
Subject: [Openswan Users] Nasty MTU problem - Please Help
In-Reply-To: <200901132242.29608.bfoddy@visi.com>
References: <200901132242.29608.bfoddy@visi.com>
Message-ID: <496E05C6.6070501@gmail.com>

> Sending files from a NetA host to NetB host works fine with scp.  Sending a 
> file via scp from the same NetB host back to NetA always hangs (or long ssh 
> output).  If I wireshark the transfer on the G2 internal eth1 I see the 
> following packets:
> 10.20.1.10 -> 10.20.0.10 SSHv2 packet len=1448
> 10.20.1.1  -> 10.20.1.10 ICMP Destination unreachable (Fragmentation needed)
> 10.20.1.10 -> 10.20.1.10 SSHv2 packet len-1448
> 10.20.1.1  -> 10.20.1.10 ICMP Destination unreachable (Fragmentation needed)
> 10.20.1.10 -> 10.20.0.10 SSHV2 [TCP Out-of-order] len=1386
> 10.20.1.10 -> 10.20.0.10 SSHv2 [TCP Out-of-order] len=62
> 
> 10.20.1.10 -> 10.20.0.10 SSHV2 [TCP Out-of-order] len=1386
> 10.20.1.10 -> 10.20.0.10 SSHv2 [TCP Out-of-order] len=62
> 10.20.0.10 -> 10.20.0.10 TCP   [TCP Dup ACK]
> 
> (I have saved the whole capture and can include if its needed).
> then similar repeating patterns of 1386 length packets that never make it.  
> The ssh packets are flags with don't fragment.  Its clear ssh is seeing the 
> attempted mtu discovery, but it doesn't seem to be low enough.
> 
> If I ping from 10.20.1.10 to 10.20.0.10, a "ping -s 1394" will get through, 
> but a "ping -s 1395" wont.  Reversing the pings (from 10.20.0.10 to 
> 10.20.1.10), anything over 1394 will produce 
>>From murdock.foddy.home (10.20.0.1) icmp_seq=1 Frag needed and DF set (mtu = 
> 1422)
> before the pings start getting through.  Interestingly, if I ssh to G2 then to 
> NetB host outside the VPN (normal internet SSH), the transfers never hang.  
> So it seems to only be the vpn connections having the problem.

I just dealt with a similar mtu problem and saw many of the same 
symptoms you've reported.  If you look back in the list archive, then 
you can read my messages.

To fix your problem, try the following.  On NetB, do

	$ tracepath NetA

tracepath does path mtu discovery.  Suppose the pmtu value it reports is 
1450.  Now, setup your tunnel from NetB to NetA.  Next, change the mtu 
value of eth0 like so:

	$ ifconfig eth0 mtu 1450

(I think the command may be slightly different on Redhat/Mandriva.) 
Now, test the tunnel by trying to transfer a file using scp.

-James



From openswan at thefeds.net  Wed Jan 14 13:57:54 2009
From: openswan at thefeds.net (openswan at thefeds.net)
Date: Wed, 14 Jan 2009 18:57:54 +0000 (GMT)
Subject: [Openswan Users] "Promisc" trafic over tunnel
In-Reply-To: <f18571170901140450k5289d2e2n906d2d8c086ed0ae@mail.gmail.com>
References: <f18571170901140450k5289d2e2n906d2d8c086ed0ae@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0901141856040.30613@fedex.thefeds.net>

You need to bridge eth2 and the ipsec tunnel. You may have to create a GRE 
tunnel over the ipsec tunnel to do this.

The bridge will also copy packets from the ipsec/gre tunnel to eth2.

Tim

On Wed, 14 Jan 2009, Sergio Cioban Filho wrote:

> Hi all,
>
> I'm trying redirect all "promisc" trafic captured on eth2 interface over
> ipsec tunnel.
> That is my scenario:
>
> (HUB)<------>(eth2:Server:eth0=ipsec0)<---------->(eth0=ipsec0:Client)
>
> I want redirect (or mirroring) all traffic (sniffed) on eth2 server
> interface to client ipsec0 interface.
> When I run tcpdump on ipsec0 client interface, the result must be same of
> the eth2 server interface.
>
> Any idea?
>
> Thanks,
> Regards,
> ---
> S?rgio Cioban Filho
> | Tecn?logo em Gest?o de TI
> | Linux Professional Institute Certified - Level 1
> ------------------------------------------------------------
> | Linux - Servidores - Firewall - VPN
> | Virtualiza??o - VoIP - ShellScript - C - PHP
> | http://cioban.googlepages.com
> | +55 48 9989-8733
> ------------------------------------------------------------
> ..:: Seja livre, use LiNuX!! ::..
> ------------------------------------------------------------
> Vendo GOL G3 PLUS 1.0 8V - 4 P - 2002 - Branco - COMPLET?SSIMO - R$ 20.200
> http://cioban.googlepages.com/vendogolg38v
>
-------------- next part --------------
_______________________________________________
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=283155

From openswan at thefeds.net  Wed Jan 14 14:11:35 2009
From: openswan at thefeds.net (openswan at thefeds.net)
Date: Wed, 14 Jan 2009 19:11:35 +0000 (GMT)
Subject: [Openswan Users] IPSEC SA only being installed on one side
In-Reply-To: <Pine.LNX.4.64.0901051334450.15158@fedex.thefeds.net>
References: <Pine.LNX.4.64.0812301739240.4268@fedex.thefeds.net>
	<Pine.LNX.4.64.0901011950550.6849@newtla.xelerance.com>
	<Pine.LNX.4.64.0901051334450.15158@fedex.thefeds.net>
Message-ID: <Pine.LNX.4.64.0901141904020.30613@fedex.thefeds.net>

Just moving to 1.6.20rc1 did not correct my rekeying issues, it did 
improve them but I still had some failures, including failures between two 
servers with only two switches between them.

Last Thursday I changed the OSPF options of the quagga ospfd process 
running on each of my vpn servers so that it would route round problems 
faster. The increased traffic appears to have sorted out the rekeying 
issues.

I have been testing the vpn servers so the only traffic flowing between 
them has been 5 pings every 60 seconds (for monitoring) and 2 OSPF hellos 
every 10 seconds. I have now configured OSPF to hello every second and 
this change appears to have sorted out the rekeying issues. Though I have 
no idea why.

Tim

On Mon, 5 Jan 2009, opsenswan at thefeds.net wrote:

> 2.6.20rc1 has been running for three days and is much better.
>
> I would say it is perfect for phase 2 rekeying but there are two incidents
> I am still investigating.
>
> My monitoring is still picking up quite a few incidents where I have no
> phase 1 SA but this could be because I only have a 60 second rekeying
> margin (to mitigate the effects of the rekeying problems). I will push out
> new configs with a higher rekeying margin and see what happens.
>
> Thanks
> Tim
>
> On Thu, 1 Jan 2009, Paul Wouters wrote:
>
>> On Tue, 30 Dec 2008, openswan at thefeds.net wrote:
>>
>> There have been some fixes to rekeying lately. Please try the latest
>> test release (2.6.20rc1). Though this bug might still exist.
>>
>> Paul
>>
>>> Date: Tue, 30 Dec 2008 18:35:42 +0000 (GMT)
>>> From:  <openswan at thefeds.net>
>>> To:  <users at openswan.org>
>>> Subject: [Openswan Users] IPSEC SA only being installed on one side
>>>
>>> I am trying to track down a problem I am having quite frequently where my
>>> phase 1 SA is fine (and thus DPD doesn't see any problems) but my phase 2
>>> SAs aren't in step and thus traffic can't get through.
>>>
>>> The problem appears to be that sometimes when a new phase 2 SA is
>>> negotiated one side is happy and installs the SA, but the other side
>>> (never the initiator) doesn't install the SA. The side with the newer SA
>>> then sends packets encrypted with the new SPI which the other side cannot
>>> understand.
>>>
>>> I have the following extracts from /var/log/secure:
>>>
>>> The initiator:
>>> Dec 30 12:40:04 vpn01d pluto[4943]: "tun02a01d" #442: STATE_MAIN_I4:
>>> ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256
>>> prf=oakley_sha group=modp1536}
>>> Dec 30 12:40:04 vpn01d pluto[4943]: "tun02a01d" #442: Dead Peer Detection
>>> (RFC 3706): enabled
>>> Dec 30 14:32:40 vpn01d pluto[4943]: "tun02a01d" #455: initiating Quick
>>> Mode PSK+ENCRYPT+PFS+UP+IKEv2ALLOW to replace #428 {using isakmp#442
>>> msgid:1ff67d30 proposal=AES(12)_256-SHA1(2)_160
>>> pfsgroup=OAKLEY_GROUP_MODP1536}
>>> Dec 30 14:32:40 vpn01d pluto[4943]: "tun02a01d" #455: Dead Peer Detection
>>> (RFC 3706): enabled
>>> Dec 30 14:32:40 vpn01d pluto[4943]: "tun02a01d" #455: transition from
>>> state STATE_QUICK_I1 to state STATE_QUICK_I2
>>> Dec 30 14:32:40 vpn01d pluto[4943]: "tun02a01d" #455: STATE_QUICK_I2: sent
>>> QI2, IPsec SA established transport mode {ESP=>0x0f2d2e3a <0x36134870
>>> xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=none DPD=enabled}
>>> Dec 30 14:32:50 vpn01d pluto[4943]: "tun02a01d" #455: message ignored
>>> because it contains an unexpected payload type (ISAKMP_NEXT_HASH)
>>> Dec 30 14:32:50 vpn01d pluto[4943]: "tun02a01d" #455: sending encrypted
>>> notification INVALID_PAYLOAD_TYPE to <vpn02a ip>:500
>>>
>>> The reciever:
>>> Dec 30 12:40:04 vpn02a pluto[547]: "tun02a01d" #480: STATE_MAIN_R3: sent
>>> MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256
>>> prf=oakley_sha group=modp1536}
>>> Dec 30 12:40:04 vpn02a pluto[547]: "tun02a01d" #480: Dead Peer Detection
>>> (RFC 3706): enabled
>>> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #480: the peer proposed:
>>> <vpn02a ip>/32:0/0 -> <vpn02d ip>/32:0/0
>>> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515: responding to Quick
>>> Mode proposal {msgid:1ff67d30}
>>> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515:     us:
>>> <vpn02a ip><<vpn02a ip>>[+S=C]---<vpn02a nh>
>>> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515:   them:
>>> <vpn01d nh>---<vpn01d ip><<vpn01d ip>>[+S=C]
>>> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515: keeping
>>> refhim=4294901761 during rekey
>>> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515: transition from state
>>> STATE_QUICK_R0 to state STATE_QUICK_R1
>>> Dec 30 14:32:40 vpn02a pluto[547]: "tun02a01d" #515: STATE_QUICK_R1: sent
>>> QR1, inbound IPsec SA installed, expecting QI2
>>> Dec 30 14:32:40 vpn02a pluto[547]: packet from <vpn01d ip>:500:
>>> Informational Exchange is for an unknown (expired?) SA
>>> Dec 30 14:32:50 vpn02a pluto[547]: "tun02a01d" #480: ignoring
>>> informational payload, type INVALID_PAYLOAD_TYPE msgid=00000000
>>> Dec 30 14:32:50 vpn02a pluto[547]: "tun02a01d" #480: received and ignored
>>> informational message
>>>
>>> I then end up with the following SAs on vpn02a:
>>> 000 #523: "tun02a01d":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established);
>>> EVENT_SA_REPLACE in 9590s; newest ISAKMP; lastdpd=2s(seq in:24780 out:0);
>>> idle; import:not set
>>> 000 #480: "tun02a01d":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established);
>>> EVENT_SA_REPLACE in 2449s; lastdpd=1210s(seq in:7855 out:0); idle;
>>> import:not set
>>> 000 #470: "tun02a01d":500 STATE_QUICK_R2 (IPsec SA established);
>>> EVENT_SA_REPLACE in 2026s; newest IPSEC; eroute owner; isakmp#454; idle;
>>> import:not set
>>> 000 #470: "tun02a01d" esp.f2d777e3@<vpn01d ip> esp.8ca1e089@<vpn02a ip>
>>> ref=0 refhim=4294901761
>>>
>>> and vpn01d:
>>> 000 #466: "tun02a01d":500 STATE_MAIN_I4 (ISAKMP SA established);
>>> EVENT_SA_REPLACE in 5934s; newest ISAKMP; lastdpd=1s(seq in:3752 out:0);
>>> idle; import:admin initiate
>>> 000 #455: "tun02a01d":500 STATE_QUICK_I2 (sent QI2, IPsec SA established);
>>> EVENT_SA_REPLACE in 5593s; newest IPSEC; eroute owner; isakmp#442; idle;
>>> import:admin initiate
>>> 000 #455: "tun02a01d" esp.f2d2e3a@<vpn02a ip> esp.36134870@<vpn01d ip>
>>> ref=0 refhim=4294901761
>>> 000 #442: "tun02a01d":500 STATE_MAIN_I4 (ISAKMP SA established);
>>> EVENT_SA_EXPIRE in 6050s; lastdpd=1209s(seq in:17036 out:0); idle;
>>> import:admin initiate
>>> 000 #428: "tun02a01d":500 STATE_QUICK_I2 (sent QI2, IPsec SA established);
>>> EVENT_SA_EXPIRE in 5627s; isakmp#411; idle; import:admin initiate
>>> 000 #428: "tun02a01d" esp.8ca1e089@<vpn02a ip> esp.f2d777e3@<vpn01d ip>
>>> ref=0 refhim=4294901761
>>>
>>> So you can see that vpn02a does have esp.36134870@<vpn01d ip>
>>> esp.f2d2e3a@<vpn02a ip> installed and as that is newest on vpn01d that is
>>> what it is using for all traffic to vpn02a.
>>>
>>> I am guessing that the log entry of:
>>> Dec 30 14:32:40 vpn02a pluto[547]: packet from <vpn01d ip>:500:
>>> Informational Exchange is for an unknown (expired?) SA
>>> May be the QI2 packet from vpn01d that vpn01d doesn't understand? I
>>> thought at one time that the phase 1 SA may be expiring at this point, but
>>> I am seeing this happen far too often for that. Plus as the logs show the
>>> phase 1 SA was renegotiated 112 minutes and 48 seconds earlier and I have
>>> a key life of 240 minutes with a rekeying margin of 120 minutes and a
>>> rekeying fuzz of 1% so the next phase 1 rekeying isn't due for another 6
>>> minutes to 7 minutes 12 seconds. I do see the phase 1 rekey happen in the
>>> logs 6 minutes and 25 seconds later.
>>>
>>> Does anyone have any idea how I can go about finding out why the recieving
>>> end sometimes doesn't install the new phase 2 SA?
>>>
>>> Thanks in advance for any help
>>> Tim
>>> _______________________________________________
>>> 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=283155
>>>
>>
> _______________________________________________
> 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=283155
>

From cioban at gmail.com  Wed Jan 14 13:38:13 2009
From: cioban at gmail.com (Sergio Cioban Filho)
Date: Wed, 14 Jan 2009 16:38:13 -0200
Subject: [Openswan Users] "Promisc" trafic over tunnel
In-Reply-To: <Pine.LNX.4.64.0901141856040.30613@fedex.thefeds.net>
References: <f18571170901140450k5289d2e2n906d2d8c086ed0ae@mail.gmail.com>
	<Pine.LNX.4.64.0901141856040.30613@fedex.thefeds.net>
Message-ID: <f18571170901141038w1f0d84bek77f7f454fda60227@mail.gmail.com>

Thanks for all answers,

I'm trying turn on GRE tunnel over IPSEC tunnel.
The IPSEC tunnel works fine, and GRE tunnel too, but bridge-utils dont
supports gre interfaces...

My configuration:
 - Turn on ipsec tunnel
 - execute these commands
ip tunnel add teste2 mode gre remote 20.20.20.2 local 192.168.170.38 ttl 255
ip link set teste2 up
ifconfig eth2 up promisc
brctl addbr br0
brctl addif br0 eth2
brctl addif br0 teste2

This error has occurred:
can't add teste2 to bridge br0: Invalid argument

I'm searching on internet about this problem...


Thanks,
Regards,
---
S?rgio Cioban Filho
| Tecn?logo em Gest?o de TI
| Linux Professional Institute Certified - Level 1
------------------------------------------------------------
| Linux - Servidores - Firewall - VPN
| Virtualiza??o - VoIP - ShellScript - C - PHP
| http://cioban.googlepages.com
| +55 48 9989-8733
------------------------------------------------------------
..:: Seja livre, use LiNuX!! ::..
------------------------------------------------------------
Vendo GOL G3 PLUS 1.0 8V - 4 P - 2002 - Branco - COMPLET?SSIMO - R$ 20.200
(ou R$15.000 + 13x R$391,36)
http://cioban.googlepages.com/vendogolg38v


On Wed, Jan 14, 2009 at 16:57, <openswan at thefeds.net> wrote:

> You need to bridge eth2 and the ipsec tunnel. You may have to create a GRE
> tunnel over the ipsec tunnel to do this.
>
> The bridge will also copy packets from the ipsec/gre tunnel to eth2.
>
> Tim
>
>
> On Wed, 14 Jan 2009, Sergio Cioban Filho wrote:
>
>  Hi all,
>>
>> I'm trying redirect all "promisc" trafic captured on eth2 interface over
>> ipsec tunnel.
>> That is my scenario:
>>
>> (HUB)<------>(eth2:Server:eth0=ipsec0)<---------->(eth0=ipsec0:Client)
>>
>> I want redirect (or mirroring) all traffic (sniffed) on eth2 server
>> interface to client ipsec0 interface.
>> When I run tcpdump on ipsec0 client interface, the result must be same of
>> the eth2 server interface.
>>
>> Any idea?
>>
>> Thanks,
>> Regards,
>> ---
>> S?rgio Cioban Filho
>> | Tecn?logo em Gest?o de TI
>> | Linux Professional Institute Certified - Level 1
>> ------------------------------------------------------------
>> | Linux - Servidores - Firewall - VPN
>> | Virtualiza??o - VoIP - ShellScript - C - PHP
>> | http://cioban.googlepages.com
>> | +55 48 9989-8733
>> ------------------------------------------------------------
>> ..:: Seja livre, use LiNuX!! ::..
>> ------------------------------------------------------------
>> Vendo GOL G3 PLUS 1.0 8V - 4 P - 2002 - Branco - COMPLET?SSIMO - R$ 20.200
>> http://cioban.googlepages.com/vendogolg38v
>>
>
> _______________________________________________
> 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=283155
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090114/336df934/attachment.html 

From bfoddy at visi.com  Wed Jan 14 22:51:53 2009
From: bfoddy at visi.com (Brian Foddy)
Date: Wed, 14 Jan 2009 21:51:53 -0600
Subject: [Openswan Users] Nasty MTU problem - Please Help
In-Reply-To: <496E05C6.6070501@gmail.com>
References: <200901132242.29608.bfoddy@visi.com> <496E05C6.6070501@gmail.com>
Message-ID: <200901142151.54012.bfoddy@visi.com>

On Wednesday 14 January 2009, James Muir wrote:
> > Sending files from a NetA host to NetB host works fine with scp.  Sending
> > a file via scp from the same NetB host back to NetA always hangs (or long
> > ssh output).  If I wireshark the transfer on the G2 internal eth1 I see
> > the following packets:
> > 10.20.1.10 -> 10.20.0.10 SSHv2 packet len=1448
> > 10.20.1.1  -> 10.20.1.10 ICMP Destination unreachable (Fragmentation
> > needed) 10.20.1.10 -> 10.20.1.10 SSHv2 packet len-1448
> > 10.20.1.1  -> 10.20.1.10 ICMP Destination unreachable (Fragmentation
> > needed) 10.20.1.10 -> 10.20.0.10 SSHV2 [TCP Out-of-order] len=1386
> > 10.20.1.10 -> 10.20.0.10 SSHv2 [TCP Out-of-order] len=62
> >
> > 10.20.1.10 -> 10.20.0.10 SSHV2 [TCP Out-of-order] len=1386
> > 10.20.1.10 -> 10.20.0.10 SSHv2 [TCP Out-of-order] len=62
> > 10.20.0.10 -> 10.20.0.10 TCP   [TCP Dup ACK]
> >
> > (I have saved the whole capture and can include if its needed).
> > then similar repeating patterns of 1386 length packets that never make
> > it. The ssh packets are flags with don't fragment.  Its clear ssh is
> > seeing the attempted mtu discovery, but it doesn't seem to be low enough.
> >
> > If I ping from 10.20.1.10 to 10.20.0.10, a "ping -s 1394" will get
> > through, but a "ping -s 1395" wont.  Reversing the pings (from 10.20.0.10
> > to 10.20.1.10), anything over 1394 will produce
> >
> >>From murdock.foddy.home (10.20.0.1) icmp_seq=1 Frag needed and DF set
> >> (mtu =
> >
> > 1422)
> > before the pings start getting through.  Interestingly, if I ssh to G2
> > then to NetB host outside the VPN (normal internet SSH), the transfers
> > never hang. So it seems to only be the vpn connections having the
> > problem.
>
> I just dealt with a similar mtu problem and saw many of the same
> symptoms you've reported.  If you look back in the list archive, then
> you can read my messages.
>
> To fix your problem, try the following.  On NetB, do
>
> 	$ tracepath NetA
>
> tracepath does path mtu discovery.  Suppose the pmtu value it reports is
> 1450.  Now, setup your tunnel from NetB to NetA.  Next, change the mtu
> value of eth0 like so:
>
> 	$ ifconfig eth0 mtu 1450
>
> (I think the command may be slightly different on Redhat/Mandriva.)
> Now, test the tunnel by trying to transfer a file using scp.
>
> -James
>
>

James,
Thanks for the reply.  I was hoping to not have to turn the remote firewall 
network's mtu down, but I may have to.  However your suggested command opened 
another interesting and possibly critical symptom.

tracepath from 10.20.0.10 (NetA) produces 
tracepath 10.20.1.10
 1:  starfire.foddy.home (10.20.0.10)                       0.184ms pmtu 1500
 1:  murdock.foddy.home (10.20.0.1)                         0.731ms
 1:  murdock.foddy.home (10.20.0.1)                         0.670ms
 2:  murdock.foddy.home (10.20.0.1)                         1.714ms pmtu 1422
 2:  windward.ia.foddy.home (10.20.1.1)                   134.293ms
 3:  pvr.ia.foddy.home (10.20.1.10)                       132.832ms reached
     Resume: pmtu 1422 hops 3 back 62


However tracepath from 10.20.1.10 (on NetB) only goes to the G2 gateway, 
before going to "no reply" until it quits.
tracepath 10.20.0.10
 1:  pvrfe.ia.foddy.home (10.20.1.11)                       0.254ms pmtu 1438
 1:  windward.ia.foddy.home (10.20.1.1)                     0.436ms
 2:  no reply
 3:  no reply
 4:  no reply

Never getting to NetA hosts; but the reverse works.  This sounds significant, 
is it??

Brian

From neil at JAMMConsulting.com  Thu Jan 15 16:43:28 2009
From: neil at JAMMConsulting.com (Neil Aggarwal)
Date: Thu, 15 Jan 2009 15:43:28 -0600
Subject: [Openswan Users] unexpected STRING [xauth] trying to set up
	connection to SonicWall
Message-ID: <B1F7984E99274361B2A98A326729A52D@neilhp>

Hello:

I am trying to follow the instructions on this page:
http://wiki.openswan.org/index.php/Openswan/SonicWall
to connect a CentOS 5 machine to the SonicWall at work.

I did: yum install openswan (I have the RPMForge repo
enabled) and everything seemed to install correctly.

I set up /etc/ipsec.d/sonicwall.conf with this content:
conn sonicwall
     left=1.2.3.4 (My Linux Machine's eth0 IP)
     leftsubnet=1.2.3.4/255.255.255.240
     leftid=@home
     leftxauthclient=yes
     right=5.6.7.8 (The SonicWall's external IP)
     rightsubnet=192.168.1.1/255.255.255.0
     rightxauthserver=yes
     rightid=@1234567 (Filled in the Unique Firewall Identifier.
				Do I need the '@' sign on this line?)
     keyingtries=0
     pfs=yes
     aggrmode=yes
     auto=add
     auth=esp
     esp=3des-md5-96
     ike=3des-md5-96
     authby=secret
     xauth=yes

I set up /etc/ipsec.d/sonicwall.secrets:
@home @1234567 : PSK "sharedSecet"

When I do: service ipsec start, I get this error:

can not load config '/etc/ipsec.conf': /etc/ipsec.d/sonicwall.conf:18:
syntax error, unexpected STRING [xauth]
Failed to parse config setup portion of ipsec.conf

Any ideas?

Thanks,
	Neil

--
Neil Aggarwal, (832)245-7314, www.JAMMConsulting.com
Eliminate junk email and reclaim your inbox.
Visit http://www.spammilter.com for details. 


From neil at JAMMConsulting.com  Thu Jan 15 17:21:02 2009
From: neil at JAMMConsulting.com (Neil Aggarwal)
Date: Thu, 15 Jan 2009 16:21:02 -0600
Subject: [Openswan Users] Informational Exchange message must be encrypted
	trying to connect to SonicWall
Message-ID: <16C1D6BAC8A248C49B1729D923A7AEE3@neilhp>

Hello:

I am trying to follow these instructions to connect
my linux machine at home to the SonicWall at work:
http://www.sonicwall.com/downloads/SonicOS_Enhanced_to_Openswan_Using_Aggres
sive_Mode_IKE_with_PreShared_key.pdf

I created /etc/ipsec.d/sonicwall.conf with this content:
conn sonicwall
     type=tunnel
     auto=add
     auth=esp
     pfs=no
     authby=secret
     keyingtries=0
     left=1.2.3.4 (My linux machine's eth0 IP)
     leftid=@home
     leftsubnet=1.2.3.4/28
     right=5.6.7.8 (The SonicWall's public IP)
     rightsubnet=192.168.1.0/24
     rightid=@001234567 (The SonicWall's Identifier)
     esp=3des-sha1
     keyexchange=ike
     ike=3des-sha1
     aggrmode=yes 

I created /etc/ipsec.d/sonicwall.secrets with this content:
@home @001234567 : PSK "sharedSecret"

When I do service ipsec start, I see these messages in the /var/log/secure:
Jan 15 16:14:18 jamm8 ipsec__plutorun: Starting Pluto subsystem...
Jan 15 16:14:18 jamm8 pluto[23823]: Starting Pluto (Openswan Version 2.6.14;
Vendor ID OEoSJUweaqAX) pid:23823
Jan 15 16:14:18 jamm8 pluto[23823]: Setting NAT-Traversal port-4500 floating
to on
Jan 15 16:14:18 jamm8 pluto[23823]:    port floating activation criteria
nat_t=1/port_float=1
Jan 15 16:14:18 jamm8 pluto[23823]:    including NAT-Traversal patch
(Version 0.6c)
Jan 15 16:14:18 jamm8 pluto[23823]: using /dev/urandom as source of random
entropy
Jan 15 16:14:18 jamm8 pluto[23823]: ike_alg_register_enc(): Activating
OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
Jan 15 16:14:18 jamm8 pluto[23823]: ike_alg_register_enc(): Activating
OAKLEY_TWOFISH_CBC: Ok (ret=0)
Jan 15 16:14:18 jamm8 pluto[23823]: ike_alg_register_enc(): Activating
OAKLEY_SERPENT_CBC: Ok (ret=0)
Jan 15 16:14:18 jamm8 pluto[23823]: ike_alg_register_enc(): Activating
OAKLEY_AES_CBC: Ok (ret=0)
Jan 15 16:14:18 jamm8 pluto[23823]: ike_alg_register_enc(): Activating
OAKLEY_BLOWFISH_CBC: Ok (ret=0)
Jan 15 16:14:18 jamm8 pluto[23823]: ike_alg_register_hash(): Activating
OAKLEY_SHA2_512: Ok (ret=0)
Jan 15 16:14:18 jamm8 pluto[23823]: ike_alg_register_hash(): Activating
OAKLEY_SHA2_256: Ok (ret=0)
Jan 15 16:14:18 jamm8 pluto[23823]: starting up 1 cryptographic helpers
Jan 15 16:14:18 jamm8 pluto[23823]: started helper pid=23835 (fd:7)
Jan 15 16:14:18 jamm8 pluto[23835]: using /dev/urandom as source of random
entropy
Jan 15 16:14:18 jamm8 pluto[23823]: Using Linux 2.6 IPsec interface code on
2.6.18-92.1.10.el5PAE (experimental code)
Jan 15 16:14:18 jamm8 pluto[23823]: ike_alg_register_enc(): WARNING: enc
alg=0 not found in constants.c:oakley_enc_names  
Jan 15 16:14:18 jamm8 pluto[23823]: ike_alg_register_enc(): Activating
<NULL>: Ok (ret=0)
Jan 15 16:14:18 jamm8 pluto[23823]: ike_alg_register_enc(): WARNING: enc
alg=0 not found in constants.c:oakley_enc_names  
Jan 15 16:14:18 jamm8 pluto[23823]: ike_alg_add(): ERROR: Algorithm already
exists
Jan 15 16:14:18 jamm8 pluto[23823]: ike_alg_register_enc(): Activating
<NULL>: FAILED (ret=-17)
Jan 15 16:14:18 jamm8 pluto[23823]: ike_alg_register_enc(): WARNING: enc
alg=0 not found in constants.c:oakley_enc_names  
Jan 15 16:14:18 jamm8 pluto[23823]: ike_alg_add(): ERROR: Algorithm already
exists
Jan 15 16:14:18 jamm8 pluto[23823]: ike_alg_register_enc(): Activating
<NULL>: FAILED (ret=-17)
Jan 15 16:14:18 jamm8 pluto[23823]: ike_alg_register_enc(): WARNING: enc
alg=0 not found in constants.c:oakley_enc_names  
Jan 15 16:14:18 jamm8 pluto[23823]: ike_alg_add(): ERROR: Algorithm already
exists
Jan 15 16:14:18 jamm8 pluto[23823]: ike_alg_register_enc(): Activating
<NULL>: FAILED (ret=-17)
Jan 15 16:14:18 jamm8 pluto[23823]: ike_alg_register_enc(): WARNING: enc
alg=0 not found in constants.c:oakley_enc_names  
Jan 15 16:14:18 jamm8 pluto[23823]: ike_alg_add(): ERROR: Algorithm already
exists
Jan 15 16:14:18 jamm8 pluto[23823]: ike_alg_register_enc(): Activating
<NULL>: FAILED (ret=-17)
Jan 15 16:14:18 jamm8 pluto[23823]: ike_alg_register_enc(): WARNING: enc
alg=0 not found in constants.c:oakley_enc_names  
Jan 15 16:14:18 jamm8 pluto[23823]: ike_alg_add(): ERROR: Algorithm already
exists
Jan 15 16:14:19 jamm8 pluto[23823]: ike_alg_register_enc(): Activating
<NULL>: FAILED (ret=-17)
Jan 15 16:14:19 jamm8 pluto[23823]: Could not change to directory
'/etc/ipsec.d/cacerts': /
Jan 15 16:14:19 jamm8 pluto[23823]: Could not change to directory
'/etc/ipsec.d/aacerts': /
Jan 15 16:14:19 jamm8 pluto[23823]: Could not change to directory
'/etc/ipsec.d/ocspcerts': /
Jan 15 16:14:19 jamm8 pluto[23823]: Could not change to directory
'/etc/ipsec.d/crls'
Jan 15 16:14:19 jamm8 pluto[23823]: Changing back to directory '/' failed -
(2 No such file or directory)
Jan 15 16:14:19 jamm8 pluto[23823]: Changing back to directory '/' failed -
(2 No such file or directory)
Jan 15 16:14:19 jamm8 pluto[23823]: added connection description "sonicwall"
Jan 15 16:14:19 jamm8 pluto[23823]: listening for IKE messages
Jan 15 16:14:19 jamm8 pluto[23823]: adding interface eth0/eth0
206.123.70.61:500
Jan 15 16:14:19 jamm8 pluto[23823]: adding interface eth0/eth0
206.123.70.61:4500
Jan 15 16:14:19 jamm8 pluto[23823]: adding interface lo/lo 127.0.0.1:500
Jan 15 16:14:19 jamm8 pluto[23823]: adding interface lo/lo 127.0.0.1:4500
Jan 15 16:14:19 jamm8 pluto[23823]: adding interface lo/lo ::1:500
Jan 15 16:14:19 jamm8 pluto[23823]: loading secrets from
"/etc/ipsec.secrets"
Jan 15 16:14:19 jamm8 pluto[23823]: loading secrets from
"/etc/ipsec.d/sonicwall.secrets"

Should I be concerned about the lack of certs directories?
I search Google, but it seems other people posted their logs with those
entries
and they did not seem to imply it was a problem so I decided to continue.

When I do ipsec auto --add sonicwall, I get these messages:

Jan 15 16:16:53 jamm8 pluto[23823]: "sonicwall": deleting connection
Jan 15 16:16:53 jamm8 pluto[23823]: added connection description "sonicwall"

So, I guess it took down the connection from last time and added it back
again.

Now, when I do ipsec auto --up sonicwall, I get these messages:

Jan 15 16:18:13 jamm8 pluto[23823]: "sonicwall" #1: multiple transforms were
set in aggressive mode. Only first one used.
Jan 15 16:18:13 jamm8 pluto[23823]: "sonicwall" #1: transform (5,2,2,0)
ignored.
Jan 15 16:18:13 jamm8 pluto[23823]: "sonicwall" #1: initiating Aggressive
Mode #1, connection "sonicwall"
Jan 15 16:18:13 jamm8 pluto[23823]: "sonicwall" #1: multiple transforms were
set in aggressive mode. Only first one used.
Jan 15 16:18:13 jamm8 pluto[23823]: "sonicwall" #1: transform (5,2,2,0)
ignored.
Jan 15 16:18:13 jamm8 pluto[23823]: | setting sec: 1
Jan 15 16:18:13 jamm8 pluto[23823]: "sonicwall" #1: Informational Exchange
message must be encrypted

I don't know what these messages mean.

Any help?

Thanks,
  Neil


--
Neil Aggarwal, (832)245-7314, www.JAMMConsulting.com
Eliminate junk email and reclaim your inbox.
Visit http://www.spammilter.com for details. 



From bach at mbconnectline.de  Wed Jan 14 08:35:52 2009
From: bach at mbconnectline.de (Bach Johannes MB Connect Line GmbH)
Date: Wed, 14 Jan 2009 14:35:52 +0100
Subject: [Openswan Users] point-to-point connection
Message-ID: <47253A408E5A49C3B777513493121AAE@STATION63WSXP12>

Hello list,
 
I have a problem with creating a connection as shown as follows:
 
host1.1 -------------------
-------------------------- host1.2  
                              |
|
                              |---- UBUNTU-VPN-SERVER -----|
                              |
|
host2.1 -------------------
-------------------------- host2.2
 

I want to configure an UBUNTU-VPN-Server (with only one network-hardware
---> i use virtual interfaces/lans) so that host1.1 can log in via vpn
and host 1.2 can log in via vpn.
Both hosts should meat each other in the Servers virtual LAN1. Host2.1
and host 2.2 should meat each other in the virtual LAN2. The 1.x hosts
should not be able to ping the 2.x hosts. 

I wanted to solve that probleme with interface-forwarding. when host1.1
logs in he gets ipsec0 when host1.2 logs in he gets ipsec1 BUT there is
only one interface for both connections.and neither host1.1 nor host1.2
are getting an ip from the vpn-server. there are only the entries in the
routing-table. But what if the subnet of host1.1 and host 1.2 have the
same netadress? there will be adressconflicts in the routing-table....
Thats because I wanted to solve that problem via interface-forwarding
BUT as already mentioned ipsec with openswan does not build extra
interfaces for each connection.

Has anybody who understood what i want (sorry for my bad english.. :) an
idea how reach the assembly above?

 

thanx for ya help,

with best regards from germany bavaria (OKTOBERFEST),

 

joe

 

Technikum:

 

MB connect line 

Fernwartungssysteme GmbH

Winnettener Str. 5

D-91550 Dinkelsb?hl

Tel.: 0049 9851 582529 84

Fax: 0049 9851 582529 99

 

 

Stammhaus:

 

MB connect line

Fernwartungssysteme GmbH

Raiffeisenstrasse 4

D-74360 Ilsfeld

Fon: 0049 7062 9178788

Fax: 0049 7062 9178792

 

 

Sitz der Gesellschaft: D-74360 Ilsfeld

Ust. Id. Nummer: DE185259018

Registergericht: Stuttgart Germany HRB106261

Gesch?ftsf?hrer: Werner Belle, Siegfried M?ller

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090114/571013b3/attachment.html 

From muir.james.a at gmail.com  Fri Jan 16 09:42:30 2009
From: muir.james.a at gmail.com (James Muir)
Date: Fri, 16 Jan 2009 09:42:30 -0500
Subject: [Openswan Users] unexpected STRING [xauth] trying to set up
 connection to SonicWall
In-Reply-To: <B1F7984E99274361B2A98A326729A52D@neilhp>
References: <B1F7984E99274361B2A98A326729A52D@neilhp>
Message-ID: <49709CD6.4080406@gmail.com>

Neil Aggarwal wrote:

> When I do: service ipsec start, I get this error:
> 
> can not load config '/etc/ipsec.conf': /etc/ipsec.d/sonicwall.conf:18:
> syntax error, unexpected STRING [xauth]
> Failed to parse config setup portion of ipsec.conf
> 
> Any ideas?

openswan does not like the line "xauth=yes" in sonicwall.conf (i.e. it 
does not recognize "xauth=yes" as a valid config option).

Which version of openswan are you using?  Some of the configuration 
options have changed.

I have openswan 2.6.19 configured to connect to a Sonicwall.  I posted 
details on this a few weeks ago:

http://lists.openswan.org/pipermail/users/2008-December/015923.html

Try the config files posted there.

-James



From muir.james.a at gmail.com  Fri Jan 16 10:02:10 2009
From: muir.james.a at gmail.com (James Muir)
Date: Fri, 16 Jan 2009 10:02:10 -0500
Subject: [Openswan Users] Nasty MTU problem - Please Help
In-Reply-To: <200901142151.54012.bfoddy@visi.com>
References: <200901132242.29608.bfoddy@visi.com> <496E05C6.6070501@gmail.com>
	<200901142151.54012.bfoddy@visi.com>
Message-ID: <4970A172.3020805@gmail.com>

Brian Foddy wrote:
> James,
> Thanks for the reply.  I was hoping to not have to turn the remote firewall 
> network's mtu down, but I may have to.  However your suggested command opened 
> another interesting and possibly critical symptom.
> 
> tracepath from 10.20.0.10 (NetA) produces 
> tracepath 10.20.1.10
>  1:  starfire.foddy.home (10.20.0.10)                       0.184ms pmtu 1500
>  1:  murdock.foddy.home (10.20.0.1)                         0.731ms
>  1:  murdock.foddy.home (10.20.0.1)                         0.670ms
>  2:  murdock.foddy.home (10.20.0.1)                         1.714ms pmtu 1422
>  2:  windward.ia.foddy.home (10.20.1.1)                   134.293ms
>  3:  pvr.ia.foddy.home (10.20.1.10)                       132.832ms reached
>      Resume: pmtu 1422 hops 3 back 62
> 
> 
> However tracepath from 10.20.1.10 (on NetB) only goes to the G2 gateway, 
> before going to "no reply" until it quits.
> tracepath 10.20.0.10
>  1:  pvrfe.ia.foddy.home (10.20.1.11)                       0.254ms pmtu 1438
>  1:  windward.ia.foddy.home (10.20.1.1)                     0.436ms
>  2:  no reply
>  3:  no reply
>  4:  no reply
> 
> Never getting to NetA hosts; but the reverse works.  This sounds significant, 
> is it??

I don't know if this is significant.  Assuming that the path NetB --> 
NetA is the reverse of NetA --> NetB, it looks like murdock.foddy.home 
does not want to respond to tracepath queries orginating from NetB. 
There are lots of hosts that won't respond to tracepath queries, which 
are sent using udp.  My guess is that this isn't a big deal.

On NetB, set up your tunnel to NetA; next, set the mtu value of eth0 on 
NetB to 1422.  I bet this will fix your icmp fragmentation problem.

-James

From arrow.jianqing at gmail.com  Fri Jan 16 11:45:14 2009
From: arrow.jianqing at gmail.com (Jianqing Zhang)
Date: Fri, 16 Jan 2009 10:45:14 -0600
Subject: [Openswan Users] SPI quesion
Message-ID: <8a38e1330901160845td2f7a91h654100ca5bdca436@mail.gmail.com>

When I configured SPD and SAD manually, I find that SPIs for the
outgoing packets could be same but those for incoming packets must be
unique. Why?

From charlessimon at hotmail.com  Fri Jan 16 13:32:29 2009
From: charlessimon at hotmail.com (simon charles)
Date: Fri, 16 Jan 2009 13:32:29 -0500
Subject: [Openswan Users] point-to-point connection
In-Reply-To: <47253A408E5A49C3B777513493121AAE@STATION63WSXP12>
References: <47253A408E5A49C3B777513493121AAE@STATION63WSXP12>
Message-ID: <BLU108-W13329AD3A43B2D6FAAAB4CDBD40@phx.gbl>


Hi !
    If it is a point-to-point ( host-to-host ) vpn tunnel then your rightsubnets are going to be a /32 and hence unique for host1.1 and host1.2 pair and host2.1 and 2.2 pair.
Ex:
host1.1
left={host1.1 public ip addr }
leftsubnet=1.1.1.1/32
right={ubuntu public ip addr }
rightsubnet=1.1.1.2/32

host1.2
left={host1.2 public ip addr }
leftsubnet=1.1.1.2/32
right={ubuntu public ip addr }
rightsubnet=1.1.1.1/32

ubuntu
conn host1.1
left={ubuntu public ip addr }
leftsubnet=1.1.1.2/32
right={host1.1 public ip addr }
rightsubnet=1.1.1.1/32

conn host1.2
left={ubuntu public ip addr }
leftsubnet=1.1.1.1/32
right={host1.2 public ip addr }
rightsubnet=1.1.1.2/32

This way you will have
1.1.1.1/32<-->host1.1<-->ubuntu<-->host1.2<-->1.1.1.2/32
 
  Hope that helps.

- Simon Charles - 




From: bach at mbconnectline.de
To: users at lists.openswan.org
Date: Wed, 14 Jan 2009 14:35:52 +0100
Subject: [Openswan Users] point-to-point connection






Nachricht



Hello 
list,
 
I have a problem 
with creating a connection as shown as follows:
 
host1.1 
-------------------                                                          
-------------------------- host1.2  
                              
|                                                         |
                              |---- 
UBUNTU-VPN-SERVER -----|
                              
|                                                         
|
host2.1 
-------------------   
                                                       
-------------------------- host2.2
 

I want 
to configure an UBUNTU-VPN-Server (with only one network-hardware ---> i use 
virtual interfaces/lans) so that host1.1 can log in via vpn and host 1.2 can log 
in via vpn.
Both hosts should meat each other in the Servers virtual LAN1. 
Host2.1 and host 2.2 should meat each other in the virtual LAN2. The 1.x hosts 
should not be able to ping the 2.x hosts. 
I 
wanted to solve that probleme with interface-forwarding. when host1.1 logs in he 
gets ipsec0 when host1.2 logs in he gets ipsec1 BUT there is only one interface 
for both connections.and neither host1.1 nor host1.2 are getting an ip from the 
vpn-server. there are only the entries in the routing-table. But what if the 
subnet of host1.1 and host 1.2 have the same netadress? there will be 
adressconflicts in the routing-table.... Thats because I wanted to solve that 
problem via interface-forwarding BUT as already mentioned ipsec with openswan 
does not build extra interfaces for each connection.
Has 
anybody who understood what i want (sorry for my bad english.. :) an idea how 
reach the assembly 
above?
 
thanx 
for ya help,
with 
best regards from germany bavaria (OKTOBERFEST),
 
joe
 
Technikum:
 
MB connect line 
Fernwartungssysteme GmbH
Winnettener Str. 5
D-91550 Dinkelsb?hl
Tel.: 0049 9851 582529 84
Fax: 0049 9851 582529 99
 
 
Stammhaus:
 
MB connect line
Fernwartungssysteme GmbH
Raiffeisenstrasse 4
D-74360 Ilsfeld
Fon: 0049 7062 9178788
Fax: 0049 7062 9178792
 
 
Sitz der Gesellschaft: D-74360 Ilsfeld
Ust. Id. Nummer: DE185259018
Registergericht: Stuttgart Germany HRB106261
Gesch?ftsf?hrer: Werner Belle, Siegfried M?ller
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090116/1f9ca7dd/attachment.html 

From satish at eventmonitor.com  Fri Jan 16 16:23:04 2009
From: satish at eventmonitor.com (Satish Reddy)
Date: Fri, 16 Jan 2009 16:23:04 -0500
Subject: [Openswan Users] VPN connects then disconnects after 1.1 minutes
Message-ID: <200901162124.n0GLO2NM032371@rs35.luxsci.com>

Hi,

            I had a working VPN server before I updated. I had openswan
2.4.4 and pppd 2.4.2 with kernel 2.6.11-gentoo-r5. I then updated to latest
versions openswan 2.4.13-r2, l2tpd 0.70_pre20031121 and pppd 2.4.4 on gentoo
with kernel 2.6.11-gentoo-r5. 

 

After the upgrades I am not able to communicate through tunnel and it closes
the tunnel.

Tunnel establishes but no traffic flows from the VPN server to the VPN
Client Gateway. I am seeing ESP packets coming from VPN Client's Gateway to
VPN Server. And after 1.1 minutes pppd terminates connection.

 

Here are the logs I see just before terminating connection.

 

Jan 16 16:04:49 [pluto] "l2tp"[4] 66.92.79.15 #4: transition from state
STATE_QUICK_R1 to state STATE_QUICK_R2

Jan 16 16:04:49 [pluto] "l2tp"[4] 66.92.79.15 #4: STATE_QUICK_R2: IPsec SA
established {ESP=>0xb56abcff <0x332a9303 xfrm=3DES_0-HMAC_MD5
NATD=66.92.79.15:4500 DPD=none}

Jan 16 16:04:50 [l2tpd] control_finish: Connection established to
66.92.79.15, 1701.  Local: 28388, Remote: 9.  LNS session is 'default'_

Jan 16 16:04:50 [l2tpd] control_finish: Call established with 66.92.79.15,
Local: 16272, Remote: 1, Serial: 0_

Jan 16 16:04:50 [pppd] pppd 2.4.4 started by root, uid 0

Jan 16 16:04:50 [pppd] Using interface ppp0

Jan 16 16:04:50 [pppd] Connect: ppp0 <--> /dev/ttyp0

Jan 16 16:04:50 [pppd] Unsupported protocol 'Compression Control Protocol'
(0x80fd) received

Jan 16 16:04:50 [pppd] found interface eth0 for proxy arp

Jan 16 16:04:50 [pppd] local  IP address 10.0.0.200

Jan 16 16:04:50 [pppd] remote IP address 10.0.0.201

Jan 16 16:05:01 [cron] (root) CMD (/bin/run-parts /etc/cron.mrtg 1>
/dev/null)

Jan 16 16:05:55 [pppd] Terminating on signal 15

Jan 16 16:05:55 [pppd] Modem hangup

Jan 16 16:05:55 [pppd] Connect time 1.1 minutes.

Jan 16 16:05:55 [pppd] Sent 6324 bytes, received 22985 bytes.

Jan 16 16:05:55 [pppd] Connection terminated.

Jan 16 16:05:56 [pppd] Exit.

Jan 16 16:05:56 [l2tpd] call_close : Connection 9 closed to 66.92.79.15,
port 1701 (Timeout)_

 

I really appreciate your feedback.

 

Thanks

Satish

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090116/08d29010/attachment.html 

From igor.widlinski at eigendev.com  Fri Jan 16 17:15:32 2009
From: igor.widlinski at eigendev.com (Igor Widlinski)
Date: Fri, 16 Jan 2009 14:15:32 -0800
Subject: [Openswan Users] PAYLOAD_MALFORMED
In-Reply-To: <Pine.LNX.4.64.0812202140330.11540@fedex.thefeds.net>
References: <6dc38d6f33dee312455dbc6954f07c29@email.freenet.de>	<Pine.LNX.4.64.0812191413120.6748@newtla.xelerance.com>
	<Pine.LNX.4.64.0812202140330.11540@fedex.thefeds.net>
Message-ID: <49710704.1050800@eigendev.com>

Hey Guys,

I am having hell of a time coming up with a fail over mechanism for our vpn machine. I've done quite a bit of research with no use. The set up is pretty simple. Vpn client should connect to the primary server, if that one is down, it should connect to secondary server. And roll back to primary when that one comes back online.
Only one server is up at any time. Subnets behind the servers are the same.

I've tried to mock around with updown scrip but it just hangs, looks likey you can't execute "ipsec auto ' commands in that script....

Anything will help.

Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090116/774473ab/attachment-0001.html 

From neil at JAMMConsulting.com  Fri Jan 16 18:12:39 2009
From: neil at JAMMConsulting.com (Neil Aggarwal)
Date: Fri, 16 Jan 2009 17:12:39 -0600
Subject: [Openswan Users] unexpected STRING [xauth] trying to set up
	connection to SonicWall
In-Reply-To: <49709CD6.4080406@gmail.com>
References: <B1F7984E99274361B2A98A326729A52D@neilhp>
	<49709CD6.4080406@gmail.com>
Message-ID: <1A1DBE364D744CB1866947C40CF1CEED@neilhp>

James:

Based on your post, I changed my config files to:

sonicwall.conf:
conn sonicwall
     type=tunnel
     auto=add
     auth=esp
     pfs=no
     authby=secret
     keyingtries=0
     left=1.2.3.4
     leftid=1.2.3.4
     leftsubnet=1.2.3.4/28
     leftxauthclient=yes
     right=5.6.7.8
     rightsubnet=192.168.1.0/24
     rightid=@00ABCDE
     rightxauthserver=yes
     esp=3des-sha1
     keyexchange=ike
     ike=3des-sha1-modp1024
     aggrmode=yes

sonicwall.secrets:

1.2.3.4 @00ABCDE : PSK "myPass"

I still get this output:

Jan 16 17:08:18 jamm8 pluto[29365]: "sonicwall" #1: initiating Aggressive
Mode #1, connection "sonicwall"
Jan 16 17:08:18 jamm8 pluto[29365]: | setting sec: 1
Jan 16 17:08:18 jamm8 pluto[29365]: "sonicwall" #1: Informational Exchange
message must be encrypted

Any idea?

Thanks,
	Neil

--
Neil Aggarwal, (832)245-7314, www.JAMMConsulting.com
Eliminate junk email and reclaim your inbox.
Visit http://www.spammilter.com for details.  

> I have openswan 2.6.19 configured to connect to a Sonicwall.  
> I posted 
> details on this a few weeks ago:
> 
> http://lists.openswan.org/pipermail/users/2008-December/015923.html
> 
> Try the config files posted there.


From igor.widlinski at eigendev.com  Fri Jan 16 18:53:15 2009
From: igor.widlinski at eigendev.com (Igor Widlinski)
Date: Fri, 16 Jan 2009 15:53:15 -0800
Subject: [Openswan Users] PAYLOAD_MALFORMED
In-Reply-To: <49710704.1050800@eigendev.com>
References: <6dc38d6f33dee312455dbc6954f07c29@email.freenet.de>	<Pine.LNX.4.64.0812191413120.6748@newtla.xelerance.com>	<Pine.LNX.4.64.0812202140330.11540@fedex.thefeds.net>
	<49710704.1050800@eigendev.com>
Message-ID: <49711DEB.5050709@eigendev.com>

Ooops, forgot to change subject...

Igor Widlinski wrote:
>  Hey Guys,
>
> I am having hell of a time coming up with a fail over mechanism for our vpn machine. I've done quite a bit of research with no use. The set up is pretty simple. Vpn client should connect to the primary server, if that one is down, it should connect to secondary server. And roll back to primary when that one comes back online.
> Only one server is up at any time. Subnets behind the servers are the same.
>
> I've tried to mock around with updown scrip but it just hangs, looks likey you can't execute "ipsec auto ' commands in that script....
>
> Anything will help.
>
> Thanks
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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=283155
>   


-- 
Igor Widlinski
Systems Administrator
Eigen Development Ltd.
#300 - 1807 West 10th Avenue
Vancouver BC, V6J 2A9

t. 604.736.1066 
f. 604.736.5669
e. igor.widlinski at eigendev.com

*************************************************

ATTENTION
The information in this e-mail and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). It must not be disclosed to any person without our authority. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorized to and must not disclose, copy, distribute, or retain this message or any part of it.

*************************************************


From igor.widlinski at eigendev.com  Fri Jan 16 18:53:55 2009
From: igor.widlinski at eigendev.com (Igor Widlinski)
Date: Fri, 16 Jan 2009 15:53:55 -0800
Subject: [Openswan Users] VPN Failover
In-Reply-To: <1A1DBE364D744CB1866947C40CF1CEED@neilhp>
References: <B1F7984E99274361B2A98A326729A52D@neilhp>	<49709CD6.4080406@gmail.com>
	<1A1DBE364D744CB1866947C40CF1CEED@neilhp>
Message-ID: <49711E13.2050700@eigendev.com>

 Hey Guys,

I am having hell of a time coming up with a fail over mechanism for our vpn machine.
 I've done quite a bit of research with no use. The set up is pretty simple. 
Vpn client should connect to the primary server, if that one is down, it should connect to secondary server. 
And roll back to primary when that one comes back online.
Only one server is up at any time. Subnets behind the servers are the same.

I've tried to mock around with updown scrip but it just hangs, looks likey you can't execute "ipsec auto ' commands in that script....

Anything will help.

Thanks



From joshihirenn at gmail.com  Sat Jan 17 02:46:17 2009
From: joshihirenn at gmail.com (hiren joshi)
Date: Sat, 17 Jan 2009 13:16:17 +0530
Subject: [Openswan Users] VPN connects then disconnects after 1.1 minutes
In-Reply-To: <200901162124.n0GLO2NM032371@rs35.luxsci.com>
References: <200901162124.n0GLO2NM032371@rs35.luxsci.com>
Message-ID: <29820bf40901162346j3e63e3edy4fa9307094c6c842@mail.gmail.com>

[Sorry for replying in Dev list. Resending it to Users list.]

Have a look at: http://bugs.xelerance.com/view.php?id=1007

Regards,
hiren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090117/0c201b83/attachment.html 

From alfonso.viso at selftrade.com  Sat Jan 17 07:07:54 2009
From: alfonso.viso at selftrade.com (Alfonso Viso)
Date: Sat, 17 Jan 2009 13:07:54 +0100
Subject: [Openswan Users] vpn connection
Message-ID: <515251629957C542816307570516B86D1EEFDE@BSRSPCLE001.boursorama.fr>

hi all,
 
i can set openswan between Pix Cisco and Linux Server FC4. I use NETKEY version and PSK. 
the remote site can connect to our intranet, and i see that the tunnel is up and the traffic is coming throught the tunnel. The problem is when i try to ping the other side, the traffic from local side don't go throught tunnel, i mean  the traffic generated by our side, for example. i only see traffic response by our side.
Any body could be help us?
thanks in advanced and sorry for my english.
 
regards
Alfonso



___________________________________

Ce message contient des informations confidentielles ou appartenant ?
Boursorama et est ?tabli ? l'intention exclusive de ses destinataires. Toute
divulgation, utilisation, diffusion ou reproduction (totale ou partielle) de ce
message, ou des informations qu'il contient, doit ?tre pr?alablement
autoris?e. Tout message ?lectronique est susceptible d'alt?ration et son
int?grit? ne peut ?tre assur?e. Boursorama d?cline toute responsabilit? au
titre de ce message s'il a ?t? modifi? ou falsifi?. Si vous n'?tes pas
destinataire de ce message, merci de le d?truire imm?diatement et d'avertir
l'exp?diteur de l'erreur de distribution et de la destruction du message.
___________________________________

This e-mail contains confidential information or information belonging to
Boursorama and is intended solely for the addressees. The unauthorised
disclosure, use, dissemination or copying (either whole or partial) of this
e-mail, or any information it contains, is prohibited. E-mails are susceptible
to alteration and their integrity cannot be guaranteed. Boursorama shall not be
liable for this e-mail if modified or falsified. If you are not the intended
recipient of this e-mail, please delete it immediately from your system and
notify the sender of the wrong delivery and the mail deletion.
___________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090117/d3161475/attachment.html 

From petrik.salovaara at solotes.fi  Sat Jan 17 08:25:05 2009
From: petrik.salovaara at solotes.fi (Petrik Salovaara)
Date: Sat, 17 Jan 2009 15:25:05 +0200
Subject: [Openswan Users] Netgear FVS318, PAYLOAD_MALFORMED
Message-ID: <4971DC31.3080902@solotes.fi>

Greetings,

I am trying to get a VPN connection between openswan and Netgear FVS318 using PSK.
My openswan linux box currently works fine with another openswan linux box and
several roadwarriors using certificates. I have followed instructions on
http://wiki.openswan.org/index.php/Openswan/NetGearFVS318 without success.

Bottom line is that openswan reports "PAYLOAD_MALFORMED" in STATE_MAIN_I3
Any help is appreciated.

Here's the config in openswan:
> 
> # /etc/ipsec.conf - FreeS/WAN IPsec configuration file
> config setup
>         #plutodebug=all
>         #plutoload=%search
>         #plutostart=%search
>         interfaces=%defaultroute
>         klipsdebug=none
>         nat_traversal=yes
>         plutodebug=none
>         strictcrlpolicy=no
>         uniqueids=yes
>         virtual_private=%v4:192.168.239.0/24
> 
> conn %default
>         auto=add
>         auth=esp
>         compress=no
>         authby=rsasig
>         keyingtries=1
>         left=83.145.201.2
>         leftcert=/etc/ipsec.d/certs/www.solotes.fi_crt.pem
>         leftid="C=FI, O=Solotes Oy, CN=www.solotes.fi"
>         leftnexthop=83.145.201.254
>         leftrsasigkey=%cert
>         leftsubnet=192.168.240.0/24
> 
> conn fvs318
>         type=tunnel
>         left=83.145.201.2
>         leftsubnet=192.168.240.0/24
>         leftnexthop=83.145.201.254
>         leftid="83.145.201.2"
>         right=83.145.204.59
>         rightsubnet=192.168.1.0/24
>         rightnexthop=83.145.204.254
>         rightid="83.145.204.59"
>         ikelifetime=1440m
>         keylife=480m
>         pfs=yes
>         keyexchange=ike
>         authby=secret
>         auto=start
> 
> conn gw-oskari
>         right=%any
>         rightcert=/etc/ipsec.d/certs/gw.osku.solotes.fi_crt.pem
>         rightid="C=FI, O=Solotes Oy, CN=gw.osku.solotes.fi"
>         rightrsasigkey=%cert
>         rightsubnet=192.168.2.0/24
>         type=tunnel
> 
> conn jukka
>         right=%any
>         rightcert=/etc/ipsec.d/certs/jukka.rw.solotes.fi_crt.pem
>         rightid="C=FI, O=Solotes Oy, CN=jukka.rw.solotes.fi"
>         rightrsasigkey=%cert
>         rightsubnet=vhost:%priv
>         type=tunnel
> 
> conn trikki
>         right=%any
>         rightcert=/etc/ipsec.d/certs/trikki.rw.solotes.fi_crt.pem
>         rightid="C=FI, O=Solotes Oy, CN=trikki.rw.solotes.fi"
>         rightrsasigkey=%cert
>         rightsubnet=vhost:%priv
>         type=tunnel


Netgear box is configured as follows:
> http://www.solotes.fi/private/trikki/netgear/fvs318_ike_policy.gif
> http://www.solotes.fi/private/trikki/netgear/fvs318_vpn_auto_policy.gif


This is what goes into log/secure when starting ipsec:
> Jan 14 17:32:34 www ipsec__plutorun: Starting Pluto subsystem...
> Jan 14 17:32:34 www pluto[21402]: Starting Pluto (Openswan Version 2.4.7 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR; Vendor ID OEZ~BaB]r\134p_)
> Jan 14 17:32:34 www pluto[21402]: Setting NAT-Traversal port-4500 floating to on
> Jan 14 17:32:34 www pluto[21402]:    port floating activation criteria nat_t=1/port_fload=1
> Jan 14 17:32:34 www pluto[21402]:   including NAT-Traversal patch (Version 0.6c)
> Jan 14 17:32:34 www pluto[21402]: ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok (ret=0)
> Jan 14 17:32:34 www pluto[21402]: starting up 1 cryptographic helpers
> Jan 14 17:32:34 www pluto[21402]: started helper pid=21406 (fd:6)
> Jan 14 17:32:34 www pluto[21402]: Using NETKEY IPsec interface code on 2.6.18-53.1.19.el5
> Jan 14 17:32:35 www pluto[21402]: Changing to directory '/etc/ipsec.d/cacerts'
> Jan 14 17:32:35 www pluto[21402]:   loaded CA cert file 'solotes-2007_cacert.pem' (1675 bytes)
> Jan 14 17:32:35 www pluto[21402]: Could not change to directory '/etc/ipsec.d/aacerts'
> Jan 14 17:32:35 www pluto[21402]: Could not change to directory '/etc/ipsec.d/ocspcerts'
> Jan 14 17:32:35 www pluto[21402]: Could not change to directory '/etc/ipsec.d/crls'
> Jan 14 17:32:35 www pluto[21402]:   loaded host cert file '/etc/ipsec.d/certs/www.solotes.fi_crt.pem' (4304 bytes)
> Jan 14 17:32:35 www pluto[21402]:   loaded host cert file '/etc/ipsec.d/certs/trikki.rw.solotes.fi_crt.pem' (4318 bytes)
> Jan 14 17:32:35 www pluto[21402]: added connection description "trikki"
> Jan 14 17:32:35 www pluto[21402]:   loaded host cert file '/etc/ipsec.d/certs/www.solotes.fi_crt.pem' (4304 bytes)
> Jan 14 17:32:35 www pluto[21402]:   loaded host cert file '/etc/ipsec.d/certs/gw.osku.solotes.fi_crt.pem' (4312 bytes)
> Jan 14 17:32:35 www pluto[21402]: added connection description "gw-oskari"
> Jan 14 17:32:35 www pluto[21402]:   loaded host cert file '/etc/ipsec.d/certs/www.solotes.fi_crt.pem' (4304 bytes)
> Jan 14 17:32:35 www pluto[21402]:   loaded host cert file '/etc/ipsec.d/certs/jukka.rw.solotes.fi_crt.pem' (4317 bytes)
> Jan 14 17:32:35 www pluto[21402]: added connection description "jukka"
> Jan 14 17:32:35 www pluto[21402]:   loaded host cert file '/etc/ipsec.d/certs/www.solotes.fi_crt.pem' (4304 bytes)
> Jan 14 17:32:35 www pluto[21402]:   no subjectAltName matches ID '83.145.201.2', replaced by subject DN
> Jan 14 17:32:35 www pluto[21402]: added connection description "fvs318"
> Jan 14 17:32:35 www pluto[21402]: listening for IKE messages
> Jan 14 17:32:35 www pluto[21402]: adding interface virbr0/virbr0 192.168.122.1:500
> Jan 14 17:32:35 www pluto[21402]: adding interface virbr0/virbr0 192.168.122.1:4500
> Jan 14 17:32:35 www pluto[21402]: adding interface eth1/eth1 192.168.240.254:500
> Jan 14 17:32:35 www pluto[21402]: adding interface eth1/eth1 192.168.240.254:4500
> Jan 14 17:32:35 www pluto[21402]: adding interface eth0/eth0 83.145.201.2:500
> Jan 14 17:32:35 www pluto[21402]: adding interface eth0/eth0 83.145.201.2:4500
> Jan 14 17:32:35 www pluto[21402]: adding interface eth2/eth2 192.168.240.253:500
> Jan 14 17:32:35 www pluto[21402]: adding interface eth2/eth2 192.168.240.253:4500
> Jan 14 17:32:35 www pluto[21402]: adding interface lo/lo 127.0.0.1:500
> Jan 14 17:32:35 www pluto[21402]: adding interface lo/lo 127.0.0.1:4500
> Jan 14 17:32:35 www pluto[21402]: adding interface lo/lo ::1:500
> Jan 14 17:32:35 www pluto[21402]: loading secrets from "/etc/ipsec.secrets"
> Jan 14 17:32:35 www pluto[21402]:   loaded private key file '/etc/ipsec.d/private/gw.osku.solotes.fi_key.pem' (887 bytes)
> Jan 14 17:32:35 www pluto[21402]:   loaded private key file '/etc/ipsec.d/private/solotes-2007_cakey.pem' (1675 bytes)
> Jan 14 17:32:35 www pluto[21402]:   loaded private key file '/etc/ipsec.d/private/www.solotes.fi_key.pem' (887 bytes)
> Jan 14 17:32:35 www pluto[21402]: "fvs318" #1: initiating Main Mode
> Jan 14 17:32:35 www pluto[21402]: "fvs318" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
> Jan 14 17:32:35 www pluto[21402]: "fvs318" #1: STATE_MAIN_I2: sent MI2, expecting MR2
> Jan 14 17:32:35 www pluto[21402]: packet from 89.27.54.216:500: phase 1 message is part of an unknown exchange
> Jan 14 17:32:36 www pluto[21402]: "fvs318" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
> Jan 14 17:32:36 www pluto[21402]: "fvs318" #1: STATE_MAIN_I3: sent MI3, expecting MR3
> Jan 14 17:32:38 www pluto[21402]: "fvs318" #1: byte 2 of ISAKMP Hash Payload must be zero, but is not
> Jan 14 17:32:38 www pluto[21402]: "fvs318" #1: malformed payload in packet
> Jan 14 17:32:38 www pluto[21402]: | payload malformed after IV
> Jan 14 17:32:38 www pluto[21402]: |   b8 6f 9b ad  f4 a6 c1 21
> Jan 14 17:32:38 www pluto[21402]: "fvs318" #1: sending notification PAYLOAD_MALFORMED to 83.145.204.59:500
> Jan 14 17:32:55 www pluto[21402]: packet from 89.27.54.216:500: phase 1 message is part of an unknown exchange
> Jan 14 17:33:46 www pluto[21402]: "fvs318" #1: max number of retransmissions (2) reached STATE_MAIN_I3.  Possible authentication failure: no acceptable response to our first encrypted message

When turning on plutodebug=all, log shows following:
> http://www.solotes.fi/private/trikki/netgear/log_debug_all.txt

Petrik Salovaara
mailto:petrik.salovaara at solotes.fi





From tis at foobar.fi  Sat Jan 17 13:46:28 2009
From: tis at foobar.fi (Tuomo Soini)
Date: Sat, 17 Jan 2009 20:46:28 +0200
Subject: [Openswan Users] Netgear FVS318, PAYLOAD_MALFORMED
In-Reply-To: <4971DC31.3080902@solotes.fi>
References: <4971DC31.3080902@solotes.fi>
Message-ID: <49722784.50003@foobar.fi>

Petrik Salovaara wrote:
> Greetings,
> 
> I am trying to get a VPN connection between openswan and Netgear FVS318 using PSK.
> My openswan linux box currently works fine with another openswan linux box and
> several roadwarriors using certificates. I have followed instructions on
> http://wiki.openswan.org/index.php/Openswan/NetGearFVS318 without success.

> Here's the config in openswan:
>> # /etc/ipsec.conf - FreeS/WAN IPsec configuration file
>> config setup
>>         #plutodebug=all
>>         #plutoload=%search
>>         #plutostart=%search
>>         interfaces=%defaultroute
>>         klipsdebug=none
>>         nat_traversal=yes
>>         plutodebug=none
>>         strictcrlpolicy=no
>>         uniqueids=yes
>>         virtual_private=%v4:192.168.239.0/24
>>
>> conn %default
>>         auto=add
>>         auth=esp
>>         compress=no
>>         authby=rsasig
>>         keyingtries=1
>>         left=83.145.201.2
>>         leftcert=/etc/ipsec.d/certs/www.solotes.fi_crt.pem
>>         leftid="C=FI, O=Solotes Oy, CN=www.solotes.fi"
>>         leftnexthop=83.145.201.254
>>         leftrsasigkey=%cert
>>         leftsubnet=192.168.240.0/24

Don't load certificaes and set id in conn %default. It makes your config
very errorprone as you can find out below. Here you load certificate for
_every_ conn, even psk ones!

>> conn fvs318
>>         type=tunnel
>>         left=83.145.201.2
>>         leftsubnet=192.168.240.0/24
>>         leftnexthop=83.145.201.254
>>         leftid="83.145.201.2"
>>         right=83.145.204.59
>>         rightsubnet=192.168.1.0/24
>>         rightnexthop=83.145.204.254
>>         rightid="83.145.204.59"
>>         ikelifetime=1440m
>>         keylife=480m
>>         pfs=yes
>>         keyexchange=ike
>>         authby=secret
>>         auto=start

This config is wrong because you load certificate from conn default but
you don't disable loading of cert for this conn. You can do it like this
but I suggest you load certificate from conn's not from conn %default.

	# this disables loading leftcert.
	leftcert=""

>> Jan 14 17:32:35 www pluto[21402]:   loaded host cert file '/etc/ipsec.d/certs/www.solotes.fi_crt.pem' (4304 bytes)
>> Jan 14 17:32:35 www pluto[21402]:   no subjectAltName matches ID '83.145.201.2', replaced by subject DN

This logentry say you what went wrong. You just missed this very
important notification which broke your conn.

-- 
Tuomo Soini <tis at foobar.fi>
Foobar Linux services
+358 40 5240030
Foobar Oy <http://foobar.fi/>

From ml at as-support.com  Mon Jan 19 05:18:47 2009
From: ml at as-support.com (Markus Locher)
Date: Mon, 19 Jan 2009 11:18:47 +0100
Subject: [Openswan Users] IPSEC(epa_des_crypt): decrypted packet failed
 SA identity
References: alpine.LFD.1.10.0812181352390.31499@newtla.xelerance.com
Message-ID: <49745387.6090205@as-support.com>

Hi Paul,

I found the solution and it has nothing to do with OpenSWAN.

The error has occured, because the OpenL2TP-Daemon has not sent his
packages through port 1701 to 1701, but IPSec expected to get those
packages on port 1701. So filled openl2tp.conf with the parameter
"our_udp_port=1701"  ( not only "udp_port" as described in online
documentation of openl2tp.org) and the IPSec-error disapeared.

Now I have another problem (and this time with openswan). Ipsec sends
"malformed" packages. I will set up another post for this.

Thank you very much. Hopefully read you in the next post.

Regards Markus


From ml at as-support.com  Mon Jan 19 06:26:25 2009
From: ml at as-support.com (Markus Locher)
Date: Mon, 19 Jan 2009 12:26:25 +0100
Subject: [Openswan Users] OpenSwan Client sends "Malformed Packet" of type
	ESP
References: alpine.LFD.1.10.0812181352390.31499@newtla.xelerance.com
Message-ID: <49746361.3030208@as-support.com>

Hi list,

I found similar but not equal problems in this mailling list so I post this.

The OpenSwan-Daemon is sending "malformed packages" of type "esp" to a
CISCO-router - which the CISCO never gets. That happens when I start
openl2tpd to create the tunnel of the VPN.

Log of WireShark:
------------------------
(Phase 1 Main Mode and Quick Mode logs are OK!)
...
client-ip      cisco-ip           ESP               ESP(SPI=0x87fbfeef)
client-ip      cisco-ip           ESP               ESP(SPI=0x87fbfeef) 
[Malformed Packet]
client-ip      cisco-ip           ESP               ESP(SPI=0x87fbfeef) 
[Malformed Packet]
client-ip      cisco-ip           ESP               ESP(SPI=0x87fbfeef) 
[Malformed Packet]
client-ip      cisco-ip           ESP               ESP(SPI=0x87fbfeef) 
[Malformed Packet]
client-ip      cisco-ip           ESP               ESP(SPI=0x87fbfeef)
client-ip      cisco-ip           ESP               ESP(SPI=0x87fbfeef)
client-ip      cisco-ip           ESP               ESP(SPI=0x87fbfeef) 
[Malformed Packet]
...
----------------------

The PSK used is absolutely correct. I changed it and ipsec failed with
errors

    "Informational Exchange message is invalid because it has a Message
ID of 0" from startup log
 and
    "inserting event EVENT_CRYPTO_FAILED, timeout in 300 seconds for#1"
from messages-log with "plutodebug=all" set
and
    "MESZ: %CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from <client-ip>
failed its sanity check or is malformed" from CISCO-log. 

So this can't be the problem.

The SPI's are equal as far as both outputs from "setkey -DP" and "setkey
-D" compared to the CISCO's "show crypto ipsec sa" output are the same.

The question is : Why is ipsec sending one good ESP packet followed by
malformed packages and why are they malformed?


------------IPSEC.CONF------------
# basic configuration
config setup
        # Do not set debug= options to debug configuration issues!
        # plutodebug / klipsdebug = "all", "none" or a combation from below:
        # "raw crypt parsing emitting control klips pfkey natt x509 dpd
private"
        # eg:
        #plutodebug="control parsing"
        plutodebug="all"
        #klipsdebug="all"
        #
        # enable to get logs per-peer
        #plutoopts="--perpeerlog"
        #
        # Only enable *debug=all if you are a developer
        #
        # NAT-TRAVERSAL support, see README.NAT-Traversal
        nat_traversal=yes
        # exclude networks used on server side by adding %v4:!a.b.c.0/24
        #virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%4:172.16.0.0/12
        virtual_private=%v4:10.255.255.1/32,%v4:192.168.0.0/24
        #virtual_private=%v4:192.168.0.0/24
        # OE is now off by default. Uncomment and change to on, to enable.
        OE=off
        # which IPsec stack to use. netkey,klips,mast,auto or none
        #protostack=netkey
        protostack=auto
        fragicmp=yes    # only for KLIPS - disable PMTU
        nhelpers=0


# Add connections here

conn L2TPPSKCLIENT
        #
        # ----------------------------------------------------------
        # Use a Preshared Key. Disable Perfect Forward Secrecy.
        # Initiate rekeying.
        # Connection type _must_ be Transport Mode.
        #
        authby=secret
        pfs=no          # default is yes
        rekey=yes
        keyingtries=3
        keyexchange=ike
        type=transport
        #
        # Specify type of encryption for ISAKAMP SA (IPsec Phase 1)
        # Cipher= 3des, Hash = sha, DH-Group = 2
        ike=3des-sha1-modp1024
        # Specify type of encryption for IPSEC SA (IPsec Phase 2)
        # Cipher= 3des, Hash = sha, DH-Group = 2
        phase2=esp
        phase2alg=3des-sha1
        #
        # Specifiy liftime of ike and key management
        # Note: Should match values on remote end
        ikelifetime=3600s
        salifetime=600s
        #
        # Keep connection alive through DPD (Dead Peer Detection)
        dpddelay=30
        dpdtimeout=120
        dpdaction=clear
        #
        #
        # Try XAUTH authentication
        #leftxauthclient=yes
        # ----------------------------------------------------------
        # The local Linux machine that connects as a client.
        #
        # The external network interface is used to connect to the server.
        # If you want to use a different interface or if there is no
        # defaultroute, you can use:   left=your.ip.addr.ess
        #left=87.106.244.79
        left=%defaultroute
        #leftsubnet=10.255.255.1/32
        #leftsubnet=87.106.244.79/32
        #left=%defaultroute
        leftnexthop=%defaultroute
        leftid=87.106.244.79
        leftprotoport=17/1701
        #
        # ----------------------------------------------------------
        # The remote server.
        #
        # Connect to the server at this IP address.
        right=217.91.16.223
        #rightid=217.91.16.223
        #rightsubnet=192.168.0.0/24  # Caused fail of phase 2 :
NO_PROPOSAL_CHOOSEN
        #rightsubnet=217.91.16.223/24
        rightprotoport=17/1701
        # ----------------------------------------------------------
        #
        # Change 'ignore' to 'add' to enable this configuration.
        #
        auto=add


## Disabling OE -- I think this is the old notation
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
---------------------------------------------------

Thanks for your help.

Markus





From petermcgill at goco.net  Mon Jan 19 09:43:26 2009
From: petermcgill at goco.net (Peter McGill)
Date: Mon, 19 Jan 2009 09:43:26 -0500
Subject: [Openswan Users] vpn connection
In-Reply-To: <515251629957C542816307570516B86D1EEFDE@BSRSPCLE001.boursorama.fr>
References: <515251629957C542816307570516B86D1EEFDE@BSRSPCLE001.boursorama.fr>
Message-ID: <4974918E.3030105@goco.net>

Alfonso,

There is several possible causes here.
Please send the output of the following
commands, to help in troubleshooting.
ipsec verify
netstat -nr
cat ipsec.conf
ipsec status
iptables -t filter -L -n -v
iptables -t nat -L -n -v
iptables -t mangle -L -n -v

Peter

Alfonso Viso wrote:
> hi all,
>  
> i can set openswan between Pix Cisco and Linux Server FC4. I use NETKEY 
> version and PSK.
> the remote site can connect to our intranet, and i see that the tunnel 
> is up and the traffic is coming throught the tunnel. The problem is when 
> i try to ping the other side, the traffic from local side don't go 
> throught tunnel, i mean  the traffic generated by our side, for example. 
> i only see traffic response by our side.
> Any body could be help us?
> thanks in advanced and sorry for my english.
>  
> regards
> Alfonso
> ------------------------------------------------------------------------
> 
> Ce message contient des informations confidentielles ou appartenant ? 
> Boursorama et est ?tabli ? l'intention exclusive de ses destinataires. 
> Toute divulgation, utilisation, diffusion ou reproduction (totale ou 
> partielle) de ce message, ou des informations qu'il contient, doit ?tre 
> pr?alablement autoris?e. Tout message ?lectronique est susceptible 
> d'alt?ration et son int?grit? ne peut ?tre assur?e.
> Boursorama d?cline toute responsabilit? au titre de ce message s'il a 
> ?t? modifi? ou falsifi?. Si vous n'?tes pas destinataire de ce message, 
> merci de le d?truire imm?diatement et d'avertir l'exp?diteur de l'erreur 
> de distribution et de la destruction du message.
> 
> ------------------------------------------------------------------------
> 
> This e-mail contains confidential information or information belonging 
> to Boursorama and is intended solely for the addressees. The 
> unauthorised disclosure, use, dissemination or copying (either whole or 
> partial) of this e-mail, or any information it contains, is prohibited. 
> E-mails are susceptible to alteration and their integrity cannot be 
> guaranteed. Boursorama shall not be liable for this e-mail if modified 
> or falsified. If you are not the intended recipient of this e-mail, 
> please delete it immediately from your system and notify the sender of 
> the wrong delivery and the mail deletion.
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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=283155

From muir.james.a at gmail.com  Mon Jan 19 10:02:34 2009
From: muir.james.a at gmail.com (James Muir)
Date: Mon, 19 Jan 2009 10:02:34 -0500
Subject: [Openswan Users] unexpected STRING [xauth] trying to set up
 connection to SonicWall
In-Reply-To: <1A1DBE364D744CB1866947C40CF1CEED@neilhp>
References: <B1F7984E99274361B2A98A326729A52D@neilhp>	<49709CD6.4080406@gmail.com>
	<1A1DBE364D744CB1866947C40CF1CEED@neilhp>
Message-ID: <4974960A.8050300@gmail.com>

Neil Aggarwal wrote:
> James:
> 
> Based on your post, I changed my config files to:
> 
> sonicwall.conf:
> conn sonicwall
>      type=tunnel
>      auto=add
>      auth=esp
>      pfs=no
>      authby=secret
>      keyingtries=0
>      left=1.2.3.4
>      leftid=1.2.3.4
>      leftsubnet=1.2.3.4/28
>      leftxauthclient=yes
>      right=5.6.7.8
>      rightsubnet=192.168.1.0/24
>      rightid=@00ABCDE
>      rightxauthserver=yes
>      esp=3des-sha1
>      keyexchange=ike
>      ike=3des-sha1-modp1024
>      aggrmode=yes
> 
> sonicwall.secrets:
> 
> 1.2.3.4 @00ABCDE : PSK "myPass"
> 
> I still get this output:
> 
> Jan 16 17:08:18 jamm8 pluto[29365]: "sonicwall" #1: initiating Aggressive
> Mode #1, connection "sonicwall"
> Jan 16 17:08:18 jamm8 pluto[29365]: | setting sec: 1
> Jan 16 17:08:18 jamm8 pluto[29365]: "sonicwall" #1: Informational Exchange
> message must be encrypted
> 
> Any idea?

I'm not certain if it will solve your problem, but I think you have the 
file ipsec.secrets configured incorrectly.  PSK is short for "pre-shared 
key" -- your password doesn't go there.  PSK + XAUTH is an 
authentication method; my sonicwall uses this method, but yours might do 
something different (talk to your sys admin).

Assuming that your sonicwall is set to do PSK + XAUTH, your pre-shared 
key is a hex-string that both you and the sonicwall share (e.g. 
0123456789ABCDEF).  Your sys admin can give this to you.  This is the 
string that goes in ipsec.secrets.

Once you initiate your connection, and the PSK is verified, the 
sonicwall will prompt you for your password.

-James

From petermcgill at goco.net  Mon Jan 19 10:40:01 2009
From: petermcgill at goco.net (Peter McGill)
Date: Mon, 19 Jan 2009 10:40:01 -0500
Subject: [Openswan Users] vpn connection
In-Reply-To: <515251629957C542816307570516B86D1EEFDE@BSRSPCLE001.boursorama.fr>
References: <515251629957C542816307570516B86D1EEFDE@BSRSPCLE001.boursorama.fr>
Message-ID: <9C8EE1620B60499BBC2127D3BBD5E6B1@peter>

Alfonso,

There is several possible causes here.
Please send the output of the following
commands, to help in troubleshooting.
ipsec verify
netstat -nr
cat ipsec.conf
ipsec status
iptables -t filter -L -n -v
iptables -t nat -L -n -v
iptables -t mangle -L -n -v

Peter McGill
IT Systems Analyst
Gra Ham Energy Limited 

> -----Original Message-----
> From: users-bounces at openswan.org 
> [mailto:users-bounces at openswan.org] On Behalf Of Alfonso Viso
> Sent: January 17, 2009 7:08 AM
> To: users at openswan.org
> Subject: [Openswan Users] vpn connection
> 
> hi all,
>  
> i can set openswan between Pix Cisco and Linux Server FC4. I 
> use NETKEY version and PSK. 
> the remote site can connect to our intranet, and i see that 
> the tunnel is up and the traffic is coming throught the 
> tunnel. The problem is when i try to ping the other side, the 
> traffic from local side don't go throught tunnel, i mean  the 
> traffic generated by our side, for example. i only see 
> traffic response by our side.
> Any body could be help us?
> thanks in advanced and sorry for my english.
>  
> regards
> Alfonso
> ________________________________
> 
> 
> Ce message contient des informations confidentielles ou 
> appartenant ? Boursorama et est ?tabli ? l'intention 
> exclusive de ses destinataires. Toute divulgation, 
> utilisation, diffusion ou reproduction (totale ou partielle) 
> de ce message, ou des informations qu'il contient, doit ?tre 
> pr?alablement autoris?e. Tout message ?lectronique est 
> susceptible d'alt?ration et son int?grit? ne peut ?tre assur?e.
> Boursorama d?cline toute responsabilit? au titre de ce 
> message s'il a ?t? modifi? ou falsifi?. Si vous n'?tes pas 
> destinataire de ce message, merci de le d?truire 
> imm?diatement et d'avertir l'exp?diteur de l'erreur de 
> distribution et de la destruction du message. 
> 
> ________________________________
> 
> This e-mail contains confidential information or information 
> belonging to Boursorama and is intended solely for the 
> addressees. The unauthorised disclosure, use, dissemination 
> or copying (either whole or partial) of this e-mail, or any 
> information it contains, is prohibited. E-mails are 
> susceptible to alteration and their integrity cannot be 
> guaranteed. Boursorama shall not be liable for this e-mail if 
> modified or falsified. If you are not the intended recipient 
> of this e-mail, please delete it immediately from your system 
> and notify the sender of the wrong delivery and the mail deletion. 
> 
> ________________________________
> 
> 


From alfonso.viso at selftrade.com  Mon Jan 19 11:17:08 2009
From: alfonso.viso at selftrade.com (Alfonso Viso)
Date: Mon, 19 Jan 2009 17:17:08 +0100
Subject: [Openswan Users] vpn connection
Message-ID: <515251629957C542816307570516B86D630953@BSRSPCLE001.boursorama.fr>

Hello Peter,

i send you the information:
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.13/K2.6.17-1.2142_FC4smp (netkey)
Checking for IPsec support in kernel                            [OK]
Testing against enforced SElinux mode                           [OK]
NETKEY detected, testing for disabled ICMP send_redirects       [OK]
NETKEY detected, testing for disabled ICMP accept_redirects     [OK]
Checking for RSA private key (/etc/ipsec.secrets)               [DISABLED]
  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]
Opportunistic Encryption Support                                [DISABLED]

netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
<net_public>   0.0.0.0         255.255.255.240 U         0 0          0 eth1
10.105.228.0    0.0.0.0         255.255.252.0   U         0 0          0 eth1
10.105.240.0    0.0.0.0         255.255.252.0   U         0 0          0 eth0
10.105.0.0      10.105.240.20   255.255.0.0     UG        0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth1
172.0.0.0       10.105.240.20   255.0.0.0       UG        0 0          0 eth0
10.0.0.0        10.105.240.20   255.0.0.0       UG        0 0          0 eth0
0.0.0.0        <gateway internet>   0.0.0.0         UG        0 0          0 eth1


iptables -t mangle -L -n -v
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

the iptables rules are ok, but we don't have configured any nat's rules, perhaps is it the problem?.
Other thing, i read in an article if there are many vpn it's necessary to use klips instead of netkey, is this true?.

thanks
Alfonso

-----Original Message-----
From: Peter McGill [mailto:petermcgill at goco.net]
Sent: lunes, 19 de enero de 2009 16:40
To: Alfonso Viso; users at openswan.org
Subject: RE: [Openswan Users] vpn connection


Alfonso,

There is several possible causes here.
Please send the output of the following
commands, to help in troubleshooting.
ipsec verify
netstat -nr
cat ipsec.conf
ipsec status
iptables -t filter -L -n -v
iptables -t nat -L -n -v
iptables -t mangle -L -n -v

Peter McGill
IT Systems Analyst
Gra Ham Energy Limited 

> -----Original Message-----
> From: users-bounces at openswan.org 
> [mailto:users-bounces at openswan.org] On Behalf Of Alfonso Viso
> Sent: January 17, 2009 7:08 AM
> To: users at openswan.org
> Subject: [Openswan Users] vpn connection
> 
> hi all,
>  
> i can set openswan between Pix Cisco and Linux Server FC4. I 
> use NETKEY version and PSK. 
> the remote site can connect to our intranet, and i see that 
> the tunnel is up and the traffic is coming throught the 
> tunnel. The problem is when i try to ping the other side, the 
> traffic from local side don't go throught tunnel, i mean  the 
> traffic generated by our side, for example. i only see 
> traffic response by our side.
> Any body could be help us?
> thanks in advanced and sorry for my english.
>  
> regards
> Alfonso
> ________________________________
> 
> 
> Ce message contient des informations confidentielles ou 
> appartenant ? Boursorama et est ?tabli ? l'intention 
> exclusive de ses destinataires. Toute divulgation, 
> utilisation, diffusion ou reproduction (totale ou partielle) 
> de ce message, ou des informations qu'il contient, doit ?tre 
> pr?alablement autoris?e. Tout message ?lectronique est 
> susceptible d'alt?ration et son int?grit? ne peut ?tre assur?e.
> Boursorama d?cline toute responsabilit? au titre de ce 
> message s'il a ?t? modifi? ou falsifi?. Si vous n'?tes pas 
> destinataire de ce message, merci de le d?truire 
> imm?diatement et d'avertir l'exp?diteur de l'erreur de 
> distribution et de la destruction du message. 
> 
> ________________________________
> 
> This e-mail contains confidential information or information 
> belonging to Boursorama and is intended solely for the 
> addressees. The unauthorised disclosure, use, dissemination 
> or copying (either whole or partial) of this e-mail, or any 
> information it contains, is prohibited. E-mails are 
> susceptible to alteration and their integrity cannot be 
> guaranteed. Boursorama shall not be liable for this e-mail if 
> modified or falsified. If you are not the intended recipient 
> of this e-mail, please delete it immediately from your system 
> and notify the sender of the wrong delivery and the mail deletion. 
> 
> ________________________________
> 
> 




___________________________________

Ce message contient des informations confidentielles ou appartenant ?
Boursorama et est ?tabli ? l'intention exclusive de ses destinataires. Toute
divulgation, utilisation, diffusion ou reproduction (totale ou partielle) de ce
message, ou des informations qu'il contient, doit ?tre pr?alablement
autoris?e. Tout message ?lectronique est susceptible d'alt?ration et son
int?grit? ne peut ?tre assur?e. Boursorama d?cline toute responsabilit? au
titre de ce message s'il a ?t? modifi? ou falsifi?. Si vous n'?tes pas
destinataire de ce message, merci de le d?truire imm?diatement et d'avertir
l'exp?diteur de l'erreur de distribution et de la destruction du message.
___________________________________

This e-mail contains confidential information or information belonging to
Boursorama and is intended solely for the addressees. The unauthorised
disclosure, use, dissemination or copying (either whole or partial) of this
e-mail, or any information it contains, is prohibited. E-mails are susceptible
to alteration and their integrity cannot be guaranteed. Boursorama shall not be
liable for this e-mail if modified or falsified. If you are not the intended
recipient of this e-mail, please delete it immediately from your system and
notify the sender of the wrong delivery and the mail deletion.
___________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ipsec_status.txt
Url: http://lists.openswan.org/pipermail/users/attachments/20090119/1afce57f/attachment-0001.txt 

From petermcgill at goco.net  Mon Jan 19 11:42:27 2009
From: petermcgill at goco.net (Peter McGill)
Date: Mon, 19 Jan 2009 11:42:27 -0500
Subject: [Openswan Users] vpn connection
In-Reply-To: <515251629957C542816307570516B86D630953@BSRSPCLE001.boursorama.fr>
References: <515251629957C542816307570516B86D630953@BSRSPCLE001.boursorama.fr>
Message-ID: <EAFBE147F61941FF85EEACF5D84C393E@peter>

Alfonso,

No you don't need KLIPS.
I don't see anything wrong with the info you sent so far.
Are you pinging from server to server or from subnet to subnet?
The two endpoints of your pings must be within the left/rightsubnets that you have defined.
ping -I often does not work, do your ping tests to/from hosts in the subnets.
If you use leftsourceip=<server lan ip> in your config then this can also help.
Showing me your ping output might help here.
You need to permit the ipsec traffic through your firewall both the openswan traffic ike/esp and the tunnel traffic (pings, etc...).
You also cannot nat the tunnel traffic.
I cannot tell if you've done this without...
iptables -t filter -L -n -v
iptables -t nat -L -n -v
I cannot tell if you have a configuration error without the following:
cat ipsec.conf
ipsec status

Peter McGill
IT Systems Analyst
Gra Ham Energy Limited 

> -----Original Message-----
> From: Alfonso Viso [mailto:alfonso.viso at selftrade.com] 
> Sent: January 19, 2009 11:17 AM
> To: petermcgill at goco.net; users at openswan.org
> Subject: RE: [Openswan Users] vpn connection
> 
> Hello Peter,
> 
> i send you the information:
> 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.13/K2.6.17-1.2142_FC4smp (netkey)
> Checking for IPsec support in kernel                            [OK]
> Testing against enforced SElinux mode                           [OK]
> NETKEY detected, testing for disabled ICMP send_redirects       [OK]
> NETKEY detected, testing for disabled ICMP accept_redirects     [OK]
> Checking for RSA private key (/etc/ipsec.secrets)             
>   [DISABLED]
>   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]
> Opportunistic Encryption Support                              
>   [DISABLED]
> 
> netstat -nr
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags   MSS 
> Window  irtt Iface
> <net_public>   0.0.0.0         255.255.255.240 U         0 0  
>         0 eth1
> 10.105.228.0    0.0.0.0         255.255.252.0   U         0 0 
>          0 eth1
> 10.105.240.0    0.0.0.0         255.255.252.0   U         0 0 
>          0 eth0
> 10.105.0.0      10.105.240.20   255.255.0.0     UG        0 0 
>          0 eth0
> 169.254.0.0     0.0.0.0         255.255.0.0     U         0 0 
>          0 eth1
> 172.0.0.0       10.105.240.20   255.0.0.0       UG        0 0 
>          0 eth0
> 10.0.0.0        10.105.240.20   255.0.0.0       UG        0 0 
>          0 eth0
> 0.0.0.0        <gateway internet>   0.0.0.0         UG        
> 0 0          0 eth1
> 
> 
> iptables -t mangle -L -n -v
> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target     prot opt in     out     source         
>       destination
> 
> Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target     prot opt in     out     source         
>       destination
> 
> Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target     prot opt in     out     source         
>       destination
> 
> Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target     prot opt in     out     source         
>       destination
> 
> Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target     prot opt in     out     source         
>       destination
> 
> the iptables rules are ok, but we don't have configured any 
> nat's rules, perhaps is it the problem?.
> Other thing, i read in an article if there are many vpn it's 
> necessary to use klips instead of netkey, is this true?.
> 
> thanks
> Alfonso
> 
> -----Original Message-----
> From: Peter McGill [mailto:petermcgill at goco.net]
> Sent: lunes, 19 de enero de 2009 16:40
> To: Alfonso Viso; users at openswan.org
> Subject: RE: [Openswan Users] vpn connection
> 
> 
> Alfonso,
> 
> There is several possible causes here.
> Please send the output of the following
> commands, to help in troubleshooting.
> ipsec verify
> netstat -nr
> cat ipsec.conf
> ipsec status
> iptables -t filter -L -n -v
> iptables -t nat -L -n -v
> iptables -t mangle -L -n -v
> 
> Peter McGill
> IT Systems Analyst
> Gra Ham Energy Limited 
> 
> > -----Original Message-----
> > From: users-bounces at openswan.org 
> > [mailto:users-bounces at openswan.org] On Behalf Of Alfonso Viso
> > Sent: January 17, 2009 7:08 AM
> > To: users at openswan.org
> > Subject: [Openswan Users] vpn connection
> > 
> > hi all,
> >  
> > i can set openswan between Pix Cisco and Linux Server FC4. I 
> > use NETKEY version and PSK. 
> > the remote site can connect to our intranet, and i see that 
> > the tunnel is up and the traffic is coming throught the 
> > tunnel. The problem is when i try to ping the other side, the 
> > traffic from local side don't go throught tunnel, i mean  the 
> > traffic generated by our side, for example. i only see 
> > traffic response by our side.
> > Any body could be help us?
> > thanks in advanced and sorry for my english.
> >  
> > regards
> > Alfonso
> > ________________________________
> > 
> > 
> > Ce message contient des informations confidentielles ou 
> > appartenant ? Boursorama et est ?tabli ? l'intention 
> > exclusive de ses destinataires. Toute divulgation, 
> > utilisation, diffusion ou reproduction (totale ou partielle) 
> > de ce message, ou des informations qu'il contient, doit ?tre 
> > pr?alablement autoris?e. Tout message ?lectronique est 
> > susceptible d'alt?ration et son int?grit? ne peut ?tre assur?e.
> > Boursorama d?cline toute responsabilit? au titre de ce 
> > message s'il a ?t? modifi? ou falsifi?. Si vous n'?tes pas 
> > destinataire de ce message, merci de le d?truire 
> > imm?diatement et d'avertir l'exp?diteur de l'erreur de 
> > distribution et de la destruction du message. 
> > 
> > ________________________________
> > 
> > This e-mail contains confidential information or information 
> > belonging to Boursorama and is intended solely for the 
> > addressees. The unauthorised disclosure, use, dissemination 
> > or copying (either whole or partial) of this e-mail, or any 
> > information it contains, is prohibited. E-mails are 
> > susceptible to alteration and their integrity cannot be 
> > guaranteed. Boursorama shall not be liable for this e-mail if 
> > modified or falsified. If you are not the intended recipient 
> > of this e-mail, please delete it immediately from your system 
> > and notify the sender of the wrong delivery and the mail deletion. 
> > 
> > ________________________________
> > 
> > 
> 
> 
> 
> 
> ___________________________________
> 
> Ce message contient des informations confidentielles ou appartenant ?
> Boursorama et est ?tabli ? l'intention exclusive de ses 
> destinataires. Toute
> divulgation, utilisation, diffusion ou reproduction (totale 
> ou partielle) de ce
> message, ou des informations qu'il contient, doit ?tre pr?alablement
> autoris?e. Tout message ?lectronique est susceptible 
> d'alt?ration et son
> int?grit? ne peut ?tre assur?e. Boursorama d?cline toute 
> responsabilit? au
> titre de ce message s'il a ?t? modifi? ou falsifi?. Si vous n'?tes pas
> destinataire de ce message, merci de le d?truire 
> imm?diatement et d'avertir
> l'exp?diteur de l'erreur de distribution et de la destruction 
> du message.
> ___________________________________
> 
> This e-mail contains confidential information or information 
> belonging to
> Boursorama and is intended solely for the addressees. The unauthorised
> disclosure, use, dissemination or copying (either whole or 
> partial) of this
> e-mail, or any information it contains, is prohibited. 
> E-mails are susceptible
> to alteration and their integrity cannot be guaranteed. 
> Boursorama shall not be
> liable for this e-mail if modified or falsified. If you are 
> not the intended
> recipient of this e-mail, please delete it immediately from 
> your system and
> notify the sender of the wrong delivery and the mail deletion.
> ___________________________________
> 


From alfonso.viso at selftrade.com  Tue Jan 20 11:32:18 2009
From: alfonso.viso at selftrade.com (Alfonso Viso)
Date: Tue, 20 Jan 2009 17:32:18 +0100
Subject: [Openswan Users] vpn connection
Message-ID: <515251629957C542816307570516B86D630963@BSRSPCLE001.boursorama.fr>

sorry Peter, 
i forgot to send you ipsec.conf:
config setup
        nat_traversal=yes
        forwardcontrol=yes
        virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16

conn %default
        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1

conn pix-velazquez
        type=tunnel
        authby=secret
        left=<public_ip_server>
        leftsubnet=10.105.0.0/16
        right=<public_ip_remote>
        rightsubnet=10.105.224.0/22  
        esp=3des-md5
        keyexchange=ike
        pfs=yes
        auto=add
        spi=0x0

conn pix-barcelona
        type=tunnel
        authby=secret
        left=<public_ip_server>
        leftsubnet=10.105.0.0/16
        right=%any
        rightsubnet=10.105.228.0/22
        esp=3des-md5
        keyexchange=ike
        pfs=yes
        auto=add
        spi=0x0

conn pix-barcelona1
        type=tunnel
        authby=secret
        left=<public_ip_server>
        leftsubnet=10.3.241.0/24
        right=%any
        rightsubnet=10.105.228.0/22
        esp=3des-md5
        keyexchange=ike
        pfs=yes
        auto=add
        spi=0x0

conn pix-barcelona2
        type=tunnel
        authby=secret
        left=<public_ip_server>
        leftsubnet=10.2.6.0/24
        right=%any
        rightsubnet=10.105.228.0/22
        esp=3des-md5
        keyexchange=ike
        pfs=yes
        auto=add
        spi=0x0

conn pix-barcelona3
        type=tunnel
        authby=secret
        left=<public_ip_server>
        leftsubnet=172.26.26.0/24
        right=%any
        rightsubnet=10.105.228.0/22
        esp=3des-md5
        keyexchange=ike
        pfs=yes
        auto=add
        spi=0x0

#Disable Opportunistic Encryption
I have configured four differents connection to "Barcelona" because they connect to other network throught our network.
about iptables rules i permit the traffic of port 50,51,500 and 4500, and i don't set any nat rules, is this neccesary?.

thanks for the help

Alfonso
.......
-----Original Message-----
From: Peter McGill [mailto:petermcgill at goco.net]
Sent: lunes, 19 de enero de 2009 17:42
To: Alfonso Viso; users at openswan.org
Subject: RE: [Openswan Users] vpn connection


Alfonso,

No you don't need KLIPS.
I don't see anything wrong with the info you sent so far.
Are you pinging from server to server or from subnet to subnet?
The two endpoints of your pings must be within the left/rightsubnets that you have defined.
ping -I often does not work, do your ping tests to/from hosts in the subnets.
If you use leftsourceip=<server lan ip> in your config then this can also help.
Showing me your ping output might help here.
You need to permit the ipsec traffic through your firewall both the openswan traffic ike/esp and the tunnel traffic (pings, etc...).
You also cannot nat the tunnel traffic.
I cannot tell if you've done this without...
iptables -t filter -L -n -v
iptables -t nat -L -n -v
I cannot tell if you have a configuration error without the following:
cat ipsec.conf
ipsec status

Peter McGill
IT Systems Analyst
Gra Ham Energy Limited 

> -----Original Message-----
> From: Alfonso Viso [mailto:alfonso.viso at selftrade.com] 
> Sent: January 19, 2009 11:17 AM
> To: petermcgill at goco.net; users at openswan.org
> Subject: RE: [Openswan Users] vpn connection
> 
> Hello Peter,
> 
> i send you the information:
> 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.13/K2.6.17-1.2142_FC4smp (netkey)
> Checking for IPsec support in kernel                            [OK]
> Testing against enforced SElinux mode                           [OK]
> NETKEY detected, testing for disabled ICMP send_redirects       [OK]
> NETKEY detected, testing for disabled ICMP accept_redirects     [OK]
> Checking for RSA private key (/etc/ipsec.secrets)             
>   [DISABLED]
>   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]
> Opportunistic Encryption Support                              
>   [DISABLED]
> 
> netstat -nr
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags   MSS 
> Window  irtt Iface
> <net_public>   0.0.0.0         255.255.255.240 U         0 0  
>         0 eth1
> 10.105.228.0    0.0.0.0         255.255.252.0   U         0 0 
>          0 eth1
> 10.105.240.0    0.0.0.0         255.255.252.0   U         0 0 
>          0 eth0
> 10.105.0.0      10.105.240.20   255.255.0.0     UG        0 0 
>          0 eth0
> 169.254.0.0     0.0.0.0         255.255.0.0     U         0 0 
>          0 eth1
> 172.0.0.0       10.105.240.20   255.0.0.0       UG        0 0 
>          0 eth0
> 10.0.0.0        10.105.240.20   255.0.0.0       UG        0 0 
>          0 eth0
> 0.0.0.0        <gateway internet>   0.0.0.0         UG        
> 0 0          0 eth1
> 
> 
> iptables -t mangle -L -n -v
> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target     prot opt in     out     source         
>       destination
> 
> Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target     prot opt in     out     source         
>       destination
> 
> Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target     prot opt in     out     source         
>       destination
> 
> Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target     prot opt in     out     source         
>       destination
> 
> Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target     prot opt in     out     source         
>       destination
> 
> the iptables rules are ok, but we don't have configured any 
> nat's rules, perhaps is it the problem?.
> Other thing, i read in an article if there are many vpn it's 
> necessary to use klips instead of netkey, is this true?.
> 
> thanks
> Alfonso
> 
> -----Original Message-----
> From: Peter McGill [mailto:petermcgill at goco.net]
> Sent: lunes, 19 de enero de 2009 16:40
> To: Alfonso Viso; users at openswan.org
> Subject: RE: [Openswan Users] vpn connection
> 
> 
> Alfonso,
> 
> There is several possible causes here.
> Please send the output of the following
> commands, to help in troubleshooting.
> ipsec verify
> netstat -nr
> cat ipsec.conf
> ipsec status
> iptables -t filter -L -n -v
> iptables -t nat -L -n -v
> iptables -t mangle -L -n -v
> 
> Peter McGill
> IT Systems Analyst
> Gra Ham Energy Limited 
> 
> > -----Original Message-----
> > From: users-bounces at openswan.org 
> > [mailto:users-bounces at openswan.org] On Behalf Of Alfonso Viso
> > Sent: January 17, 2009 7:08 AM
> > To: users at openswan.org
> > Subject: [Openswan Users] vpn connection
> > 
> > hi all,
> >  
> > i can set openswan between Pix Cisco and Linux Server FC4. I 
> > use NETKEY version and PSK. 
> > the remote site can connect to our intranet, and i see that 
> > the tunnel is up and the traffic is coming throught the 
> > tunnel. The problem is when i try to ping the other side, the 
> > traffic from local side don't go throught tunnel, i mean  the 
> > traffic generated by our side, for example. i only see 
> > traffic response by our side.
> > Any body could be help us?
> > thanks in advanced and sorry for my english.
> >  
> > regards
> > Alfonso
> > ________________________________
> > 
> > 
> > Ce message contient des informations confidentielles ou 
> > appartenant ? Boursorama et est ?tabli ? l'intention 
> > exclusive de ses destinataires. Toute divulgation, 
> > utilisation, diffusion ou reproduction (totale ou partielle) 
> > de ce message, ou des informations qu'il contient, doit ?tre 
> > pr?alablement autoris?e. Tout message ?lectronique est 
> > susceptible d'alt?ration et son int?grit? ne peut ?tre assur?e.
> > Boursorama d?cline toute responsabilit? au titre de ce 
> > message s'il a ?t? modifi? ou falsifi?. Si vous n'?tes pas 
> > destinataire de ce message, merci de le d?truire 
> > imm?diatement et d'avertir l'exp?diteur de l'erreur de 
> > distribution et de la destruction du message. 
> > 
> > ________________________________
> > 
> > This e-mail contains confidential information or information 
> > belonging to Boursorama and is intended solely for the 
> > addressees. The unauthorised disclosure, use, dissemination 
> > or copying (either whole or partial) of this e-mail, or any 
> > information it contains, is prohibited. E-mails are 
> > susceptible to alteration and their integrity cannot be 
> > guaranteed. Boursorama shall not be liable for this e-mail if 
> > modified or falsified. If you are not the intended recipient 
> > of this e-mail, please delete it immediately from your system 
> > and notify the sender of the wrong delivery and the mail deletion. 
> > 
> > ________________________________
> > 
> > 
> 
> 
> 
> 
> ___________________________________
> 
> Ce message contient des informations confidentielles ou appartenant ?
> Boursorama et est ?tabli ? l'intention exclusive de ses 
> destinataires. Toute
> divulgation, utilisation, diffusion ou reproduction (totale 
> ou partielle) de ce
> message, ou des informations qu'il contient, doit ?tre pr?alablement
> autoris?e. Tout message ?lectronique est susceptible 
> d'alt?ration et son
> int?grit? ne peut ?tre assur?e. Boursorama d?cline toute 
> responsabilit? au
> titre de ce message s'il a ?t? modifi? ou falsifi?. Si vous n'?tes pas
> destinataire de ce message, merci de le d?truire 
> imm?diatement et d'avertir
> l'exp?diteur de l'erreur de distribution et de la destruction 
> du message.
> ___________________________________
> 
> This e-mail contains confidential information or information 
> belonging to
> Boursorama and is intended solely for the addressees. The unauthorised
> disclosure, use, dissemination or copying (either whole or 
> partial) of this
> e-mail, or any information it contains, is prohibited. 
> E-mails are susceptible
> to alteration and their integrity cannot be guaranteed. 
> Boursorama shall not be
> liable for this e-mail if modified or falsified. If you are 
> not the intended
> recipient of this e-mail, please delete it immediately from 
> your system and
> notify the sender of the wrong delivery and the mail deletion.
> ___________________________________
> 



___________________________________

Ce message contient des informations confidentielles ou appartenant ?
Boursorama et est ?tabli ? l'intention exclusive de ses destinataires. Toute
divulgation, utilisation, diffusion ou reproduction (totale ou partielle) de ce
message, ou des informations qu'il contient, doit ?tre pr?alablement
autoris?e. Tout message ?lectronique est susceptible d'alt?ration et son
int?grit? ne peut ?tre assur?e. Boursorama d?cline toute responsabilit? au
titre de ce message s'il a ?t? modifi? ou falsifi?. Si vous n'?tes pas
destinataire de ce message, merci de le d?truire imm?diatement et d'avertir
l'exp?diteur de l'erreur de distribution et de la destruction du message.
___________________________________

This e-mail contains confidential information or information belonging to
Boursorama and is intended solely for the addressees. The unauthorised
disclosure, use, dissemination or copying (either whole or partial) of this
e-mail, or any information it contains, is prohibited. E-mails are susceptible
to alteration and their integrity cannot be guaranteed. Boursorama shall not be
liable for this e-mail if modified or falsified. If you are not the intended
recipient of this e-mail, please delete it immediately from your system and
notify the sender of the wrong delivery and the mail deletion.
___________________________________

From neil at JAMMConsulting.com  Tue Jan 20 11:38:05 2009
From: neil at JAMMConsulting.com (Neil Aggarwal)
Date: Tue, 20 Jan 2009 10:38:05 -0600
Subject: [Openswan Users] unexpected STRING [xauth] trying to set up
	connection to SonicWall
In-Reply-To: <4974960A.8050300@gmail.com>
References: <B1F7984E99274361B2A98A326729A52D@neilhp>	<49709CD6.4080406@gmail.com><1A1DBE364D744CB1866947C40CF1CEED@neilhp>
	<4974960A.8050300@gmail.com>
Message-ID: <E9C157E44E874AAB8FC893C593EF4F2B@neilhp>

James:

So, there will be two hex strings in the secrets file?

One after the IP address (with the @ sign) and the other
after the PSK keyword?

Thanks,
	Neil

--
Neil Aggarwal, (832)245-7314, www.JAMMConsulting.com
Eliminate junk email and reclaim your inbox.
Visit http://www.spammilter.com for details.  

> > sonicwall.secrets:
> > 
> > 1.2.3.4 @00ABCDE : PSK "myPass"

> I'm not certain if it will solve your problem, but I think 
> you have the 
> file ipsec.secrets configured incorrectly.  PSK is short for 
> "pre-shared 
> key" -- your password doesn't go there.  PSK + XAUTH is an 
> authentication method; my sonicwall uses this method, but 
> yours might do 
> something different (talk to your sys admin).
> 
> Assuming that your sonicwall is set to do PSK + XAUTH, your 
> pre-shared 
> key is a hex-string that both you and the sonicwall share (e.g. 
> 0123456789ABCDEF).  Your sys admin can give this to you.  This is the 
> string that goes in ipsec.secrets.
> 
> Once you initiate your connection, and the PSK is verified, the 
> sonicwall will prompt you for your password.


From petermcgill at goco.net  Tue Jan 20 12:36:04 2009
From: petermcgill at goco.net (Peter McGill)
Date: Tue, 20 Jan 2009 12:36:04 -0500
Subject: [Openswan Users] vpn connection
In-Reply-To: <515251629957C542816307570516B86D630963@BSRSPCLE001.boursorama.fr>
References: <515251629957C542816307570516B86D630963@BSRSPCLE001.boursorama.fr>
Message-ID: <0AC290C71F3B48A59D419B61AA2AAD6B@peter>

Alfonso,

You shouldn't be using spi=, remove those lines.
They are for manual keying, which should not be used.
The output of ipsec auto --status should have a line including:
"IPsec SA established" for each connection. This indicates
a successful tunnel connection.

You also need to allow the tunnel traffic through your firewall.
Ie) to/from 10.105.0.0/16, 10.105.224.0/22, etc...

You need to exclude ipsec from any nat rules, so if your not doing
any natting your fine, but if you are you need to exclude the ipsec.

Your virtual_private line is wrong it should exclude any local subnets.
But it doesn't appear that your using it anyway.


Peter McGill
IT Systems Analyst
Gra Ham Energy Limited 

> -----Original Message-----
> From: Alfonso Viso [mailto:alfonso.viso at selftrade.com] 
> Sent: January 20, 2009 11:32 AM
> To: petermcgill at goco.net; users at openswan.org
> Subject: RE: [Openswan Users] vpn connection
> 
> sorry Peter, 
> i forgot to send you ipsec.conf:
> config setup
>         nat_traversal=yes
>         forwardcontrol=yes
>         
> virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16
> 
> conn %default
>         ikelifetime=60m
>         keylife=20m
>         rekeymargin=3m
>         keyingtries=1
> 
> conn pix-velazquez
>         type=tunnel
>         authby=secret
>         left=<public_ip_server>
>         leftsubnet=10.105.0.0/16
>         right=<public_ip_remote>
>         rightsubnet=10.105.224.0/22  
>         esp=3des-md5
>         keyexchange=ike
>         pfs=yes
>         auto=add
>         spi=0x0
> 
> conn pix-barcelona
>         type=tunnel
>         authby=secret
>         left=<public_ip_server>
>         leftsubnet=10.105.0.0/16
>         right=%any
>         rightsubnet=10.105.228.0/22
>         esp=3des-md5
>         keyexchange=ike
>         pfs=yes
>         auto=add
>         spi=0x0
> 
> conn pix-barcelona1
>         type=tunnel
>         authby=secret
>         left=<public_ip_server>
>         leftsubnet=10.3.241.0/24
>         right=%any
>         rightsubnet=10.105.228.0/22
>         esp=3des-md5
>         keyexchange=ike
>         pfs=yes
>         auto=add
>         spi=0x0
> 
> conn pix-barcelona2
>         type=tunnel
>         authby=secret
>         left=<public_ip_server>
>         leftsubnet=10.2.6.0/24
>         right=%any
>         rightsubnet=10.105.228.0/22
>         esp=3des-md5
>         keyexchange=ike
>         pfs=yes
>         auto=add
>         spi=0x0
> 
> conn pix-barcelona3
>         type=tunnel
>         authby=secret
>         left=<public_ip_server>
>         leftsubnet=172.26.26.0/24
>         right=%any
>         rightsubnet=10.105.228.0/22
>         esp=3des-md5
>         keyexchange=ike
>         pfs=yes
>         auto=add
>         spi=0x0
> 
> #Disable Opportunistic Encryption
> I have configured four differents connection to "Barcelona" 
> because they connect to other network throught our network.
> about iptables rules i permit the traffic of port 50,51,500 
> and 4500, and i don't set any nat rules, is this neccesary?.
> 
> thanks for the help
> 
> Alfonso
> .......
> -----Original Message-----
> From: Peter McGill [mailto:petermcgill at goco.net]
> Sent: lunes, 19 de enero de 2009 17:42
> To: Alfonso Viso; users at openswan.org
> Subject: RE: [Openswan Users] vpn connection
> 
> 
> Alfonso,
> 
> No you don't need KLIPS.
> I don't see anything wrong with the info you sent so far.
> Are you pinging from server to server or from subnet to subnet?
> The two endpoints of your pings must be within the 
> left/rightsubnets that you have defined.
> ping -I often does not work, do your ping tests to/from hosts 
> in the subnets.
> If you use leftsourceip=<server lan ip> in your config then 
> this can also help.
> Showing me your ping output might help here.
> You need to permit the ipsec traffic through your firewall 
> both the openswan traffic ike/esp and the tunnel traffic 
> (pings, etc...).
> You also cannot nat the tunnel traffic.
> I cannot tell if you've done this without...
> iptables -t filter -L -n -v
> iptables -t nat -L -n -v
> I cannot tell if you have a configuration error without the following:
> cat ipsec.conf
> ipsec status
> 
> Peter McGill
> IT Systems Analyst
> Gra Ham Energy Limited 
> 
> > -----Original Message-----
> > From: Alfonso Viso [mailto:alfonso.viso at selftrade.com] 
> > Sent: January 19, 2009 11:17 AM
> > To: petermcgill at goco.net; users at openswan.org
> > Subject: RE: [Openswan Users] vpn connection
> > 
> > Hello Peter,
> > 
> > i send you the information:
> > 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.13/K2.6.17-1.2142_FC4smp (netkey)
> > Checking for IPsec support in kernel                            [OK]
> > Testing against enforced SElinux mode                           [OK]
> > NETKEY detected, testing for disabled ICMP send_redirects       [OK]
> > NETKEY detected, testing for disabled ICMP accept_redirects     [OK]
> > Checking for RSA private key (/etc/ipsec.secrets)             
> >   [DISABLED]
> >   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]
> > Opportunistic Encryption Support                              
> >   [DISABLED]
> > 
> > netstat -nr
> > Kernel IP routing table
> > Destination     Gateway         Genmask         Flags   MSS 
> > Window  irtt Iface
> > <net_public>   0.0.0.0         255.255.255.240 U         0 0  
> >         0 eth1
> > 10.105.228.0    0.0.0.0         255.255.252.0   U         0 0 
> >          0 eth1
> > 10.105.240.0    0.0.0.0         255.255.252.0   U         0 0 
> >          0 eth0
> > 10.105.0.0      10.105.240.20   255.255.0.0     UG        0 0 
> >          0 eth0
> > 169.254.0.0     0.0.0.0         255.255.0.0     U         0 0 
> >          0 eth1
> > 172.0.0.0       10.105.240.20   255.0.0.0       UG        0 0 
> >          0 eth0
> > 10.0.0.0        10.105.240.20   255.0.0.0       UG        0 0 
> >          0 eth0
> > 0.0.0.0        <gateway internet>   0.0.0.0         UG        
> > 0 0          0 eth1
> > 
> > 
> > iptables -t mangle -L -n -v
> > Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
> >  pkts bytes target     prot opt in     out     source         
> >       destination
> > 
> > Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
> >  pkts bytes target     prot opt in     out     source         
> >       destination
> > 
> > Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
> >  pkts bytes target     prot opt in     out     source         
> >       destination
> > 
> > Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
> >  pkts bytes target     prot opt in     out     source         
> >       destination
> > 
> > Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
> >  pkts bytes target     prot opt in     out     source         
> >       destination
> > 
> > the iptables rules are ok, but we don't have configured any 
> > nat's rules, perhaps is it the problem?.
> > Other thing, i read in an article if there are many vpn it's 
> > necessary to use klips instead of netkey, is this true?.
> > 
> > thanks
> > Alfonso
> > 
> > -----Original Message-----
> > From: Peter McGill [mailto:petermcgill at goco.net]
> > Sent: lunes, 19 de enero de 2009 16:40
> > To: Alfonso Viso; users at openswan.org
> > Subject: RE: [Openswan Users] vpn connection
> > 
> > 
> > Alfonso,
> > 
> > There is several possible causes here.
> > Please send the output of the following
> > commands, to help in troubleshooting.
> > ipsec verify
> > netstat -nr
> > cat ipsec.conf
> > ipsec status
> > iptables -t filter -L -n -v
> > iptables -t nat -L -n -v
> > iptables -t mangle -L -n -v
> > 
> > Peter McGill
> > IT Systems Analyst
> > Gra Ham Energy Limited 
> > 
> > > -----Original Message-----
> > > From: users-bounces at openswan.org 
> > > [mailto:users-bounces at openswan.org] On Behalf Of Alfonso Viso
> > > Sent: January 17, 2009 7:08 AM
> > > To: users at openswan.org
> > > Subject: [Openswan Users] vpn connection
> > > 
> > > hi all,
> > >  
> > > i can set openswan between Pix Cisco and Linux Server FC4. I 
> > > use NETKEY version and PSK. 
> > > the remote site can connect to our intranet, and i see that 
> > > the tunnel is up and the traffic is coming throught the 
> > > tunnel. The problem is when i try to ping the other side, the 
> > > traffic from local side don't go throught tunnel, i mean  the 
> > > traffic generated by our side, for example. i only see 
> > > traffic response by our side.
> > > Any body could be help us?
> > > thanks in advanced and sorry for my english.
> > >  
> > > regards
> > > Alfonso
> > > ________________________________
> > > 
> > > 
> > > Ce message contient des informations confidentielles ou 
> > > appartenant ? Boursorama et est ?tabli ? l'intention 
> > > exclusive de ses destinataires. Toute divulgation, 
> > > utilisation, diffusion ou reproduction (totale ou partielle) 
> > > de ce message, ou des informations qu'il contient, doit ?tre 
> > > pr?alablement autoris?e. Tout message ?lectronique est 
> > > susceptible d'alt?ration et son int?grit? ne peut ?tre assur?e.
> > > Boursorama d?cline toute responsabilit? au titre de ce 
> > > message s'il a ?t? modifi? ou falsifi?. Si vous n'?tes pas 
> > > destinataire de ce message, merci de le d?truire 
> > > imm?diatement et d'avertir l'exp?diteur de l'erreur de 
> > > distribution et de la destruction du message. 
> > > 
> > > ________________________________
> > > 
> > > This e-mail contains confidential information or information 
> > > belonging to Boursorama and is intended solely for the 
> > > addressees. The unauthorised disclosure, use, dissemination 
> > > or copying (either whole or partial) of this e-mail, or any 
> > > information it contains, is prohibited. E-mails are 
> > > susceptible to alteration and their integrity cannot be 
> > > guaranteed. Boursorama shall not be liable for this e-mail if 
> > > modified or falsified. If you are not the intended recipient 
> > > of this e-mail, please delete it immediately from your system 
> > > and notify the sender of the wrong delivery and the mail 
> deletion. 
> > > 
> > > ________________________________
> > > 
> > > 
> > 
> > 
> > 
> > 
> > ___________________________________
> > 
> > Ce message contient des informations confidentielles ou 
> appartenant ?
> > Boursorama et est ?tabli ? l'intention exclusive de ses 
> > destinataires. Toute
> > divulgation, utilisation, diffusion ou reproduction (totale 
> > ou partielle) de ce
> > message, ou des informations qu'il contient, doit ?tre pr?alablement
> > autoris?e. Tout message ?lectronique est susceptible 
> > d'alt?ration et son
> > int?grit? ne peut ?tre assur?e. Boursorama d?cline toute 
> > responsabilit? au
> > titre de ce message s'il a ?t? modifi? ou falsifi?. Si vous 
> n'?tes pas
> > destinataire de ce message, merci de le d?truire 
> > imm?diatement et d'avertir
> > l'exp?diteur de l'erreur de distribution et de la destruction 
> > du message.
> > ___________________________________
> > 
> > This e-mail contains confidential information or information 
> > belonging to
> > Boursorama and is intended solely for the addressees. The 
> unauthorised
> > disclosure, use, dissemination or copying (either whole or 
> > partial) of this
> > e-mail, or any information it contains, is prohibited. 
> > E-mails are susceptible
> > to alteration and their integrity cannot be guaranteed. 
> > Boursorama shall not be
> > liable for this e-mail if modified or falsified. If you are 
> > not the intended
> > recipient of this e-mail, please delete it immediately from 
> > your system and
> > notify the sender of the wrong delivery and the mail deletion.
> > ___________________________________
> > 
> 
> 
> 
> ___________________________________
> 
> Ce message contient des informations confidentielles ou appartenant ?
> Boursorama et est ?tabli ? l'intention exclusive de ses 
> destinataires. Toute
> divulgation, utilisation, diffusion ou reproduction (totale 
> ou partielle) de ce
> message, ou des informations qu'il contient, doit ?tre pr?alablement
> autoris?e. Tout message ?lectronique est susceptible 
> d'alt?ration et son
> int?grit? ne peut ?tre assur?e. Boursorama d?cline toute 
> responsabilit? au
> titre de ce message s'il a ?t? modifi? ou falsifi?. Si vous n'?tes pas
> destinataire de ce message, merci de le d?truire 
> imm?diatement et d'avertir
> l'exp?diteur de l'erreur de distribution et de la destruction 
> du message.
> ___________________________________
> 
> This e-mail contains confidential information or information 
> belonging to
> Boursorama and is intended solely for the addressees. The unauthorised
> disclosure, use, dissemination or copying (either whole or 
> partial) of this
> e-mail, or any information it contains, is prohibited. 
> E-mails are susceptible
> to alteration and their integrity cannot be guaranteed. 
> Boursorama shall not be
> liable for this e-mail if modified or falsified. If you are 
> not the intended
> recipient of this e-mail, please delete it immediately from 
> your system and
> notify the sender of the wrong delivery and the mail deletion.
> ___________________________________


From paul at xelerance.com  Tue Jan 20 20:54:56 2009
From: paul at xelerance.com (Paul Wouters)
Date: Tue, 20 Jan 2009 20:54:56 -0500 (EST)
Subject: [Openswan Users] unexpected STRING [xauth] trying to set up
 connection to SonicWall
In-Reply-To: <E9C157E44E874AAB8FC893C593EF4F2B@neilhp>
References: <B1F7984E99274361B2A98A326729A52D@neilhp>
	<49709CD6.4080406@gmail.com><1A1DBE364D744CB1866947C40CF1CEED@neilhp>
	<4974960A.8050300@gmail.com> <E9C157E44E874AAB8FC893C593EF4F2B@neilhp>
Message-ID: <Pine.LNX.4.64.0901202049570.29417@newtla.xelerance.com>

On Tue, 20 Jan 2009, Neil Aggarwal wrote:

> Subject: Re: [Openswan Users] unexpected STRING [xauth] trying to set up
>     connection to SonicWall
> 
> So, there will be two hex strings in the secrets file?
> 
> One after the IP address (with the @ sign) and the other
> after the PSK keyword?

>From the ipsec.secrets man page:

           # XAUTH password, used with leftxauthusername=username
           @username : XAUTH "password"

Note that xauth= is not a valid keyword anymore. It is xauthserver=
and xauthclient=. See 'man ipsec.conf'

Paul

From ml at as-support.com  Wed Jan 21 05:45:45 2009
From: ml at as-support.com (Markus Locher)
Date: Wed, 21 Jan 2009 11:45:45 +0100
Subject: [Openswan Users] OpenSwan Client sends "Malformed Packet" of
 typeESP
References: 49746361.3030208@as-support.com
Message-ID: <4976FCD9.4010202@as-support.com>

Hello list,

some more information on this problem.

It's really remarkable, because there is no indication of errors anywhere.

Problem:
==================
- I can set up a ipsec (transport) connection - packets are encapsulated
in ESP when they are transported.
- I can set up a openl2tp connection - when ipsec IS NOT STARTED!
- The ipsec keys and all following handshake on port 500 (isakmp)
function properly.
- Ipsec communicates on port 1701 for both sides (CISCO <---> openswan).
- The SPI's are equal at the time of communication for inbound and
outbound on both systems.
- Setkey -D(P) showing the right routing information (as I can see).
---------------------------------------------
217.0.0.0[any] 87.0.0.0[any] udp
fwd prio high + 1073739744 ipsec
esp/transport//unique#16385
created: Jan 21 11:08:23 2009 lastused:
lifetime: 0(s) validtime: 0(s)
spid=4202 seq=12 pid=32726
refcnt=1
87.0.0.0[any] 217.0.0.0[any] udp
out prio high + 1073739744 ipsec
esp/transport//unique#16385
created: Jan 21 11:23:16 2009 lastused:
lifetime: 0(s) validtime: 0(s)
spid=4209 seq=0 pid=32726
refcnt=1
---------------------------------------------
- CISCO shows only sendig packages to client on port 1701
- Client sends 5-6 packages and CISCO does the same, but I don't see any
incoming on port UDP 1701 __ON BOTH SYSTMES__. So ESP packages are lost
in space.

Conclusion:
======================
1) ESP packets are encrypted correctly, ...
because the SPI's are equal and none of both systems complain that.
Except the wireshark of the client, which says some packets are
malformed, but CISCO has no send or receive errors and has the right
count of decrypt/encrypt packets.
2) ESP packets are send correctly, ...
because port on both sides is 1701 on any send message.
3) The tunnel with l2tp - without ipsec - function properly, so ipsec
must be the problem.


Questions:
=======================
A) There are my ESP packets and how can I find them?
B) Is there a way to look into ESP packets except of tcpdump (which I
can't compile with crypto).
C) Could it be that the NETKEY module of the kernel is the problem and
can I trace it's output somehow?








Am 2009-01-19 11:26, Markus Locher schrieb:
> Hi list,
>
> I found similar but not equal problems in this mailling list so I post
this.
>
> The OpenSwan-Daemon is sending "malformed packages" of type "esp" to a
> CISCO-router - which the CISCO never gets. That happens when I start
> openl2tpd to create the tunnel of the VPN.
>
> Log of WireShark:
>
> The PSK used is absolutely correct. I changed it and ipsec failed with
> errors
>
> "Informational Exchange message is invalid because it has a Message
> ID of 0" from startup log
> and
> "inserting event EVENT_CRYPTO_FAILED, timeout in 300 seconds for#1"
> from messages-log with "plutodebug=all" set
> and
> "MESZ: %CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from
> failed its sanity check or is malformed" from CISCO-log.
>
> So this can't be the problem.
>
> The SPI's are equal as far as both outputs from "setkey -DP" and "setkey
> -D" compared to the CISCO's "show crypto ipsec sa" output are the same.
>
> The question is : Why is ipsec sending one good ESP packet followed by
> malformed packages and why are they malformed?
>
>
> ------------IPSEC.CONF------------
> # basic configuration
> config setup
> # Do not set debug= options to debug configuration issues!
> # plutodebug / klipsdebug = "all", "none" or a combation from below:
> # "raw crypt parsing emitting control klips pfkey natt x509 dpd
> private"
> # eg:
> #plutodebug="control parsing"
> plutodebug="all"
> #klipsdebug="all"
> #
> # enable to get logs per-peer
> #plutoopts="--perpeerlog"
> #
> # Only enable *debug=all if you are a developer
> #
> # NAT-TRAVERSAL support, see README.NAT-Traversal
> nat_traversal=yes
> # exclude networks used on server side by adding %v4:!a.b.c.0/24
> #virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%4:172.16.0.0/12
> virtual_private=%v4:10.255.255.1/32,%v4:192.168.0.0/24
> #virtual_private=%v4:192.168.0.0/24
> # OE is now off by default. Uncomment and change to on, to enable.
> OE=off
> # which IPsec stack to use. netkey,klips,mast,auto or none
> #protostack=netkey
> protostack=auto
> fragicmp=yes # only for KLIPS - disable PMTU
> nhelpers=0
>
>
> # Add connections here
>
> conn L2TPPSKCLIENT
> #
> # ----------------------------------------------------------
> # Use a Preshared Key. Disable Perfect Forward Secrecy.
> # Initiate rekeying.
> # Connection type _must_ be Transport Mode.
> #
> authby=secret
> pfs=no # default is yes
> rekey=yes
> keyingtries=3
> keyexchange=ike
> type=transport
> #
> # Specify type of encryption for ISAKAMP SA (IPsec Phase 1)
> # Cipher= 3des, Hash = sha, DH-Group = 2
> ike=3des-sha1-modp1024
> # Specify type of encryption for IPSEC SA (IPsec Phase 2)
> # Cipher= 3des, Hash = sha, DH-Group = 2
> phase2=esp
> phase2alg=3des-sha1
> #
> # Specifiy liftime of ike and key management
> # Note: Should match values on remote end
> ikelifetime=3600s
> salifetime=600s
> #
> # Keep connection alive through DPD (Dead Peer Detection)
> dpddelay=30
> dpdtimeout=120
> dpdaction=clear
> #
> #
> # Try XAUTH authentication
> #leftxauthclient=yes
> # ----------------------------------------------------------
> # The local Linux machine that connects as a client.
> #
> # The external network interface is used to connect to the server.
> # If you want to use a different interface or if there is no
> # defaultroute, you can use: left=your.ip.addr.ess
> #left=87.106.244.79
>
left=???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????



From paul at xelerance.com  Wed Jan 21 11:22:43 2009
From: paul at xelerance.com (Paul Wouters)
Date: Wed, 21 Jan 2009 11:22:43 -0500 (EST)
Subject: [Openswan Users] OpenSwan Client sends "Malformed Packet" of
 typeESP
In-Reply-To: <4976FCD9.4010202@as-support.com>
References: 49746361.3030208@as-support.com <4976FCD9.4010202@as-support.com>
Message-ID: <Pine.LNX.4.64.0901211121080.1050@newtla.xelerance.com>

On Wed, 21 Jan 2009, Markus Locher wrote:

this is most probably bug http://bugs.xelerance.com/view.php?id=1004

You can check with the ip xfrm command. the setkey command is obsolete.

Paul

> Date: Wed, 21 Jan 2009 11:45:45 +0100
> From: Markus Locher <ml at as-support.com>
> To: Openswan Users <users at openswan.org>
> Subject: Re: [Openswan Users] OpenSwan Client sends "Malformed Packet" of
>     typeESP
> 
> Hello list,
> 
> some more information on this problem.
> 
> It's really remarkable, because there is no indication of errors anywhere.
> 
> Problem:
> ==================
> - I can set up a ipsec (transport) connection - packets are encapsulated
> in ESP when they are transported.
> - I can set up a openl2tp connection - when ipsec IS NOT STARTED!
> - The ipsec keys and all following handshake on port 500 (isakmp)
> function properly.
> - Ipsec communicates on port 1701 for both sides (CISCO <---> openswan).
> - The SPI's are equal at the time of communication for inbound and
> outbound on both systems.
> - Setkey -D(P) showing the right routing information (as I can see).
> ---------------------------------------------
> 217.0.0.0[any] 87.0.0.0[any] udp
> fwd prio high + 1073739744 ipsec
> esp/transport//unique#16385
> created: Jan 21 11:08:23 2009 lastused:
> lifetime: 0(s) validtime: 0(s)
> spid=4202 seq=12 pid=32726
> refcnt=1
> 87.0.0.0[any] 217.0.0.0[any] udp
> out prio high + 1073739744 ipsec
> esp/transport//unique#16385
> created: Jan 21 11:23:16 2009 lastused:
> lifetime: 0(s) validtime: 0(s)
> spid=4209 seq=0 pid=32726
> refcnt=1
> ---------------------------------------------
> - CISCO shows only sendig packages to client on port 1701
> - Client sends 5-6 packages and CISCO does the same, but I don't see any
> incoming on port UDP 1701 __ON BOTH SYSTMES__. So ESP packages are lost
> in space.
> 
> Conclusion:
> ======================
> 1) ESP packets are encrypted correctly, ...
> because the SPI's are equal and none of both systems complain that.
> Except the wireshark of the client, which says some packets are
> malformed, but CISCO has no send or receive errors and has the right
> count of decrypt/encrypt packets.
> 2) ESP packets are send correctly, ...
> because port on both sides is 1701 on any send message.
> 3) The tunnel with l2tp - without ipsec - function properly, so ipsec
> must be the problem.
> 
> 
> Questions:
> =======================
> A) There are my ESP packets and how can I find them?
> B) Is there a way to look into ESP packets except of tcpdump (which I
> can't compile with crypto).
> C) Could it be that the NETKEY module of the kernel is the problem and
> can I trace it's output somehow?
> 
> 
> 
> 
> 
> 
> 
> 
> Am 2009-01-19 11:26, Markus Locher schrieb:
> > Hi list,
> >
> > I found similar but not equal problems in this mailling list so I post
> this.
> >
> > The OpenSwan-Daemon is sending "malformed packages" of type "esp" to a
> > CISCO-router - which the CISCO never gets. That happens when I start
> > openl2tpd to create the tunnel of the VPN.
> >
> > Log of WireShark:
> >
> > The PSK used is absolutely correct. I changed it and ipsec failed with
> > errors
> >
> > "Informational Exchange message is invalid because it has a Message
> > ID of 0" from startup log
> > and
> > "inserting event EVENT_CRYPTO_FAILED, timeout in 300 seconds for#1"
> > from messages-log with "plutodebug=all" set
> > and
> > "MESZ: %CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from
> > failed its sanity check or is malformed" from CISCO-log.
> >
> > So this can't be the problem.
> >
> > The SPI's are equal as far as both outputs from "setkey -DP" and "setkey
> > -D" compared to the CISCO's "show crypto ipsec sa" output are the same.
> >
> > The question is : Why is ipsec sending one good ESP packet followed by
> > malformed packages and why are they malformed?
> >
> >
> > ------------IPSEC.CONF------------
> > # basic configuration
> > config setup
> > # Do not set debug= options to debug configuration issues!
> > # plutodebug / klipsdebug = "all", "none" or a combation from below:
> > # "raw crypt parsing emitting control klips pfkey natt x509 dpd
> > private"
> > # eg:
> > #plutodebug="control parsing"
> > plutodebug="all"
> > #klipsdebug="all"
> > #
> > # enable to get logs per-peer
> > #plutoopts="--perpeerlog"
> > #
> > # Only enable *debug=all if you are a developer
> > #
> > # NAT-TRAVERSAL support, see README.NAT-Traversal
> > nat_traversal=yes
> > # exclude networks used on server side by adding %v4:!a.b.c.0/24
> > #virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%4:172.16.0.0/12
> > virtual_private=%v4:10.255.255.1/32,%v4:192.168.0.0/24
> > #virtual_private=%v4:192.168.0.0/24
> > # OE is now off by default. Uncomment and change to on, to enable.
> > OE=off
> > # which IPsec stack to use. netkey,klips,mast,auto or none
> > #protostack=netkey
> > protostack=auto
> > fragicmp=yes # only for KLIPS - disable PMTU
> > nhelpers=0
> >
> >
> > # Add connections here
> >
> > conn L2TPPSKCLIENT
> > #
> > # ----------------------------------------------------------
> > # Use a Preshared Key. Disable Perfect Forward Secrecy.
> > # Initiate rekeying.
> > # Connection type _must_ be Transport Mode.
> > #
> > authby=secret
> > pfs=no # default is yes
> > rekey=yes
> > keyingtries=3
> > keyexchange=ike
> > type=transport
> > #
> > # Specify type of encryption for ISAKAMP SA (IPsec Phase 1)
> > # Cipher= 3des, Hash = sha, DH-Group = 2
> > ike=3des-sha1-modp1024
> > # Specify type of encryption for IPSEC SA (IPsec Phase 2)
> > # Cipher= 3des, Hash = sha, DH-Group = 2
> > phase2=esp
> > phase2alg=3des-sha1
> > #
> > # Specifiy liftime of ike and key management
> > # Note: Should match values on remote end
> > ikelifetime=3600s
> > salifetime=600s
> > #
> > # Keep connection alive through DPD (Dead Peer Detection)
> > dpddelay=30
> > dpdtimeout=120
> > dpdaction=clear
> > #
> > #
> > # Try XAUTH authentication
> > #leftxauthclient=yes
> > # ----------------------------------------------------------
> > # The local Linux machine that connects as a client.
> > #
> > # The external network interface is used to connect to the server.
> > # If you want to use a different interface or if there is no
> > # defaultroute, you can use: left=your.ip.addr.ess
> > #left=87.106.244.79
> >
> left=???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
 ??
>  ??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
> 
> 
> _______________________________________________
> 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=283155
> 

From neil at JAMMConsulting.com  Wed Jan 21 11:20:41 2009
From: neil at JAMMConsulting.com (Neil Aggarwal)
Date: Wed, 21 Jan 2009 10:20:41 -0600
Subject: [Openswan Users] unexpected STRING [xauth] trying to set up
	connection to SonicWall
In-Reply-To: <Pine.LNX.4.64.0901202049570.29417@newtla.xelerance.com>
References: <B1F7984E99274361B2A98A326729A52D@neilhp>
	<49709CD6.4080406@gmail.com><1A1DBE364D744CB1866947C40CF1CEED@neilhp>
	<4974960A.8050300@gmail.com>
	<E9C157E44E874AAB8FC893C593EF4F2B@neilhp>
	<Pine.LNX.4.64.0901202049570.29417@newtla.xelerance.com>
Message-ID: <92B21B6088CB495FBF466C57E60DAA15@neilhp>

Paul:

Is there a current working example of how to connect
to a SonicWall?

I tried the configuration posted here:
http://www.sonicwall.com/downloads/SonicOS_Enhanced_to_Openswan_Using_Aggres
sive_Mode_IKE_with_PreShared_key.pdf

And keep getting this error:
Informational Exchange message must be encrypted

Thanks,
  Neil

--
Neil Aggarwal, (832)245-7314, www.JAMMConsulting.com
Eliminate junk email and reclaim your inbox.
Visit http://www.spammilter.com for details.  

> -----Original Message-----
> From: Paul Wouters [mailto:paul at xelerance.com] 
> Sent: Tuesday, January 20, 2009 7:55 PM
> To: Neil Aggarwal
> Cc: users at openswan.org
> Subject: Re: [Openswan Users] unexpected STRING [xauth] 
> trying to set up connection to SonicWall
> 
> On Tue, 20 Jan 2009, Neil Aggarwal wrote:
> 
> > Subject: Re: [Openswan Users] unexpected STRING [xauth] 
> trying to set up
> >     connection to SonicWall
> > 
> > So, there will be two hex strings in the secrets file?
> > 
> > One after the IP address (with the @ sign) and the other
> > after the PSK keyword?
> 
> >From the ipsec.secrets man page:
> 
>            # XAUTH password, used with leftxauthusername=username
>            @username : XAUTH "password"
> 
> Note that xauth= is not a valid keyword anymore. It is xauthserver=
> and xauthclient=. See 'man ipsec.conf'
> 
> Paul


From alfonso.viso at selftrade.com  Thu Jan 22 05:34:07 2009
From: alfonso.viso at selftrade.com (Alfonso Viso)
Date: Thu, 22 Jan 2009 11:34:07 +0100
Subject: [Openswan Users] vpn connection
Message-ID: <515251629957C542816307570516B86D8E160C@BSRSPCLE001.boursorama.fr>

Hello Peter, 

I allow the traffic between 10.105.0.0/16 and 10.105.224.0/22 with this rules:
iptables -A npc-forward -j ACCEPT -i eth1 -o eth0 -s 10.105.228.0/22 -d 10.105.0.0/16 -m state --state NEW,ESTABLISHED
iptables -A npc-forward -j ACCEPT -i eth0 -o eth1 -s 10.105.0.0/16 -d 10.105.228.0/22 -m state --state NEW,ESTABLISHED

I fear i need to apply other rules, isn't it?.

-----Original Message-----
From: Peter McGill [mailto:petermcgill at goco.net] 
Sent: martes, 20 de enero de 2009 18:36
To: Alfonso Viso; users at openswan.org
Subject: RE: [Openswan Users] vpn connection

Alfonso,

You shouldn't be using spi=, remove those lines.
They are for manual keying, which should not be used.
The output of ipsec auto --status should have a line including:
"IPsec SA established" for each connection. This indicates a successful tunnel connection.

You also need to allow the tunnel traffic through your firewall.
Ie) to/from 10.105.0.0/16, 10.105.224.0/22, etc...

You need to exclude ipsec from any nat rules, so if your not doing any natting your fine, but if you are you need to exclude the ipsec.

Your virtual_private line is wrong it should exclude any local subnets.
But it doesn't appear that your using it anyway.


Peter McGill
IT Systems Analyst
Gra Ham Energy Limited 

> -----Original Message-----
> From: Alfonso Viso [mailto:alfonso.viso at selftrade.com]
> Sent: January 20, 2009 11:32 AM
> To: petermcgill at goco.net; users at openswan.org
> Subject: RE: [Openswan Users] vpn connection
> 
> sorry Peter,
> i forgot to send you ipsec.conf:
> config setup
>         nat_traversal=yes
>         forwardcontrol=yes
>         
> virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16
> 
> conn %default
>         ikelifetime=60m
>         keylife=20m
>         rekeymargin=3m
>         keyingtries=1
> 
> conn pix-velazquez
>         type=tunnel
>         authby=secret
>         left=<public_ip_server>
>         leftsubnet=10.105.0.0/16
>         right=<public_ip_remote>
>         rightsubnet=10.105.224.0/22  
>         esp=3des-md5
>         keyexchange=ike
>         pfs=yes
>         auto=add
>         spi=0x0
> 
> conn pix-barcelona
>         type=tunnel
>         authby=secret
>         left=<public_ip_server>
>         leftsubnet=10.105.0.0/16
>         right=%any
>         rightsubnet=10.105.228.0/22
>         esp=3des-md5
>         keyexchange=ike
>         pfs=yes
>         auto=add
>         spi=0x0
> 
> conn pix-barcelona1
>         type=tunnel
>         authby=secret
>         left=<public_ip_server>
>         leftsubnet=10.3.241.0/24
>         right=%any
>         rightsubnet=10.105.228.0/22
>         esp=3des-md5
>         keyexchange=ike
>         pfs=yes
>         auto=add
>         spi=0x0
> 
> conn pix-barcelona2
>         type=tunnel
>         authby=secret
>         left=<public_ip_server>
>         leftsubnet=10.2.6.0/24
>         right=%any
>         rightsubnet=10.105.228.0/22
>         esp=3des-md5
>         keyexchange=ike
>         pfs=yes
>         auto=add
>         spi=0x0
> 
> conn pix-barcelona3
>         type=tunnel
>         authby=secret
>         left=<public_ip_server>
>         leftsubnet=172.26.26.0/24
>         right=%any
>         rightsubnet=10.105.228.0/22
>         esp=3des-md5
>         keyexchange=ike
>         pfs=yes
>         auto=add
>         spi=0x0
> 
> #Disable Opportunistic Encryption
> I have configured four differents connection to "Barcelona" 
> because they connect to other network throught our network.
> about iptables rules i permit the traffic of port 50,51,500 and 4500, 
> and i don't set any nat rules, is this neccesary?.
> 
> thanks for the help
> 
> Alfonso
> .......
> -----Original Message-----
> From: Peter McGill [mailto:petermcgill at goco.net]
> Sent: lunes, 19 de enero de 2009 17:42
> To: Alfonso Viso; users at openswan.org
> Subject: RE: [Openswan Users] vpn connection
> 
> 
> Alfonso,
> 
> No you don't need KLIPS.
> I don't see anything wrong with the info you sent so far.
> Are you pinging from server to server or from subnet to subnet?
> The two endpoints of your pings must be within the left/rightsubnets 
> that you have defined.
> ping -I often does not work, do your ping tests to/from hosts in the 
> subnets.
> If you use leftsourceip=<server lan ip> in your config then this can 
> also help.
> Showing me your ping output might help here.
> You need to permit the ipsec traffic through your firewall both the 
> openswan traffic ike/esp and the tunnel traffic (pings, etc...).
> You also cannot nat the tunnel traffic.
> I cannot tell if you've done this without...
> iptables -t filter -L -n -v
> iptables -t nat -L -n -v
> I cannot tell if you have a configuration error without the following:
> cat ipsec.conf
> ipsec status
> 
> Peter McGill
> IT Systems Analyst
> Gra Ham Energy Limited
> 
> > -----Original Message-----
> > From: Alfonso Viso [mailto:alfonso.viso at selftrade.com]
> > Sent: January 19, 2009 11:17 AM
> > To: petermcgill at goco.net; users at openswan.org
> > Subject: RE: [Openswan Users] vpn connection
> > 
> > Hello Peter,
> > 
> > i send you the information:
> > 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.13/K2.6.17-1.2142_FC4smp (netkey)
> > Checking for IPsec support in kernel                            [OK]
> > Testing against enforced SElinux mode                           [OK]
> > NETKEY detected, testing for disabled ICMP send_redirects       [OK]
> > NETKEY detected, testing for disabled ICMP accept_redirects     [OK]
> > Checking for RSA private key (/etc/ipsec.secrets)             
> >   [DISABLED]
> >   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]
> > Opportunistic Encryption Support                              
> >   [DISABLED]
> > 
> > netstat -nr
> > Kernel IP routing table
> > Destination     Gateway         Genmask         Flags   MSS 
> > Window  irtt Iface
> > <net_public>   0.0.0.0         255.255.255.240 U         0 0  
> >         0 eth1
> > 10.105.228.0    0.0.0.0         255.255.252.0   U         0 0 
> >          0 eth1
> > 10.105.240.0    0.0.0.0         255.255.252.0   U         0 0 
> >          0 eth0
> > 10.105.0.0      10.105.240.20   255.255.0.0     UG        0 0 
> >          0 eth0
> > 169.254.0.0     0.0.0.0         255.255.0.0     U         0 0 
> >          0 eth1
> > 172.0.0.0       10.105.240.20   255.0.0.0       UG        0 0 
> >          0 eth0
> > 10.0.0.0        10.105.240.20   255.0.0.0       UG        0 0 
> >          0 eth0
> > 0.0.0.0        <gateway internet>   0.0.0.0         UG        
> > 0 0          0 eth1
> > 
> > 
> > iptables -t mangle -L -n -v
> > Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
> >  pkts bytes target     prot opt in     out     source         
> >       destination
> > 
> > Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
> >  pkts bytes target     prot opt in     out     source         
> >       destination
> > 
> > Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
> >  pkts bytes target     prot opt in     out     source         
> >       destination
> > 
> > Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
> >  pkts bytes target     prot opt in     out     source         
> >       destination
> > 
> > Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
> >  pkts bytes target     prot opt in     out     source         
> >       destination
> > 
> > the iptables rules are ok, but we don't have configured any nat's 
> > rules, perhaps is it the problem?.
> > Other thing, i read in an article if there are many vpn it's 
> > necessary to use klips instead of netkey, is this true?.
> > 
> > thanks
> > Alfonso
> > 
> > -----Original Message-----
> > From: Peter McGill [mailto:petermcgill at goco.net]
> > Sent: lunes, 19 de enero de 2009 16:40
> > To: Alfonso Viso; users at openswan.org
> > Subject: RE: [Openswan Users] vpn connection
> > 
> > 
> > Alfonso,
> > 
> > There is several possible causes here.
> > Please send the output of the following commands, to help in 
> > troubleshooting.
> > ipsec verify
> > netstat -nr
> > cat ipsec.conf
> > ipsec status
> > iptables -t filter -L -n -v
> > iptables -t nat -L -n -v
> > iptables -t mangle -L -n -v
> > 
> > Peter McGill
> > IT Systems Analyst
> > Gra Ham Energy Limited
> > 
> > > -----Original Message-----
> > > From: users-bounces at openswan.org
> > > [mailto:users-bounces at openswan.org] On Behalf Of Alfonso Viso
> > > Sent: January 17, 2009 7:08 AM
> > > To: users at openswan.org
> > > Subject: [Openswan Users] vpn connection
> > > 
> > > hi all,
> > >  
> > > i can set openswan between Pix Cisco and Linux Server FC4. I use 
> > > NETKEY version and PSK.
> > > the remote site can connect to our intranet, and i see that the 
> > > tunnel is up and the traffic is coming throught the tunnel. The 
> > > problem is when i try to ping the other side, the traffic from 
> > > local side don't go throught tunnel, i mean  the traffic generated 
> > > by our side, for example. i only see traffic response by our side.
> > > Any body could be help us?
> > > thanks in advanced and sorry for my english.
> > >  
> > > regards
> > > Alfonso
> > > ________________________________
> > > 
> > > 
> > > Ce message contient des informations confidentielles ou 
> > > appartenant ? Boursorama et est ?tabli ? l'intention exclusive de 
> > > ses destinataires. Toute divulgation, utilisation, diffusion ou 
> > > reproduction (totale ou partielle) de ce message, ou des 
> > > informations qu'il contient, doit ?tre pr?alablement autoris?e. 
> > > Tout message ?lectronique est susceptible d'alt?ration et son 
> > > int?grit? ne peut ?tre assur?e.
> > > Boursorama d?cline toute responsabilit? au titre de ce message 
> > > s'il a ?t? modifi? ou falsifi?. Si vous n'?tes pas destinataire de 
> > > ce message, merci de le d?truire imm?diatement et d'avertir 
> > > l'exp?diteur de l'erreur de distribution et de la destruction du 
> > > message.
> > > 
> > > ________________________________
> > > 
> > > This e-mail contains confidential information or information 
> > > belonging to Boursorama and is intended solely for the addressees. 
> > > The unauthorised disclosure, use, dissemination or copying (either 
> > > whole or partial) of this e-mail, or any information it contains, 
> > > is prohibited. E-mails are susceptible to alteration and their 
> > > integrity cannot be guaranteed. Boursorama shall not be liable for 
> > > this e-mail if modified or falsified. If you are not the intended 
> > > recipient of this e-mail, please delete it immediately from your 
> > > system and notify the sender of the wrong delivery and the mail
> deletion. 
> > > 
> > > ________________________________
> > > 
> > > 
> > 
> > 
> > 
> > 
> > ___________________________________
> > 
> > Ce message contient des informations confidentielles ou
> appartenant ?
> > Boursorama et est ?tabli ? l'intention exclusive de ses 
> > destinataires. Toute divulgation, utilisation, diffusion ou 
> > reproduction (totale ou partielle) de ce message, ou des 
> > informations qu'il contient, doit ?tre pr?alablement autoris?e. Tout 
> > message ?lectronique est susceptible d'alt?ration et son int?grit? 
> > ne peut ?tre assur?e. Boursorama d?cline toute responsabilit? au 
> > titre de ce message s'il a ?t? modifi? ou falsifi?. Si vous
> n'?tes pas
> > destinataire de ce message, merci de le d?truire imm?diatement et 
> > d'avertir l'exp?diteur de l'erreur de distribution et de la 
> > destruction du message.
> > ___________________________________
> > 
> > This e-mail contains confidential information or information 
> > belonging to Boursorama and is intended solely for the addressees. 
> > The
> unauthorised
> > disclosure, use, dissemination or copying (either whole or
> > partial) of this
> > e-mail, or any information it contains, is prohibited. 
> > E-mails are susceptible
> > to alteration and their integrity cannot be guaranteed. 
> > Boursorama shall not be
> > liable for this e-mail if modified or falsified. If you are not the 
> > intended recipient of this e-mail, please delete it immediately from 
> > your system and notify the sender of the wrong delivery and the mail 
> > deletion.
> > ___________________________________
> > 
> 
> 
> 
> ___________________________________
> 
> Ce message contient des informations confidentielles ou appartenant ? 
> Boursorama et est ?tabli ? l'intention exclusive de ses destinataires. 
> Toute divulgation, utilisation, diffusion ou reproduction (totale ou 
> partielle) de ce message, ou des informations qu'il contient, doit 
> ?tre pr?alablement autoris?e. Tout message ?lectronique est 
> susceptible d'alt?ration et son int?grit? ne peut ?tre assur?e. 
> Boursorama d?cline toute responsabilit? au titre de ce message s'il a 
> ?t? modifi? ou falsifi?. Si vous n'?tes pas destinataire de ce 
> message, merci de le d?truire imm?diatement et d'avertir l'exp?diteur 
> de l'erreur de distribution et de la destruction du message.
> ___________________________________
> 
> This e-mail contains confidential information or information belonging 
> to Boursorama and is intended solely for the addressees. The 
> unauthorised disclosure, use, dissemination or copying (either whole 
> or
> partial) of this
> e-mail, or any information it contains, is prohibited. 
> E-mails are susceptible
> to alteration and their integrity cannot be guaranteed. 
> Boursorama shall not be
> liable for this e-mail if modified or falsified. If you are not the 
> intended recipient of this e-mail, please delete it immediately from 
> your system and notify the sender of the wrong delivery and the mail 
> deletion.
> ___________________________________



___________________________________

Ce message contient des informations confidentielles ou appartenant ?
Boursorama et est ?tabli ? l'intention exclusive de ses destinataires. Toute
divulgation, utilisation, diffusion ou reproduction (totale ou partielle) de ce
message, ou des informations qu'il contient, doit ?tre pr?alablement
autoris?e. Tout message ?lectronique est susceptible d'alt?ration et son
int?grit? ne peut ?tre assur?e. Boursorama d?cline toute responsabilit? au
titre de ce message s'il a ?t? modifi? ou falsifi?. Si vous n'?tes pas
destinataire de ce message, merci de le d?truire imm?diatement et d'avertir
l'exp?diteur de l'erreur de distribution et de la destruction du message.
___________________________________

This e-mail contains confidential information or information belonging to
Boursorama and is intended solely for the addressees. The unauthorised
disclosure, use, dissemination or copying (either whole or partial) of this
e-mail, or any information it contains, is prohibited. E-mails are susceptible
to alteration and their integrity cannot be guaranteed. Boursorama shall not be
liable for this e-mail if modified or falsified. If you are not the intended
recipient of this e-mail, please delete it immediately from your system and
notify the sender of the wrong delivery and the mail deletion.
___________________________________

From consultant77pk at yahoo.com  Thu Jan 22 06:29:55 2009
From: consultant77pk at yahoo.com (Fahad Aziz)
Date: Thu, 22 Jan 2009 03:29:55 -0800 (PST)
Subject: [Openswan Users] Openswan on CentOS 4.4 (Ker 2.6.9)
Message-ID: <578207.74201.qm@web32203.mail.mud.yahoo.com>

Hello,

I simply used the source package 2.6.19 on my CentOS 4.4 (Kernel 2.6.9) using , 

make programs 
make install

Installation done succesfuly but i didnt do any kernel changes and its giving me error on " service ipsec start" 

Failed to parse config setup portion of ipsec.conf

also with ipsec verify 

Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.09/K(no kernel code presently loaded)
Checking for IPsec support in kernel                            [FAILED]
Checking for RSA private key (/etc/ipsec.secrets)               [DISABLED]
Checking that pluto is running                                  [FAILED]
Two or more interfaces found, checking IP forwarding            [FAILED]
Checking for 'ip' command                                       [OK]
Checking for 'iptables' command                                 [OK]
cat: /etc/ipsec.d/*.conf: No such file or directory

Opportunistic Encryption DNS checks:
   Looking for TXT in forward dns zone: rbl                 [MISSING]
   Does the machine have at least one non-private address?      [OK]
   Looking for TXT in reverse dns zone: 47.132.xxx.xxx.in-addr.arpa.    [MISSING]



Do i need to recompile the kernel for KLIPS, but it says no need for userland tools. I need to create ipsec vpn between to CentOS boxes.. 

Any suggestion



.           (O)
.         \\oOo//  
       _\\ooOoOoo//_
------------------------
consultant77pk at yahoo.com


      

From andrew.colin at gmail.com  Thu Jan 22 07:07:34 2009
From: andrew.colin at gmail.com (andrew colin)
Date: Thu, 22 Jan 2009 14:07:34 +0200
Subject: [Openswan Users] Openswan behind NAT
Message-ID: <31da51d50901220407y4d72a453i2fb0e2425ff10a69@mail.gmail.com>

Hi All,


I have been battling with this for days, am not sure where it is
actually possible as all the posts i have come across do NOT provide a
solution.

My setup is like this


client (10.161.11.2) -------------(10.161.3.39) | NAT Device | (public
ip) ========== dynamic public ip | NAT Device
|(192.168.1,1)----------------| Openswan | (192.168.1.2)

My ipsec.conf is below

version 2.0

config setup
        interfaces=%defaultroute
        protostack=netkey
        #plutodebug=all
        nat_traversal=yes
        virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!192.168.1.0/24

conn %default
        keyingtries=1
        compress=yes
        disablearrivalcheck=no
        authby=rsasig
        leftrsasigkey=%cert
        rightrsasigkey=%cert

conn roadwarrior-net
        leftsubnet=192.168.1.0/24
        also=roadwarrior

conn roadwarrior-all
        leftsubnet=0.0.0.0/0
        also=roadwarrior

conn roadwarrior
        left=192.168.1.2
        leftnexthop=192.168.1.1
        leftcert=kudusoft.home.topdog-software.com.pem
        right=%any
        rightsubnet=vhost:%no,%priv
        rightprotoport=17/1701
        leftprotoport=17/1701
        auto=add
        pfs=yes

conn roadwarrior-l2tp
        type=transport
        left=192.168.1.2
        leftnexthop=192.168.1.1
        leftcert=kudusoft.home.topdog-software.com.pem
        leftprotoport=17/1701
        right=%any
        rightprotoport=17/1701
        rightsubnet=vhost:%no,%priv
        pfs=no

conn roadwarrior-l2tp-oldwin
        left=192.168.1.2
        leftnexthop=192.168.1.1
        leftcert=kudusoft.home.topdog-software.com.pem
        leftprotoport=17/0
        right=%any
        rightprotoport=17/1701
        rightsubnet=vhost:%no,%priv
        pfs=no
        auto=add

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


I keep getting the error below no matter how i change the
configuration, which was originally PSK based.

Jan 22 13:52:00 kudusoft pluto[15493]: "roadwarrior-net"[2]
196.37.xxx.xxx #1: Applying workaround for MS-818043 NAT-T bug
Jan 22 13:52:00 kudusoft pluto[15493]: "roadwarrior-net"[2]
196.37.xxx.xxx #1: IDci was FQDN: \304\037!\353, using
NAT_OA=10.161.11.2/32 as IDci
Jan 22 13:52:00 kudusoft pluto[15493]: "roadwarrior-net"[2]
196.37.xxx.xxx #1: the peer proposed: 196.31.xxx.xxx/32:17/1701 ->
10.161.11.2/32:17/1701
Jan 22 13:52:00 kudusoft pluto[15493]: "roadwarrior-net"[2]
196.37.xxx.xxx #1: cannot respond to IPsec SA request because no
connection is known for
196.31.xxx.xxx/32===192.168.1.2<192.168.1.2>[+S=C]:17/1701...196.37.xxx.xxx[C=ZA,
ST=Gauteng, L=Johannesburg, O=Topdog-software.com,
CN=hacher.xxxxxxx.co.za,+S=C]:17/1701===10.161.11.2/32
Jan 22 13:52:00 kudusoft pluto[15493]: "roadwarrior-net"[2]
196.37.xxx.xxx #1: sending encrypted notification
INVALID_ID_INFORMATION to 196.37.xxx.xxx:50450


I am beginning to think it is impossible to run openswan behind NAT,

Any pointers would be helpful, thanks in advance



-- 
"Dru"
To follow the path, look to the master, follow the master, walk with
the master, see through the master, become the master. (zen)
http://www.topdog.za.net/

From hofferek.attila at daxer.com  Thu Jan 22 09:04:47 2009
From: hofferek.attila at daxer.com (Hofferek Attila)
Date: Thu, 22 Jan 2009 15:04:47 +0100
Subject: [Openswan Users] subnet -> internet
Message-ID: <49787CFF.6050104@daxer.com>

Hi users!

I have a working configuration:

conn pannon
         type=tunnel
         left=a.b.c.d
         leftnexthop=a.b.c.e
	leftsubnet=a.b.c.d/32
         right=w.x.y.z
         rightsubnet=172.31.228.0/23
         spibase=0x200
         keyexchange=ike
         auth=esp
         auto=start
         keylife=24h
         authby=secret
         pfs=no
         keyingtries=3
         rekey=no


a.b.c.d---a.b.c.e...w.x.y.z===172.31.228.0/23

I am the left side. I want to route the 172.31.228.0/23 network to the 
internet. The a.b.c.d machine has got a direct internet connection. What 
to modify on my configuration? I tried leftsubnet=0.0.0.0/0 but there 
was no traffic on ipsec0 with tcpdump -i ipsec0.

Thanks in advance!
-- 
Hofferek Attila

From consultant77pk at yahoo.com  Thu Jan 22 09:35:05 2009
From: consultant77pk at yahoo.com (Fahad Aziz)
Date: Thu, 22 Jan 2009 06:35:05 -0800 (PST)
Subject: [Openswan Users] Openswan stoping issue
Message-ID: <386810.69533.qm@web32208.mail.mud.yahoo.com>

Centos kernel 2.6.9 , openswan 2.4 

service ipsec start successfully but it doesnot respond at 
service ipsec stop

it dont show any error and keep waiting till i cancle presing ctrl^c

it does not stop or show in process but its running 

any suggestions ?

PS: using default conf file.. hanvt done any configs yet.


.           (O)
.         \\oOo//  
       _\\ooOoOoo//_
------------------------
consultant77pk at yahoo.com


      

From aletozetto at santosfc.com.br  Thu Jan 22 09:57:05 2009
From: aletozetto at santosfc.com.br (Alexandre Tozetto - T.I. SFC)
Date: Thu, 22 Jan 2009 12:57:05 -0200
Subject: [Openswan Users] Openswan stoping issue
In-Reply-To: <386810.69533.qm@web32208.mail.mud.yahoo.com>
References: <386810.69533.qm@web32208.mail.mud.yahoo.com>
Message-ID: <49788941.1050008@santosfc.com.br>

Fahad,

and the logs?? don't tell anything? probably something in secure log or 
messages log show anything

the process still running? you can confirm that?

-- 
Alexandre Tozetto
Santos Futebol Clube
Tecnologia da Informa??o - TI
Tel. DDR: +55 (13) 3257-4026
Tel. : +55 (13) 3257-4000
E.Mail: ale at santosfc.com.br
E.Mail do grupo: ti at santosfc.com.br

Pense antes de imprimir, pense em seu compromisso com o Meio Ambiente!!!


Fahad Aziz escreveu:
> Centos kernel 2.6.9 , openswan 2.4 
>
> service ipsec start successfully but it doesnot respond at 
> service ipsec stop
>
> it dont show any error and keep waiting till i cancle presing ctrl^c
>
> it does not stop or show in process but its running 
>
> any suggestions ?
>
> PS: using default conf file.. hanvt done any configs yet.
>
>
> .           (O)
> .         \\oOo//  
>        _\\ooOoOoo//_
> ------------------------
> consultant77pk at yahoo.com
>
>
>       
> _______________________________________________
> 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=283155
>
>   



From aletozetto at santosfc.com.br  Thu Jan 22 10:04:31 2009
From: aletozetto at santosfc.com.br (Alexandre Tozetto - T.I. SFC)
Date: Thu, 22 Jan 2009 13:04:31 -0200
Subject: [Openswan Users] subnet -> internet
In-Reply-To: <49787CFF.6050104@daxer.com>
References: <49787CFF.6050104@daxer.com>
Message-ID: <49788AFF.2000906@santosfc.com.br>

Hofferek

show us your iptables rules, maybe the problem was there!

-- 
Alexandre Tozetto
Santos Futebol Clube
Tecnologia da Informa??o - TI
Tel. DDR: +55 (13) 3257-4026
Tel. : +55 (13) 3257-4000
E.Mail: ale at santosfc.com.br
E.Mail do grupo: ti at santosfc.com.br

Pense antes de imprimir, pense em seu compromisso com o Meio Ambiente!!!


Hofferek Attila escreveu:
> Hi users!
>
> I have a working configuration:
>
> conn pannon
>          type=tunnel
>          left=a.b.c.d
>          leftnexthop=a.b.c.e
> 	leftsubnet=a.b.c.d/32
>          right=w.x.y.z
>          rightsubnet=172.31.228.0/23
>          spibase=0x200
>          keyexchange=ike
>          auth=esp
>          auto=start
>          keylife=24h
>          authby=secret
>          pfs=no
>          keyingtries=3
>          rekey=no
>
>
> a.b.c.d---a.b.c.e...w.x.y.z===172.31.228.0/23
>
> I am the left side. I want to route the 172.31.228.0/23 network to the 
> internet. The a.b.c.d machine has got a direct internet connection. What 
> to modify on my configuration? I tried leftsubnet=0.0.0.0/0 but there 
> was no traffic on ipsec0 with tcpdump -i ipsec0.
>
> Thanks in advance!
>   



From petermcgill at goco.net  Thu Jan 22 10:50:30 2009
From: petermcgill at goco.net (Peter McGill)
Date: Thu, 22 Jan 2009 10:50:30 -0500
Subject: [Openswan Users] subnet -> internet
In-Reply-To: <49787CFF.6050104@daxer.com>
References: <49787CFF.6050104@daxer.com>
Message-ID: <73D6C801FE984720B237BDF496D10B60@peter>

I haven't tried this personally but I recall a thread on the list a few years ago.
It didn't work with subnet 0/0, probably because it is no more specific than the default route.
However I think they got it to work using two subnets, 0/1 and 128/1.

Peter McGill
IT Systems Analyst
Gra Ham Energy Limited 

> -----Original Message-----
> From: users-bounces at openswan.org 
> [mailto:users-bounces at openswan.org] On Behalf Of Hofferek Attila
> Sent: January 22, 2009 9:05 AM
> To: users at openswan.org
> Subject: [Openswan Users] subnet -> internet
> 
> Hi users!
> 
> I have a working configuration:
> 
> conn pannon
>          type=tunnel
>          left=a.b.c.d
>          leftnexthop=a.b.c.e
> 	leftsubnet=a.b.c.d/32
>          right=w.x.y.z
>          rightsubnet=172.31.228.0/23
>          spibase=0x200
>          keyexchange=ike
>          auth=esp
>          auto=start
>          keylife=24h
>          authby=secret
>          pfs=no
>          keyingtries=3
>          rekey=no
> 
> 
> a.b.c.d---a.b.c.e...w.x.y.z===172.31.228.0/23
> 
> I am the left side. I want to route the 172.31.228.0/23 
> network to the 
> internet. The a.b.c.d machine has got a direct internet 
> connection. What 
> to modify on my configuration? I tried leftsubnet=0.0.0.0/0 but there 
> was no traffic on ipsec0 with tcpdump -i ipsec0.
> 
> Thanks in advance!
> -- 
> Hofferek Attila
> _______________________________________________
> 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-294632
> 7?n=283155


From petrik.salovaara at solotes.fi  Fri Jan 16 09:21:51 2009
From: petrik.salovaara at solotes.fi (Petrik Salovaara)
Date: Fri, 16 Jan 2009 16:21:51 +0200
Subject: [Openswan Users] Openswan + Netgear FVS318
Message-ID: <497097FF.3030902@solotes.fi>

Greetings,

I am trying to get a VPN connection between openswan and Netgear FVS318 using PSK. 
My openswan linux box currently works fine with another openswan linux box and 
several roadwarriors using certificates. I have followed instructions on 
http://wiki.openswan.org/index.php/Openswan/NetGearFVS318 without success.

Bottom line is that openswan reports "PAYLOAD_MALFORMED" in STATE_MAIN_I3
Any help is appreciated.

Here's the config in openswan:
> 
> # /etc/ipsec.conf - FreeS/WAN IPsec configuration file
> config setup
>         #plutodebug=all
>         #plutoload=%search
>         #plutostart=%search
>         interfaces=%defaultroute
>         klipsdebug=none
>         nat_traversal=yes
>         plutodebug=none
>         strictcrlpolicy=no
>         uniqueids=yes
>         virtual_private=%v4:192.168.239.0/24
> 
> conn %default
>         auto=add
>         auth=esp
>         compress=no
>         authby=rsasig
>         keyingtries=1
>         left=83.145.201.2
>         leftcert=/etc/ipsec.d/certs/www.solotes.fi_crt.pem
>         leftid="C=FI, O=Solotes Oy, CN=www.solotes.fi"
>         leftnexthop=83.145.201.254
>         leftrsasigkey=%cert
>         leftsubnet=192.168.240.0/24
> 
> conn fvs318
>         type=tunnel
>         left=83.145.201.2
>         leftsubnet=192.168.240.0/24
>         leftnexthop=83.145.201.254
>         leftid="83.145.201.2"
>         right=83.145.204.59
>         rightsubnet=192.168.1.0/24
>         rightnexthop=83.145.204.254
>         rightid="83.145.204.59"
>         ikelifetime=1440m
>         keylife=480m
>         pfs=yes
>         keyexchange=ike
>         authby=secret
>         auto=start
> 
> conn gw-oskari
>         right=%any
>         rightcert=/etc/ipsec.d/certs/gw.osku.solotes.fi_crt.pem
>         rightid="C=FI, O=Solotes Oy, CN=gw.osku.solotes.fi"
>         rightrsasigkey=%cert
>         rightsubnet=192.168.2.0/24
>         type=tunnel
> 
> conn jukka
>         right=%any
>         rightcert=/etc/ipsec.d/certs/jukka.rw.solotes.fi_crt.pem
>         rightid="C=FI, O=Solotes Oy, CN=jukka.rw.solotes.fi"
>         rightrsasigkey=%cert
>         rightsubnet=vhost:%priv
>         type=tunnel
> 
> conn trikki
>         right=%any
>         rightcert=/etc/ipsec.d/certs/trikki.rw.solotes.fi_crt.pem
>         rightid="C=FI, O=Solotes Oy, CN=trikki.rw.solotes.fi"
>         rightrsasigkey=%cert
>         rightsubnet=vhost:%priv
>         type=tunnel


Netgear box is configured as follows:
> http://www.solotes.fi/private/trikki/netgear/fvs318_ike_policy.gif
> http://www.solotes.fi/private/trikki/netgear/fvs318_vpn_auto_policy.gif


This is what goes into log/secure when starting ipsec:
> Jan 14 17:32:34 www ipsec__plutorun: Starting Pluto subsystem...
> Jan 14 17:32:34 www pluto[21402]: Starting Pluto (Openswan Version 2.4.7 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR; Vendor ID OEZ~BaB]r\134p_)
> Jan 14 17:32:34 www pluto[21402]: Setting NAT-Traversal port-4500 floating to on
> Jan 14 17:32:34 www pluto[21402]:    port floating activation criteria nat_t=1/port_fload=1
> Jan 14 17:32:34 www pluto[21402]:   including NAT-Traversal patch (Version 0.6c)
> Jan 14 17:32:34 www pluto[21402]: ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok (ret=0)
> Jan 14 17:32:34 www pluto[21402]: starting up 1 cryptographic helpers
> Jan 14 17:32:34 www pluto[21402]: started helper pid=21406 (fd:6)
> Jan 14 17:32:34 www pluto[21402]: Using NETKEY IPsec interface code on 2.6.18-53.1.19.el5
> Jan 14 17:32:35 www pluto[21402]: Changing to directory '/etc/ipsec.d/cacerts'
> Jan 14 17:32:35 www pluto[21402]:   loaded CA cert file 'solotes-2007_cacert.pem' (1675 bytes)
> Jan 14 17:32:35 www pluto[21402]: Could not change to directory '/etc/ipsec.d/aacerts'
> Jan 14 17:32:35 www pluto[21402]: Could not change to directory '/etc/ipsec.d/ocspcerts'
> Jan 14 17:32:35 www pluto[21402]: Could not change to directory '/etc/ipsec.d/crls'
> Jan 14 17:32:35 www pluto[21402]:   loaded host cert file '/etc/ipsec.d/certs/www.solotes.fi_crt.pem' (4304 bytes)
> Jan 14 17:32:35 www pluto[21402]:   loaded host cert file '/etc/ipsec.d/certs/trikki.rw.solotes.fi_crt.pem' (4318 bytes)
> Jan 14 17:32:35 www pluto[21402]: added connection description "trikki"
> Jan 14 17:32:35 www pluto[21402]:   loaded host cert file '/etc/ipsec.d/certs/www.solotes.fi_crt.pem' (4304 bytes)
> Jan 14 17:32:35 www pluto[21402]:   loaded host cert file '/etc/ipsec.d/certs/gw.osku.solotes.fi_crt.pem' (4312 bytes)
> Jan 14 17:32:35 www pluto[21402]: added connection description "gw-oskari"
> Jan 14 17:32:35 www pluto[21402]:   loaded host cert file '/etc/ipsec.d/certs/www.solotes.fi_crt.pem' (4304 bytes)
> Jan 14 17:32:35 www pluto[21402]:   loaded host cert file '/etc/ipsec.d/certs/jukka.rw.solotes.fi_crt.pem' (4317 bytes)
> Jan 14 17:32:35 www pluto[21402]: added connection description "jukka"
> Jan 14 17:32:35 www pluto[21402]:   loaded host cert file '/etc/ipsec.d/certs/www.solotes.fi_crt.pem' (4304 bytes)
> Jan 14 17:32:35 www pluto[21402]:   no subjectAltName matches ID '83.145.201.2', replaced by subject DN
> Jan 14 17:32:35 www pluto[21402]: added connection description "fvs318"
> Jan 14 17:32:35 www pluto[21402]: listening for IKE messages
> Jan 14 17:32:35 www pluto[21402]: adding interface virbr0/virbr0 192.168.122.1:500
> Jan 14 17:32:35 www pluto[21402]: adding interface virbr0/virbr0 192.168.122.1:4500
> Jan 14 17:32:35 www pluto[21402]: adding interface eth1/eth1 192.168.240.254:500
> Jan 14 17:32:35 www pluto[21402]: adding interface eth1/eth1 192.168.240.254:4500
> Jan 14 17:32:35 www pluto[21402]: adding interface eth0/eth0 83.145.201.2:500
> Jan 14 17:32:35 www pluto[21402]: adding interface eth0/eth0 83.145.201.2:4500
> Jan 14 17:32:35 www pluto[21402]: adding interface eth2/eth2 192.168.240.253:500
> Jan 14 17:32:35 www pluto[21402]: adding interface eth2/eth2 192.168.240.253:4500
> Jan 14 17:32:35 www pluto[21402]: adding interface lo/lo 127.0.0.1:500
> Jan 14 17:32:35 www pluto[21402]: adding interface lo/lo 127.0.0.1:4500
> Jan 14 17:32:35 www pluto[21402]: adding interface lo/lo ::1:500
> Jan 14 17:32:35 www pluto[21402]: loading secrets from "/etc/ipsec.secrets"
> Jan 14 17:32:35 www pluto[21402]:   loaded private key file '/etc/ipsec.d/private/gw.osku.solotes.fi_key.pem' (887 bytes)
> Jan 14 17:32:35 www pluto[21402]:   loaded private key file '/etc/ipsec.d/private/solotes-2007_cakey.pem' (1675 bytes)
> Jan 14 17:32:35 www pluto[21402]:   loaded private key file '/etc/ipsec.d/private/www.solotes.fi_key.pem' (887 bytes)
> Jan 14 17:32:35 www pluto[21402]: "fvs318" #1: initiating Main Mode
> Jan 14 17:32:35 www pluto[21402]: "fvs318" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
> Jan 14 17:32:35 www pluto[21402]: "fvs318" #1: STATE_MAIN_I2: sent MI2, expecting MR2
> Jan 14 17:32:35 www pluto[21402]: packet from 89.27.54.216:500: phase 1 message is part of an unknown exchange
> Jan 14 17:32:36 www pluto[21402]: "fvs318" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
> Jan 14 17:32:36 www pluto[21402]: "fvs318" #1: STATE_MAIN_I3: sent MI3, expecting MR3
> Jan 14 17:32:38 www pluto[21402]: "fvs318" #1: byte 2 of ISAKMP Hash Payload must be zero, but is not
> Jan 14 17:32:38 www pluto[21402]: "fvs318" #1: malformed payload in packet
> Jan 14 17:32:38 www pluto[21402]: | payload malformed after IV
> Jan 14 17:32:38 www pluto[21402]: |   b8 6f 9b ad  f4 a6 c1 21
> Jan 14 17:32:38 www pluto[21402]: "fvs318" #1: sending notification PAYLOAD_MALFORMED to 83.145.204.59:500
> Jan 14 17:32:55 www pluto[21402]: packet from 89.27.54.216:500: phase 1 message is part of an unknown exchange
> Jan 14 17:33:46 www pluto[21402]: "fvs318" #1: max number of retransmissions (2) reached STATE_MAIN_I3.  Possible authentication failure: no acceptable response to our first encrypted message

When turning on plutodebug=all, log shows following:
> http://www.solotes.fi/private/trikki/netgear/log_debug_all.txt

Petrik Salovaara
mailto:petrik.salovaara at solotes.fi



From chris_garrigues at steeprockinc.com  Wed Jan 21 10:05:28 2009
From: chris_garrigues at steeprockinc.com (Chris Garrigues)
Date: Wed, 21 Jan 2009 09:05:28 -0600
Subject: [Openswan Users] OpenSWAN to SonicWALL problems
Message-ID: <497739B8.3090801@steeprockinc.com>

Hi folks.

We have a SonicWALL NSA 4500 and I've been setting up our Linux based
users up using OpenSWAN.  The Linux uses are running various versions of
Linux and OpenSWAN.  Most are working fine, but I've attached a barf
file from one who isn't.  I can't figure this one out and any assistance
would be much appreciated.

Chris

-- 
Chris Garrigues
Senior System Administrator
Ph: (512) 961-6808
chris.garrigues at SteepRockInc.com <mailto:chris.garrigues at SteepRockInc.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090121/b9841a2b/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SteepRockLogo.gif
Type: image/gif
Size: 2419 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/users/attachments/20090121/b9841a2b/attachment-0001.gif 
-------------- next part --------------
An embedded message was scrubbed...
From: Jing Luo <jing.luo at steeprockinc.com>
Subject: barf
Date: Wed, 21 Jan 2009 09:13:41 -0500 (EST)
Size: 84012
Url: http://lists.openswan.org/pipermail/users/attachments/20090121/b9841a2b/attachment-0001.eml 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.openswan.org/pipermail/users/attachments/20090121/b9841a2b/attachment-0001.bin 

From chris_garrigues at steeprockinc.com  Thu Jan 22 08:42:27 2009
From: chris_garrigues at steeprockinc.com (Chris Garrigues)
Date: Thu, 22 Jan 2009 07:42:27 -0600
Subject: [Openswan Users] OpenSWAN to SonicWALL problems
Message-ID: <497877C3.2070608@steeprockinc.com>

Hi folks.

We have a SonicWALL NSA 4500 and I've been setting up our Linux based
users up using OpenSWAN.  The Linux uses are running various versions of
Linux and OpenSWAN.  Most are working fine, but I've attached a barf
file from one who isn't.  I can't figure this one out and any assistance
would be much appreciated.

Chris


localhost.localdomain
Wed Jan 21 09:12:34 EST 2009
+ _________________________ version
+ ipsec --version
Linux Openswan U2.6.14/K2.6.27.5-41.fc9.i686 (netkey)
See `ipsec --copyright' for copyright information.
+ _________________________ /proc/version
+ cat /proc/version
Linux version 2.6.27.5-41.fc9.i686 (mockbuild@) (gcc version 4.3.0
20080428 (Red Hat 4.3.0-8) (GCC) ) #1 SMP Thu Nov 13 20:52:14 EST 2008
+ _________________________ /proc/net/ipsec_eroute
+ test -r /proc/net/ipsec_eroute
+ _________________________ netstat-rn
+ netstat -nr
+ head -n 100
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt
Iface
192.168.15.0    0.0.0.0         255.255.255.0   U         0 0          0
eth0
0.0.0.0         192.168.15.1    0.0.0.0         UG        0 0          0
eth0
+ _________________________ /proc/net/ipsec_spi
+ test -r /proc/net/ipsec_spi
+ _________________________ /proc/net/ipsec_spigrp
+ test -r /proc/net/ipsec_spigrp
+ _________________________ /proc/net/ipsec_tncfg
+ test -r /proc/net/ipsec_tncfg
+ _________________________ /proc/net/pfkey
+ test -r /proc/net/pfkey
+ cat /proc/net/pfkey
sk       RefCnt Rmem   Wmem   User   Inode
+ _________________________ ip-xfrm-state
+ ip xfrm state
+ _________________________ ip-xfrm-policy
+ ip xfrm policy
+ _________________________ /proc/crypto
+ test -r /proc/crypto
+ cat /proc/crypto
name         : deflate
driver       : deflate-generic
module       : deflate
priority     : 0
refcnt       : 1
type         : compression

name         : rfc3686(ctr(aes))
driver       : rfc3686(ctr(aes-asm))
module       : ctr
priority     : 200
refcnt       : 1
type         : blkcipher
blocksize    : 1
min keysize  : 20
max keysize  : 36
ivsize       : 8
geniv        : seqiv

name         : ctr(aes)
driver       : ctr(aes-asm)
module       : ctr
priority     : 200
refcnt       : 1
type         : blkcipher
blocksize    : 1
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : <default>

name         : cbc(twofish)
driver       : cbc(twofish-generic)
module       : cbc
priority     : 100
refcnt       : 1
type         : blkcipher
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : <default>

name         : cbc(camellia)
driver       : cbc(camellia-generic)
module       : cbc
priority     : 100
refcnt       : 1
type         : blkcipher
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : <default>

name         : camellia
driver       : camellia-generic
module       : camellia
priority     : 100
refcnt       : 1
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

name         : cbc(serpent)
driver       : cbc(serpent-generic)
module       : cbc
priority     : 0
refcnt       : 1
type         : blkcipher
blocksize    : 16
min keysize  : 0
max keysize  : 32
ivsize       : 16
geniv        : <default>

name         : cbc(aes)
driver       : cbc(aes-asm)
module       : cbc
priority     : 200
refcnt       : 1
type         : blkcipher
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : <default>

name         : cbc(blowfish)
driver       : cbc(blowfish-generic)
module       : cbc
priority     : 0
refcnt       : 1
type         : blkcipher
blocksize    : 8
min keysize  : 4
max keysize  : 56
ivsize       : 8
geniv        : <default>

name         : cbc(des3_ede)
driver       : cbc(des3_ede-generic)
module       : cbc
priority     : 0
refcnt       : 1
type         : blkcipher
blocksize    : 8
min keysize  : 24
max keysize  : 24
ivsize       : 8
geniv        : <default>

name         : cbc(des)
driver       : cbc(des-generic)
module       : cbc
priority     : 0
refcnt       : 1
type         : blkcipher
blocksize    : 8
min keysize  : 8
max keysize  : 8
ivsize       : 8
geniv        : <default>

name         : xcbc(aes)
driver       : xcbc(aes-asm)
module       : xcbc
priority     : 200
refcnt       : 1
type         : hash
blocksize    : 16
digestsize   : 16

name         : hmac(rmd160)
driver       : hmac(rmd160)
module       : kernel
priority     : 0
refcnt       : 1
type         : hash
blocksize    : 64
digestsize   : 20

name         : rmd160
driver       : rmd160
module       : rmd160
priority     : 0
refcnt       : 1
type         : digest
blocksize    : 64
digestsize   : 20

name         : hmac(sha256)
driver       : hmac(sha256-generic)
module       : kernel
priority     : 0
refcnt       : 1
type         : hash
blocksize    : 64
digestsize   : 32

name         : hmac(sha1)
driver       : hmac(sha1-generic)
module       : kernel
priority     : 0
refcnt       : 1
type         : hash
blocksize    : 64
digestsize   : 20

name         : hmac(md5)
driver       : hmac(md5-generic)
module       : kernel
priority     : 0
refcnt       : 1
type         : hash
blocksize    : 64
digestsize   : 16

name         : compress_null
driver       : compress_null-generic
module       : crypto_null
priority     : 0
refcnt       : 1
type         : compression

name         : digest_null
driver       : digest_null-generic
module       : crypto_null
priority     : 0
refcnt       : 1
type         : digest
blocksize    : 1
digestsize   : 0

name         : ecb(cipher_null)
driver       : ecb-cipher_null
module       : crypto_null
priority     : 100
refcnt       : 1
type         : blkcipher
blocksize    : 1
min keysize  : 0
max keysize  : 0
ivsize       : 0
geniv        : <default>

name         : cipher_null
driver       : cipher_null-generic
module       : crypto_null
priority     : 0
refcnt       : 1
type         : cipher
blocksize    : 1
min keysize  : 0
max keysize  : 0

name         : tnepres
driver       : tnepres-generic
module       : serpent
priority     : 0
refcnt       : 1
type         : cipher
blocksize    : 16
min keysize  : 0
max keysize  : 32

name         : serpent
driver       : serpent-generic
module       : serpent
priority     : 0
refcnt       : 1
type         : cipher
blocksize    : 16
min keysize  : 0
max keysize  : 32

name         : blowfish
driver       : blowfish-generic
module       : blowfish
priority     : 0
refcnt       : 1
type         : cipher
blocksize    : 8
min keysize  : 4
max keysize  : 56

name         : twofish
driver       : twofish-generic
module       : twofish
priority     : 100
refcnt       : 1
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

name         : sha256
driver       : sha256-generic
module       : sha256_generic
priority     : 0
refcnt       : 1
type         : digest
blocksize    : 64
digestsize   : 32

name         : sha224
driver       : sha224-generic
module       : sha256_generic
priority     : 0
refcnt       : 1
type         : digest
blocksize    : 64
digestsize   : 28

name         : sha512
driver       : sha512-generic
module       : sha512_generic
priority     : 0
refcnt       : 1
type         : digest
blocksize    : 128
digestsize   : 64

name         : sha384
driver       : sha384-generic
module       : sha512_generic
priority     : 0
refcnt       : 1
type         : digest
blocksize    : 128
digestsize   : 48

name         : des3_ede
driver       : des3_ede-generic
module       : des_generic
priority     : 0
refcnt       : 1
type         : cipher
blocksize    : 8
min keysize  : 24
max keysize  : 24

name         : des
driver       : des-generic
module       : des_generic
priority     : 0
refcnt       : 1
type         : cipher
blocksize    : 8
min keysize  : 8
max keysize  : 8

name         : aes
driver       : aes-asm
module       : aes_i586
priority     : 200
refcnt       : 1
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

name         : aes
driver       : aes-generic
module       : aes_generic
priority     : 100
refcnt       : 1
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

name         : sha1
driver       : sha1-generic
module       : kernel
priority     : 0
refcnt       : 1
type         : digest
blocksize    : 64
digestsize   : 20

name         : md5
driver       : md5-generic
module       : kernel
priority     : 0
refcnt       : 1
type         : digest
blocksize    : 64
digestsize   : 16

+ __________________________/proc/sys/net/core/xfrm-star
/usr/libexec/ipsec/barf: line 191:
__________________________/proc/sys/net/core/xfrm-star: No such file or
directory
+ for i in '/proc/sys/net/core/xfrm_*'
+ echo -n '/proc/sys/net/core/xfrm_acq_expires: '
/proc/sys/net/core/xfrm_acq_expires: + cat
/proc/sys/net/core/xfrm_acq_expires
30
+ for i in '/proc/sys/net/core/xfrm_*'
+ echo -n '/proc/sys/net/core/xfrm_aevent_etime: '
/proc/sys/net/core/xfrm_aevent_etime: + cat
/proc/sys/net/core/xfrm_aevent_etime
10
+ for i in '/proc/sys/net/core/xfrm_*'
+ echo -n '/proc/sys/net/core/xfrm_aevent_rseqth: '
/proc/sys/net/core/xfrm_aevent_rseqth: + cat
/proc/sys/net/core/xfrm_aevent_rseqth
2
+ for i in '/proc/sys/net/core/xfrm_*'
+ echo -n '/proc/sys/net/core/xfrm_larval_drop: '
/proc/sys/net/core/xfrm_larval_drop: + cat
/proc/sys/net/core/xfrm_larval_drop
0
+ _________________________ /proc/sys/net/ipsec-star
+ test -d /proc/sys/net/ipsec
+ _________________________ ipsec/status
+ ipsec auto --status
000 using kernel interface: netkey
000 %myid = (none)
000 debug none
000 
000 algorithm ESP encrypt: id=2, name=ESP_DES, ivlen=8, keysizemin=64,
keysizemax=64
000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, keysizemin=192,
keysizemax=192
000 algorithm ESP encrypt: id=7, name=ESP_BLOWFISH, ivlen=8,
keysizemin=40, keysizemax=448
000 algorithm ESP encrypt: id=11, name=ESP_NULL, ivlen=0, keysizemin=0,
keysizemax=0
000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=8, keysizemin=128,
keysizemax=256
000 algorithm ESP encrypt: id=13, name=ESP_AES_CTR, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=14, name=ESP_AES_CCM_A, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=15, name=ESP_AES_CCM_B, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=16, name=ESP_AES_CCM_C, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=18, name=ESP_AES_GCM_A, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=19, name=ESP_AES_GCM_B, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=20, name=ESP_AES_GCM_C, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=22, name=ESP_CAMELLIA, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=252, name=ESP_SERPENT, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=253, name=ESP_TWOFISH, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5,
keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1,
keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=5, name=AUTH_ALGORITHM_HMAC_SHA2_256,
keysizemin=256, keysizemax=256
000 algorithm ESP auth attr: id=8, name=AUTH_ALGORITHM_HMAC_RIPEMD,
keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=9, name=AUTH_ALGORITHM_AES_CBC,
keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=251, name=(null), keysizemin=0, keysizemax=0
000 
000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=131
000 algorithm IKE encrypt: id=3, name=OAKLEY_BLOWFISH_CBC, blocksize=8,
keydeflen=128
000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8,
keydeflen=192
000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16,
keydeflen=128
000 algorithm IKE encrypt: id=65004, name=OAKLEY_SERPENT_CBC,
blocksize=16, keydeflen=128
000 algorithm IKE encrypt: id=65005, name=OAKLEY_TWOFISH_CBC,
blocksize=16, keydeflen=128
000 algorithm IKE encrypt: id=65289, name=OAKLEY_TWOFISH_CBC_SSH,
blocksize=16, keydeflen=128
000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
000 algorithm IKE hash: id=4, name=OAKLEY_SHA2_256, hashsize=32
000 algorithm IKE hash: id=6, name=OAKLEY_SHA2_512, hashsize=64
000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192
000 
000 stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,0,0}
trans={0,0,0} attrs={0,0,0}
000 
000 "vo":
192.168.10.0/24===67.220.126.196<67.220.126.196>[@vo,+S=C]...0.0.0.0---%any[@jingluo,+S=C]===192.168.200.56/32;
unrouted; eroute owner: #0
000 "vo":     myip=unset; hisip=192.168.200.56;
000 "vo":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s;
rekey_fuzz: 100%; keyingtries: 0
000 "vo":   policy: PSK+ENCRYPT+TUNNEL+PFS+IKEv2ALLOW+lKOD+rKOD; prio:
24,32; interface: ;
000 "vo":   newest ISAKMP SA: #0; newest IPsec SA: #0;
000 "vo":   IKE algorithms wanted: AES_CBC(7)_256-SHA1(2)-MODP1536(5),
AES_CBC(7)_256-SHA1(2)-MODP1024(2); flags=-strict
000 "vo":   IKE algorithms found:  AES_CBC(7)_256-SHA1(2)_160-5,
AES_CBC(7)_256-SHA1(2)_160-2,
000 "vo":   ESP algorithms wanted: AES(12)_256-SHA1(2); flags=-strict
000 "vo":   ESP algorithms loaded: AES(12)_256-SHA1(2)_160
000 "vodmz":
192.168.8.0/24===67.220.126.196<67.220.126.196>[@vo,+S=C]...0.0.0.0---%any[@jingluo,+S=C]===192.168.200.56/32;
unrouted; eroute owner: #0
000 "vodmz":     myip=unset; hisip=192.168.200.56;
000 "vodmz":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s;
rekey_fuzz: 100%; keyingtries: 0
000 "vodmz":   policy: PSK+ENCRYPT+TUNNEL+PFS+IKEv2ALLOW+lKOD+rKOD;
prio: 24,32; interface: ;
000 "vodmz":   newest ISAKMP SA: #0; newest IPsec SA: #0;
000 "vodmz":   IKE algorithms wanted:
AES_CBC(7)_256-SHA1(2)-MODP1536(5), AES_CBC(7)_256-SHA1(2)-MODP1024(2);
flags=-strict
000 "vodmz":   IKE algorithms found:  AES_CBC(7)_256-SHA1(2)_160-5,
AES_CBC(7)_256-SHA1(2)_160-2,
000 "vodmz":   ESP algorithms wanted: AES(12)_256-SHA1(2); flags=-strict
000 "vodmz":   ESP algorithms loaded: AES(12)_256-SHA1(2)_160
000 
000 
+ _________________________ ifconfig-a
+ ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:1A:A0:49:D6:F0 
          inet addr:192.168.15.3  Bcast:192.168.15.255  Mask:255.255.255.0
          inet6 addr: fe80::21a:a0ff:fe49:d6f0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:280 errors:0 dropped:0 overruns:0 frame:0
          TX packets:293 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:232070 (226.6 KiB)  TX bytes:59972 (58.5 KiB)
          Interrupt:16

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:7774 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7774 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:388860 (379.7 KiB)  TX bytes:388860 (379.7 KiB)

pan0      Link encap:Ethernet  HWaddr 42:44:14:66:91:88 
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

+ _________________________ ip-addr-list
+ ip addr list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
    link/ether 00:1a:a0:49:d6:f0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.15.3/24 brd 192.168.15.255 scope global eth0
    inet6 fe80::21a:a0ff:fe49:d6f0/64 scope link
       valid_lft forever preferred_lft forever
3: pan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
    link/ether 42:44:14:66:91:88 brd ff:ff:ff:ff:ff:ff
+ _________________________ ip-route-list
+ ip route list
192.168.15.0/24 dev eth0  proto kernel  scope link  src 192.168.15.3
default via 192.168.15.1 dev eth0  proto static
+ _________________________ ip-rule-list
+ ip rule list
0:    from all lookup local
32766:    from all lookup main
32767:    from all lookup default
+ _________________________ ipsec_verify
+ ipsec verify --nocolour
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.14/K2.6.27.5-41.fc9.i686 (netkey)
Checking for IPsec support in kernel                            [OK]
NETKEY detected, testing for disabled ICMP send_redirects       [FAILED]

  Please disable /proc/sys/net/ipv4/conf/*/send_redirects
  or NETKEY will cause the sending of bogus ICMP redirects!

NETKEY detected, testing for disabled ICMP accept_redirects     [FAILED]

  Please disable /proc/sys/net/ipv4/conf/*/accept_redirects
  or NETKEY will accept bogus ICMP redirects!

Checking for RSA private key (/etc/ipsec.secrets)               [OK]
Checking that pluto is running                                  [OK]
Pluto not listening on port udp 500. Check interfaces defintion in
ipsec.conf.Two or more interfaces found, checking IP forwarding       
    [FAILED]
Checking for 'ip' command                                       [OK]
Checking for 'iptables' command                                 [OK]

Opportunistic Encryption DNS checks:
   Looking for TXT in forward dns zone: localhost.localdomain    [MISSING]
   Does the machine have at least one non-private address?      [FAILED]
+ _________________________ mii-tool
+ '[' -x /sbin/mii-tool ']'
+ /sbin/mii-tool -v
eth0: negotiated 100baseTx-FD, link ok
  product info: vendor 00:50:ef, model 14 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
  link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
+ _________________________ ipsec/directory
+ ipsec --directory
/usr/libexec/ipsec
+ _________________________ hostname/fqdn
+ hostname --fqdn
localhost.localdomain
+ _________________________ hostname/ipaddress
+ hostname --ip-address
127.0.0.1
+ _________________________ uptime
+ uptime
 09:12:55 up 13 min,  2 users,  load average: 0.18, 0.27, 0.19
+ _________________________ ps
+ ps alxwf
+ egrep -i 'ppid|pluto|ipsec|klips'
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
4     0  4865  3471  20   0   5668  1136 wait   S+   pts/1     
0:00              \_ /bin/sh /usr/libexec/ipsec/barf
0     0  4984  4865  20   0   2044   504 pipe_w S+   pts/1     
0:00                  \_ egrep -i ppid|pluto|ipsec|klips
1     0  4642     1  20   0   2668   412 wait   S    pts/1      0:00
/bin/sh /usr/libexec/ipsec/_plutorun --debug  --uniqueids no
--force_busy no --nocrsend no --strictcrlpolicy  --nat_traversal yes
--keep_alive  --protostack netkey --force_keepalive 
--disable_port_floating  --virtual_private  --crlcheckinterval 0
--ocspuri  --nhelpers  --dump  --opts  --stderrlog  --wait no --pre 
--post  --log daemon.error --plutorestartoncrash false --pid
/var/run/pluto/pluto.pid
1     0  4646  4642  20   0   2668   544 wait   S    pts/1      0:00  \_
/bin/sh /usr/libexec/ipsec/_plutorun --debug  --uniqueids no
--force_busy no --nocrsend no --strictcrlpolicy  --nat_traversal yes
--keep_alive  --protostack netkey --force_keepalive 
--disable_port_floating  --virtual_private  --crlcheckinterval 0
--ocspuri  --nhelpers  --dump  --opts  --stderrlog  --wait no --pre 
--post  --log daemon.error --plutorestartoncrash false --pid
/var/run/pluto/pluto.pid
4     0  4647  4646  20   0   3260  1156 select S    pts/1      0:00 
|   \_ /usr/libexec/ipsec/pluto --nofork --secretsfile
/etc/ipsec.secrets --use-netkey --nat_traversal
1     0  4648  4647  30  10   3268   580 unix_s SN   pts/1      0:00 
|       \_ pluto helper  # 
0                                                                            

0     0  4685  4647  20   0   1756   296 select S    pts/1      0:00 
|       \_ _pluto_adns
4     0  4651  4642  20   0   2668   964 pipe_w S    pts/1      0:00  \_
/bin/sh /usr/libexec/ipsec/_plutoload --wait no --post
4     0  4643     1  20   0   1808   504 pipe_w S    pts/1      0:00
logger -s -p daemon.error -t ipsec__plutorun
+ _________________________ ipsec/showdefaults
+ ipsec showdefaults
ipsec showdefaults: cannot find defaults file `/var/run/pluto/ipsec.info'
+ _________________________ ipsec/conf
+ ipsec _include /etc/ipsec.conf
+ ipsec _keycensor

#< /etc/ipsec.conf 1
# /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"
    # For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
    protostack=netkey
    nat_traversal=yes


#< /etc/ipsec.d/ipsec.conf 1
conn vo
    also=vocommon
    rightsubnet=192.168.10.0/24
    auto=start

conn vodmz
    also=vocommon
    rightsubnet=192.168.8.0/24
    auto=start

conn vocommon
    type=tunnel
    left=%defaultroute
    leftid=@jingluo
    leftsourceip=192.168.200.56
    leftsubnet=192.168.200.56/32
    rightid=@vo
    right=67.220.126.196
    keyingtries=0
    pfs=yes
    authby=secret
    auth=esp
    ike=aes256-sha1
    esp=aes256-sha1
    keyexchange=ike


#> /etc/ipsec.conf 19
+ _________________________ ipsec/secrets
+ ipsec _include /etc/ipsec.secrets
+ ipsec _secretcensor

#< /etc/ipsec.secrets 1

#< /etc/ipsec.d/ipsec.secrets 1
@jingluo @vo : PSK "[sums to 3db3...]"

#> /etc/ipsec.secrets 2
+ _________________________ ipsec/listall
+ ipsec auto --listall
000 
000 List of Public Keys:
000 
000 List of Pre-shared secrets (from /etc/ipsec.secrets)
+ '[' /etc/ipsec.d/policies ']'
+ for policy in '$POLICIES/*'
++ basename /etc/ipsec.d/policies/block
+ base=block
+ _________________________ ipsec/policies/block
+ cat /etc/ipsec.d/policies/block
# This file defines the set of CIDRs (network/mask-length) to which
# communication should never be allowed.
#
# See /usr/share/doc/openswan/policygroups.html for details.
#
# $Id: block.in,v 1.4 2003/02/17 02:22:15 mcr Exp $
#

+ for policy in '$POLICIES/*'
++ basename /etc/ipsec.d/policies/clear
+ base=clear
+ _________________________ ipsec/policies/clear
+ cat /etc/ipsec.d/policies/clear
# This file defines the set of CIDRs (network/mask-length) to which
# communication should always be in the clear.
#
# See /usr/share/doc/openswan/policygroups.html for details.
#

# root name servers should be in the clear
192.58.128.30/32
198.41.0.4/32
192.228.79.201/32
192.33.4.12/32
128.8.10.90/32
192.203.230.10/32
192.5.5.241/32
192.112.36.4/32
128.63.2.53/32
192.36.148.17/32
193.0.14.129/32
199.7.83.42/32
202.12.27.33/32
+ for policy in '$POLICIES/*'
++ basename /etc/ipsec.d/policies/clear-or-private
+ base=clear-or-private
+ _________________________ ipsec/policies/clear-or-private
+ cat /etc/ipsec.d/policies/clear-or-private
# This file defines the set of CIDRs (network/mask-length) to which
# we will communicate in the clear, or, if the other side initiates IPSEC,
# using encryption.  This behaviour is also called "Opportunistic
Responder".
#
# See /usr/share/doc/openswan/policygroups.html for details.
#
# $Id: clear-or-private.in,v 1.4 2003/02/17 02:22:15 mcr Exp $
#
+ for policy in '$POLICIES/*'
++ basename /etc/ipsec.d/policies/private
+ base=private
+ _________________________ ipsec/policies/private
+ cat /etc/ipsec.d/policies/private
# This file defines the set of CIDRs (network/mask-length) to which
# communication should always be private (i.e. encrypted).
# See /usr/share/doc/openswan/policygroups.html for details.
#
# $Id: private.in,v 1.4 2003/02/17 02:22:15 mcr Exp $
#
+ for policy in '$POLICIES/*'
++ basename /etc/ipsec.d/policies/private-or-clear
+ base=private-or-clear
+ _________________________ ipsec/policies/private-or-clear
+ cat /etc/ipsec.d/policies/private-or-clear
# This file defines the set of CIDRs (network/mask-length) to which
# communication should be private, if possible, but in the clear otherwise.
#
# If the target has a TXT (later IPSECKEY) record that specifies
# authentication material, we will require private (i.e. encrypted)
# communications.  If no such record is found, communications will be
# in the clear.
#
# See /usr/share/doc/openswan/policygroups.html for details.
#
# $Id: private-or-clear.in,v 1.5 2003/02/17 02:22:15 mcr Exp $
#

0.0.0.0/0
+ _________________________ ipsec/ls-libdir
+ ls -l /usr/libexec/ipsec
total 2256
-rwxr-xr-x 1 root root   6056 Jun  6  2008 _copyright
-rwxr-xr-x 1 root root   2379 Jun  6  2008 _include
-rwxr-xr-x 1 root root   1475 Jun  6  2008 _keycensor
-rwxr-xr-x 1 root root  10088 Jun  6  2008 _pluto_adns
-rwxr-xr-x 1 root root   2632 Jun  6  2008 _plutoload
-rwxr-xr-x 1 root root   7602 Jun  6  2008 _plutorun
-rwxr-xr-x 1 root root  13746 Jun  6  2008 _realsetup
-rwxr-xr-x 1 root root   1975 Jun  6  2008 _secretcensor
-rwxr-xr-x 1 root root   9752 Jun  6  2008 _startklips
-rwxr-xr-x 1 root root   9752 Jun  6  2008 _startklips.old
-rwxr-xr-x 1 root root   4988 Jun  6  2008 _startnetkey
-rwxr-xr-x 1 root root   4949 Jun  6  2008 _updown
-rwxr-xr-x 1 root root  14030 Jun  6  2008 _updown.klips
-rwxr-xr-x 1 root root  14030 Jun  6  2008 _updown.klips.old
-rwxr-xr-x 1 root root  13739 Jun  6  2008 _updown.mast
-rwxr-xr-x 1 root root  13739 Jun  6  2008 _updown.mast.old
-rwxr-xr-x 1 root root   8337 Jun  6  2008 _updown.netkey
-rwxr-xr-x 1 root root 188348 Jun  6  2008 addconn
-rwxr-xr-x 1 root root   6129 Jun  6  2008 auto
-rwxr-xr-x 1 root root  10758 Jun  6  2008 barf
-rwxr-xr-x 1 root root  90088 Jun  6  2008 eroute
-rwxr-xr-x 1 root root  20708 Jun  6  2008 ikeping
-rwxr-xr-x 1 root root  69804 Jun  6  2008 klipsdebug
-rwxr-xr-x 1 root root   1836 Jun  6  2008 livetest
-rwxr-xr-x 1 root root   2591 Jun  6  2008 look
-rwxr-xr-x 1 root root   1921 Jun  6  2008 newhostkey
-rwxr-xr-x 1 root root  60840 Jun  6  2008 pf_key
-rwxr-xr-x 1 root root 957728 Jun  6  2008 pluto
-rwxr-xr-x 1 root root  10236 Jun  6  2008 ranbits
-rwxr-xr-x 1 root root  20176 Jun  6  2008 rsasigkey
-rwxr-xr-x 1 root root    766 Jun  6  2008 secrets
lrwxrwxrwx 1 root root     30 Jan 20 09:30 setup ->
../../../etc/rc.d/init.d/ipsec
-rwxr-xr-x 1 root root   1054 Jun  6  2008 showdefaults
-rwxr-xr-x 1 root root 219368 Jun  6  2008 showhostkey
-rwxr-xr-x 1 root root  22744 Jun  6  2008 showpolicy
-rwxr-xr-x 1 root root 148388 Jun  6  2008 spi
-rwxr-xr-x 1 root root  77336 Jun  6  2008 spigrp
-rwxr-xr-x 1 root root  69700 Jun  6  2008 tncfg
-rwxr-xr-x 1 root root  12526 Jun  6  2008 verify
-rwxr-xr-x 1 root root  50340 Jun  6  2008 whack
+ _________________________ ipsec/ls-execdir
+ ls -l /usr/libexec/ipsec
total 2256
-rwxr-xr-x 1 root root   6056 Jun  6  2008 _copyright
-rwxr-xr-x 1 root root   2379 Jun  6  2008 _include
-rwxr-xr-x 1 root root   1475 Jun  6  2008 _keycensor
-rwxr-xr-x 1 root root  10088 Jun  6  2008 _pluto_adns
-rwxr-xr-x 1 root root   2632 Jun  6  2008 _plutoload
-rwxr-xr-x 1 root root   7602 Jun  6  2008 _plutorun
-rwxr-xr-x 1 root root  13746 Jun  6  2008 _realsetup
-rwxr-xr-x 1 root root   1975 Jun  6  2008 _secretcensor
-rwxr-xr-x 1 root root   9752 Jun  6  2008 _startklips
-rwxr-xr-x 1 root root   9752 Jun  6  2008 _startklips.old
-rwxr-xr-x 1 root root   4988 Jun  6  2008 _startnetkey
-rwxr-xr-x 1 root root   4949 Jun  6  2008 _updown
-rwxr-xr-x 1 root root  14030 Jun  6  2008 _updown.klips
-rwxr-xr-x 1 root root  14030 Jun  6  2008 _updown.klips.old
-rwxr-xr-x 1 root root  13739 Jun  6  2008 _updown.mast
-rwxr-xr-x 1 root root  13739 Jun  6  2008 _updown.mast.old
-rwxr-xr-x 1 root root   8337 Jun  6  2008 _updown.netkey
-rwxr-xr-x 1 root root 188348 Jun  6  2008 addconn
-rwxr-xr-x 1 root root   6129 Jun  6  2008 auto
-rwxr-xr-x 1 root root  10758 Jun  6  2008 barf
-rwxr-xr-x 1 root root  90088 Jun  6  2008 eroute
-rwxr-xr-x 1 root root  20708 Jun  6  2008 ikeping
-rwxr-xr-x 1 root root  69804 Jun  6  2008 klipsdebug
-rwxr-xr-x 1 root root   1836 Jun  6  2008 livetest
-rwxr-xr-x 1 root root   2591 Jun  6  2008 look
-rwxr-xr-x 1 root root   1921 Jun  6  2008 newhostkey
-rwxr-xr-x 1 root root  60840 Jun  6  2008 pf_key
-rwxr-xr-x 1 root root 957728 Jun  6  2008 pluto
-rwxr-xr-x 1 root root  10236 Jun  6  2008 ranbits
-rwxr-xr-x 1 root root  20176 Jun  6  2008 rsasigkey
-rwxr-xr-x 1 root root    766 Jun  6  2008 secrets
lrwxrwxrwx 1 root root     30 Jan 20 09:30 setup ->
../../../etc/rc.d/init.d/ipsec
-rwxr-xr-x 1 root root   1054 Jun  6  2008 showdefaults
-rwxr-xr-x 1 root root 219368 Jun  6  2008 showhostkey
-rwxr-xr-x 1 root root  22744 Jun  6  2008 showpolicy
-rwxr-xr-x 1 root root 148388 Jun  6  2008 spi
-rwxr-xr-x 1 root root  77336 Jun  6  2008 spigrp
-rwxr-xr-x 1 root root  69700 Jun  6  2008 tncfg
-rwxr-xr-x 1 root root  12526 Jun  6  2008 verify
-rwxr-xr-x 1 root root  50340 Jun  6  2008 whack
+ _________________________ /proc/net/dev
+ cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed
multicast|bytes    packets errs drop fifo colls carrier compressed
    lo:  388860    7774    0    0    0     0          0         0  
388860    7774    0    0    0     0       0          0
  eth0:  232513     283    0    0    0     0          0         0   
60510     300    0    0    0     0       0          0
  pan0:       0       0    0    0    0     0          0         0       
0       0    0    0    0     0       0          0
+ _________________________ /proc/net/route
+ cat /proc/net/route
Iface    Destination    Gateway     Flags    RefCnt    Use    Metric   
Mask        MTU    Window   
IRTT                                                      
eth0    000FA8C0    00000000    0001    0    0    0    00FFFFFF    0   
0   
0                                                                              

eth0    00000000    010FA8C0    0003    0    0    0    00000000    0   
0   
0                                                                              

+ _________________________ /proc/sys/net/ipv4/ip_no_pmtu_disc
+ cat /proc/sys/net/ipv4/ip_no_pmtu_disc
0
+ _________________________ /proc/sys/net/ipv4/ip_forward
+ cat /proc/sys/net/ipv4/ip_forward
0
+ _________________________ /proc/sys/net/ipv4/tcp_ecn
+ cat /proc/sys/net/ipv4/tcp_ecn
0
+ _________________________ /proc/sys/net/ipv4/conf/star-rp_filter
+ cd /proc/sys/net/ipv4/conf
+ egrep '^' all/rp_filter default/rp_filter eth0/rp_filter lo/rp_filter
pan0/rp_filter
all/rp_filter:0
default/rp_filter:1
eth0/rp_filter:1
lo/rp_filter:1
pan0/rp_filter:1
+ _________________________ /proc/sys/net/ipv4/conf/star-star-redirects
+ cd /proc/sys/net/ipv4/conf
+ egrep '^' all/accept_redirects all/secure_redirects all/send_redirects
default/accept_redirects default/secure_redirects default/send_redirects
eth0/accept_redirects eth0/secure_redirects eth0/send_redirects
lo/accept_redirects lo/secure_redirects lo/send_redirects
pan0/accept_redirects pan0/secure_redirects pan0/send_redirects
all/accept_redirects:1
all/secure_redirects:1
all/send_redirects:1
default/accept_redirects:1
default/secure_redirects:1
default/send_redirects:1
eth0/accept_redirects:1
eth0/secure_redirects:1
eth0/send_redirects:1
lo/accept_redirects:1
lo/secure_redirects:1
lo/send_redirects:1
pan0/accept_redirects:1
pan0/secure_redirects:1
pan0/send_redirects:1
+ _________________________ /proc/sys/net/ipv4/tcp_window_scaling
+ cat /proc/sys/net/ipv4/tcp_window_scaling
1
+ _________________________ /proc/sys/net/ipv4/tcp_adv_win_scale
+ cat /proc/sys/net/ipv4/tcp_adv_win_scale
2
+ _________________________ uname-a
+ uname -a
Linux localhost.localdomain 2.6.27.5-41.fc9.i686 #1 SMP Thu Nov 13
20:52:14 EST 2008 i686 i686 i386 GNU/Linux
+ _________________________ config-built-with
+ test -r /proc/config_built_with
+ _________________________ distro-release
+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release
+ test -f /etc/redhat-release
+ cat /etc/redhat-release
Fedora release 9 (Sulphur)
+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release
+ test -f /etc/debian-release
+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release
+ test -f /etc/SuSE-release
+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release
+ test -f /etc/mandrake-release
+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release
+ test -f /etc/mandriva-release
+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release
+ test -f /etc/gentoo-release
+ _________________________ /proc/net/ipsec_version
+ test -r /proc/net/ipsec_version
+ test -r /proc/net/pfkey
++ uname -r
+ echo 'NETKEY (2.6.27.5-41.fc9.i686) support detected '
NETKEY (2.6.27.5-41.fc9.i686) support detected
+ _________________________ iptables
+ test -r /sbin/iptables
+ iptables -L -v -n
+ _________________________ iptables-nat
+ iptables -t nat -L -v -n
+ _________________________ iptables-mangle
+ iptables -t mangle -L -v -n
+ _________________________ /proc/modules
+ test -f /proc/modules
+ cat /proc/modules
iptable_mangle 6656 0 - Live 0xfad5d000
iptable_nat 8712 0 - Live 0xfad7a000
nf_nat 17944 1 iptable_nat, Live 0xfad81000
ipcomp6 6912 0 - Live 0xfacdb000
ipcomp 6656 0 - Live 0xfac54000
ah6 9216 0 - Live 0xfad76000
ah4 8320 0 - Live 0xfacd3000
esp6 9472 0 - Live 0xfaccf000
esp4 9472 0 - Live 0xfaccb000
xfrm4_mode_beet 6400 0 - Live 0xfacbc000
xfrm4_tunnel 6272 0 - Live 0xfacb9000
xfrm4_mode_tunnel 6272 0 - Live 0xfacb6000
xfrm4_mode_transport 5760 0 - Live 0xfacb3000
xfrm6_mode_transport 5760 0 - Live 0xfac86000
xfrm6_mode_ro 5632 0 - Live 0xfac83000
xfrm6_mode_beet 6144 0 - Live 0xfac80000
xfrm6_mode_tunnel 6144 0 - Live 0xfac7d000
af_key 30356 0 - Live 0xfac66000
nls_utf8 5632 1 - Live 0xfad73000
deflate 6528 0 - Live 0xfad60000
zlib_deflate 21224 1 deflate, Live 0xfad6c000
ctr 7936 0 - Live 0xfad34000
camellia 22144 0 - Live 0xfad65000
bridge 43668 0 - Live 0xfad47000
stp 6148 1 bridge, Live 0xfad37000
bnep 14848 2 - Live 0xfad2a000
rfcomm 33936 4 - Live 0xfad53000
rmd160 14720 0 - Live 0xfad2f000
l2cap 21504 16 bnep,rfcomm, Live 0xfad18000
bluetooth 48608 5 bnep,rfcomm,l2cap, Live 0xfad3a000
crypto_null 6784 0 - Live 0xfad0f000
ccm 11776 0 - Live 0xfad26000
serpent 22912 0 - Live 0xfad1f000
blowfish 12032 0 - Live 0xfacf7000
twofish 10880 0 - Live 0xfad0b000
twofish_common 17024 1 twofish, Live 0xfad12000
ecb 6528 0 - Live 0xfad08000
xcbc 8200 0 - Live 0xfad04000
cbc 7168 0 - Live 0xfacfb000
crypto_blkcipher 18052 5 ctr,crypto_null,ccm,ecb,cbc, Live 0xfacfe000
sha256_generic 16128 0 - Live 0xfacee000
sha512_generic 11904 0 - Live 0xfacf3000
des_generic 20352 0 - Live 0xfacde000
aes_i586 11648 0 - Live 0xfacbf000
aes_generic 31144 1 aes_i586, Live 0xface5000
xfrm_ipcomp 8584 2 ipcomp6,ipcomp, Live 0xfacd7000
aead 9600 3 esp6,esp4,ccm, Live 0xfacc3000
tunnel4 6792 1 xfrm4_tunnel, Live 0xfac51000
xfrm6_tunnel 9860 1 ipcomp6, Live 0xfac62000
tunnel6 6664 1 xfrm6_tunnel, Live 0xfac5f000
fuse 49436 3 - Live 0xfac6f000
sunrpc 155924 3 - Live 0xfac8b000
ipt_REJECT 6656 2 - Live 0xfac5c000
nf_conntrack_ipv4 11528 5 iptable_nat,nf_nat, Live 0xfab28000
iptable_filter 6528 1 - Live 0xfac40000
ip_tables 13712 3 iptable_mangle,iptable_nat,iptable_filter, Live 0xfac57000
ip6t_REJECT 7296 2 - Live 0xfac38000
xt_tcpudp 6656 2 - Live 0xfac35000
nf_conntrack_ipv6 15864 2 - Live 0xfac3b000
xt_state 5888 4 - Live 0xfac32000
nf_conntrack 51424 5
iptable_nat,nf_nat,nf_conntrack_ipv4,nf_conntrack_ipv6,xt_state, Live
0xfac43000
ip6table_filter 6400 1 - Live 0xfab2c000
ip6_tables 14736 1 ip6table_filter, Live 0xf8ade000
x_tables 15236 7
iptable_nat,ipt_REJECT,ip_tables,ip6t_REJECT,xt_tcpudp,xt_state,ip6_tables,
Live 0xf8ad1000
cpufreq_ondemand 9868 2 - Live 0xf8ada000
acpi_cpufreq 12172 0 - Live 0xf8ad6000
dm_multipath 17292 0 - Live 0xf8a59000
scsi_dh 9476 1 dm_multipath, Live 0xf89d2000
radeon 119044 2 - Live 0xf8b08000
drm 146404 3 radeon, Live 0xf8ae3000
ipv6 230260 39
ipcomp6,ah6,esp6,xfrm6_mode_beet,xfrm6_mode_tunnel,xfrm6_tunnel,tunnel6,ip6t_REJECT,nf_conntrack_ipv6,
Live 0xf8a1f000
snd_hda_intel 351380 4 - Live 0xf8a5f000
snd_seq_dummy 6660 0 - Live 0xf89a3000
snd_seq_oss 30364 0 - Live 0xf89e3000
snd_seq_midi_event 9600 1 snd_seq_oss, Live 0xf89b0000
snd_seq 48576 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event, Live
0xf89d6000
snd_seq_device 9996 3 snd_seq_dummy,snd_seq_oss,snd_seq, Live 0xf89ac000
snd_pcm_oss 42496 0 - Live 0xf89ba000
snd_mixer_oss 16896 1 snd_pcm_oss, Live 0xf89a6000
snd_pcm 65924 3 snd_hda_intel,snd_pcm_oss, Live 0xf896e000
snd_timer 22024 2 snd_seq,snd_pcm, Live 0xf8926000
snd_page_alloc 11016 2 snd_hda_intel,snd_pcm, Live 0xf896a000
snd_hwdep 10500 1 snd_hda_intel, Live 0xf8937000
ppdev 10372 0 - Live 0xf8933000
snd 50744 17
snd_hda_intel,snd_seq_dummy,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_hwdep,
Live 0xf8991000
parport_pc 25620 0 - Live 0xf893d000
parport 31956 2 ppdev,parport_pc, Live 0xf8961000
dcdbas 10272 0 - Live 0xf891e000
sr_mod 17064 1 - Live 0xf892d000
tg3 107780 0 - Live 0xf8945000
serio_raw 8836 0 - Live 0xf8922000
libphy 18560 1 tg3, Live 0xf88fd000
soundcore 9416 1 snd, Live 0xf891a000
iTCO_wdt 13732 0 - Live 0xf8903000
cdrom 32664 1 sr_mod, Live 0xf8911000
i2c_i801 12048 0 - Live 0xf88ca000
iTCO_vendor_support 6916 1 iTCO_wdt, Live 0xf8834000
pcspkr 6272 0 - Live 0xf88ba000
i2c_core 21396 2 drm,i2c_i801, Live 0xf88f0000
sg 31028 0 - Live 0xf8908000
dm_snapshot 19364 0 - Live 0xf88f7000
dm_zero 5632 0 - Live 0xf88ad000
dm_mirror 19968 0 - Live 0xf88b4000
dm_log 12164 1 dm_mirror, Live 0xf884e000
dm_mod 48692 10 dm_multipath,dm_snapshot,dm_zero,dm_mirror,dm_log, Live
0xf88bd000
pata_acpi 7680 0 - Live 0xf884b000
ata_generic 8452 0 - Live 0xf8847000
ata_piix 24836 3 - Live 0xf88a5000
libata 134380 3 pata_acpi,ata_generic,ata_piix, Live 0xf88ce000
sd_mod 32408 3 - Live 0xf889c000
scsi_mod 123772 5 scsi_dh,sr_mod,sg,libata,sd_mod, Live 0xf885f000
crc_t10dif 5632 1 sd_mod, Live 0xf8844000
ext3 109192 2 - Live 0xf8880000
jbd 42900 1 ext3, Live 0xf8853000
mbcache 10244 1 ext3, Live 0xf8839000
uhci_hcd 23312 0 - Live 0xf883d000
ohci_hcd 24336 0 - Live 0xf8824000
ehci_hcd 32524 0 - Live 0xf882b000
+ _________________________ /proc/meminfo
+ cat /proc/meminfo
MemTotal:      2072476 kB
MemFree:       1448564 kB
Buffers:         16808 kB
Cached:         200772 kB
SwapCached:          0 kB
Active:         394208 kB
Inactive:       105636 kB
HighTotal:     1177596 kB
HighFree:       683760 kB
LowTotal:       894880 kB
LowFree:        764804 kB
SwapTotal:     2031608 kB
SwapFree:      2031608 kB
Dirty:             116 kB
Writeback:           0 kB
AnonPages:      282396 kB
Mapped:          68340 kB
Slab:            25928 kB
SReclaimable:    10220 kB
SUnreclaim:      15708 kB
PageTables:       5136 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
WritebackTmp:        0 kB
CommitLimit:   3067844 kB
Committed_AS:   878784 kB
VmallocTotal:   110584 kB
VmallocUsed:     38328 kB
VmallocChunk:    72156 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
HugePages_Surp:      0
Hugepagesize:     4096 kB
DirectMap4k:      8192 kB
DirectMap4M:    909312 kB
+ _________________________ /proc/net/ipsec-ls
+ test -f /proc/net/ipsec_version
+ _________________________ usr/src/linux/.config
+ test -f /proc/config.gz
++ uname -r
+ test -f /lib/modules/2.6.27.5-41.fc9.i686/build/.config
+ echo 'no .config file found, cannot list kernel properties'
no .config file found, cannot list kernel properties
+ _________________________ etc/syslog.conf
+ _________________________ etc/syslog-ng/syslog-ng.conf
+ cat /etc/syslog-ng/syslog-ng.conf
cat: /etc/syslog-ng/syslog-ng.conf: No such file or directory
+ cat /etc/syslog.conf
cat: /etc/syslog.conf: No such file or directory
+ _________________________ etc/resolv.conf
+ cat /etc/resolv.conf
# generated by NetworkManager, do not edit!

nameserver 192.168.15.1

+ _________________________ lib/modules-ls
+ ls -ltr /lib/modules
total 12
drwxr-xr-x 7 root root 4096 Oct 24 17:56 2.6.26.6-79.fc9.i686
drwxr-xr-x 7 root root 4096 Nov 15 12:00 2.6.27.5-37.fc9.i686
drwxr-xr-x 7 root root 4096 Nov 19 13:03 2.6.27.5-41.fc9.i686
+ _________________________ /proc/ksyms-netif_rx
+ test -r /proc/ksyms
+ test -r /proc/kallsyms
+ egrep netif_rx /proc/kallsyms
c05d6055 T netif_rx
c05d6697 T netif_rx_ni
c072abbc r __ksymtab_netif_rx
c072acc4 r __ksymtab_netif_rx_ni
c073b292 r __kstrtab_netif_rx
c073b4ce r __kstrtab_netif_rx_ni
c05d6697 u netif_rx_ni    [bnep]
c05d6055 u netif_rx    [ipv6]
f894f103 t netif_rx_schedule    [tg3]
f8950af8 t netif_rx_complete    [tg3]
+ _________________________ lib/modules-netif_rx
+ modulegoo kernel/net/ipv4/ipip.o netif_rx
+ set +x
2.6.26.6-79.fc9.i686:
2.6.27.5-37.fc9.i686:
2.6.27.5-41.fc9.i686:
+ _________________________ kern.debug
+ test -f /var/log/kern.debug
+ _________________________ klog
+ sed -n '5304,$p' /var/log/messages
+ egrep -i 'ipsec|klips|pluto'
+ case "$1" in
+ cat
Jan 21 09:10:00 localhost ipsec_setup: Starting Openswan IPsec
U2.6.14/K2.6.27.5-41.fc9.i686...
Jan 21 09:10:00 localhost ipsec_setup:
Jan 21 09:10:00 localhost ipsec_setup:
Jan 21 09:10:00 localhost setroubleshoot: SELinux is preventing logger
(ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
Jan 21 09:10:00 localhost setroubleshoot: SELinux is preventing logger
(ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
Jan 21 09:10:01 localhost setroubleshoot: SELinux is preventing logger
(ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
Jan 21 09:10:01 localhost setroubleshoot: SELinux is preventing pluto
(ipsec_t) "search" to ./home (home_root_t). For complete SELinux
messages. run sealert -l 606544c1-5dfb-428e-badb-d719177ea1a7
Jan 21 09:10:01 localhost setroubleshoot: SELinux is preventing pluto
(ipsec_t) "search" to ./home (home_root_t). For complete SELinux
messages. run sealert -l 606544c1-5dfb-428e-badb-d719177ea1a7
Jan 21 09:10:01 localhost setroubleshoot: SELinux is preventing logger
(ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
Jan 21 09:10:02 localhost setroubleshoot: SELinux is preventing logger
(ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
Jan 21 09:10:02 localhost setroubleshoot: SELinux is preventing auto
(ipsec_mgmt_t) "execute_no_trans" to /bin/bash (shell_exec_t). For
complete SELinux messages. run sealert -l
12b4c94d-97f6-41cb-886f-048b26a24b1f
Jan 21 09:10:02 localhost setroubleshoot: SELinux is preventing logger
(ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
Jan 21 09:10:02 localhost setroubleshoot: SELinux is preventing auto
(ipsec_mgmt_t) "execute_no_trans" to /bin/bash (shell_exec_t). For
complete SELinux messages. run sealert -l
12b4c94d-97f6-41cb-886f-048b26a24b1f
Jan 21 09:10:03 localhost setroubleshoot: SELinux is preventing logger
(ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
Jan 21 09:10:03 localhost setroubleshoot: SELinux is preventing auto
(ipsec_mgmt_t) "execute_no_trans" to /bin/bash (shell_exec_t). For
complete SELinux messages. run sealert -l
12b4c94d-97f6-41cb-886f-048b26a24b1f
Jan 21 09:10:03 localhost setroubleshoot: SELinux is preventing logger
(ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
Jan 21 09:10:04 localhost setroubleshoot: SELinux is preventing auto
(ipsec_mgmt_t) "execute_no_trans" to /bin/bash (shell_exec_t). For
complete SELinux messages. run sealert -l
12b4c94d-97f6-41cb-886f-048b26a24b1f
Jan 21 09:10:04 localhost setroubleshoot: SELinux is preventing logger
(ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
Jan 21 09:10:04 localhost setroubleshoot: SELinux is preventing auto
(ipsec_mgmt_t) "execute_no_trans" to /bin/bash (shell_exec_t). For
complete SELinux messages. run sealert -l
12b4c94d-97f6-41cb-886f-048b26a24b1f
Jan 21 09:10:04 localhost setroubleshoot: SELinux is preventing logger
(ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
+ _________________________ plog
+ sed -n '2,$p' /var/log/secure
+ egrep -i pluto
+ case "$1" in
+ cat
Jan 20 09:48:52 localhost pluto[13851]: Starting Pluto (Openswan Version
2.6.14; Vendor ID OEoSJUweaqAX) pid:13851
Jan 20 09:48:52 localhost pluto[13851]: Setting NAT-Traversal port-4500
floating to on
Jan 20 09:48:52 localhost pluto[13851]:    port floating activation
criteria nat_t=1/port_float=1
Jan 20 09:48:52 localhost pluto[13851]:    including NAT-Traversal patch
(Version 0.6c)
Jan 20 09:48:52 localhost pluto[13851]: using /dev/urandom as source of
random entropy
Jan 20 09:48:52 localhost pluto[13851]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
Jan 20 09:48:52 localhost pluto[13851]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
Jan 20 09:48:52 localhost pluto[13851]: ike_alg_register_enc():
Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
Jan 20 09:48:52 localhost pluto[13851]: ike_alg_register_enc():
Activating OAKLEY_AES_CBC: Ok (ret=0)
Jan 20 09:48:52 localhost pluto[13851]: ike_alg_register_enc():
Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
Jan 20 09:48:52 localhost pluto[13851]: ike_alg_register_hash():
Activating OAKLEY_SHA2_512: Ok (ret=0)
Jan 20 09:48:52 localhost pluto[13851]: ike_alg_register_hash():
Activating OAKLEY_SHA2_256: Ok (ret=0)
Jan 20 09:48:52 localhost pluto[13851]: starting up 1 cryptographic helpers
Jan 20 09:48:52 localhost pluto[13851]: started helper pid=13852 (fd:7)
Jan 20 09:48:52 localhost pluto[13851]: Using Linux 2.6 IPsec interface
code on 2.6.27.5-41.fc9.i686 (experimental code)
Jan 20 09:48:52 localhost pluto[13852]: using /dev/urandom as source of
random entropy
Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc():
Activating <NULL>: Ok (ret=0)
Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 09:48:53 localhost pluto[13851]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 09:48:53 localhost pluto[13851]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 09:48:53 localhost pluto[13851]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 09:48:53 localhost pluto[13851]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 09:48:53 localhost pluto[13851]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 20 09:48:53 localhost pluto[13851]: Could not change to directory
'/etc/ipsec.d/cacerts': /usr/sbin
Jan 20 09:48:53 localhost pluto[13851]: Could not change to directory
'/etc/ipsec.d/aacerts': /usr/sbin
Jan 20 09:48:53 localhost pluto[13851]: Could not change to directory
'/etc/ipsec.d/ocspcerts': /usr/sbin
Jan 20 09:48:53 localhost pluto[13851]: Could not change to directory
'/etc/ipsec.d/crls'
Jan 20 09:48:53 localhost pluto[13851]: Changing back to directory
'/usr/sbin' failed - (2 No such file or directory)
Jan 20 09:48:53 localhost pluto[13851]: Changing back to directory
'/usr/sbin' failed - (2 No such file or directory)
Jan 20 09:48:53 localhost pluto[13851]: added connection description "vo"
Jan 20 09:48:53 localhost pluto[13851]: added connection description "vodmz"
Jan 20 09:49:32 localhost pluto[13851]: loading secrets from
"/etc/ipsec.secrets"
Jan 20 09:49:32 localhost pluto[13851]: no secrets filename matched
"/etc/ipsec.d/*.secrets"
Jan 20 09:56:08 localhost pluto[13851]: forgetting secrets
Jan 20 09:56:08 localhost pluto[13851]: no secrets filename matched
"/etc/ipsec.secrets"
Jan 20 09:56:24 localhost pluto[13851]: loading secrets from
"/etc/ipsec.secrets"
Jan 20 09:56:24 localhost pluto[13851]: no secrets filename matched
"/etc/ipsec.d/*.secrets"
Jan 20 09:57:04 localhost pluto[13851]: shutting down
Jan 20 09:57:04 localhost pluto[13851]: forgetting secrets
Jan 20 09:57:04 localhost pluto[13851]: "vodmz": deleting connection
Jan 20 09:57:04 localhost pluto[13851]: "vo": deleting connection
Jan 20 09:57:05 localhost pluto[14592]: Starting Pluto (Openswan Version
2.6.14; Vendor ID OEoSJUweaqAX) pid:14592
Jan 20 09:57:05 localhost pluto[14592]: Setting NAT-Traversal port-4500
floating to on
Jan 20 09:57:05 localhost pluto[14592]:    port floating activation
criteria nat_t=1/port_float=1
Jan 20 09:57:05 localhost pluto[14592]:    including NAT-Traversal patch
(Version 0.6c)
Jan 20 09:57:05 localhost pluto[14592]: using /dev/urandom as source of
random entropy
Jan 20 09:57:05 localhost pluto[14592]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
Jan 20 09:57:05 localhost pluto[14592]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
Jan 20 09:57:05 localhost pluto[14592]: ike_alg_register_enc():
Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
Jan 20 09:57:05 localhost pluto[14592]: ike_alg_register_enc():
Activating OAKLEY_AES_CBC: Ok (ret=0)
Jan 20 09:57:05 localhost pluto[14592]: ike_alg_register_enc():
Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
Jan 20 09:57:05 localhost pluto[14592]: ike_alg_register_hash():
Activating OAKLEY_SHA2_512: Ok (ret=0)
Jan 20 09:57:05 localhost pluto[14592]: ike_alg_register_hash():
Activating OAKLEY_SHA2_256: Ok (ret=0)
Jan 20 09:57:05 localhost pluto[14592]: starting up 1 cryptographic helpers
Jan 20 09:57:05 localhost pluto[14601]: using /dev/urandom as source of
random entropy
Jan 20 09:57:05 localhost pluto[14592]: started helper pid=14601 (fd:7)
Jan 20 09:57:05 localhost pluto[14592]: Using Linux 2.6 IPsec interface
code on 2.6.27.5-41.fc9.i686 (experimental code)
Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc():
Activating <NULL>: Ok (ret=0)
Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 09:57:06 localhost pluto[14592]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 09:57:06 localhost pluto[14592]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 09:57:06 localhost pluto[14592]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 09:57:06 localhost pluto[14592]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 09:57:06 localhost pluto[14592]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 20 09:57:06 localhost pluto[14592]: Could not change to directory
'/etc/ipsec.d/cacerts': /etc
Jan 20 09:57:06 localhost pluto[14592]: Could not change to directory
'/etc/ipsec.d/aacerts': /etc
Jan 20 09:57:06 localhost pluto[14592]: Could not change to directory
'/etc/ipsec.d/ocspcerts': /etc
Jan 20 09:57:06 localhost pluto[14592]: Could not change to directory
'/etc/ipsec.d/crls'
Jan 20 09:57:06 localhost pluto[14592]: Changing back to directory
'/etc' failed - (2 No such file or directory)
Jan 20 09:57:06 localhost pluto[14592]: Changing back to directory
'/etc' failed - (2 No such file or directory)
Jan 20 09:57:06 localhost pluto[14592]: added connection description "vo"
Jan 20 09:57:06 localhost pluto[14592]: added connection description "vodmz"
Jan 20 09:57:08 localhost pluto[14592]: loading secrets from
"/etc/ipsec.secrets"
Jan 20 09:57:08 localhost pluto[14592]: no secrets filename matched
"/etc/ipsec.d/*.secrets"
Jan 20 09:59:17 localhost pluto[14592]: forgetting secrets
Jan 20 09:59:17 localhost pluto[14592]: loading secrets from
"/etc/ipsec.secrets"
Jan 20 09:59:17 localhost pluto[14592]: loading secrets from
"/etc/ipsec.d/ipsec.secrets"
Jan 20 10:01:37 localhost pluto[14592]: "vo": deleting connection
Jan 20 10:01:37 localhost pluto[14592]: added connection description "vo"
Jan 20 10:01:43 localhost pluto[14592]: "vodmz": deleting connection
Jan 20 10:01:43 localhost pluto[14592]: added connection description "vodmz"
Jan 20 10:07:07 localhost pluto[14592]: shutting down
Jan 20 10:07:07 localhost pluto[14592]: forgetting secrets
Jan 20 10:07:07 localhost pluto[14592]: "vodmz": deleting connection
Jan 20 10:07:07 localhost pluto[14592]: "vo": deleting connection
Jan 20 10:07:09 localhost pluto[15199]: Starting Pluto (Openswan Version
2.6.14; Vendor ID OEoSJUweaqAX) pid:15199
Jan 20 10:07:09 localhost pluto[15199]: Setting NAT-Traversal port-4500
floating to on
Jan 20 10:07:09 localhost pluto[15199]:    port floating activation
criteria nat_t=1/port_float=1
Jan 20 10:07:09 localhost pluto[15199]:    including NAT-Traversal patch
(Version 0.6c)
Jan 20 10:07:09 localhost pluto[15199]: using /dev/urandom as source of
random entropy
Jan 20 10:07:09 localhost pluto[15199]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
Jan 20 10:07:09 localhost pluto[15199]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
Jan 20 10:07:09 localhost pluto[15199]: ike_alg_register_enc():
Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
Jan 20 10:07:09 localhost pluto[15199]: ike_alg_register_enc():
Activating OAKLEY_AES_CBC: Ok (ret=0)
Jan 20 10:07:09 localhost pluto[15199]: ike_alg_register_enc():
Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
Jan 20 10:07:09 localhost pluto[15199]: ike_alg_register_hash():
Activating OAKLEY_SHA2_512: Ok (ret=0)
Jan 20 10:07:09 localhost pluto[15199]: ike_alg_register_hash():
Activating OAKLEY_SHA2_256: Ok (ret=0)
Jan 20 10:07:09 localhost pluto[15199]: starting up 1 cryptographic helpers
Jan 20 10:07:09 localhost pluto[15201]: using /dev/urandom as source of
random entropy
Jan 20 10:07:09 localhost pluto[15199]: started helper pid=15201 (fd:7)
Jan 20 10:07:09 localhost pluto[15199]: Using Linux 2.6 IPsec interface
code on 2.6.27.5-41.fc9.i686 (experimental code)
Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc():
Activating <NULL>: Ok (ret=0)
Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 10:07:10 localhost pluto[15199]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 10:07:10 localhost pluto[15199]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 10:07:10 localhost pluto[15199]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 10:07:10 localhost pluto[15199]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 10:07:10 localhost pluto[15199]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 20 10:07:10 localhost pluto[15199]: Could not change to directory
'/etc/ipsec.d/cacerts': /etc
Jan 20 10:07:10 localhost pluto[15199]: Could not change to directory
'/etc/ipsec.d/aacerts': /etc
Jan 20 10:07:10 localhost pluto[15199]: Could not change to directory
'/etc/ipsec.d/ocspcerts': /etc
Jan 20 10:07:10 localhost pluto[15199]: Could not change to directory
'/etc/ipsec.d/crls'
Jan 20 10:07:10 localhost pluto[15199]: Changing back to directory
'/etc' failed - (2 No such file or directory)
Jan 20 10:07:10 localhost pluto[15199]: Changing back to directory
'/etc' failed - (2 No such file or directory)
Jan 20 10:07:10 localhost pluto[15199]: added connection description "vo"
Jan 20 10:07:10 localhost pluto[15199]: added connection description "vodmz"
Jan 20 10:17:24 localhost pluto[15199]: shutting down
Jan 20 10:17:24 localhost pluto[15199]: "vodmz": deleting connection
Jan 20 10:17:24 localhost pluto[15199]: "vo": deleting connection
Jan 20 10:17:27 localhost pluto[15738]: Starting Pluto (Openswan Version
2.6.14; Vendor ID OEoSJUweaqAX) pid:15738
Jan 20 10:17:27 localhost pluto[15738]: Setting NAT-Traversal port-4500
floating to on
Jan 20 10:17:27 localhost pluto[15738]:    port floating activation
criteria nat_t=1/port_float=1
Jan 20 10:17:27 localhost pluto[15738]:    including NAT-Traversal patch
(Version 0.6c)
Jan 20 10:17:27 localhost pluto[15738]: using /dev/urandom as source of
random entropy
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc():
Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc():
Activating OAKLEY_AES_CBC: Ok (ret=0)
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc():
Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_hash():
Activating OAKLEY_SHA2_512: Ok (ret=0)
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_hash():
Activating OAKLEY_SHA2_256: Ok (ret=0)
Jan 20 10:17:27 localhost pluto[15738]: starting up 1 cryptographic helpers
Jan 20 10:17:27 localhost pluto[15744]: using /dev/urandom as source of
random entropy
Jan 20 10:17:27 localhost pluto[15738]: started helper pid=15744 (fd:7)
Jan 20 10:17:27 localhost pluto[15738]: Using Linux 2.6 IPsec interface
code on 2.6.27.5-41.fc9.i686 (experimental code)
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc():
Activating <NULL>: Ok (ret=0)
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 20 10:17:27 localhost pluto[15738]: Could not change to directory
'/etc/ipsec.d/cacerts': /etc
Jan 20 10:17:27 localhost pluto[15738]: Could not change to directory
'/etc/ipsec.d/aacerts': /etc
Jan 20 10:17:27 localhost pluto[15738]: Could not change to directory
'/etc/ipsec.d/ocspcerts': /etc
Jan 20 10:17:27 localhost pluto[15738]: Could not change to directory
'/etc/ipsec.d/crls'
Jan 20 10:17:27 localhost pluto[15738]: Changing back to directory
'/etc' failed - (2 No such file or directory)
Jan 20 10:17:27 localhost pluto[15738]: Changing back to directory
'/etc' failed - (2 No such file or directory)
Jan 20 10:17:27 localhost pluto[15738]: added connection description "vo"
Jan 20 10:17:27 localhost pluto[15738]: added connection description "vodmz"
Jan 21 08:59:07 localhost pluto[15738]: shutting down
Jan 21 08:59:07 localhost pluto[15738]: "vodmz": deleting connection
Jan 21 08:59:07 localhost pluto[15738]: "vo": deleting connection
Jan 21 09:00:20 localhost pluto[2326]: Starting Pluto (Openswan Version
2.6.14; Vendor ID OEoSJUweaqAX) pid:2326
Jan 21 09:00:20 localhost pluto[2326]: Setting NAT-Traversal port-4500
floating to on
Jan 21 09:00:20 localhost pluto[2326]:    port floating activation
criteria nat_t=1/port_float=1
Jan 21 09:00:20 localhost pluto[2326]:    including NAT-Traversal patch
(Version 0.6c)
Jan 21 09:00:20 localhost pluto[2326]: using /dev/urandom as source of
random entropy
Jan 21 09:00:20 localhost pluto[2326]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
Jan 21 09:00:20 localhost pluto[2326]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
Jan 21 09:00:20 localhost pluto[2326]: ike_alg_register_enc():
Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
Jan 21 09:00:20 localhost pluto[2326]: ike_alg_register_enc():
Activating OAKLEY_AES_CBC: Ok (ret=0)
Jan 21 09:00:20 localhost pluto[2326]: ike_alg_register_enc():
Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
Jan 21 09:00:20 localhost pluto[2326]: ike_alg_register_hash():
Activating OAKLEY_SHA2_512: Ok (ret=0)
Jan 21 09:00:20 localhost pluto[2326]: ike_alg_register_hash():
Activating OAKLEY_SHA2_256: Ok (ret=0)
Jan 21 09:00:20 localhost pluto[2326]: starting up 1 cryptographic helpers
Jan 21 09:00:20 localhost pluto[2342]: using /dev/urandom as source of
random entropy
Jan 21 09:00:20 localhost pluto[2326]: started helper pid=2342 (fd:7)
Jan 21 09:00:20 localhost pluto[2326]: Using Linux 2.6 IPsec interface
code on 2.6.27.5-41.fc9.i686 (experimental code)
Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc():
Activating <NULL>: Ok (ret=0)
Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:00:21 localhost pluto[2326]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:00:21 localhost pluto[2326]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:00:21 localhost pluto[2326]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:00:21 localhost pluto[2326]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:00:21 localhost pluto[2326]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 21 09:00:21 localhost pluto[2326]: Could not change to directory
'/etc/ipsec.d/cacerts': /
Jan 21 09:00:21 localhost pluto[2326]: Could not change to directory
'/etc/ipsec.d/aacerts': /
Jan 21 09:00:21 localhost pluto[2326]: Could not change to directory
'/etc/ipsec.d/ocspcerts': /
Jan 21 09:00:21 localhost pluto[2326]: Could not change to directory
'/etc/ipsec.d/crls'
Jan 21 09:00:21 localhost pluto[2326]: Changing back to directory '/'
failed - (2 No such file or directory)
Jan 21 09:00:21 localhost pluto[2326]: Changing back to directory '/'
failed - (2 No such file or directory)
Jan 21 09:00:21 localhost pluto[2326]: added connection description "vo"
Jan 21 09:00:21 localhost pluto[2326]: added connection description "vodmz"
Jan 21 09:06:20 localhost pluto[2326]: shutting down
Jan 21 09:06:20 localhost pluto[2326]: "vodmz": deleting connection
Jan 21 09:06:20 localhost pluto[2326]: "vo": deleting connection
Jan 21 09:06:22 localhost pluto[3784]: Starting Pluto (Openswan Version
2.6.14; Vendor ID OEoSJUweaqAX) pid:3784
Jan 21 09:06:22 localhost pluto[3784]: Setting NAT-Traversal port-4500
floating to on
Jan 21 09:06:22 localhost pluto[3784]:    port floating activation
criteria nat_t=1/port_float=1
Jan 21 09:06:22 localhost pluto[3784]:    including NAT-Traversal patch
(Version 0.6c)
Jan 21 09:06:22 localhost pluto[3784]: using /dev/urandom as source of
random entropy
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc():
Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc():
Activating OAKLEY_AES_CBC: Ok (ret=0)
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc():
Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_hash():
Activating OAKLEY_SHA2_512: Ok (ret=0)
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_hash():
Activating OAKLEY_SHA2_256: Ok (ret=0)
Jan 21 09:06:22 localhost pluto[3784]: starting up 1 cryptographic helpers
Jan 21 09:06:22 localhost pluto[3784]: started helper pid=3785 (fd:7)
Jan 21 09:06:22 localhost pluto[3784]: Using Linux 2.6 IPsec interface
code on 2.6.27.5-41.fc9.i686 (experimental code)
Jan 21 09:06:22 localhost pluto[3785]: using /dev/urandom as source of
random entropy
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc():
Activating <NULL>: Ok (ret=0)
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 21 09:06:22 localhost pluto[3784]: Could not change to directory
'/etc/ipsec.d/cacerts': /home/jingluo
Jan 21 09:06:22 localhost pluto[3784]: Could not change to directory
'/etc/ipsec.d/aacerts': /home/jingluo
Jan 21 09:06:22 localhost pluto[3784]: Could not change to directory
'/etc/ipsec.d/ocspcerts': /home/jingluo
Jan 21 09:06:22 localhost pluto[3784]: Could not change to directory
'/etc/ipsec.d/crls'
Jan 21 09:06:22 localhost pluto[3784]: added connection description "vo"
Jan 21 09:06:22 localhost pluto[3784]: added connection description "vodmz"
Jan 21 09:08:35 localhost pluto[3784]: loading secrets from
"/etc/ipsec.secrets"
Jan 21 09:08:35 localhost pluto[3784]: loading secrets from
"/etc/ipsec.d/ipsec.secrets"
Jan 21 09:08:44 localhost pluto[3784]: "vo": deleting connection
Jan 21 09:08:44 localhost pluto[3784]: added connection description "vo"
Jan 21 09:08:52 localhost pluto[3784]: "vodmz": deleting connection
Jan 21 09:08:52 localhost pluto[3784]: added connection description "vodmz"
Jan 21 09:09:04 localhost pluto[3784]: forgetting secrets
Jan 21 09:09:04 localhost pluto[3784]: loading secrets from
"/etc/ipsec.secrets"
Jan 21 09:09:04 localhost pluto[3784]: loading secrets from
"/etc/ipsec.d/ipsec.secrets"
Jan 21 09:09:08 localhost pluto[3784]: shutting down
Jan 21 09:09:08 localhost pluto[3784]: forgetting secrets
Jan 21 09:09:08 localhost pluto[3784]: "vodmz": deleting connection
Jan 21 09:09:08 localhost pluto[3784]: "vo": deleting connection
Jan 21 09:09:10 localhost pluto[4268]: Starting Pluto (Openswan Version
2.6.14; Vendor ID OEoSJUweaqAX) pid:4268
Jan 21 09:09:10 localhost pluto[4268]: Setting NAT-Traversal port-4500
floating to on
Jan 21 09:09:10 localhost pluto[4268]:    port floating activation
criteria nat_t=1/port_float=1
Jan 21 09:09:10 localhost pluto[4268]:    including NAT-Traversal patch
(Version 0.6c)
Jan 21 09:09:10 localhost pluto[4268]: using /dev/urandom as source of
random entropy
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc():
Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc():
Activating OAKLEY_AES_CBC: Ok (ret=0)
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc():
Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_hash():
Activating OAKLEY_SHA2_512: Ok (ret=0)
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_hash():
Activating OAKLEY_SHA2_256: Ok (ret=0)
Jan 21 09:09:10 localhost pluto[4268]: starting up 1 cryptographic helpers
Jan 21 09:09:10 localhost pluto[4268]: started helper pid=4271 (fd:7)
Jan 21 09:09:10 localhost pluto[4268]: Using Linux 2.6 IPsec interface
code on 2.6.27.5-41.fc9.i686 (experimental code)
Jan 21 09:09:10 localhost pluto[4271]: using /dev/urandom as source of
random entropy
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc():
Activating <NULL>: Ok (ret=0)
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 21 09:09:10 localhost pluto[4268]: Could not change to directory
'/etc/ipsec.d/cacerts': /home/jingluo
Jan 21 09:09:10 localhost pluto[4268]: Could not change to directory
'/etc/ipsec.d/aacerts': /home/jingluo
Jan 21 09:09:10 localhost pluto[4268]: Could not change to directory
'/etc/ipsec.d/ocspcerts': /home/jingluo
Jan 21 09:09:10 localhost pluto[4268]: Could not change to directory
'/etc/ipsec.d/crls'
Jan 21 09:09:10 localhost pluto[4268]: added connection description "vo"
Jan 21 09:09:10 localhost pluto[4268]: added connection description "vodmz"
Jan 21 09:09:57 localhost pluto[4268]: shutting down
Jan 21 09:09:57 localhost pluto[4268]: "vodmz": deleting connection
Jan 21 09:09:57 localhost pluto[4268]: "vo": deleting connection
Jan 21 09:10:00 localhost pluto[4647]: Starting Pluto (Openswan Version
2.6.14; Vendor ID OEoSJUweaqAX) pid:4647
Jan 21 09:10:00 localhost pluto[4647]: Setting NAT-Traversal port-4500
floating to on
Jan 21 09:10:00 localhost pluto[4647]:    port floating activation
criteria nat_t=1/port_float=1
Jan 21 09:10:00 localhost pluto[4647]:    including NAT-Traversal patch
(Version 0.6c)
Jan 21 09:10:00 localhost pluto[4647]: using /dev/urandom as source of
random entropy
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc():
Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc():
Activating OAKLEY_AES_CBC: Ok (ret=0)
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc():
Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_hash():
Activating OAKLEY_SHA2_512: Ok (ret=0)
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_hash():
Activating OAKLEY_SHA2_256: Ok (ret=0)
Jan 21 09:10:00 localhost pluto[4647]: starting up 1 cryptographic helpers
Jan 21 09:10:00 localhost pluto[4647]: started helper pid=4648 (fd:7)
Jan 21 09:10:00 localhost pluto[4647]: Using Linux 2.6 IPsec interface
code on 2.6.27.5-41.fc9.i686 (experimental code)
Jan 21 09:10:00 localhost pluto[4648]: using /dev/urandom as source of
random entropy
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc():
Activating <NULL>: Ok (ret=0)
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 21 09:10:00 localhost pluto[4647]: Could not change to directory
'/etc/ipsec.d/cacerts': /home/jingluo
Jan 21 09:10:00 localhost pluto[4647]: Could not change to directory
'/etc/ipsec.d/aacerts': /home/jingluo
Jan 21 09:10:00 localhost pluto[4647]: Could not change to directory
'/etc/ipsec.d/ocspcerts': /home/jingluo
Jan 21 09:10:00 localhost pluto[4647]: Could not change to directory
'/etc/ipsec.d/crls'
Jan 21 09:10:00 localhost pluto[4647]: added connection description "vo"
Jan 21 09:10:00 localhost pluto[4647]: added connection description "vodmz"
+ _________________________ date
+ date
Wed Jan 21 09:12:55 EST 2009
-------------- next part --------------
An embedded message was scrubbed...
From: Jing Luo <jing.luo at steeprockinc.com>
Subject: barf
Date: Wed, 21 Jan 2009 09:13:41 -0500 (EST)
Size: 84013
Url: http://lists.openswan.org/pipermail/users/attachments/20090122/3b68dde3/attachment-0001.eml 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.openswan.org/pipermail/users/attachments/20090122/3b68dde3/attachment-0001.bin 

From petermcgill at goco.net  Fri Jan 23 10:29:26 2009
From: petermcgill at goco.net (Peter McGill)
Date: Fri, 23 Jan 2009 10:29:26 -0500
Subject: [Openswan Users] Openswan + Netgear FVS318
In-Reply-To: <497097FF.3030902@solotes.fi>
References: <497097FF.3030902@solotes.fi>
Message-ID: <4979E256.50006@goco.net>

Petrik,

PAYLOAD_MALFORMED is usually due to a config mismatch.

Check that your key in /etc/ipsec.secrets matches the key on the Netgear.
ie) 83.145.201.2 83.145.204.59 : PSK "your secret key"

Check the subnets on the Netgear match yours:
leftsubnet=192.168.240.0/24
rightsubnet=192.168.1.0/24

Check that the Netgear has Perfect Forward Secrecy on (pfs).
Or if you can't find the setting set pfs=no, Openswan will
still use pfs if asked, just won't require it.

Explicitly set the authentication and encryption methods used on both 
ends, for example:
	# IKE Authentication (Phase 1)
	#   3DES, MD5, Diffie Hellman (DH) Group 2 (1024 bit)
	ike=3des-md5-modp1024
	# ESP Encryption (Phase 2)
	#   3DES, MD5, Diffie Hellman (DH) Group (Same as Phase 1)
	esp=3des-md5

Try initiating with the Netgear instead of Openswan (auto=add).
The logs may give a better indication of the error (plutodebug=none).

Peter McGill

Petrik Salovaara wrote:
> Greetings,
> 
> I am trying to get a VPN connection between openswan and Netgear FVS318 using PSK. 
> My openswan linux box currently works fine with another openswan linux box and 
> several roadwarriors using certificates. I have followed instructions on 
> http://wiki.openswan.org/index.php/Openswan/NetGearFVS318 without success.
> 
> Bottom line is that openswan reports "PAYLOAD_MALFORMED" in STATE_MAIN_I3
> Any help is appreciated.
> 
> Here's the config in openswan:
>> # /etc/ipsec.conf - FreeS/WAN IPsec configuration file
>> config setup
>>         #plutodebug=all
>>         #plutoload=%search
>>         #plutostart=%search
>>         interfaces=%defaultroute
>>         klipsdebug=none
>>         nat_traversal=yes
>>         plutodebug=none
>>         strictcrlpolicy=no
>>         uniqueids=yes
>>         virtual_private=%v4:192.168.239.0/24
>>
>> conn %default
>>         auto=add
>>         auth=esp
>>         compress=no
>>         authby=rsasig
>>         keyingtries=1
>>         left=83.145.201.2
>>         leftcert=/etc/ipsec.d/certs/www.solotes.fi_crt.pem
>>         leftid="C=FI, O=Solotes Oy, CN=www.solotes.fi"
>>         leftnexthop=83.145.201.254
>>         leftrsasigkey=%cert
>>         leftsubnet=192.168.240.0/24
>>
>> conn fvs318
>>         type=tunnel
>>         left=83.145.201.2
>>         leftsubnet=192.168.240.0/24
>>         leftnexthop=83.145.201.254
>>         leftid="83.145.201.2"
>>         right=83.145.204.59
>>         rightsubnet=192.168.1.0/24
>>         rightnexthop=83.145.204.254
>>         rightid="83.145.204.59"
>>         ikelifetime=1440m
>>         keylife=480m
>>         pfs=yes
>>         keyexchange=ike
>>         authby=secret
>>         auto=start
>>
>> conn gw-oskari
>>         right=%any
>>         rightcert=/etc/ipsec.d/certs/gw.osku.solotes.fi_crt.pem
>>         rightid="C=FI, O=Solotes Oy, CN=gw.osku.solotes.fi"
>>         rightrsasigkey=%cert
>>         rightsubnet=192.168.2.0/24
>>         type=tunnel
>>
>> conn jukka
>>         right=%any
>>         rightcert=/etc/ipsec.d/certs/jukka.rw.solotes.fi_crt.pem
>>         rightid="C=FI, O=Solotes Oy, CN=jukka.rw.solotes.fi"
>>         rightrsasigkey=%cert
>>         rightsubnet=vhost:%priv
>>         type=tunnel
>>
>> conn trikki
>>         right=%any
>>         rightcert=/etc/ipsec.d/certs/trikki.rw.solotes.fi_crt.pem
>>         rightid="C=FI, O=Solotes Oy, CN=trikki.rw.solotes.fi"
>>         rightrsasigkey=%cert
>>         rightsubnet=vhost:%priv
>>         type=tunnel
> 
> 
> Netgear box is configured as follows:
>> http://www.solotes.fi/private/trikki/netgear/fvs318_ike_policy.gif
>> http://www.solotes.fi/private/trikki/netgear/fvs318_vpn_auto_policy.gif
> 
> 
> This is what goes into log/secure when starting ipsec:
>> Jan 14 17:32:34 www ipsec__plutorun: Starting Pluto subsystem...
>> Jan 14 17:32:34 www pluto[21402]: Starting Pluto (Openswan Version 2.4.7 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR; Vendor ID OEZ~BaB]r\134p_)
>> Jan 14 17:32:34 www pluto[21402]: Setting NAT-Traversal port-4500 floating to on
>> Jan 14 17:32:34 www pluto[21402]:    port floating activation criteria nat_t=1/port_fload=1
>> Jan 14 17:32:34 www pluto[21402]:   including NAT-Traversal patch (Version 0.6c)
>> Jan 14 17:32:34 www pluto[21402]: ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok (ret=0)
>> Jan 14 17:32:34 www pluto[21402]: starting up 1 cryptographic helpers
>> Jan 14 17:32:34 www pluto[21402]: started helper pid=21406 (fd:6)
>> Jan 14 17:32:34 www pluto[21402]: Using NETKEY IPsec interface code on 2.6.18-53.1.19.el5
>> Jan 14 17:32:35 www pluto[21402]: Changing to directory '/etc/ipsec.d/cacerts'
>> Jan 14 17:32:35 www pluto[21402]:   loaded CA cert file 'solotes-2007_cacert.pem' (1675 bytes)
>> Jan 14 17:32:35 www pluto[21402]: Could not change to directory '/etc/ipsec.d/aacerts'
>> Jan 14 17:32:35 www pluto[21402]: Could not change to directory '/etc/ipsec.d/ocspcerts'
>> Jan 14 17:32:35 www pluto[21402]: Could not change to directory '/etc/ipsec.d/crls'
>> Jan 14 17:32:35 www pluto[21402]:   loaded host cert file '/etc/ipsec.d/certs/www.solotes.fi_crt.pem' (4304 bytes)
>> Jan 14 17:32:35 www pluto[21402]:   loaded host cert file '/etc/ipsec.d/certs/trikki.rw.solotes.fi_crt.pem' (4318 bytes)
>> Jan 14 17:32:35 www pluto[21402]: added connection description "trikki"
>> Jan 14 17:32:35 www pluto[21402]:   loaded host cert file '/etc/ipsec.d/certs/www.solotes.fi_crt.pem' (4304 bytes)
>> Jan 14 17:32:35 www pluto[21402]:   loaded host cert file '/etc/ipsec.d/certs/gw.osku.solotes.fi_crt.pem' (4312 bytes)
>> Jan 14 17:32:35 www pluto[21402]: added connection description "gw-oskari"
>> Jan 14 17:32:35 www pluto[21402]:   loaded host cert file '/etc/ipsec.d/certs/www.solotes.fi_crt.pem' (4304 bytes)
>> Jan 14 17:32:35 www pluto[21402]:   loaded host cert file '/etc/ipsec.d/certs/jukka.rw.solotes.fi_crt.pem' (4317 bytes)
>> Jan 14 17:32:35 www pluto[21402]: added connection description "jukka"
>> Jan 14 17:32:35 www pluto[21402]:   loaded host cert file '/etc/ipsec.d/certs/www.solotes.fi_crt.pem' (4304 bytes)
>> Jan 14 17:32:35 www pluto[21402]:   no subjectAltName matches ID '83.145.201.2', replaced by subject DN
>> Jan 14 17:32:35 www pluto[21402]: added connection description "fvs318"
>> Jan 14 17:32:35 www pluto[21402]: listening for IKE messages
>> Jan 14 17:32:35 www pluto[21402]: adding interface virbr0/virbr0 192.168.122.1:500
>> Jan 14 17:32:35 www pluto[21402]: adding interface virbr0/virbr0 192.168.122.1:4500
>> Jan 14 17:32:35 www pluto[21402]: adding interface eth1/eth1 192.168.240.254:500
>> Jan 14 17:32:35 www pluto[21402]: adding interface eth1/eth1 192.168.240.254:4500
>> Jan 14 17:32:35 www pluto[21402]: adding interface eth0/eth0 83.145.201.2:500
>> Jan 14 17:32:35 www pluto[21402]: adding interface eth0/eth0 83.145.201.2:4500
>> Jan 14 17:32:35 www pluto[21402]: adding interface eth2/eth2 192.168.240.253:500
>> Jan 14 17:32:35 www pluto[21402]: adding interface eth2/eth2 192.168.240.253:4500
>> Jan 14 17:32:35 www pluto[21402]: adding interface lo/lo 127.0.0.1:500
>> Jan 14 17:32:35 www pluto[21402]: adding interface lo/lo 127.0.0.1:4500
>> Jan 14 17:32:35 www pluto[21402]: adding interface lo/lo ::1:500
>> Jan 14 17:32:35 www pluto[21402]: loading secrets from "/etc/ipsec.secrets"
>> Jan 14 17:32:35 www pluto[21402]:   loaded private key file '/etc/ipsec.d/private/gw.osku.solotes.fi_key.pem' (887 bytes)
>> Jan 14 17:32:35 www pluto[21402]:   loaded private key file '/etc/ipsec.d/private/solotes-2007_cakey.pem' (1675 bytes)
>> Jan 14 17:32:35 www pluto[21402]:   loaded private key file '/etc/ipsec.d/private/www.solotes.fi_key.pem' (887 bytes)
>> Jan 14 17:32:35 www pluto[21402]: "fvs318" #1: initiating Main Mode
>> Jan 14 17:32:35 www pluto[21402]: "fvs318" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
>> Jan 14 17:32:35 www pluto[21402]: "fvs318" #1: STATE_MAIN_I2: sent MI2, expecting MR2
>> Jan 14 17:32:35 www pluto[21402]: packet from 89.27.54.216:500: phase 1 message is part of an unknown exchange
>> Jan 14 17:32:36 www pluto[21402]: "fvs318" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
>> Jan 14 17:32:36 www pluto[21402]: "fvs318" #1: STATE_MAIN_I3: sent MI3, expecting MR3
>> Jan 14 17:32:38 www pluto[21402]: "fvs318" #1: byte 2 of ISAKMP Hash Payload must be zero, but is not
>> Jan 14 17:32:38 www pluto[21402]: "fvs318" #1: malformed payload in packet
>> Jan 14 17:32:38 www pluto[21402]: | payload malformed after IV
>> Jan 14 17:32:38 www pluto[21402]: |   b8 6f 9b ad  f4 a6 c1 21
>> Jan 14 17:32:38 www pluto[21402]: "fvs318" #1: sending notification PAYLOAD_MALFORMED to 83.145.204.59:500
>> Jan 14 17:32:55 www pluto[21402]: packet from 89.27.54.216:500: phase 1 message is part of an unknown exchange
>> Jan 14 17:33:46 www pluto[21402]: "fvs318" #1: max number of retransmissions (2) reached STATE_MAIN_I3.  Possible authentication failure: no acceptable response to our first encrypted message
> 
> When turning on plutodebug=all, log shows following:
>> http://www.solotes.fi/private/trikki/netgear/log_debug_all.txt
> 
> Petrik Salovaara
> mailto:petrik.salovaara at solotes.fi
> 
> 
> _______________________________________________
> 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=283155
> 

From petermcgill at goco.net  Fri Jan 23 10:41:36 2009
From: petermcgill at goco.net (Peter McGill)
Date: Fri, 23 Jan 2009 10:41:36 -0500
Subject: [Openswan Users] OpenSWAN to SonicWALL problems
In-Reply-To: <497877C3.2070608@steeprockinc.com>
References: <497877C3.2070608@steeprockinc.com>
Message-ID: <4979E530.1060303@goco.net>

Chris,

It appears that you still have opportunistic encryption on.
 > + ipsec verify
 > Opportunistic Encryption DNS checks:
 >    Looking for TXT in forward dns zone: localhost.localdomain   [MISSING]
 >    Does the machine have at least one non-private address?      [FAILED]

I don't see anywhere that you've turned opportunistic encryption off.
ipsec.conf:
config setup
	oe=off # Openswan 2.6.x only

or

include /etc/ipsec.d/examples/no_oe.conf

Peter

Chris Garrigues wrote:
> Hi folks.
> 
> We have a SonicWALL NSA 4500 and I've been setting up our Linux based
> users up using OpenSWAN.  The Linux uses are running various versions of
> Linux and OpenSWAN.  Most are working fine, but I've attached a barf
> file from one who isn't.  I can't figure this one out and any assistance
> would be much appreciated.
> 
> Chris
> 
> 
> localhost.localdomain
> Wed Jan 21 09:12:34 EST 2009
> + _________________________ version
> + ipsec --version
> Linux Openswan U2.6.14/K2.6.27.5-41.fc9.i686 (netkey)
> See `ipsec --copyright' for copyright information.
> + _________________________ /proc/version
> + cat /proc/version
> Linux version 2.6.27.5-41.fc9.i686 (mockbuild@) (gcc version 4.3.0
> 20080428 (Red Hat 4.3.0-8) (GCC) ) #1 SMP Thu Nov 13 20:52:14 EST 2008
> + _________________________ /proc/net/ipsec_eroute
> + test -r /proc/net/ipsec_eroute
> + _________________________ netstat-rn
> + netstat -nr
> + head -n 100
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags   MSS Window  irtt
> Iface
> 192.168.15.0    0.0.0.0         255.255.255.0   U         0 0          0
> eth0
> 0.0.0.0         192.168.15.1    0.0.0.0         UG        0 0          0
> eth0
> + _________________________ /proc/net/ipsec_spi
> + test -r /proc/net/ipsec_spi
> + _________________________ /proc/net/ipsec_spigrp
> + test -r /proc/net/ipsec_spigrp
> + _________________________ /proc/net/ipsec_tncfg
> + test -r /proc/net/ipsec_tncfg
> + _________________________ /proc/net/pfkey
> + test -r /proc/net/pfkey
> + cat /proc/net/pfkey
> sk       RefCnt Rmem   Wmem   User   Inode
> + _________________________ ip-xfrm-state
> + ip xfrm state
> + _________________________ ip-xfrm-policy
> + ip xfrm policy
> + _________________________ /proc/crypto
> + test -r /proc/crypto
> + cat /proc/crypto
> name         : deflate
> driver       : deflate-generic
> module       : deflate
> priority     : 0
> refcnt       : 1
> type         : compression
> 
> name         : rfc3686(ctr(aes))
> driver       : rfc3686(ctr(aes-asm))
> module       : ctr
> priority     : 200
> refcnt       : 1
> type         : blkcipher
> blocksize    : 1
> min keysize  : 20
> max keysize  : 36
> ivsize       : 8
> geniv        : seqiv
> 
> name         : ctr(aes)
> driver       : ctr(aes-asm)
> module       : ctr
> priority     : 200
> refcnt       : 1
> type         : blkcipher
> blocksize    : 1
> min keysize  : 16
> max keysize  : 32
> ivsize       : 16
> geniv        : <default>
> 
> name         : cbc(twofish)
> driver       : cbc(twofish-generic)
> module       : cbc
> priority     : 100
> refcnt       : 1
> type         : blkcipher
> blocksize    : 16
> min keysize  : 16
> max keysize  : 32
> ivsize       : 16
> geniv        : <default>
> 
> name         : cbc(camellia)
> driver       : cbc(camellia-generic)
> module       : cbc
> priority     : 100
> refcnt       : 1
> type         : blkcipher
> blocksize    : 16
> min keysize  : 16
> max keysize  : 32
> ivsize       : 16
> geniv        : <default>
> 
> name         : camellia
> driver       : camellia-generic
> module       : camellia
> priority     : 100
> refcnt       : 1
> type         : cipher
> blocksize    : 16
> min keysize  : 16
> max keysize  : 32
> 
> name         : cbc(serpent)
> driver       : cbc(serpent-generic)
> module       : cbc
> priority     : 0
> refcnt       : 1
> type         : blkcipher
> blocksize    : 16
> min keysize  : 0
> max keysize  : 32
> ivsize       : 16
> geniv        : <default>
> 
> name         : cbc(aes)
> driver       : cbc(aes-asm)
> module       : cbc
> priority     : 200
> refcnt       : 1
> type         : blkcipher
> blocksize    : 16
> min keysize  : 16
> max keysize  : 32
> ivsize       : 16
> geniv        : <default>
> 
> name         : cbc(blowfish)
> driver       : cbc(blowfish-generic)
> module       : cbc
> priority     : 0
> refcnt       : 1
> type         : blkcipher
> blocksize    : 8
> min keysize  : 4
> max keysize  : 56
> ivsize       : 8
> geniv        : <default>
> 
> name         : cbc(des3_ede)
> driver       : cbc(des3_ede-generic)
> module       : cbc
> priority     : 0
> refcnt       : 1
> type         : blkcipher
> blocksize    : 8
> min keysize  : 24
> max keysize  : 24
> ivsize       : 8
> geniv        : <default>
> 
> name         : cbc(des)
> driver       : cbc(des-generic)
> module       : cbc
> priority     : 0
> refcnt       : 1
> type         : blkcipher
> blocksize    : 8
> min keysize  : 8
> max keysize  : 8
> ivsize       : 8
> geniv        : <default>
> 
> name         : xcbc(aes)
> driver       : xcbc(aes-asm)
> module       : xcbc
> priority     : 200
> refcnt       : 1
> type         : hash
> blocksize    : 16
> digestsize   : 16
> 
> name         : hmac(rmd160)
> driver       : hmac(rmd160)
> module       : kernel
> priority     : 0
> refcnt       : 1
> type         : hash
> blocksize    : 64
> digestsize   : 20
> 
> name         : rmd160
> driver       : rmd160
> module       : rmd160
> priority     : 0
> refcnt       : 1
> type         : digest
> blocksize    : 64
> digestsize   : 20
> 
> name         : hmac(sha256)
> driver       : hmac(sha256-generic)
> module       : kernel
> priority     : 0
> refcnt       : 1
> type         : hash
> blocksize    : 64
> digestsize   : 32
> 
> name         : hmac(sha1)
> driver       : hmac(sha1-generic)
> module       : kernel
> priority     : 0
> refcnt       : 1
> type         : hash
> blocksize    : 64
> digestsize   : 20
> 
> name         : hmac(md5)
> driver       : hmac(md5-generic)
> module       : kernel
> priority     : 0
> refcnt       : 1
> type         : hash
> blocksize    : 64
> digestsize   : 16
> 
> name         : compress_null
> driver       : compress_null-generic
> module       : crypto_null
> priority     : 0
> refcnt       : 1
> type         : compression
> 
> name         : digest_null
> driver       : digest_null-generic
> module       : crypto_null
> priority     : 0
> refcnt       : 1
> type         : digest
> blocksize    : 1
> digestsize   : 0
> 
> name         : ecb(cipher_null)
> driver       : ecb-cipher_null
> module       : crypto_null
> priority     : 100
> refcnt       : 1
> type         : blkcipher
> blocksize    : 1
> min keysize  : 0
> max keysize  : 0
> ivsize       : 0
> geniv        : <default>
> 
> name         : cipher_null
> driver       : cipher_null-generic
> module       : crypto_null
> priority     : 0
> refcnt       : 1
> type         : cipher
> blocksize    : 1
> min keysize  : 0
> max keysize  : 0
> 
> name         : tnepres
> driver       : tnepres-generic
> module       : serpent
> priority     : 0
> refcnt       : 1
> type         : cipher
> blocksize    : 16
> min keysize  : 0
> max keysize  : 32
> 
> name         : serpent
> driver       : serpent-generic
> module       : serpent
> priority     : 0
> refcnt       : 1
> type         : cipher
> blocksize    : 16
> min keysize  : 0
> max keysize  : 32
> 
> name         : blowfish
> driver       : blowfish-generic
> module       : blowfish
> priority     : 0
> refcnt       : 1
> type         : cipher
> blocksize    : 8
> min keysize  : 4
> max keysize  : 56
> 
> name         : twofish
> driver       : twofish-generic
> module       : twofish
> priority     : 100
> refcnt       : 1
> type         : cipher
> blocksize    : 16
> min keysize  : 16
> max keysize  : 32
> 
> name         : sha256
> driver       : sha256-generic
> module       : sha256_generic
> priority     : 0
> refcnt       : 1
> type         : digest
> blocksize    : 64
> digestsize   : 32
> 
> name         : sha224
> driver       : sha224-generic
> module       : sha256_generic
> priority     : 0
> refcnt       : 1
> type         : digest
> blocksize    : 64
> digestsize   : 28
> 
> name         : sha512
> driver       : sha512-generic
> module       : sha512_generic
> priority     : 0
> refcnt       : 1
> type         : digest
> blocksize    : 128
> digestsize   : 64
> 
> name         : sha384
> driver       : sha384-generic
> module       : sha512_generic
> priority     : 0
> refcnt       : 1
> type         : digest
> blocksize    : 128
> digestsize   : 48
> 
> name         : des3_ede
> driver       : des3_ede-generic
> module       : des_generic
> priority     : 0
> refcnt       : 1
> type         : cipher
> blocksize    : 8
> min keysize  : 24
> max keysize  : 24
> 
> name         : des
> driver       : des-generic
> module       : des_generic
> priority     : 0
> refcnt       : 1
> type         : cipher
> blocksize    : 8
> min keysize  : 8
> max keysize  : 8
> 
> name         : aes
> driver       : aes-asm
> module       : aes_i586
> priority     : 200
> refcnt       : 1
> type         : cipher
> blocksize    : 16
> min keysize  : 16
> max keysize  : 32
> 
> name         : aes
> driver       : aes-generic
> module       : aes_generic
> priority     : 100
> refcnt       : 1
> type         : cipher
> blocksize    : 16
> min keysize  : 16
> max keysize  : 32
> 
> name         : sha1
> driver       : sha1-generic
> module       : kernel
> priority     : 0
> refcnt       : 1
> type         : digest
> blocksize    : 64
> digestsize   : 20
> 
> name         : md5
> driver       : md5-generic
> module       : kernel
> priority     : 0
> refcnt       : 1
> type         : digest
> blocksize    : 64
> digestsize   : 16
> 
> + __________________________/proc/sys/net/core/xfrm-star
> /usr/libexec/ipsec/barf: line 191:
> __________________________/proc/sys/net/core/xfrm-star: No such file or
> directory
> + for i in '/proc/sys/net/core/xfrm_*'
> + echo -n '/proc/sys/net/core/xfrm_acq_expires: '
> /proc/sys/net/core/xfrm_acq_expires: + cat
> /proc/sys/net/core/xfrm_acq_expires
> 30
> + for i in '/proc/sys/net/core/xfrm_*'
> + echo -n '/proc/sys/net/core/xfrm_aevent_etime: '
> /proc/sys/net/core/xfrm_aevent_etime: + cat
> /proc/sys/net/core/xfrm_aevent_etime
> 10
> + for i in '/proc/sys/net/core/xfrm_*'
> + echo -n '/proc/sys/net/core/xfrm_aevent_rseqth: '
> /proc/sys/net/core/xfrm_aevent_rseqth: + cat
> /proc/sys/net/core/xfrm_aevent_rseqth
> 2
> + for i in '/proc/sys/net/core/xfrm_*'
> + echo -n '/proc/sys/net/core/xfrm_larval_drop: '
> /proc/sys/net/core/xfrm_larval_drop: + cat
> /proc/sys/net/core/xfrm_larval_drop
> 0
> + _________________________ /proc/sys/net/ipsec-star
> + test -d /proc/sys/net/ipsec
> + _________________________ ipsec/status
> + ipsec auto --status
> 000 using kernel interface: netkey
> 000 %myid = (none)
> 000 debug none
> 000 
> 000 algorithm ESP encrypt: id=2, name=ESP_DES, ivlen=8, keysizemin=64,
> keysizemax=64
> 000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, keysizemin=192,
> keysizemax=192
> 000 algorithm ESP encrypt: id=7, name=ESP_BLOWFISH, ivlen=8,
> keysizemin=40, keysizemax=448
> 000 algorithm ESP encrypt: id=11, name=ESP_NULL, ivlen=0, keysizemin=0,
> keysizemax=0
> 000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=8, keysizemin=128,
> keysizemax=256
> 000 algorithm ESP encrypt: id=13, name=ESP_AES_CTR, ivlen=8,
> keysizemin=128, keysizemax=256
> 000 algorithm ESP encrypt: id=14, name=ESP_AES_CCM_A, ivlen=8,
> keysizemin=128, keysizemax=256
> 000 algorithm ESP encrypt: id=15, name=ESP_AES_CCM_B, ivlen=8,
> keysizemin=128, keysizemax=256
> 000 algorithm ESP encrypt: id=16, name=ESP_AES_CCM_C, ivlen=8,
> keysizemin=128, keysizemax=256
> 000 algorithm ESP encrypt: id=18, name=ESP_AES_GCM_A, ivlen=8,
> keysizemin=128, keysizemax=256
> 000 algorithm ESP encrypt: id=19, name=ESP_AES_GCM_B, ivlen=8,
> keysizemin=128, keysizemax=256
> 000 algorithm ESP encrypt: id=20, name=ESP_AES_GCM_C, ivlen=8,
> keysizemin=128, keysizemax=256
> 000 algorithm ESP encrypt: id=22, name=ESP_CAMELLIA, ivlen=8,
> keysizemin=128, keysizemax=256
> 000 algorithm ESP encrypt: id=252, name=ESP_SERPENT, ivlen=8,
> keysizemin=128, keysizemax=256
> 000 algorithm ESP encrypt: id=253, name=ESP_TWOFISH, ivlen=8,
> keysizemin=128, keysizemax=256
> 000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5,
> keysizemin=128, keysizemax=128
> 000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1,
> keysizemin=160, keysizemax=160
> 000 algorithm ESP auth attr: id=5, name=AUTH_ALGORITHM_HMAC_SHA2_256,
> keysizemin=256, keysizemax=256
> 000 algorithm ESP auth attr: id=8, name=AUTH_ALGORITHM_HMAC_RIPEMD,
> keysizemin=160, keysizemax=160
> 000 algorithm ESP auth attr: id=9, name=AUTH_ALGORITHM_AES_CBC,
> keysizemin=128, keysizemax=128
> 000 algorithm ESP auth attr: id=251, name=(null), keysizemin=0, keysizemax=0
> 000 
> 000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=131
> 000 algorithm IKE encrypt: id=3, name=OAKLEY_BLOWFISH_CBC, blocksize=8,
> keydeflen=128
> 000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8,
> keydeflen=192
> 000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16,
> keydeflen=128
> 000 algorithm IKE encrypt: id=65004, name=OAKLEY_SERPENT_CBC,
> blocksize=16, keydeflen=128
> 000 algorithm IKE encrypt: id=65005, name=OAKLEY_TWOFISH_CBC,
> blocksize=16, keydeflen=128
> 000 algorithm IKE encrypt: id=65289, name=OAKLEY_TWOFISH_CBC_SSH,
> blocksize=16, keydeflen=128
> 000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
> 000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
> 000 algorithm IKE hash: id=4, name=OAKLEY_SHA2_256, hashsize=32
> 000 algorithm IKE hash: id=6, name=OAKLEY_SHA2_512, hashsize=64
> 000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
> 000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
> 000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
> 000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
> 000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
> 000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
> 000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192
> 000 
> 000 stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,0,0}
> trans={0,0,0} attrs={0,0,0}
> 000 
> 000 "vo":
> 192.168.10.0/24===67.220.126.196<67.220.126.196>[@vo,+S=C]...0.0.0.0---%any[@jingluo,+S=C]===192.168.200.56/32;
> unrouted; eroute owner: #0
> 000 "vo":     myip=unset; hisip=192.168.200.56;
> 000 "vo":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s;
> rekey_fuzz: 100%; keyingtries: 0
> 000 "vo":   policy: PSK+ENCRYPT+TUNNEL+PFS+IKEv2ALLOW+lKOD+rKOD; prio:
> 24,32; interface: ;
> 000 "vo":   newest ISAKMP SA: #0; newest IPsec SA: #0;
> 000 "vo":   IKE algorithms wanted: AES_CBC(7)_256-SHA1(2)-MODP1536(5),
> AES_CBC(7)_256-SHA1(2)-MODP1024(2); flags=-strict
> 000 "vo":   IKE algorithms found:  AES_CBC(7)_256-SHA1(2)_160-5,
> AES_CBC(7)_256-SHA1(2)_160-2,
> 000 "vo":   ESP algorithms wanted: AES(12)_256-SHA1(2); flags=-strict
> 000 "vo":   ESP algorithms loaded: AES(12)_256-SHA1(2)_160
> 000 "vodmz":
> 192.168.8.0/24===67.220.126.196<67.220.126.196>[@vo,+S=C]...0.0.0.0---%any[@jingluo,+S=C]===192.168.200.56/32;
> unrouted; eroute owner: #0
> 000 "vodmz":     myip=unset; hisip=192.168.200.56;
> 000 "vodmz":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s;
> rekey_fuzz: 100%; keyingtries: 0
> 000 "vodmz":   policy: PSK+ENCRYPT+TUNNEL+PFS+IKEv2ALLOW+lKOD+rKOD;
> prio: 24,32; interface: ;
> 000 "vodmz":   newest ISAKMP SA: #0; newest IPsec SA: #0;
> 000 "vodmz":   IKE algorithms wanted:
> AES_CBC(7)_256-SHA1(2)-MODP1536(5), AES_CBC(7)_256-SHA1(2)-MODP1024(2);
> flags=-strict
> 000 "vodmz":   IKE algorithms found:  AES_CBC(7)_256-SHA1(2)_160-5,
> AES_CBC(7)_256-SHA1(2)_160-2,
> 000 "vodmz":   ESP algorithms wanted: AES(12)_256-SHA1(2); flags=-strict
> 000 "vodmz":   ESP algorithms loaded: AES(12)_256-SHA1(2)_160
> 000 
> 000 
> + _________________________ ifconfig-a
> + ifconfig -a
> eth0      Link encap:Ethernet  HWaddr 00:1A:A0:49:D6:F0 
>           inet addr:192.168.15.3  Bcast:192.168.15.255  Mask:255.255.255.0
>           inet6 addr: fe80::21a:a0ff:fe49:d6f0/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:280 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:293 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:232070 (226.6 KiB)  TX bytes:59972 (58.5 KiB)
>           Interrupt:16
> 
> lo        Link encap:Local Loopback 
>           inet addr:127.0.0.1  Mask:255.0.0.0
>           inet6 addr: ::1/128 Scope:Host
>           UP LOOPBACK RUNNING  MTU:16436  Metric:1
>           RX packets:7774 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:7774 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0
>           RX bytes:388860 (379.7 KiB)  TX bytes:388860 (379.7 KiB)
> 
> pan0      Link encap:Ethernet  HWaddr 42:44:14:66:91:88 
>           BROADCAST MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0
>           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
> 
> + _________________________ ip-addr-list
> + ip addr list
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 scope host lo
>     inet6 ::1/128 scope host
>        valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UP qlen 1000
>     link/ether 00:1a:a0:49:d6:f0 brd ff:ff:ff:ff:ff:ff
>     inet 192.168.15.3/24 brd 192.168.15.255 scope global eth0
>     inet6 fe80::21a:a0ff:fe49:d6f0/64 scope link
>        valid_lft forever preferred_lft forever
> 3: pan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
>     link/ether 42:44:14:66:91:88 brd ff:ff:ff:ff:ff:ff
> + _________________________ ip-route-list
> + ip route list
> 192.168.15.0/24 dev eth0  proto kernel  scope link  src 192.168.15.3
> default via 192.168.15.1 dev eth0  proto static
> + _________________________ ip-rule-list
> + ip rule list
> 0:    from all lookup local
> 32766:    from all lookup main
> 32767:    from all lookup default
> + _________________________ ipsec_verify
> + ipsec verify --nocolour
> Checking your system to see if IPsec got installed and started correctly:
> Version check and ipsec on-path                                 [OK]
> Linux Openswan U2.6.14/K2.6.27.5-41.fc9.i686 (netkey)
> Checking for IPsec support in kernel                            [OK]
> NETKEY detected, testing for disabled ICMP send_redirects       [FAILED]
> 
>   Please disable /proc/sys/net/ipv4/conf/*/send_redirects
>   or NETKEY will cause the sending of bogus ICMP redirects!
> 
> NETKEY detected, testing for disabled ICMP accept_redirects     [FAILED]
> 
>   Please disable /proc/sys/net/ipv4/conf/*/accept_redirects
>   or NETKEY will accept bogus ICMP redirects!
> 
> Checking for RSA private key (/etc/ipsec.secrets)               [OK]
> Checking that pluto is running                                  [OK]
> Pluto not listening on port udp 500. Check interfaces defintion in
> ipsec.conf.Two or more interfaces found, checking IP forwarding       
>     [FAILED]
> Checking for 'ip' command                                       [OK]
> Checking for 'iptables' command                                 [OK]
> 
> Opportunistic Encryption DNS checks:
>    Looking for TXT in forward dns zone: localhost.localdomain    [MISSING]
>    Does the machine have at least one non-private address?      [FAILED]
> + _________________________ mii-tool
> + '[' -x /sbin/mii-tool ']'
> + /sbin/mii-tool -v
> eth0: negotiated 100baseTx-FD, link ok
>   product info: vendor 00:50:ef, model 14 rev 0
>   basic mode:   autonegotiation enabled
>   basic status: autonegotiation complete, link ok
>   capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
>   advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
>   link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> + _________________________ ipsec/directory
> + ipsec --directory
> /usr/libexec/ipsec
> + _________________________ hostname/fqdn
> + hostname --fqdn
> localhost.localdomain
> + _________________________ hostname/ipaddress
> + hostname --ip-address
> 127.0.0.1
> + _________________________ uptime
> + uptime
>  09:12:55 up 13 min,  2 users,  load average: 0.18, 0.27, 0.19
> + _________________________ ps
> + ps alxwf
> + egrep -i 'ppid|pluto|ipsec|klips'
> F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
> 4     0  4865  3471  20   0   5668  1136 wait   S+   pts/1     
> 0:00              \_ /bin/sh /usr/libexec/ipsec/barf
> 0     0  4984  4865  20   0   2044   504 pipe_w S+   pts/1     
> 0:00                  \_ egrep -i ppid|pluto|ipsec|klips
> 1     0  4642     1  20   0   2668   412 wait   S    pts/1      0:00
> /bin/sh /usr/libexec/ipsec/_plutorun --debug  --uniqueids no
> --force_busy no --nocrsend no --strictcrlpolicy  --nat_traversal yes
> --keep_alive  --protostack netkey --force_keepalive 
> --disable_port_floating  --virtual_private  --crlcheckinterval 0
> --ocspuri  --nhelpers  --dump  --opts  --stderrlog  --wait no --pre 
> --post  --log daemon.error --plutorestartoncrash false --pid
> /var/run/pluto/pluto.pid
> 1     0  4646  4642  20   0   2668   544 wait   S    pts/1      0:00  \_
> /bin/sh /usr/libexec/ipsec/_plutorun --debug  --uniqueids no
> --force_busy no --nocrsend no --strictcrlpolicy  --nat_traversal yes
> --keep_alive  --protostack netkey --force_keepalive 
> --disable_port_floating  --virtual_private  --crlcheckinterval 0
> --ocspuri  --nhelpers  --dump  --opts  --stderrlog  --wait no --pre 
> --post  --log daemon.error --plutorestartoncrash false --pid
> /var/run/pluto/pluto.pid
> 4     0  4647  4646  20   0   3260  1156 select S    pts/1      0:00 
> |   \_ /usr/libexec/ipsec/pluto --nofork --secretsfile
> /etc/ipsec.secrets --use-netkey --nat_traversal
> 1     0  4648  4647  30  10   3268   580 unix_s SN   pts/1      0:00 
> |       \_ pluto helper  # 
> 0                                                                            
> 
> 0     0  4685  4647  20   0   1756   296 select S    pts/1      0:00 
> |       \_ _pluto_adns
> 4     0  4651  4642  20   0   2668   964 pipe_w S    pts/1      0:00  \_
> /bin/sh /usr/libexec/ipsec/_plutoload --wait no --post
> 4     0  4643     1  20   0   1808   504 pipe_w S    pts/1      0:00
> logger -s -p daemon.error -t ipsec__plutorun
> + _________________________ ipsec/showdefaults
> + ipsec showdefaults
> ipsec showdefaults: cannot find defaults file `/var/run/pluto/ipsec.info'
> + _________________________ ipsec/conf
> + ipsec _include /etc/ipsec.conf
> + ipsec _keycensor
> 
> #< /etc/ipsec.conf 1
> # /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"
>     # For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
>     protostack=netkey
>     nat_traversal=yes
> 
> 
> #< /etc/ipsec.d/ipsec.conf 1
> conn vo
>     also=vocommon
>     rightsubnet=192.168.10.0/24
>     auto=start
> 
> conn vodmz
>     also=vocommon
>     rightsubnet=192.168.8.0/24
>     auto=start
> 
> conn vocommon
>     type=tunnel
>     left=%defaultroute
>     leftid=@jingluo
>     leftsourceip=192.168.200.56
>     leftsubnet=192.168.200.56/32
>     rightid=@vo
>     right=67.220.126.196
>     keyingtries=0
>     pfs=yes
>     authby=secret
>     auth=esp
>     ike=aes256-sha1
>     esp=aes256-sha1
>     keyexchange=ike
> 
> 
> #> /etc/ipsec.conf 19
> + _________________________ ipsec/secrets
> + ipsec _include /etc/ipsec.secrets
> + ipsec _secretcensor
> 
> #< /etc/ipsec.secrets 1
> 
> #< /etc/ipsec.d/ipsec.secrets 1
> @jingluo @vo : PSK "[sums to 3db3...]"
> 
> #> /etc/ipsec.secrets 2
> + _________________________ ipsec/listall
> + ipsec auto --listall
> 000 
> 000 List of Public Keys:
> 000 
> 000 List of Pre-shared secrets (from /etc/ipsec.secrets)
> + '[' /etc/ipsec.d/policies ']'
> + for policy in '$POLICIES/*'
> ++ basename /etc/ipsec.d/policies/block
> + base=block
> + _________________________ ipsec/policies/block
> + cat /etc/ipsec.d/policies/block
> # This file defines the set of CIDRs (network/mask-length) to which
> # communication should never be allowed.
> #
> # See /usr/share/doc/openswan/policygroups.html for details.
> #
> # $Id: block.in,v 1.4 2003/02/17 02:22:15 mcr Exp $
> #
> 
> + for policy in '$POLICIES/*'
> ++ basename /etc/ipsec.d/policies/clear
> + base=clear
> + _________________________ ipsec/policies/clear
> + cat /etc/ipsec.d/policies/clear
> # This file defines the set of CIDRs (network/mask-length) to which
> # communication should always be in the clear.
> #
> # See /usr/share/doc/openswan/policygroups.html for details.
> #
> 
> # root name servers should be in the clear
> 192.58.128.30/32
> 198.41.0.4/32
> 192.228.79.201/32
> 192.33.4.12/32
> 128.8.10.90/32
> 192.203.230.10/32
> 192.5.5.241/32
> 192.112.36.4/32
> 128.63.2.53/32
> 192.36.148.17/32
> 193.0.14.129/32
> 199.7.83.42/32
> 202.12.27.33/32
> + for policy in '$POLICIES/*'
> ++ basename /etc/ipsec.d/policies/clear-or-private
> + base=clear-or-private
> + _________________________ ipsec/policies/clear-or-private
> + cat /etc/ipsec.d/policies/clear-or-private
> # This file defines the set of CIDRs (network/mask-length) to which
> # we will communicate in the clear, or, if the other side initiates IPSEC,
> # using encryption.  This behaviour is also called "Opportunistic
> Responder".
> #
> # See /usr/share/doc/openswan/policygroups.html for details.
> #
> # $Id: clear-or-private.in,v 1.4 2003/02/17 02:22:15 mcr Exp $
> #
> + for policy in '$POLICIES/*'
> ++ basename /etc/ipsec.d/policies/private
> + base=private
> + _________________________ ipsec/policies/private
> + cat /etc/ipsec.d/policies/private
> # This file defines the set of CIDRs (network/mask-length) to which
> # communication should always be private (i.e. encrypted).
> # See /usr/share/doc/openswan/policygroups.html for details.
> #
> # $Id: private.in,v 1.4 2003/02/17 02:22:15 mcr Exp $
> #
> + for policy in '$POLICIES/*'
> ++ basename /etc/ipsec.d/policies/private-or-clear
> + base=private-or-clear
> + _________________________ ipsec/policies/private-or-clear
> + cat /etc/ipsec.d/policies/private-or-clear
> # This file defines the set of CIDRs (network/mask-length) to which
> # communication should be private, if possible, but in the clear otherwise.
> #
> # If the target has a TXT (later IPSECKEY) record that specifies
> # authentication material, we will require private (i.e. encrypted)
> # communications.  If no such record is found, communications will be
> # in the clear.
> #
> # See /usr/share/doc/openswan/policygroups.html for details.
> #
> # $Id: private-or-clear.in,v 1.5 2003/02/17 02:22:15 mcr Exp $
> #
> 
> 0.0.0.0/0
> + _________________________ ipsec/ls-libdir
> + ls -l /usr/libexec/ipsec
> total 2256
> -rwxr-xr-x 1 root root   6056 Jun  6  2008 _copyright
> -rwxr-xr-x 1 root root   2379 Jun  6  2008 _include
> -rwxr-xr-x 1 root root   1475 Jun  6  2008 _keycensor
> -rwxr-xr-x 1 root root  10088 Jun  6  2008 _pluto_adns
> -rwxr-xr-x 1 root root   2632 Jun  6  2008 _plutoload
> -rwxr-xr-x 1 root root   7602 Jun  6  2008 _plutorun
> -rwxr-xr-x 1 root root  13746 Jun  6  2008 _realsetup
> -rwxr-xr-x 1 root root   1975 Jun  6  2008 _secretcensor
> -rwxr-xr-x 1 root root   9752 Jun  6  2008 _startklips
> -rwxr-xr-x 1 root root   9752 Jun  6  2008 _startklips.old
> -rwxr-xr-x 1 root root   4988 Jun  6  2008 _startnetkey
> -rwxr-xr-x 1 root root   4949 Jun  6  2008 _updown
> -rwxr-xr-x 1 root root  14030 Jun  6  2008 _updown.klips
> -rwxr-xr-x 1 root root  14030 Jun  6  2008 _updown.klips.old
> -rwxr-xr-x 1 root root  13739 Jun  6  2008 _updown.mast
> -rwxr-xr-x 1 root root  13739 Jun  6  2008 _updown.mast.old
> -rwxr-xr-x 1 root root   8337 Jun  6  2008 _updown.netkey
> -rwxr-xr-x 1 root root 188348 Jun  6  2008 addconn
> -rwxr-xr-x 1 root root   6129 Jun  6  2008 auto
> -rwxr-xr-x 1 root root  10758 Jun  6  2008 barf
> -rwxr-xr-x 1 root root  90088 Jun  6  2008 eroute
> -rwxr-xr-x 1 root root  20708 Jun  6  2008 ikeping
> -rwxr-xr-x 1 root root  69804 Jun  6  2008 klipsdebug
> -rwxr-xr-x 1 root root   1836 Jun  6  2008 livetest
> -rwxr-xr-x 1 root root   2591 Jun  6  2008 look
> -rwxr-xr-x 1 root root   1921 Jun  6  2008 newhostkey
> -rwxr-xr-x 1 root root  60840 Jun  6  2008 pf_key
> -rwxr-xr-x 1 root root 957728 Jun  6  2008 pluto
> -rwxr-xr-x 1 root root  10236 Jun  6  2008 ranbits
> -rwxr-xr-x 1 root root  20176 Jun  6  2008 rsasigkey
> -rwxr-xr-x 1 root root    766 Jun  6  2008 secrets
> lrwxrwxrwx 1 root root     30 Jan 20 09:30 setup ->
> ../../../etc/rc.d/init.d/ipsec
> -rwxr-xr-x 1 root root   1054 Jun  6  2008 showdefaults
> -rwxr-xr-x 1 root root 219368 Jun  6  2008 showhostkey
> -rwxr-xr-x 1 root root  22744 Jun  6  2008 showpolicy
> -rwxr-xr-x 1 root root 148388 Jun  6  2008 spi
> -rwxr-xr-x 1 root root  77336 Jun  6  2008 spigrp
> -rwxr-xr-x 1 root root  69700 Jun  6  2008 tncfg
> -rwxr-xr-x 1 root root  12526 Jun  6  2008 verify
> -rwxr-xr-x 1 root root  50340 Jun  6  2008 whack
> + _________________________ ipsec/ls-execdir
> + ls -l /usr/libexec/ipsec
> total 2256
> -rwxr-xr-x 1 root root   6056 Jun  6  2008 _copyright
> -rwxr-xr-x 1 root root   2379 Jun  6  2008 _include
> -rwxr-xr-x 1 root root   1475 Jun  6  2008 _keycensor
> -rwxr-xr-x 1 root root  10088 Jun  6  2008 _pluto_adns
> -rwxr-xr-x 1 root root   2632 Jun  6  2008 _plutoload
> -rwxr-xr-x 1 root root   7602 Jun  6  2008 _plutorun
> -rwxr-xr-x 1 root root  13746 Jun  6  2008 _realsetup
> -rwxr-xr-x 1 root root   1975 Jun  6  2008 _secretcensor
> -rwxr-xr-x 1 root root   9752 Jun  6  2008 _startklips
> -rwxr-xr-x 1 root root   9752 Jun  6  2008 _startklips.old
> -rwxr-xr-x 1 root root   4988 Jun  6  2008 _startnetkey
> -rwxr-xr-x 1 root root   4949 Jun  6  2008 _updown
> -rwxr-xr-x 1 root root  14030 Jun  6  2008 _updown.klips
> -rwxr-xr-x 1 root root  14030 Jun  6  2008 _updown.klips.old
> -rwxr-xr-x 1 root root  13739 Jun  6  2008 _updown.mast
> -rwxr-xr-x 1 root root  13739 Jun  6  2008 _updown.mast.old
> -rwxr-xr-x 1 root root   8337 Jun  6  2008 _updown.netkey
> -rwxr-xr-x 1 root root 188348 Jun  6  2008 addconn
> -rwxr-xr-x 1 root root   6129 Jun  6  2008 auto
> -rwxr-xr-x 1 root root  10758 Jun  6  2008 barf
> -rwxr-xr-x 1 root root  90088 Jun  6  2008 eroute
> -rwxr-xr-x 1 root root  20708 Jun  6  2008 ikeping
> -rwxr-xr-x 1 root root  69804 Jun  6  2008 klipsdebug
> -rwxr-xr-x 1 root root   1836 Jun  6  2008 livetest
> -rwxr-xr-x 1 root root   2591 Jun  6  2008 look
> -rwxr-xr-x 1 root root   1921 Jun  6  2008 newhostkey
> -rwxr-xr-x 1 root root  60840 Jun  6  2008 pf_key
> -rwxr-xr-x 1 root root 957728 Jun  6  2008 pluto
> -rwxr-xr-x 1 root root  10236 Jun  6  2008 ranbits
> -rwxr-xr-x 1 root root  20176 Jun  6  2008 rsasigkey
> -rwxr-xr-x 1 root root    766 Jun  6  2008 secrets
> lrwxrwxrwx 1 root root     30 Jan 20 09:30 setup ->
> ../../../etc/rc.d/init.d/ipsec
> -rwxr-xr-x 1 root root   1054 Jun  6  2008 showdefaults
> -rwxr-xr-x 1 root root 219368 Jun  6  2008 showhostkey
> -rwxr-xr-x 1 root root  22744 Jun  6  2008 showpolicy
> -rwxr-xr-x 1 root root 148388 Jun  6  2008 spi
> -rwxr-xr-x 1 root root  77336 Jun  6  2008 spigrp
> -rwxr-xr-x 1 root root  69700 Jun  6  2008 tncfg
> -rwxr-xr-x 1 root root  12526 Jun  6  2008 verify
> -rwxr-xr-x 1 root root  50340 Jun  6  2008 whack
> + _________________________ /proc/net/dev
> + cat /proc/net/dev
> Inter-|   Receive                                                |  Transmit
>  face |bytes    packets errs drop fifo frame compressed
> multicast|bytes    packets errs drop fifo colls carrier compressed
>     lo:  388860    7774    0    0    0     0          0         0  
> 388860    7774    0    0    0     0       0          0
>   eth0:  232513     283    0    0    0     0          0         0   
> 60510     300    0    0    0     0       0          0
>   pan0:       0       0    0    0    0     0          0         0       
> 0       0    0    0    0     0       0          0
> + _________________________ /proc/net/route
> + cat /proc/net/route
> Iface    Destination    Gateway     Flags    RefCnt    Use    Metric   
> Mask        MTU    Window   
> IRTT                                                      
> eth0    000FA8C0    00000000    0001    0    0    0    00FFFFFF    0   
> 0   
> 0                                                                              
> 
> eth0    00000000    010FA8C0    0003    0    0    0    00000000    0   
> 0   
> 0                                                                              
> 
> + _________________________ /proc/sys/net/ipv4/ip_no_pmtu_disc
> + cat /proc/sys/net/ipv4/ip_no_pmtu_disc
> 0
> + _________________________ /proc/sys/net/ipv4/ip_forward
> + cat /proc/sys/net/ipv4/ip_forward
> 0
> + _________________________ /proc/sys/net/ipv4/tcp_ecn
> + cat /proc/sys/net/ipv4/tcp_ecn
> 0
> + _________________________ /proc/sys/net/ipv4/conf/star-rp_filter
> + cd /proc/sys/net/ipv4/conf
> + egrep '^' all/rp_filter default/rp_filter eth0/rp_filter lo/rp_filter
> pan0/rp_filter
> all/rp_filter:0
> default/rp_filter:1
> eth0/rp_filter:1
> lo/rp_filter:1
> pan0/rp_filter:1
> + _________________________ /proc/sys/net/ipv4/conf/star-star-redirects
> + cd /proc/sys/net/ipv4/conf
> + egrep '^' all/accept_redirects all/secure_redirects all/send_redirects
> default/accept_redirects default/secure_redirects default/send_redirects
> eth0/accept_redirects eth0/secure_redirects eth0/send_redirects
> lo/accept_redirects lo/secure_redirects lo/send_redirects
> pan0/accept_redirects pan0/secure_redirects pan0/send_redirects
> all/accept_redirects:1
> all/secure_redirects:1
> all/send_redirects:1
> default/accept_redirects:1
> default/secure_redirects:1
> default/send_redirects:1
> eth0/accept_redirects:1
> eth0/secure_redirects:1
> eth0/send_redirects:1
> lo/accept_redirects:1
> lo/secure_redirects:1
> lo/send_redirects:1
> pan0/accept_redirects:1
> pan0/secure_redirects:1
> pan0/send_redirects:1
> + _________________________ /proc/sys/net/ipv4/tcp_window_scaling
> + cat /proc/sys/net/ipv4/tcp_window_scaling
> 1
> + _________________________ /proc/sys/net/ipv4/tcp_adv_win_scale
> + cat /proc/sys/net/ipv4/tcp_adv_win_scale
> 2
> + _________________________ uname-a
> + uname -a
> Linux localhost.localdomain 2.6.27.5-41.fc9.i686 #1 SMP Thu Nov 13
> 20:52:14 EST 2008 i686 i686 i386 GNU/Linux
> + _________________________ config-built-with
> + test -r /proc/config_built_with
> + _________________________ distro-release
> + for distro in /etc/redhat-release /etc/debian-release
> /etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
> /etc/gentoo-release
> + test -f /etc/redhat-release
> + cat /etc/redhat-release
> Fedora release 9 (Sulphur)
> + for distro in /etc/redhat-release /etc/debian-release
> /etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
> /etc/gentoo-release
> + test -f /etc/debian-release
> + for distro in /etc/redhat-release /etc/debian-release
> /etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
> /etc/gentoo-release
> + test -f /etc/SuSE-release
> + for distro in /etc/redhat-release /etc/debian-release
> /etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
> /etc/gentoo-release
> + test -f /etc/mandrake-release
> + for distro in /etc/redhat-release /etc/debian-release
> /etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
> /etc/gentoo-release
> + test -f /etc/mandriva-release
> + for distro in /etc/redhat-release /etc/debian-release
> /etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
> /etc/gentoo-release
> + test -f /etc/gentoo-release
> + _________________________ /proc/net/ipsec_version
> + test -r /proc/net/ipsec_version
> + test -r /proc/net/pfkey
> ++ uname -r
> + echo 'NETKEY (2.6.27.5-41.fc9.i686) support detected '
> NETKEY (2.6.27.5-41.fc9.i686) support detected
> + _________________________ iptables
> + test -r /sbin/iptables
> + iptables -L -v -n
> + _________________________ iptables-nat
> + iptables -t nat -L -v -n
> + _________________________ iptables-mangle
> + iptables -t mangle -L -v -n
> + _________________________ /proc/modules
> + test -f /proc/modules
> + cat /proc/modules
> iptable_mangle 6656 0 - Live 0xfad5d000
> iptable_nat 8712 0 - Live 0xfad7a000
> nf_nat 17944 1 iptable_nat, Live 0xfad81000
> ipcomp6 6912 0 - Live 0xfacdb000
> ipcomp 6656 0 - Live 0xfac54000
> ah6 9216 0 - Live 0xfad76000
> ah4 8320 0 - Live 0xfacd3000
> esp6 9472 0 - Live 0xfaccf000
> esp4 9472 0 - Live 0xfaccb000
> xfrm4_mode_beet 6400 0 - Live 0xfacbc000
> xfrm4_tunnel 6272 0 - Live 0xfacb9000
> xfrm4_mode_tunnel 6272 0 - Live 0xfacb6000
> xfrm4_mode_transport 5760 0 - Live 0xfacb3000
> xfrm6_mode_transport 5760 0 - Live 0xfac86000
> xfrm6_mode_ro 5632 0 - Live 0xfac83000
> xfrm6_mode_beet 6144 0 - Live 0xfac80000
> xfrm6_mode_tunnel 6144 0 - Live 0xfac7d000
> af_key 30356 0 - Live 0xfac66000
> nls_utf8 5632 1 - Live 0xfad73000
> deflate 6528 0 - Live 0xfad60000
> zlib_deflate 21224 1 deflate, Live 0xfad6c000
> ctr 7936 0 - Live 0xfad34000
> camellia 22144 0 - Live 0xfad65000
> bridge 43668 0 - Live 0xfad47000
> stp 6148 1 bridge, Live 0xfad37000
> bnep 14848 2 - Live 0xfad2a000
> rfcomm 33936 4 - Live 0xfad53000
> rmd160 14720 0 - Live 0xfad2f000
> l2cap 21504 16 bnep,rfcomm, Live 0xfad18000
> bluetooth 48608 5 bnep,rfcomm,l2cap, Live 0xfad3a000
> crypto_null 6784 0 - Live 0xfad0f000
> ccm 11776 0 - Live 0xfad26000
> serpent 22912 0 - Live 0xfad1f000
> blowfish 12032 0 - Live 0xfacf7000
> twofish 10880 0 - Live 0xfad0b000
> twofish_common 17024 1 twofish, Live 0xfad12000
> ecb 6528 0 - Live 0xfad08000
> xcbc 8200 0 - Live 0xfad04000
> cbc 7168 0 - Live 0xfacfb000
> crypto_blkcipher 18052 5 ctr,crypto_null,ccm,ecb,cbc, Live 0xfacfe000
> sha256_generic 16128 0 - Live 0xfacee000
> sha512_generic 11904 0 - Live 0xfacf3000
> des_generic 20352 0 - Live 0xfacde000
> aes_i586 11648 0 - Live 0xfacbf000
> aes_generic 31144 1 aes_i586, Live 0xface5000
> xfrm_ipcomp 8584 2 ipcomp6,ipcomp, Live 0xfacd7000
> aead 9600 3 esp6,esp4,ccm, Live 0xfacc3000
> tunnel4 6792 1 xfrm4_tunnel, Live 0xfac51000
> xfrm6_tunnel 9860 1 ipcomp6, Live 0xfac62000
> tunnel6 6664 1 xfrm6_tunnel, Live 0xfac5f000
> fuse 49436 3 - Live 0xfac6f000
> sunrpc 155924 3 - Live 0xfac8b000
> ipt_REJECT 6656 2 - Live 0xfac5c000
> nf_conntrack_ipv4 11528 5 iptable_nat,nf_nat, Live 0xfab28000
> iptable_filter 6528 1 - Live 0xfac40000
> ip_tables 13712 3 iptable_mangle,iptable_nat,iptable_filter, Live 0xfac57000
> ip6t_REJECT 7296 2 - Live 0xfac38000
> xt_tcpudp 6656 2 - Live 0xfac35000
> nf_conntrack_ipv6 15864 2 - Live 0xfac3b000
> xt_state 5888 4 - Live 0xfac32000
> nf_conntrack 51424 5
> iptable_nat,nf_nat,nf_conntrack_ipv4,nf_conntrack_ipv6,xt_state, Live
> 0xfac43000
> ip6table_filter 6400 1 - Live 0xfab2c000
> ip6_tables 14736 1 ip6table_filter, Live 0xf8ade000
> x_tables 15236 7
> iptable_nat,ipt_REJECT,ip_tables,ip6t_REJECT,xt_tcpudp,xt_state,ip6_tables,
> Live 0xf8ad1000
> cpufreq_ondemand 9868 2 - Live 0xf8ada000
> acpi_cpufreq 12172 0 - Live 0xf8ad6000
> dm_multipath 17292 0 - Live 0xf8a59000
> scsi_dh 9476 1 dm_multipath, Live 0xf89d2000
> radeon 119044 2 - Live 0xf8b08000
> drm 146404 3 radeon, Live 0xf8ae3000
> ipv6 230260 39
> ipcomp6,ah6,esp6,xfrm6_mode_beet,xfrm6_mode_tunnel,xfrm6_tunnel,tunnel6,ip6t_REJECT,nf_conntrack_ipv6,
> Live 0xf8a1f000
> snd_hda_intel 351380 4 - Live 0xf8a5f000
> snd_seq_dummy 6660 0 - Live 0xf89a3000
> snd_seq_oss 30364 0 - Live 0xf89e3000
> snd_seq_midi_event 9600 1 snd_seq_oss, Live 0xf89b0000
> snd_seq 48576 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event, Live
> 0xf89d6000
> snd_seq_device 9996 3 snd_seq_dummy,snd_seq_oss,snd_seq, Live 0xf89ac000
> snd_pcm_oss 42496 0 - Live 0xf89ba000
> snd_mixer_oss 16896 1 snd_pcm_oss, Live 0xf89a6000
> snd_pcm 65924 3 snd_hda_intel,snd_pcm_oss, Live 0xf896e000
> snd_timer 22024 2 snd_seq,snd_pcm, Live 0xf8926000
> snd_page_alloc 11016 2 snd_hda_intel,snd_pcm, Live 0xf896a000
> snd_hwdep 10500 1 snd_hda_intel, Live 0xf8937000
> ppdev 10372 0 - Live 0xf8933000
> snd 50744 17
> snd_hda_intel,snd_seq_dummy,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_hwdep,
> Live 0xf8991000
> parport_pc 25620 0 - Live 0xf893d000
> parport 31956 2 ppdev,parport_pc, Live 0xf8961000
> dcdbas 10272 0 - Live 0xf891e000
> sr_mod 17064 1 - Live 0xf892d000
> tg3 107780 0 - Live 0xf8945000
> serio_raw 8836 0 - Live 0xf8922000
> libphy 18560 1 tg3, Live 0xf88fd000
> soundcore 9416 1 snd, Live 0xf891a000
> iTCO_wdt 13732 0 - Live 0xf8903000
> cdrom 32664 1 sr_mod, Live 0xf8911000
> i2c_i801 12048 0 - Live 0xf88ca000
> iTCO_vendor_support 6916 1 iTCO_wdt, Live 0xf8834000
> pcspkr 6272 0 - Live 0xf88ba000
> i2c_core 21396 2 drm,i2c_i801, Live 0xf88f0000
> sg 31028 0 - Live 0xf8908000
> dm_snapshot 19364 0 - Live 0xf88f7000
> dm_zero 5632 0 - Live 0xf88ad000
> dm_mirror 19968 0 - Live 0xf88b4000
> dm_log 12164 1 dm_mirror, Live 0xf884e000
> dm_mod 48692 10 dm_multipath,dm_snapshot,dm_zero,dm_mirror,dm_log, Live
> 0xf88bd000
> pata_acpi 7680 0 - Live 0xf884b000
> ata_generic 8452 0 - Live 0xf8847000
> ata_piix 24836 3 - Live 0xf88a5000
> libata 134380 3 pata_acpi,ata_generic,ata_piix, Live 0xf88ce000
> sd_mod 32408 3 - Live 0xf889c000
> scsi_mod 123772 5 scsi_dh,sr_mod,sg,libata,sd_mod, Live 0xf885f000
> crc_t10dif 5632 1 sd_mod, Live 0xf8844000
> ext3 109192 2 - Live 0xf8880000
> jbd 42900 1 ext3, Live 0xf8853000
> mbcache 10244 1 ext3, Live 0xf8839000
> uhci_hcd 23312 0 - Live 0xf883d000
> ohci_hcd 24336 0 - Live 0xf8824000
> ehci_hcd 32524 0 - Live 0xf882b000
> + _________________________ /proc/meminfo
> + cat /proc/meminfo
> MemTotal:      2072476 kB
> MemFree:       1448564 kB
> Buffers:         16808 kB
> Cached:         200772 kB
> SwapCached:          0 kB
> Active:         394208 kB
> Inactive:       105636 kB
> HighTotal:     1177596 kB
> HighFree:       683760 kB
> LowTotal:       894880 kB
> LowFree:        764804 kB
> SwapTotal:     2031608 kB
> SwapFree:      2031608 kB
> Dirty:             116 kB
> Writeback:           0 kB
> AnonPages:      282396 kB
> Mapped:          68340 kB
> Slab:            25928 kB
> SReclaimable:    10220 kB
> SUnreclaim:      15708 kB
> PageTables:       5136 kB
> NFS_Unstable:        0 kB
> Bounce:              0 kB
> WritebackTmp:        0 kB
> CommitLimit:   3067844 kB
> Committed_AS:   878784 kB
> VmallocTotal:   110584 kB
> VmallocUsed:     38328 kB
> VmallocChunk:    72156 kB
> HugePages_Total:     0
> HugePages_Free:      0
> HugePages_Rsvd:      0
> HugePages_Surp:      0
> Hugepagesize:     4096 kB
> DirectMap4k:      8192 kB
> DirectMap4M:    909312 kB
> + _________________________ /proc/net/ipsec-ls
> + test -f /proc/net/ipsec_version
> + _________________________ usr/src/linux/.config
> + test -f /proc/config.gz
> ++ uname -r
> + test -f /lib/modules/2.6.27.5-41.fc9.i686/build/.config
> + echo 'no .config file found, cannot list kernel properties'
> no .config file found, cannot list kernel properties
> + _________________________ etc/syslog.conf
> + _________________________ etc/syslog-ng/syslog-ng.conf
> + cat /etc/syslog-ng/syslog-ng.conf
> cat: /etc/syslog-ng/syslog-ng.conf: No such file or directory
> + cat /etc/syslog.conf
> cat: /etc/syslog.conf: No such file or directory
> + _________________________ etc/resolv.conf
> + cat /etc/resolv.conf
> # generated by NetworkManager, do not edit!
> 
> nameserver 192.168.15.1
> 
> + _________________________ lib/modules-ls
> + ls -ltr /lib/modules
> total 12
> drwxr-xr-x 7 root root 4096 Oct 24 17:56 2.6.26.6-79.fc9.i686
> drwxr-xr-x 7 root root 4096 Nov 15 12:00 2.6.27.5-37.fc9.i686
> drwxr-xr-x 7 root root 4096 Nov 19 13:03 2.6.27.5-41.fc9.i686
> + _________________________ /proc/ksyms-netif_rx
> + test -r /proc/ksyms
> + test -r /proc/kallsyms
> + egrep netif_rx /proc/kallsyms
> c05d6055 T netif_rx
> c05d6697 T netif_rx_ni
> c072abbc r __ksymtab_netif_rx
> c072acc4 r __ksymtab_netif_rx_ni
> c073b292 r __kstrtab_netif_rx
> c073b4ce r __kstrtab_netif_rx_ni
> c05d6697 u netif_rx_ni    [bnep]
> c05d6055 u netif_rx    [ipv6]
> f894f103 t netif_rx_schedule    [tg3]
> f8950af8 t netif_rx_complete    [tg3]
> + _________________________ lib/modules-netif_rx
> + modulegoo kernel/net/ipv4/ipip.o netif_rx
> + set +x
> 2.6.26.6-79.fc9.i686:
> 2.6.27.5-37.fc9.i686:
> 2.6.27.5-41.fc9.i686:
> + _________________________ kern.debug
> + test -f /var/log/kern.debug
> + _________________________ klog
> + sed -n '5304,$p' /var/log/messages
> + egrep -i 'ipsec|klips|pluto'
> + case "$1" in
> + cat
> Jan 21 09:10:00 localhost ipsec_setup: Starting Openswan IPsec
> U2.6.14/K2.6.27.5-41.fc9.i686...
> Jan 21 09:10:00 localhost ipsec_setup:
> Jan 21 09:10:00 localhost ipsec_setup:
> Jan 21 09:10:00 localhost setroubleshoot: SELinux is preventing logger
> (ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
> run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
> Jan 21 09:10:00 localhost setroubleshoot: SELinux is preventing logger
> (ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
> run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
> Jan 21 09:10:01 localhost setroubleshoot: SELinux is preventing logger
> (ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
> run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
> Jan 21 09:10:01 localhost setroubleshoot: SELinux is preventing pluto
> (ipsec_t) "search" to ./home (home_root_t). For complete SELinux
> messages. run sealert -l 606544c1-5dfb-428e-badb-d719177ea1a7
> Jan 21 09:10:01 localhost setroubleshoot: SELinux is preventing pluto
> (ipsec_t) "search" to ./home (home_root_t). For complete SELinux
> messages. run sealert -l 606544c1-5dfb-428e-badb-d719177ea1a7
> Jan 21 09:10:01 localhost setroubleshoot: SELinux is preventing logger
> (ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
> run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
> Jan 21 09:10:02 localhost setroubleshoot: SELinux is preventing logger
> (ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
> run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
> Jan 21 09:10:02 localhost setroubleshoot: SELinux is preventing auto
> (ipsec_mgmt_t) "execute_no_trans" to /bin/bash (shell_exec_t). For
> complete SELinux messages. run sealert -l
> 12b4c94d-97f6-41cb-886f-048b26a24b1f
> Jan 21 09:10:02 localhost setroubleshoot: SELinux is preventing logger
> (ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
> run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
> Jan 21 09:10:02 localhost setroubleshoot: SELinux is preventing auto
> (ipsec_mgmt_t) "execute_no_trans" to /bin/bash (shell_exec_t). For
> complete SELinux messages. run sealert -l
> 12b4c94d-97f6-41cb-886f-048b26a24b1f
> Jan 21 09:10:03 localhost setroubleshoot: SELinux is preventing logger
> (ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
> run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
> Jan 21 09:10:03 localhost setroubleshoot: SELinux is preventing auto
> (ipsec_mgmt_t) "execute_no_trans" to /bin/bash (shell_exec_t). For
> complete SELinux messages. run sealert -l
> 12b4c94d-97f6-41cb-886f-048b26a24b1f
> Jan 21 09:10:03 localhost setroubleshoot: SELinux is preventing logger
> (ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
> run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
> Jan 21 09:10:04 localhost setroubleshoot: SELinux is preventing auto
> (ipsec_mgmt_t) "execute_no_trans" to /bin/bash (shell_exec_t). For
> complete SELinux messages. run sealert -l
> 12b4c94d-97f6-41cb-886f-048b26a24b1f
> Jan 21 09:10:04 localhost setroubleshoot: SELinux is preventing logger
> (ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
> run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
> Jan 21 09:10:04 localhost setroubleshoot: SELinux is preventing auto
> (ipsec_mgmt_t) "execute_no_trans" to /bin/bash (shell_exec_t). For
> complete SELinux messages. run sealert -l
> 12b4c94d-97f6-41cb-886f-048b26a24b1f
> Jan 21 09:10:04 localhost setroubleshoot: SELinux is preventing logger
> (ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
> run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
> + _________________________ plog
> + sed -n '2,$p' /var/log/secure
> + egrep -i pluto
> + case "$1" in
> + cat
> Jan 20 09:48:52 localhost pluto[13851]: Starting Pluto (Openswan Version
> 2.6.14; Vendor ID OEoSJUweaqAX) pid:13851
> Jan 20 09:48:52 localhost pluto[13851]: Setting NAT-Traversal port-4500
> floating to on
> Jan 20 09:48:52 localhost pluto[13851]:    port floating activation
> criteria nat_t=1/port_float=1
> Jan 20 09:48:52 localhost pluto[13851]:    including NAT-Traversal patch
> (Version 0.6c)
> Jan 20 09:48:52 localhost pluto[13851]: using /dev/urandom as source of
> random entropy
> Jan 20 09:48:52 localhost pluto[13851]: ike_alg_register_enc():
> Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
> Jan 20 09:48:52 localhost pluto[13851]: ike_alg_register_enc():
> Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
> Jan 20 09:48:52 localhost pluto[13851]: ike_alg_register_enc():
> Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
> Jan 20 09:48:52 localhost pluto[13851]: ike_alg_register_enc():
> Activating OAKLEY_AES_CBC: Ok (ret=0)
> Jan 20 09:48:52 localhost pluto[13851]: ike_alg_register_enc():
> Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
> Jan 20 09:48:52 localhost pluto[13851]: ike_alg_register_hash():
> Activating OAKLEY_SHA2_512: Ok (ret=0)
> Jan 20 09:48:52 localhost pluto[13851]: ike_alg_register_hash():
> Activating OAKLEY_SHA2_256: Ok (ret=0)
> Jan 20 09:48:52 localhost pluto[13851]: starting up 1 cryptographic helpers
> Jan 20 09:48:52 localhost pluto[13851]: started helper pid=13852 (fd:7)
> Jan 20 09:48:52 localhost pluto[13851]: Using Linux 2.6 IPsec interface
> code on 2.6.27.5-41.fc9.i686 (experimental code)
> Jan 20 09:48:52 localhost pluto[13852]: using /dev/urandom as source of
> random entropy
> Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc():
> Activating <NULL>: Ok (ret=0)
> Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 09:48:53 localhost pluto[13851]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 09:48:53 localhost pluto[13851]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 09:48:53 localhost pluto[13851]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 09:48:53 localhost pluto[13851]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 09:48:53 localhost pluto[13851]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 20 09:48:53 localhost pluto[13851]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 20 09:48:53 localhost pluto[13851]: Could not change to directory
> '/etc/ipsec.d/cacerts': /usr/sbin
> Jan 20 09:48:53 localhost pluto[13851]: Could not change to directory
> '/etc/ipsec.d/aacerts': /usr/sbin
> Jan 20 09:48:53 localhost pluto[13851]: Could not change to directory
> '/etc/ipsec.d/ocspcerts': /usr/sbin
> Jan 20 09:48:53 localhost pluto[13851]: Could not change to directory
> '/etc/ipsec.d/crls'
> Jan 20 09:48:53 localhost pluto[13851]: Changing back to directory
> '/usr/sbin' failed - (2 No such file or directory)
> Jan 20 09:48:53 localhost pluto[13851]: Changing back to directory
> '/usr/sbin' failed - (2 No such file or directory)
> Jan 20 09:48:53 localhost pluto[13851]: added connection description "vo"
> Jan 20 09:48:53 localhost pluto[13851]: added connection description "vodmz"
> Jan 20 09:49:32 localhost pluto[13851]: loading secrets from
> "/etc/ipsec.secrets"
> Jan 20 09:49:32 localhost pluto[13851]: no secrets filename matched
> "/etc/ipsec.d/*.secrets"
> Jan 20 09:56:08 localhost pluto[13851]: forgetting secrets
> Jan 20 09:56:08 localhost pluto[13851]: no secrets filename matched
> "/etc/ipsec.secrets"
> Jan 20 09:56:24 localhost pluto[13851]: loading secrets from
> "/etc/ipsec.secrets"
> Jan 20 09:56:24 localhost pluto[13851]: no secrets filename matched
> "/etc/ipsec.d/*.secrets"
> Jan 20 09:57:04 localhost pluto[13851]: shutting down
> Jan 20 09:57:04 localhost pluto[13851]: forgetting secrets
> Jan 20 09:57:04 localhost pluto[13851]: "vodmz": deleting connection
> Jan 20 09:57:04 localhost pluto[13851]: "vo": deleting connection
> Jan 20 09:57:05 localhost pluto[14592]: Starting Pluto (Openswan Version
> 2.6.14; Vendor ID OEoSJUweaqAX) pid:14592
> Jan 20 09:57:05 localhost pluto[14592]: Setting NAT-Traversal port-4500
> floating to on
> Jan 20 09:57:05 localhost pluto[14592]:    port floating activation
> criteria nat_t=1/port_float=1
> Jan 20 09:57:05 localhost pluto[14592]:    including NAT-Traversal patch
> (Version 0.6c)
> Jan 20 09:57:05 localhost pluto[14592]: using /dev/urandom as source of
> random entropy
> Jan 20 09:57:05 localhost pluto[14592]: ike_alg_register_enc():
> Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
> Jan 20 09:57:05 localhost pluto[14592]: ike_alg_register_enc():
> Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
> Jan 20 09:57:05 localhost pluto[14592]: ike_alg_register_enc():
> Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
> Jan 20 09:57:05 localhost pluto[14592]: ike_alg_register_enc():
> Activating OAKLEY_AES_CBC: Ok (ret=0)
> Jan 20 09:57:05 localhost pluto[14592]: ike_alg_register_enc():
> Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
> Jan 20 09:57:05 localhost pluto[14592]: ike_alg_register_hash():
> Activating OAKLEY_SHA2_512: Ok (ret=0)
> Jan 20 09:57:05 localhost pluto[14592]: ike_alg_register_hash():
> Activating OAKLEY_SHA2_256: Ok (ret=0)
> Jan 20 09:57:05 localhost pluto[14592]: starting up 1 cryptographic helpers
> Jan 20 09:57:05 localhost pluto[14601]: using /dev/urandom as source of
> random entropy
> Jan 20 09:57:05 localhost pluto[14592]: started helper pid=14601 (fd:7)
> Jan 20 09:57:05 localhost pluto[14592]: Using Linux 2.6 IPsec interface
> code on 2.6.27.5-41.fc9.i686 (experimental code)
> Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc():
> Activating <NULL>: Ok (ret=0)
> Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 09:57:06 localhost pluto[14592]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 09:57:06 localhost pluto[14592]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 09:57:06 localhost pluto[14592]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 09:57:06 localhost pluto[14592]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 09:57:06 localhost pluto[14592]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 20 09:57:06 localhost pluto[14592]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 20 09:57:06 localhost pluto[14592]: Could not change to directory
> '/etc/ipsec.d/cacerts': /etc
> Jan 20 09:57:06 localhost pluto[14592]: Could not change to directory
> '/etc/ipsec.d/aacerts': /etc
> Jan 20 09:57:06 localhost pluto[14592]: Could not change to directory
> '/etc/ipsec.d/ocspcerts': /etc
> Jan 20 09:57:06 localhost pluto[14592]: Could not change to directory
> '/etc/ipsec.d/crls'
> Jan 20 09:57:06 localhost pluto[14592]: Changing back to directory
> '/etc' failed - (2 No such file or directory)
> Jan 20 09:57:06 localhost pluto[14592]: Changing back to directory
> '/etc' failed - (2 No such file or directory)
> Jan 20 09:57:06 localhost pluto[14592]: added connection description "vo"
> Jan 20 09:57:06 localhost pluto[14592]: added connection description "vodmz"
> Jan 20 09:57:08 localhost pluto[14592]: loading secrets from
> "/etc/ipsec.secrets"
> Jan 20 09:57:08 localhost pluto[14592]: no secrets filename matched
> "/etc/ipsec.d/*.secrets"
> Jan 20 09:59:17 localhost pluto[14592]: forgetting secrets
> Jan 20 09:59:17 localhost pluto[14592]: loading secrets from
> "/etc/ipsec.secrets"
> Jan 20 09:59:17 localhost pluto[14592]: loading secrets from
> "/etc/ipsec.d/ipsec.secrets"
> Jan 20 10:01:37 localhost pluto[14592]: "vo": deleting connection
> Jan 20 10:01:37 localhost pluto[14592]: added connection description "vo"
> Jan 20 10:01:43 localhost pluto[14592]: "vodmz": deleting connection
> Jan 20 10:01:43 localhost pluto[14592]: added connection description "vodmz"
> Jan 20 10:07:07 localhost pluto[14592]: shutting down
> Jan 20 10:07:07 localhost pluto[14592]: forgetting secrets
> Jan 20 10:07:07 localhost pluto[14592]: "vodmz": deleting connection
> Jan 20 10:07:07 localhost pluto[14592]: "vo": deleting connection
> Jan 20 10:07:09 localhost pluto[15199]: Starting Pluto (Openswan Version
> 2.6.14; Vendor ID OEoSJUweaqAX) pid:15199
> Jan 20 10:07:09 localhost pluto[15199]: Setting NAT-Traversal port-4500
> floating to on
> Jan 20 10:07:09 localhost pluto[15199]:    port floating activation
> criteria nat_t=1/port_float=1
> Jan 20 10:07:09 localhost pluto[15199]:    including NAT-Traversal patch
> (Version 0.6c)
> Jan 20 10:07:09 localhost pluto[15199]: using /dev/urandom as source of
> random entropy
> Jan 20 10:07:09 localhost pluto[15199]: ike_alg_register_enc():
> Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
> Jan 20 10:07:09 localhost pluto[15199]: ike_alg_register_enc():
> Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
> Jan 20 10:07:09 localhost pluto[15199]: ike_alg_register_enc():
> Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
> Jan 20 10:07:09 localhost pluto[15199]: ike_alg_register_enc():
> Activating OAKLEY_AES_CBC: Ok (ret=0)
> Jan 20 10:07:09 localhost pluto[15199]: ike_alg_register_enc():
> Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
> Jan 20 10:07:09 localhost pluto[15199]: ike_alg_register_hash():
> Activating OAKLEY_SHA2_512: Ok (ret=0)
> Jan 20 10:07:09 localhost pluto[15199]: ike_alg_register_hash():
> Activating OAKLEY_SHA2_256: Ok (ret=0)
> Jan 20 10:07:09 localhost pluto[15199]: starting up 1 cryptographic helpers
> Jan 20 10:07:09 localhost pluto[15201]: using /dev/urandom as source of
> random entropy
> Jan 20 10:07:09 localhost pluto[15199]: started helper pid=15201 (fd:7)
> Jan 20 10:07:09 localhost pluto[15199]: Using Linux 2.6 IPsec interface
> code on 2.6.27.5-41.fc9.i686 (experimental code)
> Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc():
> Activating <NULL>: Ok (ret=0)
> Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 10:07:10 localhost pluto[15199]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 10:07:10 localhost pluto[15199]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 10:07:10 localhost pluto[15199]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 10:07:10 localhost pluto[15199]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 10:07:10 localhost pluto[15199]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 20 10:07:10 localhost pluto[15199]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 20 10:07:10 localhost pluto[15199]: Could not change to directory
> '/etc/ipsec.d/cacerts': /etc
> Jan 20 10:07:10 localhost pluto[15199]: Could not change to directory
> '/etc/ipsec.d/aacerts': /etc
> Jan 20 10:07:10 localhost pluto[15199]: Could not change to directory
> '/etc/ipsec.d/ocspcerts': /etc
> Jan 20 10:07:10 localhost pluto[15199]: Could not change to directory
> '/etc/ipsec.d/crls'
> Jan 20 10:07:10 localhost pluto[15199]: Changing back to directory
> '/etc' failed - (2 No such file or directory)
> Jan 20 10:07:10 localhost pluto[15199]: Changing back to directory
> '/etc' failed - (2 No such file or directory)
> Jan 20 10:07:10 localhost pluto[15199]: added connection description "vo"
> Jan 20 10:07:10 localhost pluto[15199]: added connection description "vodmz"
> Jan 20 10:17:24 localhost pluto[15199]: shutting down
> Jan 20 10:17:24 localhost pluto[15199]: "vodmz": deleting connection
> Jan 20 10:17:24 localhost pluto[15199]: "vo": deleting connection
> Jan 20 10:17:27 localhost pluto[15738]: Starting Pluto (Openswan Version
> 2.6.14; Vendor ID OEoSJUweaqAX) pid:15738
> Jan 20 10:17:27 localhost pluto[15738]: Setting NAT-Traversal port-4500
> floating to on
> Jan 20 10:17:27 localhost pluto[15738]:    port floating activation
> criteria nat_t=1/port_float=1
> Jan 20 10:17:27 localhost pluto[15738]:    including NAT-Traversal patch
> (Version 0.6c)
> Jan 20 10:17:27 localhost pluto[15738]: using /dev/urandom as source of
> random entropy
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc():
> Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc():
> Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc():
> Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc():
> Activating OAKLEY_AES_CBC: Ok (ret=0)
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc():
> Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_hash():
> Activating OAKLEY_SHA2_512: Ok (ret=0)
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_hash():
> Activating OAKLEY_SHA2_256: Ok (ret=0)
> Jan 20 10:17:27 localhost pluto[15738]: starting up 1 cryptographic helpers
> Jan 20 10:17:27 localhost pluto[15744]: using /dev/urandom as source of
> random entropy
> Jan 20 10:17:27 localhost pluto[15738]: started helper pid=15744 (fd:7)
> Jan 20 10:17:27 localhost pluto[15738]: Using Linux 2.6 IPsec interface
> code on 2.6.27.5-41.fc9.i686 (experimental code)
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc():
> Activating <NULL>: Ok (ret=0)
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 20 10:17:27 localhost pluto[15738]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 20 10:17:27 localhost pluto[15738]: Could not change to directory
> '/etc/ipsec.d/cacerts': /etc
> Jan 20 10:17:27 localhost pluto[15738]: Could not change to directory
> '/etc/ipsec.d/aacerts': /etc
> Jan 20 10:17:27 localhost pluto[15738]: Could not change to directory
> '/etc/ipsec.d/ocspcerts': /etc
> Jan 20 10:17:27 localhost pluto[15738]: Could not change to directory
> '/etc/ipsec.d/crls'
> Jan 20 10:17:27 localhost pluto[15738]: Changing back to directory
> '/etc' failed - (2 No such file or directory)
> Jan 20 10:17:27 localhost pluto[15738]: Changing back to directory
> '/etc' failed - (2 No such file or directory)
> Jan 20 10:17:27 localhost pluto[15738]: added connection description "vo"
> Jan 20 10:17:27 localhost pluto[15738]: added connection description "vodmz"
> Jan 21 08:59:07 localhost pluto[15738]: shutting down
> Jan 21 08:59:07 localhost pluto[15738]: "vodmz": deleting connection
> Jan 21 08:59:07 localhost pluto[15738]: "vo": deleting connection
> Jan 21 09:00:20 localhost pluto[2326]: Starting Pluto (Openswan Version
> 2.6.14; Vendor ID OEoSJUweaqAX) pid:2326
> Jan 21 09:00:20 localhost pluto[2326]: Setting NAT-Traversal port-4500
> floating to on
> Jan 21 09:00:20 localhost pluto[2326]:    port floating activation
> criteria nat_t=1/port_float=1
> Jan 21 09:00:20 localhost pluto[2326]:    including NAT-Traversal patch
> (Version 0.6c)
> Jan 21 09:00:20 localhost pluto[2326]: using /dev/urandom as source of
> random entropy
> Jan 21 09:00:20 localhost pluto[2326]: ike_alg_register_enc():
> Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
> Jan 21 09:00:20 localhost pluto[2326]: ike_alg_register_enc():
> Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
> Jan 21 09:00:20 localhost pluto[2326]: ike_alg_register_enc():
> Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
> Jan 21 09:00:20 localhost pluto[2326]: ike_alg_register_enc():
> Activating OAKLEY_AES_CBC: Ok (ret=0)
> Jan 21 09:00:20 localhost pluto[2326]: ike_alg_register_enc():
> Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
> Jan 21 09:00:20 localhost pluto[2326]: ike_alg_register_hash():
> Activating OAKLEY_SHA2_512: Ok (ret=0)
> Jan 21 09:00:20 localhost pluto[2326]: ike_alg_register_hash():
> Activating OAKLEY_SHA2_256: Ok (ret=0)
> Jan 21 09:00:20 localhost pluto[2326]: starting up 1 cryptographic helpers
> Jan 21 09:00:20 localhost pluto[2342]: using /dev/urandom as source of
> random entropy
> Jan 21 09:00:20 localhost pluto[2326]: started helper pid=2342 (fd:7)
> Jan 21 09:00:20 localhost pluto[2326]: Using Linux 2.6 IPsec interface
> code on 2.6.27.5-41.fc9.i686 (experimental code)
> Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc():
> Activating <NULL>: Ok (ret=0)
> Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:00:21 localhost pluto[2326]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:00:21 localhost pluto[2326]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:00:21 localhost pluto[2326]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:00:21 localhost pluto[2326]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:00:21 localhost pluto[2326]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 21 09:00:21 localhost pluto[2326]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 21 09:00:21 localhost pluto[2326]: Could not change to directory
> '/etc/ipsec.d/cacerts': /
> Jan 21 09:00:21 localhost pluto[2326]: Could not change to directory
> '/etc/ipsec.d/aacerts': /
> Jan 21 09:00:21 localhost pluto[2326]: Could not change to directory
> '/etc/ipsec.d/ocspcerts': /
> Jan 21 09:00:21 localhost pluto[2326]: Could not change to directory
> '/etc/ipsec.d/crls'
> Jan 21 09:00:21 localhost pluto[2326]: Changing back to directory '/'
> failed - (2 No such file or directory)
> Jan 21 09:00:21 localhost pluto[2326]: Changing back to directory '/'
> failed - (2 No such file or directory)
> Jan 21 09:00:21 localhost pluto[2326]: added connection description "vo"
> Jan 21 09:00:21 localhost pluto[2326]: added connection description "vodmz"
> Jan 21 09:06:20 localhost pluto[2326]: shutting down
> Jan 21 09:06:20 localhost pluto[2326]: "vodmz": deleting connection
> Jan 21 09:06:20 localhost pluto[2326]: "vo": deleting connection
> Jan 21 09:06:22 localhost pluto[3784]: Starting Pluto (Openswan Version
> 2.6.14; Vendor ID OEoSJUweaqAX) pid:3784
> Jan 21 09:06:22 localhost pluto[3784]: Setting NAT-Traversal port-4500
> floating to on
> Jan 21 09:06:22 localhost pluto[3784]:    port floating activation
> criteria nat_t=1/port_float=1
> Jan 21 09:06:22 localhost pluto[3784]:    including NAT-Traversal patch
> (Version 0.6c)
> Jan 21 09:06:22 localhost pluto[3784]: using /dev/urandom as source of
> random entropy
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc():
> Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc():
> Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc():
> Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc():
> Activating OAKLEY_AES_CBC: Ok (ret=0)
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc():
> Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_hash():
> Activating OAKLEY_SHA2_512: Ok (ret=0)
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_hash():
> Activating OAKLEY_SHA2_256: Ok (ret=0)
> Jan 21 09:06:22 localhost pluto[3784]: starting up 1 cryptographic helpers
> Jan 21 09:06:22 localhost pluto[3784]: started helper pid=3785 (fd:7)
> Jan 21 09:06:22 localhost pluto[3784]: Using Linux 2.6 IPsec interface
> code on 2.6.27.5-41.fc9.i686 (experimental code)
> Jan 21 09:06:22 localhost pluto[3785]: using /dev/urandom as source of
> random entropy
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc():
> Activating <NULL>: Ok (ret=0)
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 21 09:06:22 localhost pluto[3784]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 21 09:06:22 localhost pluto[3784]: Could not change to directory
> '/etc/ipsec.d/cacerts': /home/jingluo
> Jan 21 09:06:22 localhost pluto[3784]: Could not change to directory
> '/etc/ipsec.d/aacerts': /home/jingluo
> Jan 21 09:06:22 localhost pluto[3784]: Could not change to directory
> '/etc/ipsec.d/ocspcerts': /home/jingluo
> Jan 21 09:06:22 localhost pluto[3784]: Could not change to directory
> '/etc/ipsec.d/crls'
> Jan 21 09:06:22 localhost pluto[3784]: added connection description "vo"
> Jan 21 09:06:22 localhost pluto[3784]: added connection description "vodmz"
> Jan 21 09:08:35 localhost pluto[3784]: loading secrets from
> "/etc/ipsec.secrets"
> Jan 21 09:08:35 localhost pluto[3784]: loading secrets from
> "/etc/ipsec.d/ipsec.secrets"
> Jan 21 09:08:44 localhost pluto[3784]: "vo": deleting connection
> Jan 21 09:08:44 localhost pluto[3784]: added connection description "vo"
> Jan 21 09:08:52 localhost pluto[3784]: "vodmz": deleting connection
> Jan 21 09:08:52 localhost pluto[3784]: added connection description "vodmz"
> Jan 21 09:09:04 localhost pluto[3784]: forgetting secrets
> Jan 21 09:09:04 localhost pluto[3784]: loading secrets from
> "/etc/ipsec.secrets"
> Jan 21 09:09:04 localhost pluto[3784]: loading secrets from
> "/etc/ipsec.d/ipsec.secrets"
> Jan 21 09:09:08 localhost pluto[3784]: shutting down
> Jan 21 09:09:08 localhost pluto[3784]: forgetting secrets
> Jan 21 09:09:08 localhost pluto[3784]: "vodmz": deleting connection
> Jan 21 09:09:08 localhost pluto[3784]: "vo": deleting connection
> Jan 21 09:09:10 localhost pluto[4268]: Starting Pluto (Openswan Version
> 2.6.14; Vendor ID OEoSJUweaqAX) pid:4268
> Jan 21 09:09:10 localhost pluto[4268]: Setting NAT-Traversal port-4500
> floating to on
> Jan 21 09:09:10 localhost pluto[4268]:    port floating activation
> criteria nat_t=1/port_float=1
> Jan 21 09:09:10 localhost pluto[4268]:    including NAT-Traversal patch
> (Version 0.6c)
> Jan 21 09:09:10 localhost pluto[4268]: using /dev/urandom as source of
> random entropy
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc():
> Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc():
> Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc():
> Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc():
> Activating OAKLEY_AES_CBC: Ok (ret=0)
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc():
> Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_hash():
> Activating OAKLEY_SHA2_512: Ok (ret=0)
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_hash():
> Activating OAKLEY_SHA2_256: Ok (ret=0)
> Jan 21 09:09:10 localhost pluto[4268]: starting up 1 cryptographic helpers
> Jan 21 09:09:10 localhost pluto[4268]: started helper pid=4271 (fd:7)
> Jan 21 09:09:10 localhost pluto[4268]: Using Linux 2.6 IPsec interface
> code on 2.6.27.5-41.fc9.i686 (experimental code)
> Jan 21 09:09:10 localhost pluto[4271]: using /dev/urandom as source of
> random entropy
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc():
> Activating <NULL>: Ok (ret=0)
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 21 09:09:10 localhost pluto[4268]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 21 09:09:10 localhost pluto[4268]: Could not change to directory
> '/etc/ipsec.d/cacerts': /home/jingluo
> Jan 21 09:09:10 localhost pluto[4268]: Could not change to directory
> '/etc/ipsec.d/aacerts': /home/jingluo
> Jan 21 09:09:10 localhost pluto[4268]: Could not change to directory
> '/etc/ipsec.d/ocspcerts': /home/jingluo
> Jan 21 09:09:10 localhost pluto[4268]: Could not change to directory
> '/etc/ipsec.d/crls'
> Jan 21 09:09:10 localhost pluto[4268]: added connection description "vo"
> Jan 21 09:09:10 localhost pluto[4268]: added connection description "vodmz"
> Jan 21 09:09:57 localhost pluto[4268]: shutting down
> Jan 21 09:09:57 localhost pluto[4268]: "vodmz": deleting connection
> Jan 21 09:09:57 localhost pluto[4268]: "vo": deleting connection
> Jan 21 09:10:00 localhost pluto[4647]: Starting Pluto (Openswan Version
> 2.6.14; Vendor ID OEoSJUweaqAX) pid:4647
> Jan 21 09:10:00 localhost pluto[4647]: Setting NAT-Traversal port-4500
> floating to on
> Jan 21 09:10:00 localhost pluto[4647]:    port floating activation
> criteria nat_t=1/port_float=1
> Jan 21 09:10:00 localhost pluto[4647]:    including NAT-Traversal patch
> (Version 0.6c)
> Jan 21 09:10:00 localhost pluto[4647]: using /dev/urandom as source of
> random entropy
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc():
> Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc():
> Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc():
> Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc():
> Activating OAKLEY_AES_CBC: Ok (ret=0)
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc():
> Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_hash():
> Activating OAKLEY_SHA2_512: Ok (ret=0)
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_hash():
> Activating OAKLEY_SHA2_256: Ok (ret=0)
> Jan 21 09:10:00 localhost pluto[4647]: starting up 1 cryptographic helpers
> Jan 21 09:10:00 localhost pluto[4647]: started helper pid=4648 (fd:7)
> Jan 21 09:10:00 localhost pluto[4647]: Using Linux 2.6 IPsec interface
> code on 2.6.27.5-41.fc9.i686 (experimental code)
> Jan 21 09:10:00 localhost pluto[4648]: using /dev/urandom as source of
> random entropy
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc():
> Activating <NULL>: Ok (ret=0)
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc(): WARNING:
> enc alg=0 not found in constants.c:oakley_enc_names 
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_add(): ERROR: Algorithm
> already exists
> Jan 21 09:10:00 localhost pluto[4647]: ike_alg_register_enc():
> Activating <NULL>: FAILED (ret=-17)
> Jan 21 09:10:00 localhost pluto[4647]: Could not change to directory
> '/etc/ipsec.d/cacerts': /home/jingluo
> Jan 21 09:10:00 localhost pluto[4647]: Could not change to directory
> '/etc/ipsec.d/aacerts': /home/jingluo
> Jan 21 09:10:00 localhost pluto[4647]: Could not change to directory
> '/etc/ipsec.d/ocspcerts': /home/jingluo
> Jan 21 09:10:00 localhost pluto[4647]: Could not change to directory
> '/etc/ipsec.d/crls'
> Jan 21 09:10:00 localhost pluto[4647]: added connection description "vo"
> Jan 21 09:10:00 localhost pluto[4647]: added connection description "vodmz"
> + _________________________ date
> + date
> Wed Jan 21 09:12:55 EST 2009
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> barf
> From:
> Jing Luo <jing.luo at steeprockinc.com>
> Date:
> Wed, 21 Jan 2009 09:13:41 -0500 (EST)
> To:
> Chris Garrigues <chris.garrigues at steeprockinc.com>
> 
> To:
> Chris Garrigues <chris.garrigues at steeprockinc.com>
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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=283155

From consultant77pk at yahoo.com  Sat Jan 24 06:32:18 2009
From: consultant77pk at yahoo.com (Fahad Aziz)
Date: Sat, 24 Jan 2009 03:32:18 -0800 (PST)
Subject: [Openswan Users] PC to Network config Openswan
Message-ID: <604273.41871.qm@web32203.mail.mud.yahoo.com>

I am able to do  NEt to Net Config using ipsec PSK mode and both private networks are communicating fine ... but problem is another PC with openswan which has only one NIC with global IP .. i need to connect single PC with global IP to another openswan with private network and 2 nics .. such as 

Openswan 2.4 at Kernel 2.6 Native... (both same)

SITE 1 - eth0 = 221.132.xx.xx (global) Openswan 

Site 2 -eth0 = 221.133.xx.xx (glocal) Openswan 
       -eth1 = 192.168.xx.xx (privte or local)

how to 221.132.xx.xx communicate with 192.168.xx.xx  , 


221.132.xx.xx ---------- 221.133.xx.xx ---- 192.168.xx.xx 

I tried make alias eth at Site 1 but alias IP can ping but not the global. 

I am new to Openswan, any hint or suggesstion plz...

Regards

.           (O)
.         \\oOo//  
       _\\ooOoOoo//_
------------------------
consultant77pk at yahoo.com


      

From mhw at WittsEnd.com  Sat Jan 24 13:13:12 2009
From: mhw at WittsEnd.com (Michael H. Warfield)
Date: Sat, 24 Jan 2009 13:13:12 -0500
Subject: [Openswan Users] Extruded subnet (revisited yet again).
Message-ID: <1232820792.6946.101.camel@canyon.wittsend.com>

Hey all,

	Ok...  I've been trying to solve this for ages and I've really wanted
to figure this out on my own but I haven't.  I see in the archives this
has been kicked around from time to time but I can't find a definitive
answer (and old old hints in some other forums imply that there wasn't
one at the time but patches were "on the way").

	I'm trying to set up an extruded subnet as follows:

	Subnet-----------------------Gate1======Gate2----Internet
	130.205.0.0/19 --130.205.12.1  PubIP===PubIp

	The subnet behind Gate1 is a nice large /19 (it's a research network).
I've extruded that /19 from the /18 that Gate2 resides on.  The extruded
tunnel is basically 130.205.0.0/19 <=> 0.0.0.0/0.

	In the main conn:

        right=130.205.32.4
	rightsubnet=0.0.0.0/0
        rightnexthop=130.205.32.1
        left=%defaultroute
	leftnexthop=%defaultroute
        leftsubnet=130.205.0.0/19

	The extruded tunnel itself works.  That is, anything from the internet
can reach Gate1 on it's local extruded address (130.205.12.130) and
anything on the other side of Gate1 in that entire /19 (like
130.205.12.131).  But...  Gate1 can not communicate with any of the
hosts behind it (130.205.12.130 on Gate1 can not ping 130.205.12.131 on
that subnet).  The reason is pretty obvious.  The conn for
130.205.0.0/19 <=> 0.0.0.0 is catching packets 130.205.12.130 <=>
130.205.0.0/19 and sending up the tunnel, which is wrong, instead of
routing them out their appropriate local interfaces.  I'm trying to fix
this.

	I've seen Paul's posting to this list from several years ago describing
this exact scenario and using a "type=bypass" conn to fix it.  But that
doesn't seem to work for me.  It appears that posting related to using
klips?  I'm using netkey.  If I try Paul's example, it gives me an error
saying the route is already in use by "foo" (where foo is the conn for
the extruded subnet) and refuses to do it.  If I install demi-route
connections (0.0.0.0/1 and 128.0.0.0/1) in two conns it will then
install them but it does not fix the problem and it does break the
extruded tunnel, sigh...

	I've seen some hints in some other postings in some other forums that
the answer is in using setkey or "ip xfrm policy" to set appropriate
transform policies, but I have yet to get that to work and the
documentation on that functionality is sparse to the point of being
abysmal  I have found NO documentation on the "ip xfrm" functionality
outside of the man pages, which are basically syntax only.  I couldn't
even determine from the man pages how priority works (is higher better
or is it more like nice) and what is the order of precedence (ordinally
by index or by matching prefix or what).  The setkey information looked
like it should work (setting the policy to none and I tried various
priorities) but that didn't work either (but, at least, it didn't BREAK
the tunnel).

	I've also see some hints that this could be somehow related to
netfilter+ipsec stuff but those are also old postings and seems to be a
dead end to me.

	So...  Before I go spamming the entire list with configuations and
policy dumps and what not, has anyone gotten this to work with netkey or
have a hint what else to try?  Not merely the extruded subnet.  That
works for me.  But getting their local gateway to talk with the rest of
its subnet behind it.  It's just that one corner case that's driving me
nuts.

	Regards,
	Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://lists.openswan.org/pipermail/users/attachments/20090124/15c03639/attachment.bin 

From petermcgill at goco.net  Mon Jan 26 10:26:51 2009
From: petermcgill at goco.net (Peter McGill)
Date: Mon, 26 Jan 2009 10:26:51 -0500
Subject: [Openswan Users] PC to Network config Openswan
In-Reply-To: <604273.41871.qm@web32203.mail.mud.yahoo.com>
References: <604273.41871.qm@web32203.mail.mud.yahoo.com>
Message-ID: <497DD63B.1030409@goco.net>

Fahad Aziz,

It's quite simple really the config is identical to the one you've setup 
(with the exception of the changed public ip), except for one small 
change leave out the (left|right)subnet for the side with no lan.

FYI, this uses the default subnet of: 221.132.xx.xx/32

Then all communications between 221.132.xx.xx and 192.168.xx.xx will use 
the tunnel. If you also want 221.133.xx.xx to use the tunnel when 
talking to 221.132.xx.xx then set (left|right)sourceip=192.168.xx.xx 
where 192.168.xx.xx is the private ip of 221.133.xx.xx.

See the man pages ipsec.conf or the doc/ directory in the openswan 
tarball for more details.

Clear?
If not I can create an example config, or modify yours for you if you 
provide it.

Peter

Fahad Aziz wrote:
> I am able to do  NEt to Net Config using ipsec PSK mode and both private networks are communicating fine ... but problem is another PC with openswan which has only one NIC with global IP .. i need to connect single PC with global IP to another openswan with private network and 2 nics .. such as 
> 
> Openswan 2.4 at Kernel 2.6 Native... (both same)
> 
> SITE 1 - eth0 = 221.132.xx.xx (global) Openswan 
> 
> Site 2 -eth0 = 221.133.xx.xx (glocal) Openswan 
>        -eth1 = 192.168.xx.xx (privte or local)
> 
> how to 221.132.xx.xx communicate with 192.168.xx.xx  , 
> 
> 
> 221.132.xx.xx ---------- 221.133.xx.xx ---- 192.168.xx.xx 
> 
> I tried make alias eth at Site 1 but alias IP can ping but not the global. 
> 
> I am new to Openswan, any hint or suggesstion plz...
> 
> Regards
> 
> .           (O)
> .         \\oOo//  
>        _\\ooOoOoo//_
> ------------------------
> consultant77pk at yahoo.com
> 
> 
>       
> _______________________________________________
> 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=283155
> 

From petermcgill at goco.net  Mon Jan 26 11:10:32 2009
From: petermcgill at goco.net (Peter McGill)
Date: Mon, 26 Jan 2009 11:10:32 -0500
Subject: [Openswan Users] OpenSWAN to SonicWALL problems
In-Reply-To: <497DCD35.3030804@steeprockinc.com>
References: <497877C3.2070608@steeprockinc.com> <4979E530.1060303@goco.net>
	<497DCD35.3030804@steeprockinc.com>
Message-ID: <497DE078.4030106@goco.net>

Chris,

I see a number of other problems.

> + _________________________ ipsec_verify
> + ipsec verify --nocolour
> Checking your system to see if IPsec got installed and started correctly:
> Version check and ipsec on-path                                 [OK]
> Linux Openswan U2.6.14/K2.6.27.5-41.fc9.i686 (netkey)
> Checking for IPsec support in kernel                            [OK]
> NETKEY detected, testing for disabled ICMP send_redirects       [FAILED]
> 
>   Please disable /proc/sys/net/ipv4/conf/*/send_redirects
>   or NETKEY will cause the sending of bogus ICMP redirects!
> 
> NETKEY detected, testing for disabled ICMP accept_redirects     [FAILED]
> 
>   Please disable /proc/sys/net/ipv4/conf/*/accept_redirects
>   or NETKEY will accept bogus ICMP redirects!
> 
> Checking for RSA private key (/etc/ipsec.secrets)               [OK]
> Checking that pluto is running                                  [OK]
> Pluto not listening on port udp 500. Check interfaces defintion in 
> ipsec.conf.Two or more interfaces found, checking IP forwarding        
>     [FAILED]
> Checking for 'ip' command                                       [OK]
> Checking for 'iptables' command                                 [OK]
> Opportunistic Encryption Support                                [DISABLED]

Pluto not listening on port udp 500 and no IP forwarding, see below.

 > + _________________________ /proc/sys/net/ipv4/ip_forward
 > + cat /proc/sys/net/ipv4/ip_forward
 > 0

Fix this in your startup scripts usually edit /etc/sysctl.conf:
net.ipv4.ip_forward = 1

Apply the changes:
sysctl -p /etc/sysctl.conf

 > + _________________________ klog
 > + sed -n '1151,$p' /var/log/messages
 > + egrep -i 'ipsec|klips|pluto'
 > + case "$1" in
 > + cat
 > Jan 26 09:36:38 localhost ipsec_setup: Starting Openswan IPsec
 > U2.6.14/K2.6.27.5-41.fc9.i686...
 > Jan 26 09:36:38 localhost ipsec_setup:
 > Jan 26 09:36:38 localhost ipsec_setup:
 > Jan 26 09:36:38 localhost setroubleshoot: SELinux is preventing logger
 > (ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
 > run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
 > Jan 26 09:36:39 localhost setroubleshoot: SELinux is preventing logger
 > (ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
 > run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
 > Jan 26 09:36:39 localhost setroubleshoot: SELinux is preventing logger
 > (ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
 > run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
 > Jan 26 09:36:39 localhost setroubleshoot: SELinux is preventing logger
 > (ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
 > run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
 > Jan 26 09:36:40 localhost setroubleshoot: SELinux is preventing logger
 > (ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
 > run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
 > Jan 26 09:36:40 localhost setroubleshoot: SELinux is preventing auto
 > (ipsec_mgmt_t) "execute_no_trans" to /bin/bash (shell_exec_t). For
 > complete SELinux messages. run sealert -l
 > 12b4c94d-97f6-41cb-886f-048b26a24b1f
 > Jan 26 09:36:40 localhost setroubleshoot: SELinux is preventing logger
 > (ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
 > run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
 > Jan 26 09:36:40 localhost setroubleshoot: SELinux is preventing auto
 > (ipsec_mgmt_t) "execute_no_trans" to /bin/bash (shell_exec_t). For
 > complete SELinux messages. run sealert -l
 > 12b4c94d-97f6-41cb-886f-048b26a24b1f
 > Jan 26 09:36:41 localhost setroubleshoot: SELinux is preventing logger
 > (ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
 > run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
 > Jan 26 09:36:41 localhost setroubleshoot: SELinux is preventing auto
 > (ipsec_mgmt_t) "execute_no_trans" to /bin/bash (shell_exec_t). For
 > complete SELinux messages. run sealert -l
 > 12b4c94d-97f6-41cb-886f-048b26a24b1f
 > Jan 26 09:36:41 localhost setroubleshoot: SELinux is preventing logger
 > (ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
 > run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
 > Jan 26 09:36:41 localhost setroubleshoot: SELinux is preventing auto
 > (ipsec_mgmt_t) "execute_no_trans" to /bin/bash (shell_exec_t). For
 > complete SELinux messages. run sealert -l
 > 12b4c94d-97f6-41cb-886f-048b26a24b1f
 > Jan 26 09:36:42 localhost setroubleshoot: SELinux is preventing logger
 > (ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
 > run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
 > Jan 26 09:36:42 localhost setroubleshoot: SELinux is preventing auto
 > (ipsec_mgmt_t) "execute_no_trans" to /bin/bash (shell_exec_t). For
 > complete SELinux messages. run sealert -l
 > 12b4c94d-97f6-41cb-886f-048b26a24b1f
 > Jan 26 09:36:42 localhost setroubleshoot: SELinux is preventing logger
 > (ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
 > run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2

SELinux is preventing Openswan from working, either disable SELinux or 
apply a policy which works with Openswan. I'm not sure how to do this, 
never used SELinux.

 > + _________________________ plog
 > + sed -n '5,$p' /var/log/secure
 > + egrep -i pluto
 > + case "$1" in
 > + cat
 > Jan 26 09:33:17 localhost pluto[20993]: Starting Pluto (Openswan Version
 > 2.6.14; Vendor ID OEoSJUweaqAX) pid:20993
 > Jan 26 09:33:17 localhost pluto[20993]: Setting NAT-Traversal port-4500
 > floating to on
 > Jan 26 09:33:17 localhost pluto[20993]:    port floating activation
 > criteria nat_t=1/port_float=1
 > Jan 26 09:33:17 localhost pluto[20993]:    including NAT-Traversal patch
 > (Version 0.6c)
 > Jan 26 09:33:17 localhost pluto[20993]: using /dev/urandom as source of
 > random entropy
 > Jan 26 09:33:17 localhost pluto[20993]: ike_alg_register_enc():
 > Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
 > Jan 26 09:33:17 localhost pluto[20993]: ike_alg_register_enc():
 > Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
 > Jan 26 09:33:17 localhost pluto[20993]: ike_alg_register_enc():
 > Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
 > Jan 26 09:33:17 localhost pluto[20993]: ike_alg_register_enc():
 > Activating OAKLEY_AES_CBC: Ok (ret=0)
 > Jan 26 09:33:17 localhost pluto[20993]: ike_alg_register_enc():
 > Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
 > Jan 26 09:33:17 localhost pluto[20993]: ike_alg_register_hash():
 > Activating OAKLEY_SHA2_512: Ok (ret=0)
 > Jan 26 09:33:17 localhost pluto[20993]: ike_alg_register_hash():
 > Activating OAKLEY_SHA2_256: Ok (ret=0)
 > Jan 26 09:33:17 localhost pluto[20993]: starting up 1 cryptographic 
helpers
 > Jan 26 09:33:17 localhost pluto[21003]: using /dev/urandom as source of
 > random entropy
 > Jan 26 09:33:17 localhost pluto[20993]: started helper pid=21003 (fd:7)
 > Jan 26 09:33:17 localhost pluto[20993]: Using Linux 2.6 IPsec interface
 > code on 2.6.27.5-41.fc9.i686 (experimental code)
 > Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc():
 > Activating <NULL>: Ok (ret=0)
 > Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:33:18 localhost pluto[20993]: ike_alg_add(): ERROR: Algorithm
 > already exists
 > Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc():
 > Activating <NULL>: FAILED (ret=-17)
 > Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:33:18 localhost pluto[20993]: ike_alg_add(): ERROR: Algorithm
 > already exists
 > Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc():
 > Activating <NULL>: FAILED (ret=-17)
 > Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:33:18 localhost pluto[20993]: ike_alg_add(): ERROR: Algorithm
 > already exists
 > Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc():
 > Activating <NULL>: FAILED (ret=-17)
 > Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:33:18 localhost pluto[20993]: ike_alg_add(): ERROR: Algorithm
 > already exists
 > Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc():
 > Activating <NULL>: FAILED (ret=-17)
 > Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:33:18 localhost pluto[20993]: ike_alg_add(): ERROR: Algorithm
 > already exists
 > Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc():
 > Activating <NULL>: FAILED (ret=-17)
 > Jan 26 09:33:18 localhost pluto[20993]: Could not change to directory
 > '/etc/ipsec.d/cacerts': /etc/ipsec.d
 > Jan 26 09:33:18 localhost pluto[20993]: Could not change to directory
 > '/etc/ipsec.d/aacerts': /etc/ipsec.d
 > Jan 26 09:33:18 localhost pluto[20993]: Could not change to directory
 > '/etc/ipsec.d/ocspcerts': /etc/ipsec.d
 > Jan 26 09:33:18 localhost pluto[20993]: Could not change to directory
 > '/etc/ipsec.d/crls'
 > Jan 26 09:33:18 localhost pluto[20993]: Changing back to directory
 > '/etc/ipsec.d' failed - (2 No such file or directory)
 > Jan 26 09:33:18 localhost pluto[20993]: Changing back to directory
 > '/etc/ipsec.d' failed - (2 No such file or directory)
 > Jan 26 09:33:18 localhost pluto[20993]: added connection description "vo"
 > Jan 26 09:33:18 localhost pluto[20993]: added connection description 
"vodmz"
 > Jan 26 09:33:28 localhost pluto[20993]: shutting down
 > Jan 26 09:33:28 localhost pluto[20993]: "vodmz": deleting connection
 > Jan 26 09:33:28 localhost pluto[20993]: "vo": deleting connection
 > Jan 26 09:33:31 localhost pluto[21368]: Starting Pluto (Openswan Version
 > 2.6.14; Vendor ID OEoSJUweaqAX) pid:21368
 > Jan 26 09:33:31 localhost pluto[21368]: Setting NAT-Traversal port-4500
 > floating to on
 > Jan 26 09:33:31 localhost pluto[21368]:    port floating activation
 > criteria nat_t=1/port_float=1
 > Jan 26 09:33:31 localhost pluto[21368]:    including NAT-Traversal patch
 > (Version 0.6c)
 > Jan 26 09:33:31 localhost pluto[21368]: using /dev/urandom as source of
 > random entropy
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc():
 > Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc():
 > Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc():
 > Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc():
 > Activating OAKLEY_AES_CBC: Ok (ret=0)
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc():
 > Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_hash():
 > Activating OAKLEY_SHA2_512: Ok (ret=0)
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_hash():
 > Activating OAKLEY_SHA2_256: Ok (ret=0)
 > Jan 26 09:33:31 localhost pluto[21368]: starting up 1 cryptographic 
helpers
 > Jan 26 09:33:31 localhost pluto[21371]: using /dev/urandom as source of
 > random entropy
 > Jan 26 09:33:31 localhost pluto[21368]: started helper pid=21371 (fd:7)
 > Jan 26 09:33:31 localhost pluto[21368]: Using Linux 2.6 IPsec interface
 > code on 2.6.27.5-41.fc9.i686 (experimental code)
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc():
 > Activating <NULL>: Ok (ret=0)
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_add(): ERROR: Algorithm
 > already exists
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc():
 > Activating <NULL>: FAILED (ret=-17)
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_add(): ERROR: Algorithm
 > already exists
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc():
 > Activating <NULL>: FAILED (ret=-17)
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_add(): ERROR: Algorithm
 > already exists
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc():
 > Activating <NULL>: FAILED (ret=-17)
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_add(): ERROR: Algorithm
 > already exists
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc():
 > Activating <NULL>: FAILED (ret=-17)
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_add(): ERROR: Algorithm
 > already exists
 > Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc():
 > Activating <NULL>: FAILED (ret=-17)
 > Jan 26 09:33:31 localhost pluto[21368]: Could not change to directory
 > '/etc/ipsec.d/cacerts': /etc/ipsec.d
 > Jan 26 09:33:31 localhost pluto[21368]: Could not change to directory
 > '/etc/ipsec.d/aacerts': /etc/ipsec.d
 > Jan 26 09:33:31 localhost pluto[21368]: Could not change to directory
 > '/etc/ipsec.d/ocspcerts': /etc/ipsec.d
 > Jan 26 09:33:31 localhost pluto[21368]: Could not change to directory
 > '/etc/ipsec.d/crls'
 > Jan 26 09:33:31 localhost pluto[21368]: Changing back to directory
 > '/etc/ipsec.d' failed - (2 No such file or directory)
 > Jan 26 09:33:31 localhost pluto[21368]: Changing back to directory
 > '/etc/ipsec.d' failed - (2 No such file or directory)
 > Jan 26 09:33:31 localhost pluto[21368]: added connection description "vo"
 > Jan 26 09:33:31 localhost pluto[21368]: added connection description 
"vodmz"
 > Jan 26 09:34:10 localhost pluto[21368]: shutting down
 > Jan 26 09:34:10 localhost pluto[21368]: "vodmz": deleting connection
 > Jan 26 09:34:10 localhost pluto[21368]: "vo": deleting connection
 > Jan 26 09:34:12 localhost pluto[21750]: Starting Pluto (Openswan Version
 > 2.6.14; Vendor ID OEoSJUweaqAX) pid:21750
 > Jan 26 09:34:12 localhost pluto[21750]: Setting NAT-Traversal port-4500
 > floating to on
 > Jan 26 09:34:12 localhost pluto[21750]:    port floating activation
 > criteria nat_t=1/port_float=1
 > Jan 26 09:34:12 localhost pluto[21750]:    including NAT-Traversal patch
 > (Version 0.6c)
 > Jan 26 09:34:12 localhost pluto[21750]: using /dev/urandom as source of
 > random entropy
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc():
 > Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc():
 > Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc():
 > Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc():
 > Activating OAKLEY_AES_CBC: Ok (ret=0)
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc():
 > Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_hash():
 > Activating OAKLEY_SHA2_512: Ok (ret=0)
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_hash():
 > Activating OAKLEY_SHA2_256: Ok (ret=0)
 > Jan 26 09:34:12 localhost pluto[21750]: starting up 1 cryptographic 
helpers
 > Jan 26 09:34:12 localhost pluto[21752]: using /dev/urandom as source of
 > random entropy
 > Jan 26 09:34:12 localhost pluto[21750]: started helper pid=21752 (fd:7)
 > Jan 26 09:34:12 localhost pluto[21750]: Using Linux 2.6 IPsec interface
 > code on 2.6.27.5-41.fc9.i686 (experimental code)
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc():
 > Activating <NULL>: Ok (ret=0)
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_add(): ERROR: Algorithm
 > already exists
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc():
 > Activating <NULL>: FAILED (ret=-17)
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_add(): ERROR: Algorithm
 > already exists
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc():
 > Activating <NULL>: FAILED (ret=-17)
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_add(): ERROR: Algorithm
 > already exists
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc():
 > Activating <NULL>: FAILED (ret=-17)
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_add(): ERROR: Algorithm
 > already exists
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc():
 > Activating <NULL>: FAILED (ret=-17)
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_add(): ERROR: Algorithm
 > already exists
 > Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc():
 > Activating <NULL>: FAILED (ret=-17)
 > Jan 26 09:34:12 localhost pluto[21750]: Could not change to directory
 > '/etc/ipsec.d/cacerts': /etc/ipsec.d
 > Jan 26 09:34:12 localhost pluto[21750]: Could not change to directory
 > '/etc/ipsec.d/aacerts': /etc/ipsec.d
 > Jan 26 09:34:12 localhost pluto[21750]: Could not change to directory
 > '/etc/ipsec.d/ocspcerts': /etc/ipsec.d
 > Jan 26 09:34:12 localhost pluto[21750]: Could not change to directory
 > '/etc/ipsec.d/crls'
 > Jan 26 09:34:12 localhost pluto[21750]: Changing back to directory
 > '/etc/ipsec.d' failed - (2 No such file or directory)
 > Jan 26 09:34:12 localhost pluto[21750]: Changing back to directory
 > '/etc/ipsec.d' failed - (2 No such file or directory)
 > Jan 26 09:34:12 localhost pluto[21750]: added connection description "vo"
 > Jan 26 09:34:12 localhost pluto[21750]: added connection description 
"vodmz"
 > Jan 26 09:36:36 localhost pluto[21750]: shutting down
 > Jan 26 09:36:36 localhost pluto[21750]: "vodmz": deleting connection
 > Jan 26 09:36:36 localhost pluto[21750]: "vo": deleting connection
 > Jan 26 09:36:38 localhost pluto[22267]: Starting Pluto (Openswan Version
 > 2.6.14; Vendor ID OEoSJUweaqAX) pid:22267
 > Jan 26 09:36:38 localhost pluto[22267]: Setting NAT-Traversal port-4500
 > floating to on
 > Jan 26 09:36:38 localhost pluto[22267]:    port floating activation
 > criteria nat_t=1/port_float=1
 > Jan 26 09:36:38 localhost pluto[22267]:    including NAT-Traversal patch
 > (Version 0.6c)
 > Jan 26 09:36:38 localhost pluto[22267]: using /dev/urandom as source of
 > random entropy
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc():
 > Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc():
 > Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc():
 > Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc():
 > Activating OAKLEY_AES_CBC: Ok (ret=0)
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc():
 > Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_hash():
 > Activating OAKLEY_SHA2_512: Ok (ret=0)
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_hash():
 > Activating OAKLEY_SHA2_256: Ok (ret=0)
 > Jan 26 09:36:38 localhost pluto[22267]: starting up 1 cryptographic 
helpers
 > Jan 26 09:36:38 localhost pluto[22268]: using /dev/urandom as source of
 > random entropy
 > Jan 26 09:36:38 localhost pluto[22267]: started helper pid=22268 (fd:7)
 > Jan 26 09:36:38 localhost pluto[22267]: Using Linux 2.6 IPsec interface
 > code on 2.6.27.5-41.fc9.i686 (experimental code)
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc():
 > Activating <NULL>: Ok (ret=0)
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_add(): ERROR: Algorithm
 > already exists
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc():
 > Activating <NULL>: FAILED (ret=-17)
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_add(): ERROR: Algorithm
 > already exists
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc():
 > Activating <NULL>: FAILED (ret=-17)
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_add(): ERROR: Algorithm
 > already exists
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc():
 > Activating <NULL>: FAILED (ret=-17)
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_add(): ERROR: Algorithm
 > already exists
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc():
 > Activating <NULL>: FAILED (ret=-17)
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc(): WARNING:
 > enc alg=0 not found in constants.c:oakley_enc_names
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_add(): ERROR: Algorithm
 > already exists
 > Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc():
 > Activating <NULL>: FAILED (ret=-17)
 > Jan 26 09:36:39 localhost pluto[22267]: Could not change to directory
 > '/etc/ipsec.d/cacerts': /etc/ipsec.d
 > Jan 26 09:36:39 localhost pluto[22267]: Could not change to directory
 > '/etc/ipsec.d/aacerts': /etc/ipsec.d
 > Jan 26 09:36:39 localhost pluto[22267]: Could not change to directory
 > '/etc/ipsec.d/ocspcerts': /etc/ipsec.d
 > Jan 26 09:36:39 localhost pluto[22267]: Could not change to directory
 > '/etc/ipsec.d/crls'
 > Jan 26 09:36:39 localhost pluto[22267]: Changing back to directory
 > '/etc/ipsec.d' failed - (2 No such file or directory)
 > Jan 26 09:36:39 localhost pluto[22267]: Changing back to directory
 > '/etc/ipsec.d' failed - (2 No such file or directory)
 > Jan 26 09:36:39 localhost pluto[22267]: added connection description "vo"
 > Jan 26 09:36:39 localhost pluto[22267]: added connection description 
"vodmz"

Openswan keeps restarting, possibly due to the failure caused by 
SELinux, fix that then see if this problem is fixed.

 > + _________________________ ifconfig-a
 > + ifconfig -a
 > eth0      Link encap:Ethernet  HWaddr 00:1A:A0:49:D6:F0
 >           inet addr:192.168.15.3  Bcast:192.168.15.255 
Mask:255.255.255.0
 >           inet6 addr: fe80::21a:a0ff:fe49:d6f0/64 Scope:Link
 >           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 >           RX packets:437205 errors:0 dropped:0 overruns:0 frame:0
 >           TX packets:382402 errors:0 dropped:0 overruns:0 carrier:0
 >           collisions:0 txqueuelen:1000
 >           RX bytes:392714376 (374.5 MiB)  TX bytes:73748413 (70.3 MiB)
 >           Interrupt:16
 >

> + _________________________ ipsec/conf
> + ipsec _keycensor
> + ipsec _include /etc/ipsec.conf
> 
> #< /etc/ipsec.conf 1
> # /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"
>     # For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
>     protostack=netkey
>     nat_traversal=yes
> 
> 
> #< /etc/ipsec.d/ipsec.conf 1
> conn vo
>     also=vocommon
>     rightsubnet=192.168.10.0/24
>     auto=start
> 
> conn vodmz
>     also=vocommon
>     rightsubnet=192.168.8.0/24
>     auto=start
> 
> conn vocommon
>     type=tunnel
>     left=%defaultroute
>     leftid=@jingluo
>     leftsourceip=192.168.200.56
>     leftsubnet=192.168.200.56/32
>     rightid=@vo
>     right=67.220.126.196
>     keyingtries=0
>     pfs=yes
>     authby=secret
>     auth=esp
>     ike=aes256-sha1
>     esp=aes256-sha1
>     keyexchange=ike
> 
> 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
> 
> #> /etc/ipsec.conf 19

Which side of the tunnel is this system on, jingluo or vo?
What IPSec device is on the other end?

> + _________________________ ipsec/secrets
> + ipsec _include /etc/ipsec.secrets
> + ipsec _secretcensor
> 
> #< /etc/ipsec.secrets 1
> 
> #< /etc/ipsec.d/ipsec.secrets 1
> @jingluo @vo : PSK "[sums to 3db3...]"
> 
> #> /etc/ipsec.secrets 2

You cannot identify a PSK with id's you must use IP addresses.
RSA keys are better, more flexible if you can use them.

Peter

Chris Garrigues wrote:
> Peter McGill wrote:
>> Chris,
>>
>> It appears that you still have opportunistic encryption on.
>> > + ipsec verify
>> > Opportunistic Encryption DNS checks:
>> >    Looking for TXT in forward dns zone: localhost.localdomain   
>> [MISSING]
>> >    Does the machine have at least one non-private address?      
>> [FAILED]
>>
>> I don't see anywhere that you've turned opportunistic encryption off.
>> ipsec.conf:
>> config setup
>>     oe=off # Openswan 2.6.x only
>>
>> or
>>
>> include /etc/ipsec.d/examples/no_oe.conf
> Apparently that wasn't enough.  We must have something else wrong as well.
> 
> -- 
> Chris Garrigues
> Senior System Administrator
> Ph: (512) 961-6808
> chris.garrigues at SteepRockInc.com <mailto:chris.garrigues at SteepRockInc.com>
> 

From jonah at distributivenetworks.com  Mon Jan 26 18:04:49 2009
From: jonah at distributivenetworks.com (Jonah Wittkamper)
Date: Mon, 26 Jan 2009 18:04:49 -0500
Subject: [Openswan Users] How do I sniff for decrypted packets
Message-ID: <0BD18085133D6C4FBB38DC69EA5ECED0636469@themailman.themailman.local>

I am running Openswan 2.4.9-r1

 

My only interfaces are eth0, eth1 and lo.

 

My vpn tunnel comes up but the back-and-forth has been an issue.  To
diagnose I need to sniff incoming packets, after they've been deleted.  

 

By running tcpdump on eth0 I can see ESP packets, but I can't see
decrypted packets.  My research on this mailing list suggests that I
should see both encrypted and decrypted packets, but I only see
encrypted ones.  

 

I thought turning on debug options would help log sufficient traffic
information to help, but it doesn't.

 

How am I supposed to sniff decrypted incoming packets?

 

Jonah

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090126/096da56d/attachment.html 

From paul at xelerance.com  Mon Jan 26 19:43:30 2009
From: paul at xelerance.com (Paul Wouters)
Date: Mon, 26 Jan 2009 19:43:30 -0500 (EST)
Subject: [Openswan Users] How do I sniff for decrypted packets
In-Reply-To: <0BD18085133D6C4FBB38DC69EA5ECED0636469@themailman.themailman.local>
References: <0BD18085133D6C4FBB38DC69EA5ECED0636469@themailman.themailman.local>
Message-ID: <Pine.LNX.4.64.0901261942180.4279@newtla.xelerance.com>

On Mon, 26 Jan 2009, Jonah Wittkamper wrote:

> My only interfaces are eth0, eth1 and lo.

> By running tcpdump on eth0 I can see ESP packets, but I can't see
> decrypted packets.  My research on this mailing list suggests that I
> should see both encrypted and decrypted packets, but I only see
> encrypted ones.  

No, with netkey you won't see encrypted outgoing packets, only encrypted
incoming packets. Sometimes the following hack works:

ifconfig eth0:bogus
tcpdum -i eth0:bogus -n

Paul

From gohanman at gmail.com  Mon Jan 26 20:11:21 2009
From: gohanman at gmail.com (Andy Theuninck)
Date: Mon, 26 Jan 2009 19:11:21 -0600
Subject: [Openswan Users] NAT on both sides
Message-ID: <f8a02f3e0901261711q69886363qe7e4030bb67e91d6@mail.gmail.com>

I'm trying to set up a connection with both ends behind NAT. I must be
missing something because I just cannot get it to work. Set up is like
this:

openswan server 192.168.1.2
router 1.2.3.4
(internet)
router w/ dynamic ip
openswan client 192.168.0.3

The router at 1.2.3.4 is passing IP 50, UDP 500, and UDP 4500 to 192.168.1.2

server ipsec.conf:
version 2.0     # conforms to second version of ipsec.conf specification
# basic configuration
config setup
        protostack=netkey
        nat_traversal=yes
        virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.1.0/24

conn road
        authby=secret
        pfs=no
        rekey=no
        keyingtries=3

        left=%defaultroute
        leftsubnet=192.168.1.0/24
        leftprotoport=17/%any

        right=%any
        rightprotoport=17/%any

        auto=add

client ipsec.conf:
version 2.0     # conforms to second version of ipsec.conf specification
# basic configuration
config setup
        protostack=netkey
        nat_traversal=yes
        virtual_private=%v4:192.168.0.0/16

conn WFC
        authby=secret
        pfs=no
        rekey=yes
        keyingtries=3
        type=transport

        left=192.168.0.3
        leftprotoport=17/1701

        right=209.240.239.188
        rightsubnet=192.168.1.0/24
        rightprotoport=17/1701

        auto=add

As given, when I try to bring up the connection from the client side I get this:
003 "WFC" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal):
both are NATed
108 "WFC" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "WFC" #1: received Vendor ID payload [CAN-IKEv2]
003 "WFC" #1: we require peer to have ID '209.240.239.188', but peer
declares '192.168.1.2'
218 "WFC" #1: STATE_MAIN_I3: INVALID_ID_INFORMATION

So both NATs are recognized, but it still objects to the IP mismatch.

If I add rightid=192.168.1.2 to the client's ipsec.conf, I get this
error on the server side:
Jan 26 19:04:44 key pluto[15093]: "road"[2] 68.112.168.88 #4:
STATE_MAIN_R3: sent MR3, ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha
group=modp2048}
Jan 26 19:04:44 key pluto[15093]: "road"[2] 68.112.168.88 #4: the peer
proposed: 192.168.1.0/24:17/0 -> 192.168.0.3/32:17/0
Jan 26 19:04:44 key pluto[15093]: "road"[2] 68.112.168.88 #4: cannot
respond to IPsec SA request because no connection is known for
192.168.1.0/24===192.168.1.2[+S=C]:17/%any...68.112.168.88[192.168.0.3,+S=C]:17/%any===192.168.0.3/32
Jan 26 19:04:44 key pluto[15093]: "road"[2] 68.112.168.88 #4: sending
encrypted notification INVALID_ID_INFORMATION to 68.112.168.88:4500

I'm honestly not sure if that's any closer. I tried specifying ids on
both ends with @ notation, but that gives the same error as using
rightid=192.168.1.2 (except with ids listed in the error).

From charlessimon at hotmail.com  Tue Jan 27 01:05:50 2009
From: charlessimon at hotmail.com (simon charles)
Date: Tue, 27 Jan 2009 01:05:50 -0500
Subject: [Openswan Users] NAT on both sides
In-Reply-To: <f8a02f3e0901261711q69886363qe7e4030bb67e91d6@mail.gmail.com>
References: <f8a02f3e0901261711q69886363qe7e4030bb67e91d6@mail.gmail.com>
Message-ID: <BLU108-W44760C33224A83F9260AFEDBCB0@phx.gbl>


Andy !
        Here is one of the ways to get this to work:-
server ipsec.conf:
version 2.0     # conforms to second version of ipsec.conf specification
# basic configuration
config setup
        protostack=netkey
        nat_traversal=yes
        virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.1.0/24
 
conn road
        authby=secret
        pfs=no
        rekey=no
        keyingtries=3
 
        left=%defaultroute
        leftsubnet=192.168.1.0/24
        leftprotoport=17/%any
        leftid=209.240.239.188 # Add a connection identifier for server
 
        right=%any
        rightprotoport=17/%any
        rightid=@myRW01 # Add a connection identifier for the client
 
        auto=add
 
client ipsec.conf:
version 2.0     # conforms to second version of ipsec.conf specification
# basic configuration
config setup
        protostack=netkey
        nat_traversal=yes
        virtual_private=%v4:192.168.0.0/16
 
conn WFC
        authby=secret
        pfs=no
        rekey=yes
        keyingtries=3
        type=transport
 
        left=192.168.0.3
        leftprotoport=17/1701
        leftid=@myRW01 # Add connection identifier for the client
 
        right=209.240.239.188
        rightsubnet=192.168.1.0/24
        rightprotoport=17/1701
        
        
 
        auto=addChanges to /etc/ipsec.secrets file on the server

@myRW01 209.240.239.188 : PSK "somesecretphrase01"
@myRW01 192.168.1.2 : PSK "somesecretphrase01"

     Hope that helps !

- Simon Charles - 




> Date: Mon, 26 Jan 2009 19:11:21 -0600
> From: gohanman at gmail.com
> To: users at openswan.org
> Subject: [Openswan Users] NAT on both sides
> 
> I'm trying to set up a connection with both ends behind NAT. I must be
> missing something because I just cannot get it to work. Set up is like
> this:
> 
> openswan server 192.168.1.2
> router 1.2.3.4
> (internet)
> router w/ dynamic ip
> openswan client 192.168.0.3
> 
> The router at 1.2.3.4 is passing IP 50, UDP 500, and UDP 4500 to 192.168.1.2
> 
> server ipsec.conf:
> version 2.0     # conforms to second version of ipsec.conf specification
> # basic configuration
> config setup
>         protostack=netkey
>         nat_traversal=yes
>         virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.1.0/24
> 
> conn road
>         authby=secret
>         pfs=no
>         rekey=no
>         keyingtries=3
> 
>         left=%defaultroute
>         leftsubnet=192.168.1.0/24
>         leftprotoport=17/%any
> 
>         right=%any
>         rightprotoport=17/%any
> 
>         auto=add
> 
> client ipsec.conf:
> version 2.0     # conforms to second version of ipsec.conf specification
> # basic configuration
> config setup
>         protostack=netkey
>         nat_traversal=yes
>         virtual_private=%v4:192.168.0.0/16
> 
> conn WFC
>         authby=secret
>         pfs=no
>         rekey=yes
>         keyingtries=3
>         type=transport
> 
>         left=192.168.0.3
>         leftprotoport=17/1701
> 
>         right=209.240.239.188
>         rightsubnet=192.168.1.0/24
>         rightprotoport=17/1701
> 
>         auto=add
> 
> As given, when I try to bring up the connection from the client side I get this:
> 003 "WFC" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal):
> both are NATed
> 108 "WFC" #1: STATE_MAIN_I3: sent MI3, expecting MR3
> 003 "WFC" #1: received Vendor ID payload [CAN-IKEv2]
> 003 "WFC" #1: we require peer to have ID '209.240.239.188', but peer
> declares '192.168.1.2'
> 218 "WFC" #1: STATE_MAIN_I3: INVALID_ID_INFORMATION
> 
> So both NATs are recognized, but it still objects to the IP mismatch.
> 
> If I add rightid=192.168.1.2 to the client's ipsec.conf, I get this
> error on the server side:
> Jan 26 19:04:44 key pluto[15093]: "road"[2] 68.112.168.88 #4:
> STATE_MAIN_R3: sent MR3, ISAKMP SA established
> {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha
> group=modp2048}
> Jan 26 19:04:44 key pluto[15093]: "road"[2] 68.112.168.88 #4: the peer
> proposed: 192.168.1.0/24:17/0 -> 192.168.0.3/32:17/0
> Jan 26 19:04:44 key pluto[15093]: "road"[2] 68.112.168.88 #4: cannot
> respond to IPsec SA request because no connection is known for
> 192.168.1.0/24===192.168.1.2[+S=C]:17/%any...68.112.168.88[192.168.0.3,+S=C]:17/%any===192.168.0.3/32
> Jan 26 19:04:44 key pluto[15093]: "road"[2] 68.112.168.88 #4: sending
> encrypted notification INVALID_ID_INFORMATION to 68.112.168.88:4500
> 
> I'm honestly not sure if that's any closer. I tried specifying ids on
> both ends with @ notation, but that gives the same error as using
> rightid=192.168.1.2 (except with ids listed in the error).
> _______________________________________________
> 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=283155
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090127/d7746e12/attachment-0001.html 

From gohanman at gmail.com  Tue Jan 27 10:59:25 2009
From: gohanman at gmail.com (Andy Theuninck)
Date: Tue, 27 Jan 2009 09:59:25 -0600
Subject: [Openswan Users] NAT on both sides
In-Reply-To: <BLU108-W44760C33224A83F9260AFEDBCB0@phx.gbl>
References: <f8a02f3e0901261711q69886363qe7e4030bb67e91d6@mail.gmail.com>
	<BLU108-W44760C33224A83F9260AFEDBCB0@phx.gbl>
Message-ID: <f8a02f3e0901270759r3ae910aem5a5d5ad137c547ab@mail.gmail.com>

I'd prefer to avoid using IDs on the client side because I don't think
I can set a client ID on WinXP or OSX. Ideally, something like this:
http://www.jacco2.dds.nl/networking/openswan-l2tp.html#serverNATed

One thing I can't figure out is: should the NAT device in front of my
server being forwarding UDP 500/4500 and IP 50, or does NAT-T
eliminate the need to do that?

On Tue, Jan 27, 2009 at 12:05 AM, simon charles
<charlessimon at hotmail.com> wrote:
> Andy !
>         Here is one of the ways to get this to work:-
>
> server ipsec.conf:
> version 2.0     # conforms to second version of ipsec.conf specification
> # basic configuration
> config setup
>         protostack=netkey
>         nat_traversal=yes
>
> virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.1.0/24
>
> conn road
>         authby=secret
>         pfs=no
>         rekey=no
>         keyingtries=3
>
>         left=%defaultroute
>         leftsubnet=192.168.1.0/24
>         leftprotoport=17/%any
>         leftid=209.240.239.188 # Add a connection identifier for server
>
>         right=%any
>         rightprotoport=17/%any
>         rightid=@myRW01 # Add a connection identifier for the client
>
>         auto=add
>
> client ipsec.conf:
> version 2.0     # conforms to second version of ipsec.conf specification
> # basic configuration
> config setup
>         protostack=netkey
>         nat_traversal=yes
>         virtual_private=%v4:192.168.0.0/16
>
> conn WFC
>         authby=secret
>         pfs=no
>         rekey=yes
>         keyingtries=3
>         type=transport
>
>         left=192.168.0.3
>         leftprotoport=17/1701
>         leftid=@myRW01 # Add connection identifier for the client
>
>         right=209.240.239.188
>         rightsubnet=192.168.1.0/24
>         rightprotoport=17/1701
>
>
>
>         auto=add
>
> Changes to /etc/ipsec.secrets file on the server
>
> @myRW01 209.240.239.188 : PSK "somesecretphrase01"
> @myRW01 192.168.1.2 : PSK "somesecretphrase01"
>
>      Hope that helps !
>
> - Simon Charles -
>
>
>
>
>> Date: Mon, 26 Jan 2009 19:11:21 -0600
>> From: gohanman at gmail.com
>> To: users at openswan.org
>> Subject: [Openswan Users] NAT on both sides
>>
>> I'm trying to set up a connection with both ends behind NAT. I must be
>> missing something because I just cannot get it to work. Set up is like
>> this:
>>
>> openswan server 192.168.1.2
>> router 1.2.3.4
>> (internet)
>> router w/ dynamic ip
>> openswan client 192.168.0.3
>>
>> The router at 1.2.3.4 is passing IP 50, UDP 500, and UDP 4500 to
>> 192.168.1.2
>>
>> server ipsec.conf:
>> version 2.0 # conforms to second version of ipsec.conf specification
>> # basic configuration
>> config setup
>> protostack=netkey
>> nat_traversal=yes
>>
>> virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.1.0/24
>>
>> conn road
>> authby=secret
>> pfs=no
>> rekey=no
>> keyingtries=3
>>
>> left=%defaultroute
>> leftsubnet=192.168.1.0/24
>> leftprotoport=17/%any
>>
>> right=%any
>> rightprotoport=17/%any
>>
>> auto=add
>>
>> client ipsec.conf:
>> version 2.0 # conforms to second version of ipsec.conf specification
>> # basic configuration
>> config setup
>> protostack=netkey
>> nat_traversal=yes
>> virtual_private=%v4:192.168.0.0/16
>>
>> conn WFC
>> authby=secret
>> pfs=no
>> rekey=yes
>> keyingtries=3
>> type=transport
>>
>> left=192.168.0.3
>> leftprotoport=17/1701
>>
>> right=209.240.239.188
>> rightsubnet=192.168.1.0/24
>> rightprotoport=17/1701
>>
>> auto=add
>>
>> As given, when I try to bring up the connection from the client side I get
>> this:
>> 003 "WFC" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal):
>> both are NATed
>> 108 "WFC" #1: STATE_MAIN_I3: sent MI3, expecting MR3
>> 003 "WFC" #1: received Vendor ID payload [CAN-IKEv2]
>> 003 "WFC" #1: we require peer to have ID '209.240.239.188', but peer
>> declares '192.168.1.2'
>> 218 "WFC" #1: STATE_MAIN_I3: INVALID_ID_INFORMATION
>>
>> So both NATs are recognized, but it still objects to the IP mismatch.
>>
>> If I add rightid=192.168.1.2 to the client's ipsec.conf, I get this
>> error on the server side:
>> Jan 26 19:04:44 key pluto[15093]: "road"[2] 68.112.168.88 #4:
>> STATE_MAIN_R3: sent MR3, ISAKMP SA established
>> {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha
>> group=modp2048}
>> Jan 26 19:04:44 key pluto[15093]: "road"[2] 68.112.168.88 #4: the peer
>> proposed: 192.168.1.0/24:17/0 -> 192.168.0.3/32:17/0
>> Jan 26 19:04:44 key pluto[15093]: "road"[2] 68.112.168.88 #4: cannot
>> respond to IPsec SA request because no connection is known for
>>
>> 192.168.1.0/24===192.168.1.2[+S=C]:17/%any...68.112.168.88[192.168.0.3,+S=C]:17/%any===192.168.0.3/32
>> Jan 26 19:04:44 key pluto[15093]: "road"[2] 68.112.168.88 #4: sending
>> encrypted notification INVALID_ID_INFORMATION to 68.112.168.88:4500
>>
>> I'm honestly not sure if that's any closer. I tried specifying ids on
>> both ends with @ notation, but that gives the same error as using
>> rightid=192.168.1.2 (except with ids listed in the error).
>> _______________________________________________
>> 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=283155
>

From gohanman at gmail.com  Tue Jan 27 22:52:10 2009
From: gohanman at gmail.com (Andy Theuninck)
Date: Tue, 27 Jan 2009 21:52:10 -0600
Subject: [Openswan Users] NAT on both sides
In-Reply-To: <f8a02f3e0901261711q69886363qe7e4030bb67e91d6@mail.gmail.com>
References: <f8a02f3e0901261711q69886363qe7e4030bb67e91d6@mail.gmail.com>
Message-ID: <f8a02f3e0901271952h7d04090ejf8d4403d822fb3ce@mail.gmail.com>

OK, I think I'm really close. Here's my server config:

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

# basic configuration
config setup
        protostack=netkey
        nat_traversal=yes
        virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12

include /etc/ipsec.d/*.conf

conn passthrough-for-non-l2tp
        type=passthrough
        left=%defaultroute
        right=0.0.0.0
        rightsubnet=0.0.0.0/0
        auto=route

conn road
        authby=secret
        pfs=no
        rekey=no
        keyingtries=3
        type=transport

        forceencaps=yes

        left=%defaultroute
        leftprotoport=17/1701

        right=%any
        rightsubnet=vhost:%no,%priv
        rightprotoport=17/%any

        auto=add

This configuration *works* with openswan to openswan connections with
both sides NATed. When I try to connect from Vista, I get this:

Jan 27 21:46:24 key pluto[15933]: "road"[2] 68.112.168.88 #1: the peer
proposed: server.nat.public.ip/32:17/1701 -> 192.168.0.3/32:17/0
Jan 27 21:46:24 key pluto[15933]: "road"[2] 68.112.168.88 #1: cannot
respond to IPsec SA request because no connection is known for
server.nat.public.ip/32===192.168.1.2[+S=C]:17/1701...68.112.168.88[192.168.0.3,+S=C]:17/%any===192.168.0.3/32

Based on the logs from the working openswan-to-openswan connection, it
seems that the problem is the peer insisting on the public IP. I've
applied the Vista registry fix described at
http://www.jacco2.dds.nl/networking/vista-openswan.html#NAT-T and that
doesn't seem to alter results whatsoever (yes, I did reboot).

Does anyone know what I need to do to get a windows client working?

From andrew.colin at gmail.com  Wed Jan 28 01:36:43 2009
From: andrew.colin at gmail.com (andrew colin)
Date: Wed, 28 Jan 2009 08:36:43 +0200
Subject: [Openswan Users] NAT on both sides
In-Reply-To: <f8a02f3e0901271952h7d04090ejf8d4403d822fb3ce@mail.gmail.com>
References: <f8a02f3e0901261711q69886363qe7e4030bb67e91d6@mail.gmail.com>
	<f8a02f3e0901271952h7d04090ejf8d4403d822fb3ce@mail.gmail.com>
Message-ID: <31da51d50901272236g19c07b2tbe0a519bdf8d855d@mail.gmail.com>

Please let me know if you get it working with a windows client.

On Wed, Jan 28, 2009 at 5:52 AM, Andy Theuninck <gohanman at gmail.com> wrote:
> OK, I think I'm really close. Here's my server config:
>
> version 2.0     # conforms to second version of ipsec.conf specification
>
> # basic configuration
> config setup
>        protostack=netkey
>        nat_traversal=yes
>        virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
>
> include /etc/ipsec.d/*.conf
>
> conn passthrough-for-non-l2tp
>        type=passthrough
>        left=%defaultroute
>        right=0.0.0.0
>        rightsubnet=0.0.0.0/0
>        auto=route
>
> conn road
>        authby=secret
>        pfs=no
>        rekey=no
>        keyingtries=3
>        type=transport
>
>        forceencaps=yes
>
>        left=%defaultroute
>        leftprotoport=17/1701
>
>        right=%any
>        rightsubnet=vhost:%no,%priv
>        rightprotoport=17/%any
>
>        auto=add
>
> This configuration *works* with openswan to openswan connections with
> both sides NATed. When I try to connect from Vista, I get this:
>
> Jan 27 21:46:24 key pluto[15933]: "road"[2] 68.112.168.88 #1: the peer
> proposed: server.nat.public.ip/32:17/1701 -> 192.168.0.3/32:17/0
> Jan 27 21:46:24 key pluto[15933]: "road"[2] 68.112.168.88 #1: cannot
> respond to IPsec SA request because no connection is known for
> server.nat.public.ip/32===192.168.1.2[+S=C]:17/1701...68.112.168.88[192.168.0.3,+S=C]:17/%any===192.168.0.3/32
>
> Based on the logs from the working openswan-to-openswan connection, it
> seems that the problem is the peer insisting on the public IP. I've
> applied the Vista registry fix described at
> http://www.jacco2.dds.nl/networking/vista-openswan.html#NAT-T and that
> doesn't seem to alter results whatsoever (yes, I did reboot).
>
> Does anyone know what I need to do to get a windows client working?
> _______________________________________________
> 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=283155
>



-- 
"Dru"
To follow the path, look to the master, follow the master, walk with
the master, see through the master, become the master. (zen)
http://www.topdog.za.net/

From piotr.1234 at interia.pl  Wed Jan 28 08:04:17 2009
From: piotr.1234 at interia.pl (piotr.1234 at interia.pl)
Date: 28 Jan 2009 14:04:17 +0100
Subject: [Openswan Users] cisco and asa 5510
Message-ID: <20090128130421.76246719018@f36.poczta.interia.pl>


I have problem with vpn between ASA and openswan. I use some configuration from openswan page. IKE phase 1 and 2 are estabilish but packet don't pass. I turn off iptables.


10.10.10.0/24 - Openswan 192.168.1.1===192.168.1.2-Cisco--20.20.20.0/26

my conf:
config setup
        interfaces="ipsec0=eth1"
        plutodebug=control
        strictcrlpolicy=no
        nat_traversal=no
        uniqueids=yes

conn %default
        type=tunnel
        authby=secret
        ikelifetime=480m
        keylife=480m
        keyingtries=3
        auto=start
        keyexchange=ike
        pfs=no
        auth=esp
        #esp=3des-md5
        #ike=3des-sha1-modp1536
        #dpdaction=hold
        #dpddelay=60
        #dpdtimeout=500



conn erwin01
        left=192.168.1.1
        leftsubnet=10.10.10.0/24
        leftnexthop=192.168.1.2
        right=192.168.1.2
        rightsubnet=20.20.20.0/26
        rightnexthop=192.168.1.1


        
service ipsec status
IPsec running  - pluto pid: 6037
pluto pid 6037
2 tunnels up
some eroutes exist

 
Jan 27 23:05:57 erwin ipsec_setup: Starting Openswan IPsec 2.6.19...
Jan 27 23:05:57 erwin ipsec_setup: Using KLIPS/legacy stack
Jan 27 23:05:57 erwin kernel: padlock: VIA PadLock not detected.
Jan 27 23:05:57 erwin ipsec_setup: KLIPS debug `none'
Jan 27 23:05:57 erwin kernel:
Jan 27 23:05:57 erwin ipsec_setup: KLIPS ipsec0 on eth1 [ip] broadcast 
Jan 27 23:05:57 erwin pluto: adjusting ipsec.d to /etc/ipsec.d
Jan 27 23:05:57 erwin ipsec__plutorun: adjusting ipsec.d to /etc/ipsec.d
Jan 27 23:05:57 erwin ipsec_setup: ...Openswan IPsec started
Jan 27 23:05:57 erwin ipsec__plutorun: 002 added connection description "erwin01"
Jan 27 23:05:57 erwin ipsec__plutorun: 002 added connection description "erwin02"
Jan 27 23:05:58 erwin ipsec__plutorun: 104 "erwin01" #1: STATE_MAIN_I1: initiate


Jan 28 13:49:58 erwin pluto[6037]: |
Jan 28 13:49:58 erwin pluto[6037]: | *time to handle event
Jan 28 13:49:58 erwin pluto[6037]: | handling event EVENT_PENDING_PHASE2
Jan 28 13:49:58 erwin pluto[6037]: | event after this is EVENT_SHUNT_SCAN in 119 seconds
Jan 28 13:49:58 erwin pluto[6037]: | inserting event EVENT_PENDING_PHASE2, timeout in 120 seconds
Jan 28 13:49:58 erwin pluto[6037]: | pending review: connection "erwin02" checked
Jan 28 13:49:58 erwin pluto[6037]: | pending review: connection "erwin01" checked
Jan 28 13:49:58 erwin pluto[6037]: | next event EVENT_SHUNT_SCAN in 119 seconds

my cisco conf:

crypto ipsec transform-set erwin01 esp-3des esp-sha-hmac
crypto map outside_map 40 match address erwin01
crypto map outside_map 40 set peer 192.168.1.1
crypto map outside_map 40 set transform-set erwin01_w_wawie

crypto isakmp policy 10
 authentication pre-share
 encryption 3des
 hash sha
 group 2
 lifetime 28800

access-list erwin01 line 1 extended permit ip 20.20.20.0 255.255.255.192 10.10.10.0 255.255.255.0


thanks for some help
Peter

----------------------------------------------------------------------
Obdaruj swoja Walentynke ... lub siebie!
Wygraj nagrody! Sprawdz >> http://link.interia.pl/f203a 


From joshihirenn at gmail.com  Wed Jan 28 10:08:05 2009
From: joshihirenn at gmail.com (hiren joshi)
Date: Wed, 28 Jan 2009 20:38:05 +0530
Subject: [Openswan Users] manual keying: encryption-only connection with DES
Message-ID: <29820bf40901280708v2e56c027o6331af2296ae8e0e@mail.gmail.com>

Hello,

I tried to setup a manually keyed encryption-only connection with DES (for
compatibility reasons).
But failed.

# ipsec spi --af inet --said esp0x2222 at 172.16.1.11 --esp des --src
172.16.3.2 --enckey 0x9876543210987654
/usr/libexec/ipsec/spi: Invalid encryption algorithm 'des' follows '--esp'
option: lead too many(2) transforms

However the following works:

Encryption-only 3DES:
# ipsec spi --af inet --said esp0x2222 at 172.16.1.11 --esp 3des --src
172.16.3.2 --enckey 0x987654321098765432109876543210987654321098765432
# ipsec spi
esp0x2222 at 172.16.1.11 ESP_3DES: dir=out src=172.16.3.2 iv_bits=64bits
iv=0x7ec36178c1bf36e7 eklen=192 life(c,s,h)=addtime(3,0,0) natencap=none
natsport=0 natdport=0 refcount=3 ref=7

DES with authentication:
# ipsec spi --af inet --said esp0x2222 at 172.16.1.11 --esp des-md5 --src
172.16.3.2 --authkey 0x98765432109876549876543210987654 --enckey
0x9876543210987654
# ipsec spi
esp0x2222 at 172.16.1.11 ESP_ID2_HMAC_MD5: dir=out src=172.16.3.2
iv_bits=64bits iv=0xb7b6e8a5328314c1 alen=128 aklen=128 eklen=64
life(c,s,h)=addtime(2,0,0) natencap=none natsport=0 natdport=0 refcount=3
ref=9

DES is available:
# ipsec auto --status
000 interface ipsec0/eth1 172.16.3.2
000 interface ipsec0/eth1 172.16.3.2
000 %myid = (none)
000 debug none
000
000 algorithm ESP encrypt: id=2, name=ESP_DES, ivlen=64, keysizemin=64,
keysizemax=64.
...
000 algorithm IKE encrypt: id=1, name=OAKLEY_DES_CBC, blocksize=8,
keydeflen=64

Any clue?

Thanks for you time.

Regards
-hiren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090128/1e5fe04a/attachment.html 

From weirauch at checkmobile.de  Wed Jan 28 10:12:08 2009
From: weirauch at checkmobile.de (weirauch at checkmobile.de)
Date: Wed, 28 Jan 2009 16:12:08 +0100
Subject: [Openswan Users] ppp error: tty is not open yet
Message-ID: <OFBA8885DF.8FA85B6E-ONC125754C.00537087-C125754C.0053828E@checkmobile.de>

hi all,
I seem to miss something quite basic :-) trying now since 4 weeks to get 
the vpn up and running - the ipsec seems to work, the l2tp also gets up 
(at least thats how i interpret it), BUT the ppp is not coming up with its 
ppp0 device. since I have no integrated modem but run over a system with 2 
internal ethernet network cards, I am not getting how to set up the ppp 
daemon to produce correct ppp0 devices :-(
system: opensuse 11.0, kernel 2.6.25.18-0.2-default, l2tpd from Jacco de 
Leeuw. (I read through the whole mailing list, and found nothing except a 
fedora user with a similar problem in 2004. the solution was there to get 
some "character devices" configured within the kernel. but I have no idea 
of how to do that with suse...)
i start the ipsec, than the l2tp, but what to do with the ppp? is'nt that 
a process which is called by l2tpd? and how do I "teach" pppd to come up 
with a ppp0 device?? (10 years ago with old modems I knew I did it, but 
now, without any modems, I am lost, somewhat - and all the ppp how-to only 
explain the "modem"-case...)
anyone with any helpfull idea?
best regards,
philipp
philipp weirauch
hamburg, germany

ps: below the var/log/messages from the experimental server.
the client is a mac-book pro osx (but that does not seem to be of any 
problem, right?)

Jan 28 10:44:20 vpn l2tpd[8262]: check_control: control, cid = 0, Ns = 0, 
Nr = 0
Jan 28 10:44:20 vpn l2tpd[8262]: handle_avps: handling avp's for tunnel 
1435, call 0
Jan 28 10:44:20 vpn l2tpd[8262]: message_type_avp: message type 1 
(Start-Control-Connection-Request)
Jan 28 10:44:20 vpn l2tpd[8262]: protocol_version_avp: peer is using 
version 1, revision 0.
Jan 28 10:44:20 vpn l2tpd[8262]: framing_caps_avp: supported peer frames: 
async sync
Jan 28 10:44:20 vpn l2tpd[8262]: hostname_avp: peer reports hostname ''
Jan 28 10:44:20 vpn l2tpd[8262]: assigned_tunnel_avp: using peer's tunnel 
8
Jan 28 10:44:20 vpn l2tpd[8262]: receive_window_size_avp: peer wants RWS 
of 4.  Will use flow control.
Jan 28 10:44:20 vpn l2tpd[8262]: check_control: control, cid = 0, Ns = 1, 
Nr = 1
Jan 28 10:44:20 vpn l2tpd[8262]: handle_avps: handling avp's for tunnel 
1435, call 0
Jan 28 10:44:20 vpn l2tpd[8262]: message_type_avp: message type 3 
(Start-Control-Connection-Connected)
Jan 28 10:44:20 vpn l2tpd[8262]: control_finish: Connection established to 
85.182.252.146, 52011.  Local: 1435, Remote: 8.  LNS session is 'default'
Jan 28 10:44:20 vpn l2tpd[8262]: check_control: control, cid = 0, Ns = 2, 
Nr = 1
Jan 28 10:44:20 vpn l2tpd[8262]: handle_avps: handling avp's for tunnel 
1435, call 0
Jan 28 10:44:20 vpn l2tpd[8262]: message_type_avp: message type 10 
(Incoming-Call-Request)
Jan 28 10:44:20 vpn l2tpd[8262]: message_type_avp: new incoming call
Jan 28 10:44:20 vpn l2tpd[8262]: ourcid = 10644, entropy_buf = 2994
Jan 28 10:44:20 vpn l2tpd[8262]: assigned_call_avp: using peer's call 5018
Jan 28 10:44:20 vpn l2tpd[8262]: call_serno_avp: serial number is 1
Jan 28 10:44:20 vpn l2tpd[8262]: check_control: control, cid = 5018, Ns = 
3, Nr = 2
Jan 28 10:44:20 vpn l2tpd[8262]: handle_avps: handling avp's for tunnel 
1435, call 10644
Jan 28 10:44:20 vpn l2tpd[8262]: message_type_avp: message type 12 
(Incoming-Call-Connected)
Jan 28 10:44:20 vpn l2tpd[8262]: tx_speed_avp: transmit baud rate is 
1000000
Jan 28 10:44:20 vpn l2tpd[8262]: frame_type_avp: peer uses: async frames
Jan 28 10:44:20 vpn l2tpd[8262]: getPtyMaster: No more free pseudo-tty's
Jan 28 10:44:20 vpn l2tpd[8262]: start_pppd: unable to allocate pty, 
abandoning!
Jan 28 10:44:20 vpn l2tpd[8262]: control_finish: Call established with 
85.182.252.146, Local: 10644, Remote: 5018, Serial: 1

Jan 28 10:44:20 vpn l2tpd[8262]: write_packet: tty is not open yet.

Jan 28 10:44:20 vpn pluto[7812]: "L2TP-PSK-NAT"[2] 85.182.252.146 #2: 
transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Jan 28 10:44:20 vpn pluto[7812]: "L2TP-PSK-NAT"[2] 85.182.252.146 #2: 
STATE_QUICK_R2: IPsec SA established {ESP/NAT=>0x0dfeb849 <0xa94bd7f7 
xfrm=AES_128-HMAC_SHA1 NATD=85.182.252.146:4500 DPD=none}

Jan 28 10:44:23 vpn l2tpd[8262]: write_packet: tty is not open yet.

Jan 28 10:44:50 vpn syslog-ng[2251]: last message repeated 8 times
Jan 28 10:44:50 vpn l2tpd[8262]: check_control: control, cid = 5018, Ns = 
4, Nr = 2
Jan 28 10:44:50 vpn l2tpd[8262]: handle_avps: handling avp's for tunnel 
1435, call 10644
Jan 28 10:44:50 vpn l2tpd[8262]: message_type_avp: message type 14 
(Call-Disconnect-Notify)


From gohanman at gmail.com  Wed Jan 28 12:29:31 2009
From: gohanman at gmail.com (Andy Theuninck)
Date: Wed, 28 Jan 2009 11:29:31 -0600
Subject: [Openswan Users] Openswan 2.4.13 kills all non-IPSEC connections
Message-ID: <f8a02f3e0901280929i1f6bffaes9c81ef301811993e@mail.gmail.com>

I was trying to set up a nat-t on both ends connection w/ window
compatibility and ran into the bug described here:
http://bugs.xelerance.com/view.php?id=1004

The bug report suggests that using 2.4.13 will solve my problem (I'm
even using the same distro & kernel). So I compiled & installed
2.4.13. Now when I start up pluto, every single connection to the
server dies. I can't get SSH, HTTP, etc. I'm sure there's a simple
answer for this, but I can't come up with the right search terms to
get an answer out of google.

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

config setup
        protostack=netkey
        nat_traversal=yes
        virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.1.0/24

conn passthrough-for-non-l2tp
        type=passthrough
        left=%defaultroute
        right=0.0.0.0
        rightsubnet=0.0.0.0/0
        auto=route

conn road
        authby=secret
        pfs=no
        rekey=no
        keyingtries=3
        type=transport
        forceencaps=yes
        left=%defaultroute
        leftprotoport=17/1701
        right=%any
        rightsubnet=vhost:%no,%priv
        rightprotoport=17/%any
        auto=add

I have a passthrough; I'm excluding my local subnet from
virtual_private. What am I missing?

From paul at xelerance.com  Wed Jan 28 13:25:03 2009
From: paul at xelerance.com (Paul Wouters)
Date: Wed, 28 Jan 2009 13:25:03 -0500 (EST)
Subject: [Openswan Users] manual keying: encryption-only connection with
 DES
In-Reply-To: <29820bf40901280708v2e56c027o6331af2296ae8e0e@mail.gmail.com>
References: <29820bf40901280708v2e56c027o6331af2296ae8e0e@mail.gmail.com>
Message-ID: <alpine.LFD.1.10.0901281323070.13986@newtla.xelerance.com>

On Wed, 28 Jan 2009, hiren joshi wrote:

> Date: Wed, 28 Jan 2009 20:38:05 +0530
> From: hiren joshi <joshihirenn at gmail.com>
> To: users at openswan.org
> Subject: [Openswan Users] manual keying: encryption-only connection with DES
> 
> Hello,
> 
> I tried to setup a manually keyed encryption-only connection with DES
> (for compatibility reasons).
> But failed.

Did you set USE_WEAKSTUFF=true and USE_NOCRYPTO=true in Makefile.inc ?

Though really, I'm tempted to again rip out all of 1DES. It was unsafe
5 years ago, it is even more unsafe now.

Paul

From paul at xelerance.com  Wed Jan 28 13:26:30 2009
From: paul at xelerance.com (Paul Wouters)
Date: Wed, 28 Jan 2009 13:26:30 -0500 (EST)
Subject: [Openswan Users] Openswan 2.4.13 kills all non-IPSEC connections
In-Reply-To: <f8a02f3e0901280929i1f6bffaes9c81ef301811993e@mail.gmail.com>
References: <f8a02f3e0901280929i1f6bffaes9c81ef301811993e@mail.gmail.com>
Message-ID: <alpine.LFD.1.10.0901281325490.13986@newtla.xelerance.com>

On Wed, 28 Jan 2009, Andy Theuninck wrote:

> The bug report suggests that using 2.4.13 will solve my problem (I'm
> even using the same distro & kernel). So I compiled & installed
> 2.4.13. Now when I start up pluto, every single connection to the
> server dies. I can't get SSH, HTTP, etc. I'm sure there's a simple
> answer for this, but I can't come up with the right search terms to
> get an answer out of google.

include /etc/ipsec.d/examples/no_oe.conf

Paul

From openswan at in-put.de  Wed Jan 28 13:35:23 2009
From: openswan at in-put.de (Stefan Guenther)
Date: Wed, 28 Jan 2009 19:35:23 +0100
Subject: [Openswan Users] Openswan uses only the last defined connection
Message-ID: <4980A56B.3040301@in-put.de>

Hi,

we are currently using Openswan 2.4.7 on openSUSE 11.0 (X86-64).
The ipsec.conf looks as follows:

version 2.0
config setup
	interfaces=%defaultroute
	klipsdebug=none
	plutodebug=none
	uniqueids=no
	forwardcontrol=yes

conn %default
	keyingtries=3
	disablearrivalcheck=yes
	type=tunnel
	pfs=yes
	authby=secret
	keyexchange=ike
	left=217.7.231.XX
	leftsubnet=192.168.0.0/24
	leftid=217.7.231.XX


conn user1
	right=%any
	rightsubnet=192.168.2.130/32
	rightid=@user1.firma.de

conn user2
	rightid=@user2.firma.de
	rightsubnet=192.168.2.129/32

include /etc/ipsec.d/examples/no_oe.conf



And here is the /etc/ipsec.secrets:

217.7.231.xx @user1.firma.de: PSK "dummy1"
217.7.231.xx @user2.firma.de: PSK "dummy1"
#217.7.231.xx %any: PSK "dummy1"

There are no error messages when I start ipsec.
We use the Greenbow VPN client to connect to this gateway, but I can 
only use the details for connection user2 and this only works, when I 
remove the # from the last line of ipsec.secrets.

If I use the rightid and ip for connection user1, I get the following 
error messages:

#1: Main mode peer ID is ID_FQDN: '@user1.firma.de'
#1: no suitable connection for peer '@user1.firma.de'

But when I remove connection user2 the connection for user1 works perfectly.

This isn't my first ipsec configuration, but I'm completely confused, 
what's wrong with this configuration??

Thanks for any help or hint.

Stefan

From petermcgill at goco.net  Wed Jan 28 13:57:59 2009
From: petermcgill at goco.net (Peter McGill)
Date: Wed, 28 Jan 2009 13:57:59 -0500
Subject: [Openswan Users] Openswan uses only the last defined connection
In-Reply-To: <4980A56B.3040301@in-put.de>
References: <4980A56B.3040301@in-put.de>
Message-ID: <AECF97259D034AD79C26D2070BFAE0FE@peter>

When using PSKs and road warriors (right=%any) all connections must use the same PSK.
PSKs cannot be defined by id in the secrets file, they must use IP address (or %any).
This is because the PSK is sent before the id, so it doesn't know which PSK to compare
to except by IP address.

You can solve this by using RSA keys instead of PSKs which is more secure anyway.
With RSA keys the id is sent with the key and the whole problem is avoided.
RSA keys are the default for Openswan. See doc/install.html and doc/config.html,
ipsec newhostkey and ipsec showhostkey for details on using RSA keys.

I believe it is also possible to pass the id with PSKs with aggressive mode, but
as this weakens your security further, I don't recommend it.

Peter McGill
IT Systems Analyst
Gra Ham Energy Limited 

> -----Original Message-----
> From: users-bounces at openswan.org 
> [mailto:users-bounces at openswan.org] On Behalf Of Stefan Guenther
> Sent: January 28, 2009 1:35 PM
> To: users at openswan.org
> Subject: [Openswan Users] Openswan uses only the last defined 
> connection
> 
> Hi,
> 
> we are currently using Openswan 2.4.7 on openSUSE 11.0 (X86-64).
> The ipsec.conf looks as follows:
> 
> version 2.0
> config setup
> 	interfaces=%defaultroute
> 	klipsdebug=none
> 	plutodebug=none
> 	uniqueids=no
> 	forwardcontrol=yes
> 
> conn %default
> 	keyingtries=3
> 	disablearrivalcheck=yes
> 	type=tunnel
> 	pfs=yes
> 	authby=secret
> 	keyexchange=ike
> 	left=217.7.231.XX
> 	leftsubnet=192.168.0.0/24
> 	leftid=217.7.231.XX
> 
> 
> conn user1
> 	right=%any
> 	rightsubnet=192.168.2.130/32
> 	rightid=@user1.firma.de
> 
> conn user2
> 	rightid=@user2.firma.de
> 	rightsubnet=192.168.2.129/32
> 
> include /etc/ipsec.d/examples/no_oe.conf
> 
> 
> 
> And here is the /etc/ipsec.secrets:
> 
> 217.7.231.xx @user1.firma.de: PSK "dummy1"
> 217.7.231.xx @user2.firma.de: PSK "dummy1"
> #217.7.231.xx %any: PSK "dummy1"
> 
> There are no error messages when I start ipsec.
> We use the Greenbow VPN client to connect to this gateway, but I can 
> only use the details for connection user2 and this only works, when I 
> remove the # from the last line of ipsec.secrets.
> 
> If I use the rightid and ip for connection user1, I get the following 
> error messages:
> 
> #1: Main mode peer ID is ID_FQDN: '@user1.firma.de'
> #1: no suitable connection for peer '@user1.firma.de'
> 
> But when I remove connection user2 the connection for user1 
> works perfectly.
> 
> This isn't my first ipsec configuration, but I'm completely confused, 
> what's wrong with this configuration??
> 
> Thanks for any help or hint.
> 
> Stefan
> _______________________________________________
> 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-294632
> 7?n=283155


From gohanman at gmail.com  Wed Jan 28 22:50:47 2009
From: gohanman at gmail.com (Andy Theuninck)
Date: Wed, 28 Jan 2009 21:50:47 -0600
Subject: [Openswan Users] NAT on both sides
In-Reply-To: <31da51d50901272236g19c07b2tbe0a519bdf8d855d@mail.gmail.com>
References: <f8a02f3e0901261711q69886363qe7e4030bb67e91d6@mail.gmail.com>
	<f8a02f3e0901271952h7d04090ejf8d4403d822fb3ce@mail.gmail.com>
	<31da51d50901272236g19c07b2tbe0a519bdf8d855d@mail.gmail.com>
Message-ID: <f8a02f3e0901281950j2e9ba032rb8b38983c8de7008@mail.gmail.com>

OK, I've got it. I was running into a documented bug with 2.6.x
versions of openswan, so I compiled 2.4.13 from openswan.org to
replace it.

I ended up with this server configuration:
version 2.0     # conforms to second version of ipsec.conf specification

config setup
        protostack=netkey
        nat_traversal=yes
        virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.1.0/24

conn passthrough-for-non-l2tp
        type=passthrough
        left=192.168.1.2
        leftnexthop=192.168.1.254
        right=0.0.0.0
        rightsubnet=0.0.0.0/0
        auto=route

conn road
        authby=secret
        pfs=no
        rekey=no
        keyingtries=3
        type=transport
        forceencaps=yes
        left=192.168.1.2
        leftnexthop=192.168.1.254
        leftprotoport=17/1701
        right=%any
        rightsubnet=vhost:%no,%priv
        rightprotoport=17/%any
        auto=add

# disable opportunistic nonsense
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

Differences from before:
Those auto=ignore sections are necessary or pluto will gobble up all
incoming connections. Version 2.4.13 also gives errors on start up if
there is vertical whitespace within a connection section (although
comment lines interleaved are fine). I had to use left + leftnexthop
instead of %defaultroute to make both connections work. I haven't
tried an OS X client yet, but that's why forceencaps is there.
Passthrough seems to behave nicely; I can connect simultaneously by
VPN and SSH.

My xl2tpd config is extremely vanilla. I had to tweak my iptables
setup too, but that's probably not a normal set up (my VPN server
happens to also be routing traffic on 4 separate subnets).

On Wed, Jan 28, 2009 at 12:36 AM, andrew colin <andrew.colin at gmail.com> wrote:
> Please let me know if you get it working with a windows client.
>

From andrew.colin at gmail.com  Thu Jan 29 04:11:58 2009
From: andrew.colin at gmail.com (andrew colin)
Date: Thu, 29 Jan 2009 11:11:58 +0200
Subject: [Openswan Users] NAT on both sides
In-Reply-To: <f8a02f3e0901281950j2e9ba032rb8b38983c8de7008@mail.gmail.com>
References: <f8a02f3e0901261711q69886363qe7e4030bb67e91d6@mail.gmail.com>
	<f8a02f3e0901271952h7d04090ejf8d4403d822fb3ce@mail.gmail.com>
	<31da51d50901272236g19c07b2tbe0a519bdf8d855d@mail.gmail.com>
	<f8a02f3e0901281950j2e9ba032rb8b38983c8de7008@mail.gmail.com>
Message-ID: <31da51d50901290111o7f949b06lec592a8b0d0db6d7@mail.gmail.com>

Thanks mate, i will test that did you build an RPM that you can share
our just pristine source ?


On Thu, Jan 29, 2009 at 5:50 AM, Andy Theuninck <gohanman at gmail.com> wrote:
> OK, I've got it. I was running into a documented bug with 2.6.x
> versions of openswan, so I compiled 2.4.13 from openswan.org to
> replace it.
>
> I ended up with this server configuration:
> version 2.0     # conforms to second version of ipsec.conf specification
>
> config setup
>        protostack=netkey
>        nat_traversal=yes
>        virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.1.0/24
>
> conn passthrough-for-non-l2tp
>        type=passthrough
>        left=192.168.1.2
>        leftnexthop=192.168.1.254
>        right=0.0.0.0
>        rightsubnet=0.0.0.0/0
>        auto=route
>
> conn road
>        authby=secret
>        pfs=no
>        rekey=no
>        keyingtries=3
>        type=transport
>        forceencaps=yes
>        left=192.168.1.2
>        leftnexthop=192.168.1.254
>        leftprotoport=17/1701
>        right=%any
>        rightsubnet=vhost:%no,%priv
>        rightprotoport=17/%any
>        auto=add
>
> # disable opportunistic nonsense
> 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
>
> Differences from before:
> Those auto=ignore sections are necessary or pluto will gobble up all
> incoming connections. Version 2.4.13 also gives errors on start up if
> there is vertical whitespace within a connection section (although
> comment lines interleaved are fine). I had to use left + leftnexthop
> instead of %defaultroute to make both connections work. I haven't
> tried an OS X client yet, but that's why forceencaps is there.
> Passthrough seems to behave nicely; I can connect simultaneously by
> VPN and SSH.
>
> My xl2tpd config is extremely vanilla. I had to tweak my iptables
> setup too, but that's probably not a normal set up (my VPN server
> happens to also be routing traffic on 4 separate subnets).
>
> On Wed, Jan 28, 2009 at 12:36 AM, andrew colin <andrew.colin at gmail.com> wrote:
>> Please let me know if you get it working with a windows client.
>>
>



-- 
"Dru"
To follow the path, look to the master, follow the master, walk with
the master, see through the master, become the master. (zen)
http://www.topdog.za.net/

From cioban at gmail.com  Thu Jan 29 07:09:55 2009
From: cioban at gmail.com (Sergio Cioban Filho)
Date: Thu, 29 Jan 2009 10:09:55 -0200
Subject: [Openswan Users] KLIPS compile problems with kernel 2.6.28.1
Message-ID: <f18571170901290409s2645874bhe082c38894b87a94@mail.gmail.com>

Hi all,

I'm trying to compile openswan with KLIPS on CentOS 5.2 with kernel
2.6.28.1, but I have problems.

With openswan-2.4.13, I got this problem:
*make[2]: Entrando no diret?rio `/usr/src/linux-2.6.28.1'
  CC [M]  /usr/src/redhat/BUILD/openswan-2.4.13/modobj26/ipsec_init.o
In file included from
/usr/src/redhat/BUILD/openswan-2.4.13/modobj26/ipsec_init.c:85:
/usr/src/redhat/BUILD/openswan-2.4.13/linux/include/openswan/ipsec_esp.h:52:
error: expected specifier-qualifier-list before 'des_key_schedule'
/usr/src/redhat/BUILD/openswan-2.4.13/modobj26/ipsec_init.c: In function
'ipsec_cleanup':
/usr/src/redhat/BUILD/openswan-2.4.13/modobj26/ipsec_init.c:274: error: too
few arguments to function 'udp4_unregister_esp_rcvencap'
make[3]: ** [/usr/src/redhat/BUILD/openswan-2.4.13/modobj26/ipsec_init.o]
Erro 1
make[2]: ** [_module_/usr/src/redhat/BUILD/openswan-2.4.13/modobj26] Erro 2
make[2]: Saindo do diret?rio `/usr/src/linux-2.6.28.1'
make[1]: ** [module26] Erro 2
make[1]: Saindo do diret?rio `/usr/src/redhat/BUILD/openswan-2.4.13'
make: ** [module] Erro 2*



With openswan-2.6.19, I got this problem:
*make[2]: Entrando no diret?rio `/usr/src/linux-2.6.28.1'
  CC [M]  /usr/src/openswan-2.6.19/modobj26/ipsec_init.o
In file included from /usr/src/openswan-2.6.19/modobj26/ipsec_init.c:57:
include/net/ip.h: In function 'ip_hdrlen':
include/net/ip.h:50: error: 'const struct sk_buff' has no member named 'nh'
/usr/src/openswan-2.6.19/modobj26/ipsec_init.c: In function 'ipsec_cleanup':
/usr/src/openswan-2.6.19/modobj26/ipsec_init.c:360: error: too few arguments
to function 'udp4_unregister_esp_rcvencap'
make[3]: ** [/usr/src/openswan-2.6.19/modobj26/ipsec_init.o] Erro 1
make[2]: ** [_module_/usr/src/openswan-2.6.19/modobj26] Erro 2
make[2]: Saindo do diret?rio `/usr/src/linux-2.6.28.1'
make[1]: ** [module26] Erro 2
make[1]: Saindo do diret?rio `/usr/src/openswan-2.6.19'
make: ** [module] Erro 2
*

I'm trying to compile with *make  KERNELSRC=/usr/src/linux-2.6.28.1/
programs module*



Thanks,
Regards,
---
S?rgio Cioban Filho
| Tecn?logo em Gest?o de TI
| Linux Professional Institute Certified - Level 1
------------------------------------------------------------
| Linux - Servidores - Firewall - VPN
| Virtualiza??o - VoIP - ShellScript - C - PHP
| http://cioban.googlepages.com
| +55 48 9989-8733
------------------------------------------------------------
..:: Seja livre, use LiNuX!! ::..
------------------------------------------------------------
Vendo GOL G3 PLUS 1.0 8V 4P 2002 - Branco - COMPLET?SSIMO - R$ 19.500
http://cioban.googlepages.com/vendogolg38v
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090129/fbaf046e/attachment.html 

From andrew.colin at gmail.com  Thu Jan 29 07:48:25 2009
From: andrew.colin at gmail.com (andrew colin)
Date: Thu, 29 Jan 2009 14:48:25 +0200
Subject: [Openswan Users] NAT on both sides
In-Reply-To: <31da51d50901290111o7f949b06lec592a8b0d0db6d7@mail.gmail.com>
References: <f8a02f3e0901261711q69886363qe7e4030bb67e91d6@mail.gmail.com>
	<f8a02f3e0901271952h7d04090ejf8d4403d822fb3ce@mail.gmail.com>
	<31da51d50901272236g19c07b2tbe0a519bdf8d855d@mail.gmail.com>
	<f8a02f3e0901281950j2e9ba032rb8b38983c8de7008@mail.gmail.com>
	<31da51d50901290111o7f949b06lec592a8b0d0db6d7@mail.gmail.com>
Message-ID: <31da51d50901290448h7e36a30as8ed5cfa4d217f0aa@mail.gmail.com>

Hi All,


I have got it working with 2.4.13, I have noticed how ever that this
setup introduces a security problem
with l2tpd if using NETKEY

The l2tpd connection that comes out of the tunnel has a destination ip
of the servers interface, which
means you have to allow connections to port 1701 from any where if it
is to work.

If you have a dumb ass router siting infront of the openswan server
that does not have the option to
forward protocol ESP (meaning you forward everthing to the server),
your l2tpd daemon then
becomes exposed to the world.

KLIPS would be a better option here as it creates the ipsecX
interfaces to which you can apply
filtering rules.

I

On Thu, Jan 29, 2009 at 11:11 AM, andrew colin <andrew.colin at gmail.com> wrote:
> Thanks mate, i will test that did you build an RPM that you can share
> our just pristine source ?
>
>
> On Thu, Jan 29, 2009 at 5:50 AM, Andy Theuninck <gohanman at gmail.com> wrote:
>> OK, I've got it. I was running into a documented bug with 2.6.x
>> versions of openswan, so I compiled 2.4.13 from openswan.org to
>> replace it.
>>
>> I ended up with this server configuration:
>> version 2.0     # conforms to second version of ipsec.conf specification
>>
>> config setup
>>        protostack=netkey
>>        nat_traversal=yes
>>        virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.1.0/24
>>
>> conn passthrough-for-non-l2tp
>>        type=passthrough
>>        left=192.168.1.2
>>        leftnexthop=192.168.1.254
>>        right=0.0.0.0
>>        rightsubnet=0.0.0.0/0
>>        auto=route
>>
>> conn road
>>        authby=secret
>>        pfs=no
>>        rekey=no
>>        keyingtries=3
>>        type=transport
>>        forceencaps=yes
>>        left=192.168.1.2
>>        leftnexthop=192.168.1.254
>>        leftprotoport=17/1701
>>        right=%any
>>        rightsubnet=vhost:%no,%priv
>>        rightprotoport=17/%any
>>        auto=add
>>
>> # disable opportunistic nonsense
>> 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
>>
>> Differences from before:
>> Those auto=ignore sections are necessary or pluto will gobble up all
>> incoming connections. Version 2.4.13 also gives errors on start up if
>> there is vertical whitespace within a connection section (although
>> comment lines interleaved are fine). I had to use left + leftnexthop
>> instead of %defaultroute to make both connections work. I haven't
>> tried an OS X client yet, but that's why forceencaps is there.
>> Passthrough seems to behave nicely; I can connect simultaneously by
>> VPN and SSH.
>>
>> My xl2tpd config is extremely vanilla. I had to tweak my iptables
>> setup too, but that's probably not a normal set up (my VPN server
>> happens to also be routing traffic on 4 separate subnets).
>>
>> On Wed, Jan 28, 2009 at 12:36 AM, andrew colin <andrew.colin at gmail.com> wrote:
>>> Please let me know if you get it working with a windows client.
>>>
>>
>
>
>
> --
> "Dru"
> To follow the path, look to the master, follow the master, walk with
> the master, see through the master, become the master. (zen)
> http://www.topdog.za.net/
>



-- 
"Dru"
To follow the path, look to the master, follow the master, walk with
the master, see through the master, become the master. (zen)
http://www.topdog.za.net/

From petermcgill at goco.net  Thu Jan 29 08:28:26 2009
From: petermcgill at goco.net (Peter McGill)
Date: Thu, 29 Jan 2009 08:28:26 -0500
Subject: [Openswan Users] NAT on both sides
In-Reply-To: <31da51d50901290448h7e36a30as8ed5cfa4d217f0aa@mail.gmail.com>
References: <f8a02f3e0901261711q69886363qe7e4030bb67e91d6@mail.gmail.com>	<f8a02f3e0901271952h7d04090ejf8d4403d822fb3ce@mail.gmail.com>	<31da51d50901272236g19c07b2tbe0a519bdf8d855d@mail.gmail.com>	<f8a02f3e0901281950j2e9ba032rb8b38983c8de7008@mail.gmail.com>	<31da51d50901290111o7f949b06lec592a8b0d0db6d7@mail.gmail.com>
	<31da51d50901290448h7e36a30as8ed5cfa4d217f0aa@mail.gmail.com>
Message-ID: <4981AEFA.2080007@goco.net>

You can solve this on your Openswan machine by marking incomming IPSec 
packets with iptables, the mark is preserved when the packet is 
decrypted and reinserted, then you can allow marked packets for l2tp, 
etc... but drop unmarked ones for security. Read man iptables for details.

Peter

andrew colin wrote:
> Hi All,
> 
> 
> I have got it working with 2.4.13, I have noticed how ever that this
> setup introduces a security problem
> with l2tpd if using NETKEY
> 
> The l2tpd connection that comes out of the tunnel has a destination ip
> of the servers interface, which
> means you have to allow connections to port 1701 from any where if it
> is to work.
> 
> If you have a dumb ass router siting infront of the openswan server
> that does not have the option to
> forward protocol ESP (meaning you forward everthing to the server),
> your l2tpd daemon then
> becomes exposed to the world.
> 
> KLIPS would be a better option here as it creates the ipsecX
> interfaces to which you can apply
> filtering rules.
> 
> I
> 
> On Thu, Jan 29, 2009 at 11:11 AM, andrew colin <andrew.colin at gmail.com> wrote:
>> Thanks mate, i will test that did you build an RPM that you can share
>> our just pristine source ?
>>
>>
>> On Thu, Jan 29, 2009 at 5:50 AM, Andy Theuninck <gohanman at gmail.com> wrote:
>>> OK, I've got it. I was running into a documented bug with 2.6.x
>>> versions of openswan, so I compiled 2.4.13 from openswan.org to
>>> replace it.
>>>
>>> I ended up with this server configuration:
>>> version 2.0     # conforms to second version of ipsec.conf specification
>>>
>>> config setup
>>>        protostack=netkey
>>>        nat_traversal=yes
>>>        virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.1.0/24
>>>
>>> conn passthrough-for-non-l2tp
>>>        type=passthrough
>>>        left=192.168.1.2
>>>        leftnexthop=192.168.1.254
>>>        right=0.0.0.0
>>>        rightsubnet=0.0.0.0/0
>>>        auto=route
>>>
>>> conn road
>>>        authby=secret
>>>        pfs=no
>>>        rekey=no
>>>        keyingtries=3
>>>        type=transport
>>>        forceencaps=yes
>>>        left=192.168.1.2
>>>        leftnexthop=192.168.1.254
>>>        leftprotoport=17/1701
>>>        right=%any
>>>        rightsubnet=vhost:%no,%priv
>>>        rightprotoport=17/%any
>>>        auto=add
>>>
>>> # disable opportunistic nonsense
>>> 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
>>>
>>> Differences from before:
>>> Those auto=ignore sections are necessary or pluto will gobble up all
>>> incoming connections. Version 2.4.13 also gives errors on start up if
>>> there is vertical whitespace within a connection section (although
>>> comment lines interleaved are fine). I had to use left + leftnexthop
>>> instead of %defaultroute to make both connections work. I haven't
>>> tried an OS X client yet, but that's why forceencaps is there.
>>> Passthrough seems to behave nicely; I can connect simultaneously by
>>> VPN and SSH.
>>>
>>> My xl2tpd config is extremely vanilla. I had to tweak my iptables
>>> setup too, but that's probably not a normal set up (my VPN server
>>> happens to also be routing traffic on 4 separate subnets).
>>>
>>> On Wed, Jan 28, 2009 at 12:36 AM, andrew colin <andrew.colin at gmail.com> wrote:
>>>> Please let me know if you get it working with a windows client.
>>>>
>>
>>
>> --
>> "Dru"
>> To follow the path, look to the master, follow the master, walk with
>> the master, see through the master, become the master. (zen)
>> http://www.topdog.za.net/
>>
> 
> 
> 

From joshihirenn at gmail.com  Thu Jan 29 10:01:32 2009
From: joshihirenn at gmail.com (hiren joshi)
Date: Thu, 29 Jan 2009 20:31:32 +0530
Subject: [Openswan Users] manual keying: encryption-only connection with
	DES
In-Reply-To: <alpine.LFD.1.10.0901281323070.13986@newtla.xelerance.com>
References: <29820bf40901280708v2e56c027o6331af2296ae8e0e@mail.gmail.com>
	<alpine.LFD.1.10.0901281323070.13986@newtla.xelerance.com>
Message-ID: <29820bf40901290701s15cb3dadv7ec29cf51814c9d1@mail.gmail.com>

I solved this in openswan-2.4.9 with the following:

--- programs/spi/spi.c.orig     Sun Jan 18 05:48:16 2009
+++ programs/spi/spi.c  Sun Jan 18 05:48:41 2009
@@ -420,7 +420,7 @@ int decode_esp(char *algname)
   } else if(!strcmp(algname, "3des")) {
     esp_alg = XF_ESP3DES;
 #ifdef KERNEL_ALG
-  } else if((alg_info=alg_info_esp_create_from_str(algname, &alg_err,
FALSE))) {
+  } else if((alg_info=alg_info_esp_create_from_str(algname, &alg_err,
TRUE))) {
     int esp_ealg_id, esp_aalg_id;

     esp_alg = XF_OTHER_ALG;

Does it look okay?

Thanks for you time.

Regards,
-hiren

On Wed, Jan 28, 2009 at 11:55 PM, Paul Wouters <paul at xelerance.com> wrote:

> On Wed, 28 Jan 2009, hiren joshi wrote:
>
>  Date: Wed, 28 Jan 2009 20:38:05 +0530
>> From: hiren joshi <joshihirenn at gmail.com>
>> To: users at openswan.org
>> Subject: [Openswan Users] manual keying: encryption-only connection with
>> DES
>>
>> Hello,
>>
>> I tried to setup a manually keyed encryption-only connection with DES
>> (for compatibility reasons).
>> But failed.
>>
>
> Did you set USE_WEAKSTUFF=true and USE_NOCRYPTO=true in Makefile.inc ?
>
> Though really, I'm tempted to again rip out all of 1DES. It was unsafe
> 5 years ago, it is even more unsafe now.
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090129/d42a3c34/attachment.html 

From joshihirenn at gmail.com  Thu Jan 29 10:08:45 2009
From: joshihirenn at gmail.com (hiren joshi)
Date: Thu, 29 Jan 2009 20:38:45 +0530
Subject: [Openswan Users] _updown called with wrong PLUTO_VERB
Message-ID: <29820bf40901290708m14723822ib4c0c79390aad25@mail.gmail.com>

Hello,

When I manually make the following connection up (ipsec manual --up
manual_keying),
_updown script is being called with PLUTO_VERB="up-host" instead of
PLUTO_VERB="up-client".

config setup
        interfaces="ipsec0=eth1 "
        klipsdebug=none
        plutodebug="none"
        uniqueids=no
        nat_traversal=yes
        crlcheckinterval=3600
        nhelpers=0

conn %default
        leftupdown=/usr/lib/ipsec/_updown
        rightupdown=/usr/lib/ipsec/_updown

conn manual_keying
        leftsubnet=192.168.3.0/24
        rightsubnet=192.168.2.0/24
        type=tunnel
        left=172.16.3.2
        leftnexthop=172.16.3.1
        right=172.16.1.11
        spi=0x100
        leftespspi=0x1111
        rightespspi=0x2222
        esp=des
        leftespenckey=0x0123456789012345
        rightespenckey=0x9876543210987654

Any clue?

Thanks for your time.

Regards,
hiren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090129/6230f4ed/attachment-0001.html 

From gohanman at gmail.com  Thu Jan 29 10:17:51 2009
From: gohanman at gmail.com (Andy Theuninck)
Date: Thu, 29 Jan 2009 09:17:51 -0600
Subject: [Openswan Users] NAT on both sides
In-Reply-To: <31da51d50901290448h7e36a30as8ed5cfa4d217f0aa@mail.gmail.com>
References: <f8a02f3e0901261711q69886363qe7e4030bb67e91d6@mail.gmail.com>
	<f8a02f3e0901271952h7d04090ejf8d4403d822fb3ce@mail.gmail.com>
	<31da51d50901272236g19c07b2tbe0a519bdf8d855d@mail.gmail.com>
	<f8a02f3e0901281950j2e9ba032rb8b38983c8de7008@mail.gmail.com>
	<31da51d50901290111o7f949b06lec592a8b0d0db6d7@mail.gmail.com>
	<31da51d50901290448h7e36a30as8ed5cfa4d217f0aa@mail.gmail.com>
Message-ID: <f8a02f3e0901290717h7ad4efa6neb569d19efddd053@mail.gmail.com>

Wasn't the whole point here to deal with a NAT device in front of the
server? So long as that NAT device is explicitly dropping 1701, isn't
it more or less irrelevant what iptables does on the server? Packets
that get through have to either originate locally or come through the
tunnel.

I did build RPMs, actually:
http://gohanman.com/rpm/CentOS5/RPMS/i386/openswan-2.4.13-1.1.i386.rpm
http://gohanman.com/rpm/CentOS5/SRPMS/openswan-2.4.13-1.1.src.rpm

Built on CentOS, most likely will work on RHEL, and probably Fedora,
too. I purposely removed one patch that messes up %defaultroute and
took off a couple others that wouldn't apply cleanly to 2.4.13 source.
So far I haven't had any problems.

On Thu, Jan 29, 2009 at 6:48 AM, andrew colin <andrew.colin at gmail.com> wrote:
> Hi All,
>
>
> I have got it working with 2.4.13, I have noticed how ever that this
> setup introduces a security problem
> with l2tpd if using NETKEY
>
> The l2tpd connection that comes out of the tunnel has a destination ip
> of the servers interface, which
> means you have to allow connections to port 1701 from any where if it
> is to work.
>
> If you have a dumb ass router siting infront of the openswan server
> that does not have the option to
> forward protocol ESP (meaning you forward everthing to the server),
> your l2tpd daemon then
> becomes exposed to the world.
>
> KLIPS would be a better option here as it creates the ipsecX
> interfaces to which you can apply
> filtering rules.
>
> I
>
> On Thu, Jan 29, 2009 at 11:11 AM, andrew colin <andrew.colin at gmail.com> wrote:
>> Thanks mate, i will test that did you build an RPM that you can share
>> our just pristine source ?
>>
>>
>> On Thu, Jan 29, 2009 at 5:50 AM, Andy Theuninck <gohanman at gmail.com> wrote:
>>> OK, I've got it. I was running into a documented bug with 2.6.x
>>> versions of openswan, so I compiled 2.4.13 from openswan.org to
>>> replace it.
>>>
>>> I ended up with this server configuration:
>>> version 2.0     # conforms to second version of ipsec.conf specification
>>>
>>> config setup
>>>        protostack=netkey
>>>        nat_traversal=yes
>>>        virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.1.0/24
>>>
>>> conn passthrough-for-non-l2tp
>>>        type=passthrough
>>>        left=192.168.1.2
>>>        leftnexthop=192.168.1.254
>>>        right=0.0.0.0
>>>        rightsubnet=0.0.0.0/0
>>>        auto=route
>>>
>>> conn road
>>>        authby=secret
>>>        pfs=no
>>>        rekey=no
>>>        keyingtries=3
>>>        type=transport
>>>        forceencaps=yes
>>>        left=192.168.1.2
>>>        leftnexthop=192.168.1.254
>>>        leftprotoport=17/1701
>>>        right=%any
>>>        rightsubnet=vhost:%no,%priv
>>>        rightprotoport=17/%any
>>>        auto=add
>>>
>>> # disable opportunistic nonsense
>>> 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
>>>
>>> Differences from before:
>>> Those auto=ignore sections are necessary or pluto will gobble up all
>>> incoming connections. Version 2.4.13 also gives errors on start up if
>>> there is vertical whitespace within a connection section (although
>>> comment lines interleaved are fine). I had to use left + leftnexthop
>>> instead of %defaultroute to make both connections work. I haven't
>>> tried an OS X client yet, but that's why forceencaps is there.
>>> Passthrough seems to behave nicely; I can connect simultaneously by
>>> VPN and SSH.
>>>
>>> My xl2tpd config is extremely vanilla. I had to tweak my iptables
>>> setup too, but that's probably not a normal set up (my VPN server
>>> happens to also be routing traffic on 4 separate subnets).
>>>
>>> On Wed, Jan 28, 2009 at 12:36 AM, andrew colin <andrew.colin at gmail.com> wrote:
>>>> Please let me know if you get it working with a windows client.
>>>>
>>>
>>
>>
>>
>> --
>> "Dru"
>> To follow the path, look to the master, follow the master, walk with
>> the master, see through the master, become the master. (zen)
>> http://www.topdog.za.net/
>>
>
>
>
> --
> "Dru"
> To follow the path, look to the master, follow the master, walk with
> the master, see through the master, become the master. (zen)
> http://www.topdog.za.net/
>

From awilliam at whitemice.org  Thu Jan 29 11:13:36 2009
From: awilliam at whitemice.org (Adam Tauno Williams)
Date: Thu, 29 Jan 2009 11:13:36 -0500
Subject: [Openswan Users] OpenSWAN (CentOS) <--> Cisco IOS 2600
Message-ID: <1233245616.5409.52.camel@linux-nnci.site>

I have an CentOS5 host (2.6.18-92.1.22.el5 32bit /
openswan-2.6.14-1.el5_2.1) I'm trying to pair with a Cisco 2600
(C2600-IK9O3S3-M, 12.3(19)-fc2).  The OpenSWAN side I think is OK,  but
I'm a bit hazy on what exactly the IOS side should look like;  I've
found allot of information about OpenSWAN+PIX, but not so much about
OpenSWAN+IOS.

Does anyone have an example/skelton IOS configuration they can share?
I'm currently just using a pre-shared key.


From denis.beltramo at gmail.com  Thu Jan 29 12:01:21 2009
From: denis.beltramo at gmail.com (Denis Beltramo)
Date: Thu, 29 Jan 2009 18:01:21 +0100
Subject: [Openswan Users] Problem with PSK - Certificate and iphone
Message-ID: <27f0c3e40901290901w518d1d7es5976271bc22f2885@mail.gmail.com>

Hello,

I have many problem with openswan.

I have now the iPhone.. so I have make the connection for this (see below)..
When i connect with mobile card (my iphone have a public ip) work,
when connect with a wireless behind nat NOT work
when connect with a windows xp behind nat to roadwarrior-iphone work.
the error is:

an 23 20:14:05 vpnserver pluto[10098]: "roadwarrior-iphone"[2]
11.22.33.44 #1: STATE_MAIN_R3: sent MR3, ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
group=modp1024}
Jan 23 20:14:05 vpnserver pluto[10098]: "roadwarrior-iphone"[2]
11.22.33.44 #1: ignoring informational payload, type
IPSEC_INITIAL_CONTACT
Jan 23 20:14:05 vpnserver pluto[10098]: "roadwarrior-iphone"[2]
11.22.33.44 #1: received and ignored informational message
Jan 23 20:14:06 vpnserver pluto[10098]: "roadwarrior-iphone"[2]
11.22.33.44 #1: cannot respond to IPsec SA request because no
connection is known for
123.123.123.124:17/1701...11.22.33.44[192.168.2.13]:17/49156===192.168.2.13/32
Jan 23 20:14:06 vpnserver pluto[10098]: "roadwarrior-iphone"[2]
11.22.33.44 #1: sending encrypted notification INVALID_ID_INFORMATION
to 11.22.33.44:36071

The the old connection (roadwarrior) with certificate don't work and say:

an 29 17:05:27 vpnserver pluto[6105]: "roadwarrior"[26] 22.43.21.44
#36: Dead Peer Detection (RFC 3706): not enabled because peer did not
advertise it
Jan 29 17:05:27 vpnserver pluto[6105]: "roadwarrior"[26] 22.43.21.44
#36: retransmitting in response to duplicate packet; already
STATE_MAIN_R3
Jan 29 17:05:27 vpnserver pluto[6105]: "roadwarrior"[26] 22.43.21.44
#37: responding to Quick Mode {msgid:6a15fc54}
Jan 29 17:05:27 vpnserver pluto[6105]: "roadwarrior"[26] 22.43.21.44
#37: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Jan 29 17:05:27 vpnserver pluto[6105]: "roadwarrior"[26] 22.43.21.44
#37: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting
QI2
Jan 29 17:05:28 vpnserver pluto[6105]: "roadwarrior"[26] 22.43.21.44
#37: Dead Peer Detection (RFC 3706): not enabled because peer did not
advertise it
Jan 29 17:05:28 vpnserver pluto[6105]: "roadwarrior"[26] 22.43.21.44
#37: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Jan 29 17:05:28 vpnserver pluto[6105]: "roadwarrior"[26] 22.43.21.44
#37: STATE_QUICK_R2: IPsec SA established {ESP/NAT=>0x00f59a30
<0x3e0da257 xfrm=3DES_0-HMAC_SHA1 NATD=22.43.21.44:4500 DPD=none}

You say the how to resolve my problem?

The conf file:


version 2.0

config setup
       interfaces=%defaultroute
       virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!172.31.1.0/24
       nat_traversal=yes

conn %default
       keyingtries=3
       compress=no
       disablearrivalcheck=no
       authby=rsasig
       keyexchange=ike
       ikelifetime=240m
       keylife=60m

conn roadwarrior
       left=123.123.123.123
       leftcert=/etc/ipsec.d/certs/server2Cert.pem
       leftid=123.123.123.123
       leftrsasigkey=%cert
       leftnexthop=%defaultroute
       rightrsasigkey=%cert
       leftprotoport=17/1701
       rightprotoport=17/%any
       rightsubnet=vhost:%priv,%no
       forceencaps=yes
       rightca=%same
       right=%any
       dpddelay=30
       dpdtimeout=120
       dpdaction=hold
       type=transport
       auto=add
       pfs=no

conn roadwarrior-iphone
       authby=secret
       rekey=no
       keyingtries=3
       left=123.123.123.124
       leftnexthop=%defaultroute
       leftprotoport=17/1701
       right=%any
       rightprotoport=17/%any
       pfs=no
       auto=add

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

-- 
Denis Beltramo

From andrew.colin at gmail.com  Thu Jan 29 14:06:42 2009
From: andrew.colin at gmail.com (andrew colin)
Date: Thu, 29 Jan 2009 21:06:42 +0200
Subject: [Openswan Users] NAT on both sides
In-Reply-To: <f8a02f3e0901290717h7ad4efa6neb569d19efddd053@mail.gmail.com>
References: <f8a02f3e0901261711q69886363qe7e4030bb67e91d6@mail.gmail.com>
	<f8a02f3e0901271952h7d04090ejf8d4403d822fb3ce@mail.gmail.com>
	<31da51d50901272236g19c07b2tbe0a519bdf8d855d@mail.gmail.com>
	<f8a02f3e0901281950j2e9ba032rb8b38983c8de7008@mail.gmail.com>
	<31da51d50901290111o7f949b06lec592a8b0d0db6d7@mail.gmail.com>
	<31da51d50901290448h7e36a30as8ed5cfa4d217f0aa@mail.gmail.com>
	<f8a02f3e0901290717h7ad4efa6neb569d19efddd053@mail.gmail.com>
Message-ID: <31da51d50901291106i21d4a2eah17acf60b8c709178@mail.gmail.com>

On Thu, Jan 29, 2009 at 5:17 PM, Andy Theuninck <gohanman at gmail.com> wrote:
> Wasn't the whole point here to deal with a NAT device in front of the
> server? So long as that NAT device is explicitly dropping 1701, isn't
> it more or less irrelevant what iptables does on the server? Packets
> that get through have to either originate locally or come through the
> tunnel.

Well most cheap dsl routers do not have the option to foward the ESP protocol
the only work around is to use the DMZ option which sends all traffic to a inner
host.

Anyway i have found a workaround for mine by installing the tomato firmware
on the linksys device i am using which allows me to script iptables commands
that cannot go into the firewall interface.

>
> I did build RPMs, actually:
> http://gohanman.com/rpm/CentOS5/RPMS/i386/openswan-2.4.13-1.1.i386.rpm
> http://gohanman.com/rpm/CentOS5/SRPMS/openswan-2.4.13-1.1.src.rpm

Thanks, i also built my Centos rpms using the spec file inside the tarball,
still playing around with it have not had any issues so far/

>
> Built on CentOS, most likely will work on RHEL, and probably Fedora,
> too. I purposely removed one patch that messes up %defaultroute and
> took off a couple others that wouldn't apply cleanly to 2.4.13 source.
> So far I haven't had any problems.
>
> On Thu, Jan 29, 2009 at 6:48 AM, andrew colin <andrew.colin at gmail.com> wrote:
>> Hi All,
>>
>>
>> I have got it working with 2.4.13, I have noticed how ever that this
>> setup introduces a security problem
>> with l2tpd if using NETKEY
>>
>> The l2tpd connection that comes out of the tunnel has a destination ip
>> of the servers interface, which
>> means you have to allow connections to port 1701 from any where if it
>> is to work.
>>
>> If you have a dumb ass router siting infront of the openswan server
>> that does not have the option to
>> forward protocol ESP (meaning you forward everthing to the server),
>> your l2tpd daemon then
>> becomes exposed to the world.
>>
>> KLIPS would be a better option here as it creates the ipsecX
>> interfaces to which you can apply
>> filtering rules.
>>
>> I
>>
>> On Thu, Jan 29, 2009 at 11:11 AM, andrew colin <andrew.colin at gmail.com> wrote:
>>> Thanks mate, i will test that did you build an RPM that you can share
>>> our just pristine source ?
>>>
>>>
>>> On Thu, Jan 29, 2009 at 5:50 AM, Andy Theuninck <gohanman at gmail.com> wrote:
>>>> OK, I've got it. I was running into a documented bug with 2.6.x
>>>> versions of openswan, so I compiled 2.4.13 from openswan.org to
>>>> replace it.
>>>>
>>>> I ended up with this server configuration:
>>>> version 2.0     # conforms to second version of ipsec.conf specification
>>>>
>>>> config setup
>>>>        protostack=netkey
>>>>        nat_traversal=yes
>>>>        virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.1.0/24
>>>>
>>>> conn passthrough-for-non-l2tp
>>>>        type=passthrough
>>>>        left=192.168.1.2
>>>>        leftnexthop=192.168.1.254
>>>>        right=0.0.0.0
>>>>        rightsubnet=0.0.0.0/0
>>>>        auto=route
>>>>
>>>> conn road
>>>>        authby=secret
>>>>        pfs=no
>>>>        rekey=no
>>>>        keyingtries=3
>>>>        type=transport
>>>>        forceencaps=yes
>>>>        left=192.168.1.2
>>>>        leftnexthop=192.168.1.254
>>>>        leftprotoport=17/1701
>>>>        right=%any
>>>>        rightsubnet=vhost:%no,%priv
>>>>        rightprotoport=17/%any
>>>>        auto=add
>>>>
>>>> # disable opportunistic nonsense
>>>> 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
>>>>
>>>> Differences from before:
>>>> Those auto=ignore sections are necessary or pluto will gobble up all
>>>> incoming connections. Version 2.4.13 also gives errors on start up if
>>>> there is vertical whitespace within a connection section (although
>>>> comment lines interleaved are fine). I had to use left + leftnexthop
>>>> instead of %defaultroute to make both connections work. I haven't
>>>> tried an OS X client yet, but that's why forceencaps is there.
>>>> Passthrough seems to behave nicely; I can connect simultaneously by
>>>> VPN and SSH.
>>>>
>>>> My xl2tpd config is extremely vanilla. I had to tweak my iptables
>>>> setup too, but that's probably not a normal set up (my VPN server
>>>> happens to also be routing traffic on 4 separate subnets).
>>>>
>>>> On Wed, Jan 28, 2009 at 12:36 AM, andrew colin <andrew.colin at gmail.com> wrote:
>>>>> Please let me know if you get it working with a windows client.
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> "Dru"
>>> To follow the path, look to the master, follow the master, walk with
>>> the master, see through the master, become the master. (zen)
>>> http://www.topdog.za.net/
>>>
>>
>>
>>
>> --
>> "Dru"
>> To follow the path, look to the master, follow the master, walk with
>> the master, see through the master, become the master. (zen)
>> http://www.topdog.za.net/
>>
>



-- 
"Dru"
To follow the path, look to the master, follow the master, walk with
the master, see through the master, become the master. (zen)
http://www.topdog.za.net/

From andrew.colin at gmail.com  Thu Jan 29 14:08:05 2009
From: andrew.colin at gmail.com (andrew colin)
Date: Thu, 29 Jan 2009 21:08:05 +0200
Subject: [Openswan Users] NAT on both sides
In-Reply-To: <4981AEFA.2080007@goco.net>
References: <f8a02f3e0901261711q69886363qe7e4030bb67e91d6@mail.gmail.com>
	<f8a02f3e0901271952h7d04090ejf8d4403d822fb3ce@mail.gmail.com>
	<31da51d50901272236g19c07b2tbe0a519bdf8d855d@mail.gmail.com>
	<f8a02f3e0901281950j2e9ba032rb8b38983c8de7008@mail.gmail.com>
	<31da51d50901290111o7f949b06lec592a8b0d0db6d7@mail.gmail.com>
	<31da51d50901290448h7e36a30as8ed5cfa4d217f0aa@mail.gmail.com>
	<4981AEFA.2080007@goco.net>
Message-ID: <31da51d50901291108g118d9811t53e6dd4eb1b78521@mail.gmail.com>

On Thu, Jan 29, 2009 at 3:28 PM, Peter McGill <petermcgill at goco.net> wrote:
> You can solve this on your Openswan machine by marking incomming IPSec
> packets with iptables, the mark is preserved when the packet is decrypted
> and reinserted, then you can allow marked packets for l2tp, etc... but drop
> unmarked ones for security. Read man iptables for details.

Thanks learned something new, did not know the mark is preserved.

>
> Peter
>
> andrew colin wrote:
>>
>> Hi All,
>>
>>
>> I have got it working with 2.4.13, I have noticed how ever that this
>> setup introduces a security problem
>> with l2tpd if using NETKEY
>>
>> The l2tpd connection that comes out of the tunnel has a destination ip
>> of the servers interface, which
>> means you have to allow connections to port 1701 from any where if it
>> is to work.
>>
>> If you have a dumb ass router siting infront of the openswan server
>> that does not have the option to
>> forward protocol ESP (meaning you forward everthing to the server),
>> your l2tpd daemon then
>> becomes exposed to the world.
>>
>> KLIPS would be a better option here as it creates the ipsecX
>> interfaces to which you can apply
>> filtering rules.
>>
>> I
>>
>> On Thu, Jan 29, 2009 at 11:11 AM, andrew colin <andrew.colin at gmail.com>
>> wrote:
>>>
>>> Thanks mate, i will test that did you build an RPM that you can share
>>> our just pristine source ?
>>>
>>>
>>> On Thu, Jan 29, 2009 at 5:50 AM, Andy Theuninck <gohanman at gmail.com>
>>> wrote:
>>>>
>>>> OK, I've got it. I was running into a documented bug with 2.6.x
>>>> versions of openswan, so I compiled 2.4.13 from openswan.org to
>>>> replace it.
>>>>
>>>> I ended up with this server configuration:
>>>> version 2.0     # conforms to second version of ipsec.conf specification
>>>>
>>>> config setup
>>>>       protostack=netkey
>>>>       nat_traversal=yes
>>>>
>>>> virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.1.0/24
>>>>
>>>> conn passthrough-for-non-l2tp
>>>>       type=passthrough
>>>>       left=192.168.1.2
>>>>       leftnexthop=192.168.1.254
>>>>       right=0.0.0.0
>>>>       rightsubnet=0.0.0.0/0
>>>>       auto=route
>>>>
>>>> conn road
>>>>       authby=secret
>>>>       pfs=no
>>>>       rekey=no
>>>>       keyingtries=3
>>>>       type=transport
>>>>       forceencaps=yes
>>>>       left=192.168.1.2
>>>>       leftnexthop=192.168.1.254
>>>>       leftprotoport=17/1701
>>>>       right=%any
>>>>       rightsubnet=vhost:%no,%priv
>>>>       rightprotoport=17/%any
>>>>       auto=add
>>>>
>>>> # disable opportunistic nonsense
>>>> 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
>>>>
>>>> Differences from before:
>>>> Those auto=ignore sections are necessary or pluto will gobble up all
>>>> incoming connections. Version 2.4.13 also gives errors on start up if
>>>> there is vertical whitespace within a connection section (although
>>>> comment lines interleaved are fine). I had to use left + leftnexthop
>>>> instead of %defaultroute to make both connections work. I haven't
>>>> tried an OS X client yet, but that's why forceencaps is there.
>>>> Passthrough seems to behave nicely; I can connect simultaneously by
>>>> VPN and SSH.
>>>>
>>>> My xl2tpd config is extremely vanilla. I had to tweak my iptables
>>>> setup too, but that's probably not a normal set up (my VPN server
>>>> happens to also be routing traffic on 4 separate subnets).
>>>>
>>>> On Wed, Jan 28, 2009 at 12:36 AM, andrew colin <andrew.colin at gmail.com>
>>>> wrote:
>>>>>
>>>>> Please let me know if you get it working with a windows client.
>>>>>
>>>
>>>
>>> --
>>> "Dru"
>>> To follow the path, look to the master, follow the master, walk with
>>> the master, see through the master, become the master. (zen)
>>> http://www.topdog.za.net/
>>>
>>
>>
>>
>



-- 
"Dru"
To follow the path, look to the master, follow the master, walk with
the master, see through the master, become the master. (zen)
http://www.topdog.za.net/

From aespanola at arts.ucla.edu  Fri Jan 30 13:57:08 2009
From: aespanola at arts.ucla.edu (Arnel B. Espanola)
Date: Fri, 30 Jan 2009 10:57:08 -0800
Subject: [Openswan Users] Troubleshooting assistance on openswan 2.6.19
Message-ID: <49834D84.30904@arts.ucla.edu>

Hello there,

I've been running this version of Openswan on Fedora 6 for a while
without a problem. And I'm using xl2tpd-1.1.11-2.fc6 for L2TP.

Linux Openswan U2.4.5/K2.6.22.14-72.fc6 (netkey)

But recently I decided to install the latest version of Openswan on
CentOS5 and I'm having issues with it and I couldn't find the solution
for it. And I installed L2TP from source, l2tpd-0.69cvs20051030-1jdl.
Not sure if the L2TP is what causing the problem.

Linux Openswan U2.6.19/K2.6.18-92.1.22.el5 (netkey)


I just copied the my ipsec.config from old version. And kept some
default config from the new version.


/etc/ipsec.conf


config setup
	# Do not set debug= options to debug configuration issues!
	# plutodebug / klipsdebug = "all", "none" or a combation from below:
	# "raw crypt parsing emitting control klips pfkey natt x509 dpd private"
	# eg:
	# plutodebug="control parsing"
	#
	# enable to get logs per-peer
	# plutoopts="--perpeerlog"
	#
	# Only enable *debug=all if you are a developer
	#
	# NAT-TRAVERSAL support, see README.NAT-Traversal
	nat_traversal=yes
	# exclude networks used on server side by adding %v4:!a.b.c.0/24
	virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%4:172.16.0.0/12
	# OE is now off by default. Uncomment and change to on, to enable.
	OE=off
	# which IPsec stack to use. netkey,klips,mast,auto or none
	protostack=netkey
	 interfaces=%defaultroute
     klipsdebug=none
     plutodebug=none
    #  overridemtu=1410
     protostack=netkey
     nat_traversal=yes
     virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16

# Add connections here


conn %default
     keyingtries=3
     compress=yes
     disablearrivalcheck=no
     authby=secret
     type=tunnel
     keyexchange=ike
     ikelifetime=240m
     keylife=60m
conn roadwarrior-all
     leftsubnet=0.0.0.0/0
     also=roadwarrior
conn roadwarrior-l2tp
     leftprotoport=17/0
     rightprotoport=17/1701
     also=roadwarrior
conn roadwarrior-l2tp-macosx
     leftprotoport=17/1701
     rightprotoport=17/%any
     also=roadwarrior
conn roadwarrior-l2tp-updatedwin
     leftprotoport=17/1701
     rightprotoport=17/1701
     also=roadwarrior
conn roadwarrior
     pfs=no
     left=192.168.1.21
     leftnexthop=192.168.1.254
     right=%any
     auto=add


and here's the log. and it seems ipsec got established but not the L2TP.
I don't see anything being logged in ppp directory.

/var/log/secure

Jan 30 09:45:25 test pluto[26674]: packet from 10.10.10.41:500: ignoring
Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
Jan 30 09:45:25 test pluto[26674]: packet from 10.10.10.41:500: ignoring
Vendor ID payload [FRAGMENTATION]
Jan 30 09:45:25 test pluto[26674]: packet from 10.10.10.41:500: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set to=106
Jan 30 09:45:25 test pluto[26674]: packet from 10.10.10.41:500: ignoring
Vendor ID payload [Vid-Initial-Contact]
Jan 30 09:45:25 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
responding to Main Mode from unknown peer 10.10.10.41
Jan 30 09:45:25 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Jan 30 09:45:25 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
STATE_MAIN_R1: sent MR1, expecting MI2
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: no NAT
detected
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
STATE_MAIN_R2: sent MR2, expecting MI3
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
Main mode peer ID is ID_IPV4_ADDR: '10.10.10.41'
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
STATE_MAIN_R3: sent MR3, ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
group=modp2048}
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
the peer proposed: 192.168.1.21/32:0/0 -> 10.10.10.41/32:0/0
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-l2tp"[3] 10.10.10.41
#10: responding to Quick Mode proposal {msgid:31e7faf3}
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-l2tp"[3] 10.10.10.41
#10:     us: 192.168.1.21<192.168.1.21>[+S=C]:17/0---192.168.1.254
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-l2tp"[3] 10.10.10.41
#10:   them: 10.10.10.41[+S=C]:17/1701
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-l2tp"[3] 10.10.10.41
#10: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-l2tp"[3] 10.10.10.41
#10: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-l2tp"[3] 10.10.10.41
#10: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-l2tp"[3] 10.10.10.41
#10: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=>0xf954264a
<0xd247dca8 xfrm=3DES_0-HMAC_MD5 NATOA=<invalid> NATD=<invalid>:500
DPD=enabled}
Jan 30 09:45:31 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
received Delete SA(0xf954264a) payload: deleting IPSEC State #10
Jan 30 09:45:31 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
deleting connection "roadwarrior-l2tp" instance with peer 10.10.10.41
{isakmp=#0/ipsec=#0}
Jan 30 09:45:31 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
received and ignored informational message
Jan 30 09:45:32 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
received Delete SA payload: deleting ISAKMP State #9
Jan 30 09:45:32 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41:
deleting connection "roadwarrior-all" instance with peer 10.10.10.41
{isakmp=#0/ipsec=#0}
Jan 30 09:45:32 test pluto[26674]: packet from 10.10.10.41:500: received
and ignored informational message


Your help on this will be greatly appreciated. Let me know if you need
more information.

Thanks.

Arnel


From paul at xelerance.com  Fri Jan 30 14:36:10 2009
From: paul at xelerance.com (Paul Wouters)
Date: Fri, 30 Jan 2009 14:36:10 -0500 (EST)
Subject: [Openswan Users] Troubleshooting assistance on openswan 2.6.19
In-Reply-To: <49834D84.30904@arts.ucla.edu>
References: <49834D84.30904@arts.ucla.edu>
Message-ID: <alpine.LFD.1.10.0901301435350.32398@newtla.xelerance.com>

On Fri, 30 Jan 2009, Arnel B. Espanola wrote:

> I've been running this version of Openswan on Fedora 6 for a while
> without a problem. And I'm using xl2tpd-1.1.11-2.fc6 for L2TP.
>
> Linux Openswan U2.4.5/K2.6.22.14-72.fc6 (netkey)
>
> But recently I decided to install the latest version of Openswan on
> CentOS5 and I'm having issues with it and I couldn't find the solution
> for it. And I installed L2TP from source, l2tpd-0.69cvs20051030-1jdl.
> Not sure if the L2TP is what causing the problem.
>
> Linux Openswan U2.6.19/K2.6.18-92.1.22.el5 (netkey)
>
>
> I just copied the my ipsec.config from old version. And kept some
> default config from the new version.

http://bugs.xelerance.com/view.php?id=1004

Paul

From aespanola at arts.ucla.edu  Fri Jan 30 15:25:25 2009
From: aespanola at arts.ucla.edu (Arnel B. Espanola)
Date: Fri, 30 Jan 2009 12:25:25 -0800
Subject: [Openswan Users] Troubleshooting assistance on openswan 2.6.19
In-Reply-To: <alpine.LFD.1.10.0901301435350.32398@newtla.xelerance.com>
References: <49834D84.30904@arts.ucla.edu>
	<alpine.LFD.1.10.0901301435350.32398@newtla.xelerance.com>
Message-ID: <49836235.1090909@arts.ucla.edu>

So it means I have to continue using the older version until the bugs
are fixed in the latest version?

Arnel

Paul Wouters wrote:
> On Fri, 30 Jan 2009, Arnel B. Espanola wrote:
> 
>> I've been running this version of Openswan on Fedora 6 for a while
>> without a problem. And I'm using xl2tpd-1.1.11-2.fc6 for L2TP.
>>
>> Linux Openswan U2.4.5/K2.6.22.14-72.fc6 (netkey)
>>
>> But recently I decided to install the latest version of Openswan on
>> CentOS5 and I'm having issues with it and I couldn't find the solution
>> for it. And I installed L2TP from source, l2tpd-0.69cvs20051030-1jdl.
>> Not sure if the L2TP is what causing the problem.
>>
>> Linux Openswan U2.6.19/K2.6.18-92.1.22.el5 (netkey)
>>
>>
>> I just copied the my ipsec.config from old version. And kept some
>> default config from the new version.
> 
> http://bugs.xelerance.com/view.php?id=1004
> 
> Paul

From chris_garrigues at steeprockinc.com  Mon Jan 26 09:48:21 2009
From: chris_garrigues at steeprockinc.com (Chris Garrigues)
Date: Mon, 26 Jan 2009 08:48:21 -0600
Subject: [Openswan Users] OpenSWAN to SonicWALL problems
In-Reply-To: <4979E530.1060303@goco.net>
References: <497877C3.2070608@steeprockinc.com> <4979E530.1060303@goco.net>
Message-ID: <497DCD35.3030804@steeprockinc.com>

Peter McGill wrote:
> Chris,
>
> It appears that you still have opportunistic encryption on.
> > + ipsec verify
> > Opportunistic Encryption DNS checks:
> >    Looking for TXT in forward dns zone: localhost.localdomain  
> [MISSING]
> >    Does the machine have at least one non-private address?     
> [FAILED]
>
> I don't see anywhere that you've turned opportunistic encryption off.
> ipsec.conf:
> config setup
>     oe=off # Openswan 2.6.x only
>
> or
>
> include /etc/ipsec.d/examples/no_oe.conf
Apparently that wasn't enough.  We must have something else wrong as well.

Here's the latest barf:

localhost.localdomain
Mon Jan 26 09:41:08 EST 2009
+ _________________________ version
+ ipsec --version
Linux Openswan U2.6.14/K2.6.27.5-41.fc9.i686 (netkey)
See `ipsec --copyright' for copyright information.
+ _________________________ /proc/version
+ cat /proc/version
Linux version 2.6.27.5-41.fc9.i686 (mockbuild@) (gcc version 4.3.0
20080428 (Red Hat 4.3.0-8) (GCC) ) #1 SMP Thu Nov 13 20:52:14 EST 2008
+ _________________________ /proc/net/ipsec_eroute
+ test -r /proc/net/ipsec_eroute
+ _________________________ netstat-rn
+ netstat -nr
+ head -n 100
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt
Iface
192.168.15.0    0.0.0.0         255.255.255.0   U         0 0          0
eth0
0.0.0.0         192.168.15.1    0.0.0.0         UG        0 0          0
eth0
+ _________________________ /proc/net/ipsec_spi
+ test -r /proc/net/ipsec_spi
+ _________________________ /proc/net/ipsec_spigrp
+ test -r /proc/net/ipsec_spigrp
+ _________________________ /proc/net/ipsec_tncfg
+ test -r /proc/net/ipsec_tncfg
+ _________________________ /proc/net/pfkey
+ test -r /proc/net/pfkey
+ cat /proc/net/pfkey
sk       RefCnt Rmem   Wmem   User   Inode
+ _________________________ ip-xfrm-state
+ ip xfrm state
+ _________________________ ip-xfrm-policy
+ ip xfrm policy
+ _________________________ /proc/crypto
+ test -r /proc/crypto
+ cat /proc/crypto
name         : deflate
driver       : deflate-generic
module       : deflate
priority     : 0
refcnt       : 1
type         : compression

name         : rfc3686(ctr(aes))
driver       : rfc3686(ctr(aes-asm))
module       : ctr
priority     : 200
refcnt       : 1
type         : blkcipher
blocksize    : 1
min keysize  : 20
max keysize  : 36
ivsize       : 8
geniv        : seqiv

name         : ctr(aes)
driver       : ctr(aes-asm)
module       : ctr
priority     : 200
refcnt       : 1
type         : blkcipher
blocksize    : 1
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : <default>

name         : cbc(twofish)
driver       : cbc(twofish-generic)
module       : cbc
priority     : 100
refcnt       : 1
type         : blkcipher
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : <default>

name         : cbc(camellia)
driver       : cbc(camellia-generic)
module       : cbc
priority     : 100
refcnt       : 1
type         : blkcipher
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : <default>

name         : camellia
driver       : camellia-generic
module       : camellia
priority     : 100
refcnt       : 1
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

name         : cbc(serpent)
driver       : cbc(serpent-generic)
module       : cbc
priority     : 0
refcnt       : 1
type         : blkcipher
blocksize    : 16
min keysize  : 0
max keysize  : 32
ivsize       : 16
geniv        : <default>

name         : cbc(aes)
driver       : cbc(aes-asm)
module       : cbc
priority     : 200
refcnt       : 1
type         : blkcipher
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : <default>

name         : cbc(blowfish)
driver       : cbc(blowfish-generic)
module       : cbc
priority     : 0
refcnt       : 1
type         : blkcipher
blocksize    : 8
min keysize  : 4
max keysize  : 56
ivsize       : 8
geniv        : <default>

name         : cbc(des3_ede)
driver       : cbc(des3_ede-generic)
module       : cbc
priority     : 0
refcnt       : 1
type         : blkcipher
blocksize    : 8
min keysize  : 24
max keysize  : 24
ivsize       : 8
geniv        : <default>

name         : cbc(des)
driver       : cbc(des-generic)
module       : cbc
priority     : 0
refcnt       : 1
type         : blkcipher
blocksize    : 8
min keysize  : 8
max keysize  : 8
ivsize       : 8
geniv        : <default>

name         : xcbc(aes)
driver       : xcbc(aes-asm)
module       : xcbc
priority     : 200
refcnt       : 1
type         : hash
blocksize    : 16
digestsize   : 16

name         : hmac(rmd160)
driver       : hmac(rmd160)
module       : kernel
priority     : 0
refcnt       : 1
type         : hash
blocksize    : 64
digestsize   : 20

name         : rmd160
driver       : rmd160
module       : rmd160
priority     : 0
refcnt       : 1
type         : digest
blocksize    : 64
digestsize   : 20

name         : hmac(sha256)
driver       : hmac(sha256-generic)
module       : kernel
priority     : 0
refcnt       : 1
type         : hash
blocksize    : 64
digestsize   : 32

name         : hmac(sha1)
driver       : hmac(sha1-generic)
module       : kernel
priority     : 0
refcnt       : 1
type         : hash
blocksize    : 64
digestsize   : 20

name         : hmac(md5)
driver       : hmac(md5-generic)
module       : kernel
priority     : 0
refcnt       : 1
type         : hash
blocksize    : 64
digestsize   : 16

name         : compress_null
driver       : compress_null-generic
module       : crypto_null
priority     : 0
refcnt       : 1
type         : compression

name         : digest_null
driver       : digest_null-generic
module       : crypto_null
priority     : 0
refcnt       : 1
type         : digest
blocksize    : 1
digestsize   : 0

name         : ecb(cipher_null)
driver       : ecb-cipher_null
module       : crypto_null
priority     : 100
refcnt       : 1
type         : blkcipher
blocksize    : 1
min keysize  : 0
max keysize  : 0
ivsize       : 0
geniv        : <default>

name         : cipher_null
driver       : cipher_null-generic
module       : crypto_null
priority     : 0
refcnt       : 1
type         : cipher
blocksize    : 1
min keysize  : 0
max keysize  : 0

name         : tnepres
driver       : tnepres-generic
module       : serpent
priority     : 0
refcnt       : 1
type         : cipher
blocksize    : 16
min keysize  : 0
max keysize  : 32

name         : serpent
driver       : serpent-generic
module       : serpent
priority     : 0
refcnt       : 1
type         : cipher
blocksize    : 16
min keysize  : 0
max keysize  : 32

name         : blowfish
driver       : blowfish-generic
module       : blowfish
priority     : 0
refcnt       : 1
type         : cipher
blocksize    : 8
min keysize  : 4
max keysize  : 56

name         : twofish
driver       : twofish-generic
module       : twofish
priority     : 100
refcnt       : 1
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

name         : sha256
driver       : sha256-generic
module       : sha256_generic
priority     : 0
refcnt       : 1
type         : digest
blocksize    : 64
digestsize   : 32

name         : sha224
driver       : sha224-generic
module       : sha256_generic
priority     : 0
refcnt       : 1
type         : digest
blocksize    : 64
digestsize   : 28

name         : sha512
driver       : sha512-generic
module       : sha512_generic
priority     : 0
refcnt       : 1
type         : digest
blocksize    : 128
digestsize   : 64

name         : sha384
driver       : sha384-generic
module       : sha512_generic
priority     : 0
refcnt       : 1
type         : digest
blocksize    : 128
digestsize   : 48

name         : des3_ede
driver       : des3_ede-generic
module       : des_generic
priority     : 0
refcnt       : 1
type         : cipher
blocksize    : 8
min keysize  : 24
max keysize  : 24

name         : des
driver       : des-generic
module       : des_generic
priority     : 0
refcnt       : 1
type         : cipher
blocksize    : 8
min keysize  : 8
max keysize  : 8

name         : aes
driver       : aes-asm
module       : aes_i586
priority     : 200
refcnt       : 1
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

name         : aes
driver       : aes-generic
module       : aes_generic
priority     : 100
refcnt       : 1
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

name         : sha1
driver       : sha1-generic
module       : kernel
priority     : 0
refcnt       : 1
type         : digest
blocksize    : 64
digestsize   : 20

name         : md5
driver       : md5-generic
module       : kernel
priority     : 0
refcnt       : 1
type         : digest
blocksize    : 64
digestsize   : 16

+ __________________________/proc/sys/net/core/xfrm-star
/usr/libexec/ipsec/barf: line 191:
__________________________/proc/sys/net/core/xfrm-star: No such file or
directory
+ for i in '/proc/sys/net/core/xfrm_*'
+ echo -n '/proc/sys/net/core/xfrm_acq_expires: '
/proc/sys/net/core/xfrm_acq_expires: + cat
/proc/sys/net/core/xfrm_acq_expires
30
+ for i in '/proc/sys/net/core/xfrm_*'
+ echo -n '/proc/sys/net/core/xfrm_aevent_etime: '
/proc/sys/net/core/xfrm_aevent_etime: + cat
/proc/sys/net/core/xfrm_aevent_etime
10
+ for i in '/proc/sys/net/core/xfrm_*'
+ echo -n '/proc/sys/net/core/xfrm_aevent_rseqth: '
/proc/sys/net/core/xfrm_aevent_rseqth: + cat
/proc/sys/net/core/xfrm_aevent_rseqth
2
+ for i in '/proc/sys/net/core/xfrm_*'
+ echo -n '/proc/sys/net/core/xfrm_larval_drop: '
/proc/sys/net/core/xfrm_larval_drop: + cat
/proc/sys/net/core/xfrm_larval_drop
0
+ _________________________ /proc/sys/net/ipsec-star
+ test -d /proc/sys/net/ipsec
+ _________________________ ipsec/status
+ ipsec auto --status
000 using kernel interface: netkey
000 %myid = (none)
000 debug none
000 
000 algorithm ESP encrypt: id=2, name=ESP_DES, ivlen=8, keysizemin=64,
keysizemax=64
000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, keysizemin=192,
keysizemax=192
000 algorithm ESP encrypt: id=7, name=ESP_BLOWFISH, ivlen=8,
keysizemin=40, keysizemax=448
000 algorithm ESP encrypt: id=11, name=ESP_NULL, ivlen=0, keysizemin=0,
keysizemax=0
000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=8, keysizemin=128,
keysizemax=256
000 algorithm ESP encrypt: id=13, name=ESP_AES_CTR, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=14, name=ESP_AES_CCM_A, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=15, name=ESP_AES_CCM_B, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=16, name=ESP_AES_CCM_C, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=18, name=ESP_AES_GCM_A, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=19, name=ESP_AES_GCM_B, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=20, name=ESP_AES_GCM_C, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=22, name=ESP_CAMELLIA, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=252, name=ESP_SERPENT, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=253, name=ESP_TWOFISH, ivlen=8,
keysizemin=128, keysizemax=256
000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5,
keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1,
keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=5, name=AUTH_ALGORITHM_HMAC_SHA2_256,
keysizemin=256, keysizemax=256
000 algorithm ESP auth attr: id=8, name=AUTH_ALGORITHM_HMAC_RIPEMD,
keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=9, name=AUTH_ALGORITHM_AES_CBC,
keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=251, name=(null), keysizemin=0, keysizemax=0
000 
000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=131
000 algorithm IKE encrypt: id=3, name=OAKLEY_BLOWFISH_CBC, blocksize=8,
keydeflen=128
000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8,
keydeflen=192
000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16,
keydeflen=128
000 algorithm IKE encrypt: id=65004, name=OAKLEY_SERPENT_CBC,
blocksize=16, keydeflen=128
000 algorithm IKE encrypt: id=65005, name=OAKLEY_TWOFISH_CBC,
blocksize=16, keydeflen=128
000 algorithm IKE encrypt: id=65289, name=OAKLEY_TWOFISH_CBC_SSH,
blocksize=16, keydeflen=128
000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
000 algorithm IKE hash: id=4, name=OAKLEY_SHA2_256, hashsize=32
000 algorithm IKE hash: id=6, name=OAKLEY_SHA2_512, hashsize=64
000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192
000 
000 stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,0,0}
trans={0,0,0} attrs={0,0,0}
000 
000 "vo":
192.168.10.0/24===67.220.126.196<67.220.126.196>[@vo,+S=C]...0.0.0.0---%any[@jingluo,+S=C]===192.168.200.56/32;
unrouted; eroute owner: #0
000 "vo":     myip=unset; hisip=192.168.200.56;
000 "vo":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s;
rekey_fuzz: 100%; keyingtries: 0
000 "vo":   policy: PSK+ENCRYPT+TUNNEL+PFS+IKEv2ALLOW+lKOD+rKOD; prio:
24,32; interface: ;
000 "vo":   newest ISAKMP SA: #0; newest IPsec SA: #0;
000 "vo":   IKE algorithms wanted: AES_CBC(7)_256-SHA1(2)-MODP1536(5),
AES_CBC(7)_256-SHA1(2)-MODP1024(2); flags=-strict
000 "vo":   IKE algorithms found:  AES_CBC(7)_256-SHA1(2)_160-5,
AES_CBC(7)_256-SHA1(2)_160-2,
000 "vo":   ESP algorithms wanted: AES(12)_256-SHA1(2); flags=-strict
000 "vo":   ESP algorithms loaded: AES(12)_256-SHA1(2)_160
000 "vodmz":
192.168.8.0/24===67.220.126.196<67.220.126.196>[@vo,+S=C]...0.0.0.0---%any[@jingluo,+S=C]===192.168.200.56/32;
unrouted; eroute owner: #0
000 "vodmz":     myip=unset; hisip=192.168.200.56;
000 "vodmz":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s;
rekey_fuzz: 100%; keyingtries: 0
000 "vodmz":   policy: PSK+ENCRYPT+TUNNEL+PFS+IKEv2ALLOW+lKOD+rKOD;
prio: 24,32; interface: ;
000 "vodmz":   newest ISAKMP SA: #0; newest IPsec SA: #0;
000 "vodmz":   IKE algorithms wanted:
AES_CBC(7)_256-SHA1(2)-MODP1536(5), AES_CBC(7)_256-SHA1(2)-MODP1024(2);
flags=-strict
000 "vodmz":   IKE algorithms found:  AES_CBC(7)_256-SHA1(2)_160-5,
AES_CBC(7)_256-SHA1(2)_160-2,
000 "vodmz":   ESP algorithms wanted: AES(12)_256-SHA1(2); flags=-strict
000 "vodmz":   ESP algorithms loaded: AES(12)_256-SHA1(2)_160
000 
000 
+ _________________________ ifconfig-a
+ ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:1A:A0:49:D6:F0 
          inet addr:192.168.15.3  Bcast:192.168.15.255  Mask:255.255.255.0
          inet6 addr: fe80::21a:a0ff:fe49:d6f0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:437205 errors:0 dropped:0 overruns:0 frame:0
          TX packets:382402 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:392714376 (374.5 MiB)  TX bytes:73748413 (70.3 MiB)
          Interrupt:16

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:8706 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8706 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:452185 (441.5 KiB)  TX bytes:452185 (441.5 KiB)

pan0      Link encap:Ethernet  HWaddr 42:44:14:66:91:88 
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

+ _________________________ ip-addr-list
+ ip addr list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
    link/ether 00:1a:a0:49:d6:f0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.15.3/24 brd 192.168.15.255 scope global eth0
    inet6 fe80::21a:a0ff:fe49:d6f0/64 scope link
       valid_lft forever preferred_lft forever
3: pan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
    link/ether 42:44:14:66:91:88 brd ff:ff:ff:ff:ff:ff
+ _________________________ ip-route-list
+ ip route list
192.168.15.0/24 dev eth0  proto kernel  scope link  src 192.168.15.3
default via 192.168.15.1 dev eth0  proto static
+ _________________________ ip-rule-list
+ ip rule list
0:    from all lookup local
32766:    from all lookup main
32767:    from all lookup default
+ _________________________ ipsec_verify
+ ipsec verify --nocolour
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.14/K2.6.27.5-41.fc9.i686 (netkey)
Checking for IPsec support in kernel                            [OK]
NETKEY detected, testing for disabled ICMP send_redirects       [FAILED]

  Please disable /proc/sys/net/ipv4/conf/*/send_redirects
  or NETKEY will cause the sending of bogus ICMP redirects!

NETKEY detected, testing for disabled ICMP accept_redirects     [FAILED]

  Please disable /proc/sys/net/ipv4/conf/*/accept_redirects
  or NETKEY will accept bogus ICMP redirects!

Checking for RSA private key (/etc/ipsec.secrets)               [OK]
Checking that pluto is running                                  [OK]
Pluto not listening on port udp 500. Check interfaces defintion in
ipsec.conf.Two or more interfaces found, checking IP forwarding       
    [FAILED]
Checking for 'ip' command                                       [OK]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]
+ _________________________ mii-tool
+ '[' -x /sbin/mii-tool ']'
+ /sbin/mii-tool -v
eth0: negotiated 100baseTx-FD, link ok
  product info: vendor 00:50:ef, model 14 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
  link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
+ _________________________ ipsec/directory
+ ipsec --directory
/usr/libexec/ipsec
+ _________________________ hostname/fqdn
+ hostname --fqdn
localhost.localdomain
+ _________________________ hostname/ipaddress
+ hostname --ip-address
127.0.0.1
+ _________________________ uptime
+ uptime
 09:41:09 up 5 days, 41 min, 11 users,  load average: 0.51, 0.43, 0.22
+ _________________________ ps
+ ps alxwf
+ egrep -i 'ppid|pluto|ipsec|klips'
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
4     0 22375 20683  20   0   5668  1136 wait   S+   pts/10    
0:00              \_ /bin/sh /usr/libexec/ipsec/barf
0     0 22455 22375  20   0   2044   504 pipe_w S+   pts/10    
0:00                  \_ egrep -i ppid|pluto|ipsec|klips
1     0 22265     1  20   0   2668   416 wait   S    pts/10     0:00
/bin/sh /usr/libexec/ipsec/_plutorun --debug  --uniqueids no
--force_busy no --nocrsend no --strictcrlpolicy  --nat_traversal yes
--keep_alive  --protostack netkey --force_keepalive 
--disable_port_floating  --virtual_private  --crlcheckinterval 0
--ocspuri  --nhelpers  --dump  --opts  --stderrlog  --wait no --pre 
--post  --log daemon.error --plutorestartoncrash false --pid
/var/run/pluto/pluto.pid
1     0 22266 22265  20   0   2668   548 wait   S    pts/10     0:00  \_
/bin/sh /usr/libexec/ipsec/_plutorun --debug  --uniqueids no
--force_busy no --nocrsend no --strictcrlpolicy  --nat_traversal yes
--keep_alive  --protostack netkey --force_keepalive 
--disable_port_floating  --virtual_private  --crlcheckinterval 0
--ocspuri  --nhelpers  --dump  --opts  --stderrlog  --wait no --pre 
--post  --log daemon.error --plutorestartoncrash false --pid
/var/run/pluto/pluto.pid
4     0 22267 22266  20   0   3260  1152 select S    pts/10     0:00 
|   \_ /usr/libexec/ipsec/pluto --nofork --secretsfile
/etc/ipsec.secrets --use-netkey --nat_traversal
1     0 22268 22267  30  10   3268   580 unix_s SN   pts/10     0:00 
|       \_ pluto helper  # 
0                                                                            

0     0 22308 22267  20   0   1756   296 select S    pts/10     0:00 
|       \_ _pluto_adns
0     0 22270 22265  20   0   2668   968 pipe_w S    pts/10     0:00  \_
/bin/sh /usr/libexec/ipsec/_plutoload --wait no --post
0     0 22269     1  20   0   1808   504 pipe_w S    pts/10     0:00
logger -s -p daemon.error -t ipsec__plutorun
+ _________________________ ipsec/showdefaults
+ ipsec showdefaults
ipsec showdefaults: cannot find defaults file `/var/run/pluto/ipsec.info'
+ _________________________ ipsec/conf
+ ipsec _keycensor
+ ipsec _include /etc/ipsec.conf

#< /etc/ipsec.conf 1
# /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"
    # For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
    protostack=netkey
    nat_traversal=yes


#< /etc/ipsec.d/ipsec.conf 1
conn vo
    also=vocommon
    rightsubnet=192.168.10.0/24
    auto=start

conn vodmz
    also=vocommon
    rightsubnet=192.168.8.0/24
    auto=start

conn vocommon
    type=tunnel
    left=%defaultroute
    leftid=@jingluo
    leftsourceip=192.168.200.56
    leftsubnet=192.168.200.56/32
    rightid=@vo
    right=67.220.126.196
    keyingtries=0
    pfs=yes
    authby=secret
    auth=esp
    ike=aes256-sha1
    esp=aes256-sha1
    keyexchange=ike

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

#> /etc/ipsec.conf 19
+ _________________________ ipsec/secrets
+ ipsec _include /etc/ipsec.secrets
+ ipsec _secretcensor

#< /etc/ipsec.secrets 1

#< /etc/ipsec.d/ipsec.secrets 1
@jingluo @vo : PSK "[sums to 3db3...]"

#> /etc/ipsec.secrets 2
+ _________________________ ipsec/listall
+ ipsec auto --listall
000 
000 List of Public Keys:
000 
000 List of Pre-shared secrets (from /etc/ipsec.secrets)
+ '[' /etc/ipsec.d/policies ']'
+ for policy in '$POLICIES/*'
++ basename /etc/ipsec.d/policies/block
+ base=block
+ _________________________ ipsec/policies/block
+ cat /etc/ipsec.d/policies/block
# This file defines the set of CIDRs (network/mask-length) to which
# communication should never be allowed.
#
# See /usr/share/doc/openswan/policygroups.html for details.
#
# $Id: block.in,v 1.4 2003/02/17 02:22:15 mcr Exp $
#

+ for policy in '$POLICIES/*'
++ basename /etc/ipsec.d/policies/clear
+ base=clear
+ _________________________ ipsec/policies/clear
+ cat /etc/ipsec.d/policies/clear
# This file defines the set of CIDRs (network/mask-length) to which
# communication should always be in the clear.
#
# See /usr/share/doc/openswan/policygroups.html for details.
#

# root name servers should be in the clear
192.58.128.30/32
198.41.0.4/32
192.228.79.201/32
192.33.4.12/32
128.8.10.90/32
192.203.230.10/32
192.5.5.241/32
192.112.36.4/32
128.63.2.53/32
192.36.148.17/32
193.0.14.129/32
199.7.83.42/32
202.12.27.33/32
+ for policy in '$POLICIES/*'
++ basename /etc/ipsec.d/policies/clear-or-private
+ base=clear-or-private
+ _________________________ ipsec/policies/clear-or-private
+ cat /etc/ipsec.d/policies/clear-or-private
# This file defines the set of CIDRs (network/mask-length) to which
# we will communicate in the clear, or, if the other side initiates IPSEC,
# using encryption.  This behaviour is also called "Opportunistic
Responder".
#
# See /usr/share/doc/openswan/policygroups.html for details.
#
# $Id: clear-or-private.in,v 1.4 2003/02/17 02:22:15 mcr Exp $
#
+ for policy in '$POLICIES/*'
++ basename /etc/ipsec.d/policies/private
+ base=private
+ _________________________ ipsec/policies/private
+ cat /etc/ipsec.d/policies/private
# This file defines the set of CIDRs (network/mask-length) to which
# communication should always be private (i.e. encrypted).
# See /usr/share/doc/openswan/policygroups.html for details.
#
# $Id: private.in,v 1.4 2003/02/17 02:22:15 mcr Exp $
#
+ for policy in '$POLICIES/*'
++ basename /etc/ipsec.d/policies/private-or-clear
+ base=private-or-clear
+ _________________________ ipsec/policies/private-or-clear
+ cat /etc/ipsec.d/policies/private-or-clear
# This file defines the set of CIDRs (network/mask-length) to which
# communication should be private, if possible, but in the clear otherwise.
#
# If the target has a TXT (later IPSECKEY) record that specifies
# authentication material, we will require private (i.e. encrypted)
# communications.  If no such record is found, communications will be
# in the clear.
#
# See /usr/share/doc/openswan/policygroups.html for details.
#
# $Id: private-or-clear.in,v 1.5 2003/02/17 02:22:15 mcr Exp $
#

0.0.0.0/0
+ _________________________ ipsec/ls-libdir
+ ls -l /usr/libexec/ipsec
total 2256
-rwxr-xr-x 1 root root   6056 Jun  6  2008 _copyright
-rwxr-xr-x 1 root root   2379 Jun  6  2008 _include
-rwxr-xr-x 1 root root   1475 Jun  6  2008 _keycensor
-rwxr-xr-x 1 root root  10088 Jun  6  2008 _pluto_adns
-rwxr-xr-x 1 root root   2632 Jun  6  2008 _plutoload
-rwxr-xr-x 1 root root   7602 Jun  6  2008 _plutorun
-rwxr-xr-x 1 root root  13746 Jun  6  2008 _realsetup
-rwxr-xr-x 1 root root   1975 Jun  6  2008 _secretcensor
-rwxr-xr-x 1 root root   9752 Jun  6  2008 _startklips
-rwxr-xr-x 1 root root   9752 Jun  6  2008 _startklips.old
-rwxr-xr-x 1 root root   4988 Jun  6  2008 _startnetkey
-rwxr-xr-x 1 root root   4949 Jun  6  2008 _updown
-rwxr-xr-x 1 root root  14030 Jun  6  2008 _updown.klips
-rwxr-xr-x 1 root root  14030 Jun  6  2008 _updown.klips.old
-rwxr-xr-x 1 root root  13739 Jun  6  2008 _updown.mast
-rwxr-xr-x 1 root root  13739 Jun  6  2008 _updown.mast.old
-rwxr-xr-x 1 root root   8337 Jun  6  2008 _updown.netkey
-rwxr-xr-x 1 root root 188348 Jun  6  2008 addconn
-rwxr-xr-x 1 root root   6129 Jun  6  2008 auto
-rwxr-xr-x 1 root root  10758 Jun  6  2008 barf
-rwxr-xr-x 1 root root  90088 Jun  6  2008 eroute
-rwxr-xr-x 1 root root  20708 Jun  6  2008 ikeping
-rwxr-xr-x 1 root root  69804 Jun  6  2008 klipsdebug
-rwxr-xr-x 1 root root   1836 Jun  6  2008 livetest
-rwxr-xr-x 1 root root   2591 Jun  6  2008 look
-rwxr-xr-x 1 root root   1921 Jun  6  2008 newhostkey
-rwxr-xr-x 1 root root  60840 Jun  6  2008 pf_key
-rwxr-xr-x 1 root root 957728 Jun  6  2008 pluto
-rwxr-xr-x 1 root root  10236 Jun  6  2008 ranbits
-rwxr-xr-x 1 root root  20176 Jun  6  2008 rsasigkey
-rwxr-xr-x 1 root root    766 Jun  6  2008 secrets
lrwxrwxrwx 1 root root     30 Jan 20 09:30 setup ->
../../../etc/rc.d/init.d/ipsec
-rwxr-xr-x 1 root root   1054 Jun  6  2008 showdefaults
-rwxr-xr-x 1 root root 219368 Jun  6  2008 showhostkey
-rwxr-xr-x 1 root root  22744 Jun  6  2008 showpolicy
-rwxr-xr-x 1 root root 148388 Jun  6  2008 spi
-rwxr-xr-x 1 root root  77336 Jun  6  2008 spigrp
-rwxr-xr-x 1 root root  69700 Jun  6  2008 tncfg
-rwxr-xr-x 1 root root  12526 Jun  6  2008 verify
-rwxr-xr-x 1 root root  50340 Jun  6  2008 whack
+ _________________________ ipsec/ls-execdir
+ ls -l /usr/libexec/ipsec
total 2256
-rwxr-xr-x 1 root root   6056 Jun  6  2008 _copyright
-rwxr-xr-x 1 root root   2379 Jun  6  2008 _include
-rwxr-xr-x 1 root root   1475 Jun  6  2008 _keycensor
-rwxr-xr-x 1 root root  10088 Jun  6  2008 _pluto_adns
-rwxr-xr-x 1 root root   2632 Jun  6  2008 _plutoload
-rwxr-xr-x 1 root root   7602 Jun  6  2008 _plutorun
-rwxr-xr-x 1 root root  13746 Jun  6  2008 _realsetup
-rwxr-xr-x 1 root root   1975 Jun  6  2008 _secretcensor
-rwxr-xr-x 1 root root   9752 Jun  6  2008 _startklips
-rwxr-xr-x 1 root root   9752 Jun  6  2008 _startklips.old
-rwxr-xr-x 1 root root   4988 Jun  6  2008 _startnetkey
-rwxr-xr-x 1 root root   4949 Jun  6  2008 _updown
-rwxr-xr-x 1 root root  14030 Jun  6  2008 _updown.klips
-rwxr-xr-x 1 root root  14030 Jun  6  2008 _updown.klips.old
-rwxr-xr-x 1 root root  13739 Jun  6  2008 _updown.mast
-rwxr-xr-x 1 root root  13739 Jun  6  2008 _updown.mast.old
-rwxr-xr-x 1 root root   8337 Jun  6  2008 _updown.netkey
-rwxr-xr-x 1 root root 188348 Jun  6  2008 addconn
-rwxr-xr-x 1 root root   6129 Jun  6  2008 auto
-rwxr-xr-x 1 root root  10758 Jun  6  2008 barf
-rwxr-xr-x 1 root root  90088 Jun  6  2008 eroute
-rwxr-xr-x 1 root root  20708 Jun  6  2008 ikeping
-rwxr-xr-x 1 root root  69804 Jun  6  2008 klipsdebug
-rwxr-xr-x 1 root root   1836 Jun  6  2008 livetest
-rwxr-xr-x 1 root root   2591 Jun  6  2008 look
-rwxr-xr-x 1 root root   1921 Jun  6  2008 newhostkey
-rwxr-xr-x 1 root root  60840 Jun  6  2008 pf_key
-rwxr-xr-x 1 root root 957728 Jun  6  2008 pluto
-rwxr-xr-x 1 root root  10236 Jun  6  2008 ranbits
-rwxr-xr-x 1 root root  20176 Jun  6  2008 rsasigkey
-rwxr-xr-x 1 root root    766 Jun  6  2008 secrets
lrwxrwxrwx 1 root root     30 Jan 20 09:30 setup ->
../../../etc/rc.d/init.d/ipsec
-rwxr-xr-x 1 root root   1054 Jun  6  2008 showdefaults
-rwxr-xr-x 1 root root 219368 Jun  6  2008 showhostkey
-rwxr-xr-x 1 root root  22744 Jun  6  2008 showpolicy
-rwxr-xr-x 1 root root 148388 Jun  6  2008 spi
-rwxr-xr-x 1 root root  77336 Jun  6  2008 spigrp
-rwxr-xr-x 1 root root  69700 Jun  6  2008 tncfg
-rwxr-xr-x 1 root root  12526 Jun  6  2008 verify
-rwxr-xr-x 1 root root  50340 Jun  6  2008 whack
+ _________________________ /proc/net/dev
+ cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed
multicast|bytes    packets errs drop fifo colls carrier compressed
    lo:  452185    8706    0    0    0     0          0         0  
452185    8706    0    0    0     0       0          0
  eth0:392714376  437205    0    0    0     0          0         0
73748491  382403    0    0    0     0       0          0
  pan0:       0       0    0    0    0     0          0         0       
0       0    0    0    0     0       0          0
+ _________________________ /proc/net/route
+ cat /proc/net/route
Iface    Destination    Gateway     Flags    RefCnt    Use    Metric   
Mask        MTU    Window   
IRTT                                                      
eth0    000FA8C0    00000000    0001    0    0    0    00FFFFFF    0   
0   
0                                                                              

eth0    00000000    010FA8C0    0003    0    0    0    00000000    0   
0   
0                                                                              

+ _________________________ /proc/sys/net/ipv4/ip_no_pmtu_disc
+ cat /proc/sys/net/ipv4/ip_no_pmtu_disc
0
+ _________________________ /proc/sys/net/ipv4/ip_forward
+ cat /proc/sys/net/ipv4/ip_forward
0
+ _________________________ /proc/sys/net/ipv4/tcp_ecn
+ cat /proc/sys/net/ipv4/tcp_ecn
0
+ _________________________ /proc/sys/net/ipv4/conf/star-rp_filter
+ cd /proc/sys/net/ipv4/conf
+ egrep '^' all/rp_filter default/rp_filter eth0/rp_filter lo/rp_filter
pan0/rp_filter
all/rp_filter:0
default/rp_filter:1
eth0/rp_filter:1
lo/rp_filter:1
pan0/rp_filter:1
+ _________________________ /proc/sys/net/ipv4/conf/star-star-redirects
+ cd /proc/sys/net/ipv4/conf
+ egrep '^' all/accept_redirects all/secure_redirects all/send_redirects
default/accept_redirects default/secure_redirects default/send_redirects
eth0/accept_redirects eth0/secure_redirects eth0/send_redirects
lo/accept_redirects lo/secure_redirects lo/send_redirects
pan0/accept_redirects pan0/secure_redirects pan0/send_redirects
all/accept_redirects:1
all/secure_redirects:1
all/send_redirects:1
default/accept_redirects:1
default/secure_redirects:1
default/send_redirects:1
eth0/accept_redirects:1
eth0/secure_redirects:1
eth0/send_redirects:1
lo/accept_redirects:1
lo/secure_redirects:1
lo/send_redirects:1
pan0/accept_redirects:1
pan0/secure_redirects:1
pan0/send_redirects:1
+ _________________________ /proc/sys/net/ipv4/tcp_window_scaling
+ cat /proc/sys/net/ipv4/tcp_window_scaling
1
+ _________________________ /proc/sys/net/ipv4/tcp_adv_win_scale
+ cat /proc/sys/net/ipv4/tcp_adv_win_scale
2
+ _________________________ uname-a
+ uname -a
Linux localhost.localdomain 2.6.27.5-41.fc9.i686 #1 SMP Thu Nov 13
20:52:14 EST 2008 i686 i686 i386 GNU/Linux
+ _________________________ config-built-with
+ test -r /proc/config_built_with
+ _________________________ distro-release
+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release
+ test -f /etc/redhat-release
+ cat /etc/redhat-release
Fedora release 9 (Sulphur)
+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release
+ test -f /etc/debian-release
+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release
+ test -f /etc/SuSE-release
+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release
+ test -f /etc/mandrake-release
+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release
+ test -f /etc/mandriva-release
+ for distro in /etc/redhat-release /etc/debian-release
/etc/SuSE-release /etc/mandrake-release /etc/mandriva-release
/etc/gentoo-release
+ test -f /etc/gentoo-release
+ _________________________ /proc/net/ipsec_version
+ test -r /proc/net/ipsec_version
+ test -r /proc/net/pfkey
++ uname -r
+ echo 'NETKEY (2.6.27.5-41.fc9.i686) support detected '
NETKEY (2.6.27.5-41.fc9.i686) support detected
+ _________________________ iptables
+ test -r /sbin/iptables
+ iptables -L -v -n
+ _________________________ iptables-nat
+ iptables -t nat -L -v -n
+ _________________________ iptables-mangle
+ iptables -t mangle -L -v -n
+ _________________________ /proc/modules
+ test -f /proc/modules
+ cat /proc/modules
ipcomp6 6912 0 - Live 0xfacdb000
ipcomp 6656 0 - Live 0xfac54000
ah6 9216 0 - Live 0xfad76000
ah4 8320 0 - Live 0xfacd3000
esp6 9472 0 - Live 0xfaccf000
esp4 9472 0 - Live 0xfaccb000
xfrm4_mode_beet 6400 0 - Live 0xfacbc000
xfrm4_tunnel 6272 0 - Live 0xfacb9000
xfrm4_mode_tunnel 6272 0 - Live 0xfacb6000
xfrm4_mode_transport 5760 0 - Live 0xfacb3000
xfrm6_mode_transport 5760 0 - Live 0xfac86000
xfrm6_mode_ro 5632 0 - Live 0xfac83000
xfrm6_mode_beet 6144 0 - Live 0xfac80000
xfrm6_mode_tunnel 6144 0 - Live 0xfac7d000
af_key 30356 0 - Live 0xfac66000
iptable_mangle 6656 0 - Live 0xfad5d000
iptable_nat 8712 0 - Live 0xfad7a000
nf_nat 17944 1 iptable_nat, Live 0xfad81000
nls_utf8 5632 1 - Live 0xfad73000
deflate 6528 0 - Live 0xfad60000
zlib_deflate 21224 1 deflate, Live 0xfad6c000
ctr 7936 0 - Live 0xfad34000
camellia 22144 0 - Live 0xfad65000
bridge 43668 0 - Live 0xfad47000
stp 6148 1 bridge, Live 0xfad37000
bnep 14848 2 - Live 0xfad2a000
rfcomm 33936 4 - Live 0xfad53000
rmd160 14720 0 - Live 0xfad2f000
l2cap 21504 16 bnep,rfcomm, Live 0xfad18000
bluetooth 48608 5 bnep,rfcomm,l2cap, Live 0xfad3a000
crypto_null 6784 0 - Live 0xfad0f000
ccm 11776 0 - Live 0xfad26000
serpent 22912 0 - Live 0xfad1f000
blowfish 12032 0 - Live 0xfacf7000
twofish 10880 0 - Live 0xfad0b000
twofish_common 17024 1 twofish, Live 0xfad12000
ecb 6528 0 - Live 0xfad08000
xcbc 8200 0 - Live 0xfad04000
cbc 7168 0 - Live 0xfacfb000
crypto_blkcipher 18052 5 ctr,crypto_null,ccm,ecb,cbc, Live 0xfacfe000
sha256_generic 16128 0 - Live 0xfacee000
sha512_generic 11904 0 - Live 0xfacf3000
des_generic 20352 0 - Live 0xfacde000
aes_i586 11648 0 - Live 0xfacbf000
aes_generic 31144 1 aes_i586, Live 0xface5000
xfrm_ipcomp 8584 2 ipcomp6,ipcomp, Live 0xfacd7000
aead 9600 3 esp6,esp4,ccm, Live 0xfacc3000
tunnel4 6792 1 xfrm4_tunnel, Live 0xfac51000
xfrm6_tunnel 9860 1 ipcomp6, Live 0xfac62000
tunnel6 6664 1 xfrm6_tunnel, Live 0xfac5f000
fuse 49436 3 - Live 0xfac6f000
sunrpc 155924 3 - Live 0xfac8b000
ipt_REJECT 6656 2 - Live 0xfac5c000
nf_conntrack_ipv4 11528 5 iptable_nat,nf_nat, Live 0xfab28000
iptable_filter 6528 1 - Live 0xfac40000
ip_tables 13712 3 iptable_mangle,iptable_nat,iptable_filter, Live 0xfac57000
ip6t_REJECT 7296 2 - Live 0xfac38000
xt_tcpudp 6656 2 - Live 0xfac35000
nf_conntrack_ipv6 15864 2 - Live 0xfac3b000
xt_state 5888 4 - Live 0xfac32000
nf_conntrack 51424 5
iptable_nat,nf_nat,nf_conntrack_ipv4,nf_conntrack_ipv6,xt_state, Live
0xfac43000
ip6table_filter 6400 1 - Live 0xfab2c000
ip6_tables 14736 1 ip6table_filter, Live 0xf8ade000
x_tables 15236 7
iptable_nat,ipt_REJECT,ip_tables,ip6t_REJECT,xt_tcpudp,xt_state,ip6_tables,
Live 0xf8ad1000
cpufreq_ondemand 9868 2 - Live 0xf8ada000
acpi_cpufreq 12172 0 - Live 0xf8ad6000
dm_multipath 17292 0 - Live 0xf8a59000
scsi_dh 9476 1 dm_multipath, Live 0xf89d2000
radeon 119044 3 - Live 0xf8b08000
drm 146404 4 radeon, Live 0xf8ae3000
ipv6 230260 39
ipcomp6,ah6,esp6,xfrm6_mode_beet,xfrm6_mode_tunnel,xfrm6_tunnel,tunnel6,ip6t_REJECT,nf_conntrack_ipv6,
Live 0xf8a1f000
snd_hda_intel 351380 3 - Live 0xf8a5f000
snd_seq_dummy 6660 0 - Live 0xf89a3000
snd_seq_oss 30364 0 - Live 0xf89e3000
snd_seq_midi_event 9600 1 snd_seq_oss, Live 0xf89b0000
snd_seq 48576 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event, Live
0xf89d6000
snd_seq_device 9996 3 snd_seq_dummy,snd_seq_oss,snd_seq, Live 0xf89ac000
snd_pcm_oss 42496 0 - Live 0xf89ba000
snd_mixer_oss 16896 1 snd_pcm_oss, Live 0xf89a6000
snd_pcm 65924 2 snd_hda_intel,snd_pcm_oss, Live 0xf896e000
snd_timer 22024 2 snd_seq,snd_pcm, Live 0xf8926000
snd_page_alloc 11016 2 snd_hda_intel,snd_pcm, Live 0xf896a000
snd_hwdep 10500 1 snd_hda_intel, Live 0xf8937000
ppdev 10372 0 - Live 0xf8933000
snd 50744 16
snd_hda_intel,snd_seq_dummy,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_hwdep,
Live 0xf8991000
parport_pc 25620 0 - Live 0xf893d000
parport 31956 2 ppdev,parport_pc, Live 0xf8961000
dcdbas 10272 0 - Live 0xf891e000
sr_mod 17064 1 - Live 0xf892d000
tg3 107780 0 - Live 0xf8945000
serio_raw 8836 0 - Live 0xf8922000
libphy 18560 1 tg3, Live 0xf88fd000
soundcore 9416 1 snd, Live 0xf891a000
iTCO_wdt 13732 0 - Live 0xf8903000
cdrom 32664 1 sr_mod, Live 0xf8911000
i2c_i801 12048 0 - Live 0xf88ca000
iTCO_vendor_support 6916 1 iTCO_wdt, Live 0xf8834000
pcspkr 6272 0 - Live 0xf88ba000
i2c_core 21396 2 drm,i2c_i801, Live 0xf88f0000
sg 31028 0 - Live 0xf8908000
dm_snapshot 19364 0 - Live 0xf88f7000
dm_zero 5632 0 - Live 0xf88ad000
dm_mirror 19968 0 - Live 0xf88b4000
dm_log 12164 1 dm_mirror, Live 0xf884e000
dm_mod 48692 10 dm_multipath,dm_snapshot,dm_zero,dm_mirror,dm_log, Live
0xf88bd000
pata_acpi 7680 0 - Live 0xf884b000
ata_generic 8452 0 - Live 0xf8847000
ata_piix 24836 3 - Live 0xf88a5000
libata 134380 3 pata_acpi,ata_generic,ata_piix, Live 0xf88ce000
sd_mod 32408 3 - Live 0xf889c000
scsi_mod 123772 5 scsi_dh,sr_mod,sg,libata,sd_mod, Live 0xf885f000
crc_t10dif 5632 1 sd_mod, Live 0xf8844000
ext3 109192 2 - Live 0xf8880000
jbd 42900 1 ext3, Live 0xf8853000
mbcache 10244 1 ext3, Live 0xf8839000
uhci_hcd 23312 0 - Live 0xf883d000
ohci_hcd 24336 0 - Live 0xf8824000
ehci_hcd 32524 0 - Live 0xf882b000
+ _________________________ /proc/meminfo
+ cat /proc/meminfo
MemTotal:      2072476 kB
MemFree:         87604 kB
Buffers:        160136 kB
Cached:         779088 kB
SwapCached:         32 kB
Active:        1195048 kB
Inactive:       559600 kB
HighTotal:     1177596 kB
HighFree:        12000 kB
LowTotal:       894880 kB
LowFree:         75604 kB
SwapTotal:     2031608 kB
SwapFree:      2031456 kB
Dirty:             176 kB
Writeback:           0 kB
AnonPages:      815192 kB
Mapped:         143760 kB
Slab:           129540 kB
SReclaimable:   110380 kB
SUnreclaim:      19160 kB
PageTables:       7032 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
WritebackTmp:        0 kB
CommitLimit:   3067844 kB
Committed_AS:  1478656 kB
VmallocTotal:   110584 kB
VmallocUsed:     38328 kB
VmallocChunk:    72156 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
HugePages_Surp:      0
Hugepagesize:     4096 kB
DirectMap4k:      8192 kB
DirectMap4M:    909312 kB
+ _________________________ /proc/net/ipsec-ls
+ test -f /proc/net/ipsec_version
+ _________________________ usr/src/linux/.config
+ test -f /proc/config.gz
++ uname -r
+ test -f /lib/modules/2.6.27.5-41.fc9.i686/build/.config
+ echo 'no .config file found, cannot list kernel properties'
no .config file found, cannot list kernel properties
+ _________________________ etc/syslog.conf
+ _________________________ etc/syslog-ng/syslog-ng.conf
+ cat /etc/syslog-ng/syslog-ng.conf
cat: /etc/syslog-ng/syslog-ng.conf: No such file or directory
+ cat /etc/syslog.conf
cat: /etc/syslog.conf: No such file or directory
+ _________________________ etc/resolv.conf
+ cat /etc/resolv.conf
# generated by NetworkManager, do not edit!

nameserver 192.168.15.1

+ _________________________ lib/modules-ls
+ ls -ltr /lib/modules
total 12
drwxr-xr-x 7 root root 4096 Oct 24 17:56 2.6.26.6-79.fc9.i686
drwxr-xr-x 7 root root 4096 Nov 15 12:00 2.6.27.5-37.fc9.i686
drwxr-xr-x 7 root root 4096 Nov 19 13:03 2.6.27.5-41.fc9.i686
+ _________________________ /proc/ksyms-netif_rx
+ test -r /proc/ksyms
+ test -r /proc/kallsyms
+ egrep netif_rx /proc/kallsyms
c05d6055 T netif_rx
c05d6697 T netif_rx_ni
c072abbc r __ksymtab_netif_rx
c072acc4 r __ksymtab_netif_rx_ni
c073b292 r __kstrtab_netif_rx
c073b4ce r __kstrtab_netif_rx_ni
c05d6697 u netif_rx_ni    [bnep]
c05d6055 u netif_rx    [ipv6]
f894f103 t netif_rx_schedule    [tg3]
f8950af8 t netif_rx_complete    [tg3]
+ _________________________ lib/modules-netif_rx
+ modulegoo kernel/net/ipv4/ipip.o netif_rx
+ set +x
2.6.26.6-79.fc9.i686:
2.6.27.5-37.fc9.i686:
2.6.27.5-41.fc9.i686:
+ _________________________ kern.debug
+ test -f /var/log/kern.debug
+ _________________________ klog
+ sed -n '1151,$p' /var/log/messages
+ egrep -i 'ipsec|klips|pluto'
+ case "$1" in
+ cat
Jan 26 09:36:38 localhost ipsec_setup: Starting Openswan IPsec
U2.6.14/K2.6.27.5-41.fc9.i686...
Jan 26 09:36:38 localhost ipsec_setup:
Jan 26 09:36:38 localhost ipsec_setup:
Jan 26 09:36:38 localhost setroubleshoot: SELinux is preventing logger
(ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
Jan 26 09:36:39 localhost setroubleshoot: SELinux is preventing logger
(ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
Jan 26 09:36:39 localhost setroubleshoot: SELinux is preventing logger
(ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
Jan 26 09:36:39 localhost setroubleshoot: SELinux is preventing logger
(ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
Jan 26 09:36:40 localhost setroubleshoot: SELinux is preventing logger
(ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
Jan 26 09:36:40 localhost setroubleshoot: SELinux is preventing auto
(ipsec_mgmt_t) "execute_no_trans" to /bin/bash (shell_exec_t). For
complete SELinux messages. run sealert -l
12b4c94d-97f6-41cb-886f-048b26a24b1f
Jan 26 09:36:40 localhost setroubleshoot: SELinux is preventing logger
(ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
Jan 26 09:36:40 localhost setroubleshoot: SELinux is preventing auto
(ipsec_mgmt_t) "execute_no_trans" to /bin/bash (shell_exec_t). For
complete SELinux messages. run sealert -l
12b4c94d-97f6-41cb-886f-048b26a24b1f
Jan 26 09:36:41 localhost setroubleshoot: SELinux is preventing logger
(ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
Jan 26 09:36:41 localhost setroubleshoot: SELinux is preventing auto
(ipsec_mgmt_t) "execute_no_trans" to /bin/bash (shell_exec_t). For
complete SELinux messages. run sealert -l
12b4c94d-97f6-41cb-886f-048b26a24b1f
Jan 26 09:36:41 localhost setroubleshoot: SELinux is preventing logger
(ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
Jan 26 09:36:41 localhost setroubleshoot: SELinux is preventing auto
(ipsec_mgmt_t) "execute_no_trans" to /bin/bash (shell_exec_t). For
complete SELinux messages. run sealert -l
12b4c94d-97f6-41cb-886f-048b26a24b1f
Jan 26 09:36:42 localhost setroubleshoot: SELinux is preventing logger
(ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
Jan 26 09:36:42 localhost setroubleshoot: SELinux is preventing auto
(ipsec_mgmt_t) "execute_no_trans" to /bin/bash (shell_exec_t). For
complete SELinux messages. run sealert -l
12b4c94d-97f6-41cb-886f-048b26a24b1f
Jan 26 09:36:42 localhost setroubleshoot: SELinux is preventing logger
(ipsec_mgmt_t) "write" to log (devlog_t). For complete SELinux messages.
run sealert -l 68eff3d4-9eec-4f59-91c1-4d0cde3d88a2
+ _________________________ plog
+ sed -n '5,$p' /var/log/secure
+ egrep -i pluto
+ case "$1" in
+ cat
Jan 26 09:33:17 localhost pluto[20993]: Starting Pluto (Openswan Version
2.6.14; Vendor ID OEoSJUweaqAX) pid:20993
Jan 26 09:33:17 localhost pluto[20993]: Setting NAT-Traversal port-4500
floating to on
Jan 26 09:33:17 localhost pluto[20993]:    port floating activation
criteria nat_t=1/port_float=1
Jan 26 09:33:17 localhost pluto[20993]:    including NAT-Traversal patch
(Version 0.6c)
Jan 26 09:33:17 localhost pluto[20993]: using /dev/urandom as source of
random entropy
Jan 26 09:33:17 localhost pluto[20993]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
Jan 26 09:33:17 localhost pluto[20993]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
Jan 26 09:33:17 localhost pluto[20993]: ike_alg_register_enc():
Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
Jan 26 09:33:17 localhost pluto[20993]: ike_alg_register_enc():
Activating OAKLEY_AES_CBC: Ok (ret=0)
Jan 26 09:33:17 localhost pluto[20993]: ike_alg_register_enc():
Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
Jan 26 09:33:17 localhost pluto[20993]: ike_alg_register_hash():
Activating OAKLEY_SHA2_512: Ok (ret=0)
Jan 26 09:33:17 localhost pluto[20993]: ike_alg_register_hash():
Activating OAKLEY_SHA2_256: Ok (ret=0)
Jan 26 09:33:17 localhost pluto[20993]: starting up 1 cryptographic helpers
Jan 26 09:33:17 localhost pluto[21003]: using /dev/urandom as source of
random entropy
Jan 26 09:33:17 localhost pluto[20993]: started helper pid=21003 (fd:7)
Jan 26 09:33:17 localhost pluto[20993]: Using Linux 2.6 IPsec interface
code on 2.6.27.5-41.fc9.i686 (experimental code)
Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc():
Activating <NULL>: Ok (ret=0)
Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:33:18 localhost pluto[20993]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:33:18 localhost pluto[20993]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:33:18 localhost pluto[20993]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:33:18 localhost pluto[20993]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:33:18 localhost pluto[20993]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 26 09:33:18 localhost pluto[20993]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 26 09:33:18 localhost pluto[20993]: Could not change to directory
'/etc/ipsec.d/cacerts': /etc/ipsec.d
Jan 26 09:33:18 localhost pluto[20993]: Could not change to directory
'/etc/ipsec.d/aacerts': /etc/ipsec.d
Jan 26 09:33:18 localhost pluto[20993]: Could not change to directory
'/etc/ipsec.d/ocspcerts': /etc/ipsec.d
Jan 26 09:33:18 localhost pluto[20993]: Could not change to directory
'/etc/ipsec.d/crls'
Jan 26 09:33:18 localhost pluto[20993]: Changing back to directory
'/etc/ipsec.d' failed - (2 No such file or directory)
Jan 26 09:33:18 localhost pluto[20993]: Changing back to directory
'/etc/ipsec.d' failed - (2 No such file or directory)
Jan 26 09:33:18 localhost pluto[20993]: added connection description "vo"
Jan 26 09:33:18 localhost pluto[20993]: added connection description "vodmz"
Jan 26 09:33:28 localhost pluto[20993]: shutting down
Jan 26 09:33:28 localhost pluto[20993]: "vodmz": deleting connection
Jan 26 09:33:28 localhost pluto[20993]: "vo": deleting connection
Jan 26 09:33:31 localhost pluto[21368]: Starting Pluto (Openswan Version
2.6.14; Vendor ID OEoSJUweaqAX) pid:21368
Jan 26 09:33:31 localhost pluto[21368]: Setting NAT-Traversal port-4500
floating to on
Jan 26 09:33:31 localhost pluto[21368]:    port floating activation
criteria nat_t=1/port_float=1
Jan 26 09:33:31 localhost pluto[21368]:    including NAT-Traversal patch
(Version 0.6c)
Jan 26 09:33:31 localhost pluto[21368]: using /dev/urandom as source of
random entropy
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc():
Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc():
Activating OAKLEY_AES_CBC: Ok (ret=0)
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc():
Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_hash():
Activating OAKLEY_SHA2_512: Ok (ret=0)
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_hash():
Activating OAKLEY_SHA2_256: Ok (ret=0)
Jan 26 09:33:31 localhost pluto[21368]: starting up 1 cryptographic helpers
Jan 26 09:33:31 localhost pluto[21371]: using /dev/urandom as source of
random entropy
Jan 26 09:33:31 localhost pluto[21368]: started helper pid=21371 (fd:7)
Jan 26 09:33:31 localhost pluto[21368]: Using Linux 2.6 IPsec interface
code on 2.6.27.5-41.fc9.i686 (experimental code)
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc():
Activating <NULL>: Ok (ret=0)
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 26 09:33:31 localhost pluto[21368]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 26 09:33:31 localhost pluto[21368]: Could not change to directory
'/etc/ipsec.d/cacerts': /etc/ipsec.d
Jan 26 09:33:31 localhost pluto[21368]: Could not change to directory
'/etc/ipsec.d/aacerts': /etc/ipsec.d
Jan 26 09:33:31 localhost pluto[21368]: Could not change to directory
'/etc/ipsec.d/ocspcerts': /etc/ipsec.d
Jan 26 09:33:31 localhost pluto[21368]: Could not change to directory
'/etc/ipsec.d/crls'
Jan 26 09:33:31 localhost pluto[21368]: Changing back to directory
'/etc/ipsec.d' failed - (2 No such file or directory)
Jan 26 09:33:31 localhost pluto[21368]: Changing back to directory
'/etc/ipsec.d' failed - (2 No such file or directory)
Jan 26 09:33:31 localhost pluto[21368]: added connection description "vo"
Jan 26 09:33:31 localhost pluto[21368]: added connection description "vodmz"
Jan 26 09:34:10 localhost pluto[21368]: shutting down
Jan 26 09:34:10 localhost pluto[21368]: "vodmz": deleting connection
Jan 26 09:34:10 localhost pluto[21368]: "vo": deleting connection
Jan 26 09:34:12 localhost pluto[21750]: Starting Pluto (Openswan Version
2.6.14; Vendor ID OEoSJUweaqAX) pid:21750
Jan 26 09:34:12 localhost pluto[21750]: Setting NAT-Traversal port-4500
floating to on
Jan 26 09:34:12 localhost pluto[21750]:    port floating activation
criteria nat_t=1/port_float=1
Jan 26 09:34:12 localhost pluto[21750]:    including NAT-Traversal patch
(Version 0.6c)
Jan 26 09:34:12 localhost pluto[21750]: using /dev/urandom as source of
random entropy
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc():
Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc():
Activating OAKLEY_AES_CBC: Ok (ret=0)
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc():
Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_hash():
Activating OAKLEY_SHA2_512: Ok (ret=0)
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_hash():
Activating OAKLEY_SHA2_256: Ok (ret=0)
Jan 26 09:34:12 localhost pluto[21750]: starting up 1 cryptographic helpers
Jan 26 09:34:12 localhost pluto[21752]: using /dev/urandom as source of
random entropy
Jan 26 09:34:12 localhost pluto[21750]: started helper pid=21752 (fd:7)
Jan 26 09:34:12 localhost pluto[21750]: Using Linux 2.6 IPsec interface
code on 2.6.27.5-41.fc9.i686 (experimental code)
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc():
Activating <NULL>: Ok (ret=0)
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 26 09:34:12 localhost pluto[21750]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 26 09:34:12 localhost pluto[21750]: Could not change to directory
'/etc/ipsec.d/cacerts': /etc/ipsec.d
Jan 26 09:34:12 localhost pluto[21750]: Could not change to directory
'/etc/ipsec.d/aacerts': /etc/ipsec.d
Jan 26 09:34:12 localhost pluto[21750]: Could not change to directory
'/etc/ipsec.d/ocspcerts': /etc/ipsec.d
Jan 26 09:34:12 localhost pluto[21750]: Could not change to directory
'/etc/ipsec.d/crls'
Jan 26 09:34:12 localhost pluto[21750]: Changing back to directory
'/etc/ipsec.d' failed - (2 No such file or directory)
Jan 26 09:34:12 localhost pluto[21750]: Changing back to directory
'/etc/ipsec.d' failed - (2 No such file or directory)
Jan 26 09:34:12 localhost pluto[21750]: added connection description "vo"
Jan 26 09:34:12 localhost pluto[21750]: added connection description "vodmz"
Jan 26 09:36:36 localhost pluto[21750]: shutting down
Jan 26 09:36:36 localhost pluto[21750]: "vodmz": deleting connection
Jan 26 09:36:36 localhost pluto[21750]: "vo": deleting connection
Jan 26 09:36:38 localhost pluto[22267]: Starting Pluto (Openswan Version
2.6.14; Vendor ID OEoSJUweaqAX) pid:22267
Jan 26 09:36:38 localhost pluto[22267]: Setting NAT-Traversal port-4500
floating to on
Jan 26 09:36:38 localhost pluto[22267]:    port floating activation
criteria nat_t=1/port_float=1
Jan 26 09:36:38 localhost pluto[22267]:    including NAT-Traversal patch
(Version 0.6c)
Jan 26 09:36:38 localhost pluto[22267]: using /dev/urandom as source of
random entropy
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC_SSH: Ok (ret=0)
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc():
Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc():
Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc():
Activating OAKLEY_AES_CBC: Ok (ret=0)
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc():
Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_hash():
Activating OAKLEY_SHA2_512: Ok (ret=0)
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_hash():
Activating OAKLEY_SHA2_256: Ok (ret=0)
Jan 26 09:36:38 localhost pluto[22267]: starting up 1 cryptographic helpers
Jan 26 09:36:38 localhost pluto[22268]: using /dev/urandom as source of
random entropy
Jan 26 09:36:38 localhost pluto[22267]: started helper pid=22268 (fd:7)
Jan 26 09:36:38 localhost pluto[22267]: Using Linux 2.6 IPsec interface
code on 2.6.27.5-41.fc9.i686 (experimental code)
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc():
Activating <NULL>: Ok (ret=0)
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc(): WARNING:
enc alg=0 not found in constants.c:oakley_enc_names 
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_add(): ERROR: Algorithm
already exists
Jan 26 09:36:38 localhost pluto[22267]: ike_alg_register_enc():
Activating <NULL>: FAILED (ret=-17)
Jan 26 09:36:39 localhost pluto[22267]: Could not change to directory
'/etc/ipsec.d/cacerts': /etc/ipsec.d
Jan 26 09:36:39 localhost pluto[22267]: Could not change to directory
'/etc/ipsec.d/aacerts': /etc/ipsec.d
Jan 26 09:36:39 localhost pluto[22267]: Could not change to directory
'/etc/ipsec.d/ocspcerts': /etc/ipsec.d
Jan 26 09:36:39 localhost pluto[22267]: Could not change to directory
'/etc/ipsec.d/crls'
Jan 26 09:36:39 localhost pluto[22267]: Changing back to directory
'/etc/ipsec.d' failed - (2 No such file or directory)
Jan 26 09:36:39 localhost pluto[22267]: Changing back to directory
'/etc/ipsec.d' failed - (2 No such file or directory)
Jan 26 09:36:39 localhost pluto[22267]: added connection description "vo"
Jan 26 09:36:39 localhost pluto[22267]: added connection description "vodmz"
+ _________________________ date
+ date
Mon Jan 26 09:41:09 EST 2009


-- 
Chris Garrigues
Senior System Administrator
Ph: (512) 961-6808
chris.garrigues at SteepRockInc.com <mailto:chris.garrigues at SteepRockInc.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090126/151985c2/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SteepRockLogo.gif
Type: image/gif
Size: 2419 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/users/attachments/20090126/151985c2/attachment-0001.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.openswan.org/pipermail/users/attachments/20090126/151985c2/attachment-0001.bin 

From Philipp.Weirauch at checkmobile.de  Wed Jan 28 07:43:31 2009
From: Philipp.Weirauch at checkmobile.de (Philipp.Weirauch at checkmobile.de)
Date: Wed, 28 Jan 2009 13:43:31 +0100
Subject: [Openswan Users] PPP tty is not open yet error
Message-ID: <OF66589952.5379C3AB-ONC125754C.0042C132-C125754C.0045E72E@checkmobile.de>

hi all,
I seem to miss something quite basic :-) trying now since 4 weeks to get 
the vpn up and running - the ipsec seems to work, the l2tp also gets up 
(at least thats how i interpret it), BUT the ppp is not coming up with its 
ppp0 device. since I have no integrated modem but run over a system with 2 
internal ethernet network cards, I am not getting how to set up the ppp 
daemon to produce correct ppp0 devices :-(
system: opensuse 11.0, kernel 2.6.25.18-0.2-default, l2tpd from Jacco de 
Leeuw. (I read through the whole mailing list, and found nothing except a 
fedora user with a similar problem in 2004. the solution was there to get 
some "character devices" configured within the kernel. but I have no idea 
of how to do that with suse...)
i start the ipsec, than the l2tp, but what to do with the ppp? is'nt that 
a process which is called by l2tpd? and how do I "teach" pppd to come up 
with a ppp0 device?? (10 years ago with old modems I knew I did it, but 
now, without any modems, I am lost, somewhat - and all the ppp how-to only 
explain the "modem"-case...)
anyone with any helpfull idea?
best regards,
philipp
philipp weirauch
hamburg, germany

ps: below the var/log/messages from the experimental server.
the client is a mac-book pro osx (but that does not seem to be of any 
problem, right?)

Jan 28 10:44:20 vpn l2tpd[8262]: check_control: control, cid = 0, Ns = 0, 
Nr = 0
Jan 28 10:44:20 vpn l2tpd[8262]: handle_avps: handling avp's for tunnel 
1435, call 0
Jan 28 10:44:20 vpn l2tpd[8262]: message_type_avp: message type 1 
(Start-Control-Connection-Request)
Jan 28 10:44:20 vpn l2tpd[8262]: protocol_version_avp: peer is using 
version 1, revision 0.
Jan 28 10:44:20 vpn l2tpd[8262]: framing_caps_avp: supported peer frames: 
async sync
Jan 28 10:44:20 vpn l2tpd[8262]: hostname_avp: peer reports hostname ''
Jan 28 10:44:20 vpn l2tpd[8262]: assigned_tunnel_avp: using peer's tunnel 
8
Jan 28 10:44:20 vpn l2tpd[8262]: receive_window_size_avp: peer wants RWS 
of 4.  Will use flow control.
Jan 28 10:44:20 vpn l2tpd[8262]: check_control: control, cid = 0, Ns = 1, 
Nr = 1
Jan 28 10:44:20 vpn l2tpd[8262]: handle_avps: handling avp's for tunnel 
1435, call 0
Jan 28 10:44:20 vpn l2tpd[8262]: message_type_avp: message type 3 
(Start-Control-Connection-Connected)
Jan 28 10:44:20 vpn l2tpd[8262]: control_finish: Connection established to 
85.182.252.146, 52011.  Local: 1435, Remote: 8.  LNS session is 'default'
Jan 28 10:44:20 vpn l2tpd[8262]: check_control: control, cid = 0, Ns = 2, 
Nr = 1
Jan 28 10:44:20 vpn l2tpd[8262]: handle_avps: handling avp's for tunnel 
1435, call 0
Jan 28 10:44:20 vpn l2tpd[8262]: message_type_avp: message type 10 
(Incoming-Call-Request)
Jan 28 10:44:20 vpn l2tpd[8262]: message_type_avp: new incoming call
Jan 28 10:44:20 vpn l2tpd[8262]: ourcid = 10644, entropy_buf = 2994
Jan 28 10:44:20 vpn l2tpd[8262]: assigned_call_avp: using peer's call 5018
Jan 28 10:44:20 vpn l2tpd[8262]: call_serno_avp: serial number is 1
Jan 28 10:44:20 vpn l2tpd[8262]: check_control: control, cid = 5018, Ns = 
3, Nr = 2
Jan 28 10:44:20 vpn l2tpd[8262]: handle_avps: handling avp's for tunnel 
1435, call 10644
Jan 28 10:44:20 vpn l2tpd[8262]: message_type_avp: message type 12 
(Incoming-Call-Connected)
Jan 28 10:44:20 vpn l2tpd[8262]: tx_speed_avp: transmit baud rate is 
1000000
Jan 28 10:44:20 vpn l2tpd[8262]: frame_type_avp: peer uses: async frames
Jan 28 10:44:20 vpn l2tpd[8262]: getPtyMaster: No more free pseudo-tty's
Jan 28 10:44:20 vpn l2tpd[8262]: start_pppd: unable to allocate pty, 
abandoning!
Jan 28 10:44:20 vpn l2tpd[8262]: control_finish: Call established with 
85.182.252.146, Local: 10644, Remote: 5018, Serial: 1

Jan 28 10:44:20 vpn l2tpd[8262]: write_packet: tty is not open yet.

Jan 28 10:44:20 vpn pluto[7812]: "L2TP-PSK-NAT"[2] 85.182.252.146 #2: 
transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Jan 28 10:44:20 vpn pluto[7812]: "L2TP-PSK-NAT"[2] 85.182.252.146 #2: 
STATE_QUICK_R2: IPsec SA established {ESP/NAT=>0x0dfeb849 <0xa94bd7f7 
xfrm=AES_128-HMAC_SHA1 NATD=85.182.252.146:4500 DPD=none}

Jan 28 10:44:23 vpn l2tpd[8262]: write_packet: tty is not open yet.

Jan 28 10:44:50 vpn syslog-ng[2251]: last message repeated 8 times
Jan 28 10:44:50 vpn l2tpd[8262]: check_control: control, cid = 5018, Ns = 
4, Nr = 2
Jan 28 10:44:50 vpn l2tpd[8262]: handle_avps: handling avp's for tunnel 
1435, call 10644
Jan 28 10:44:50 vpn l2tpd[8262]: message_type_avp: message type 14 
(Call-Disconnect-Notify)


From denis.beltramo at gmail.com  Thu Jan 29 11:58:07 2009
From: denis.beltramo at gmail.com (Denis Beltramo)
Date: Thu, 29 Jan 2009 17:58:07 +0100
Subject: [Openswan Users] Problem with PSK - Certificate and iphone
Message-ID: <27f0c3e40901290858j2113f41aj35cac8576a60df6@mail.gmail.com>

Hello,

I have many problem with openswan.

I have now the iPhone.. so I have make the connection for this (see below)..
When i connect with mobile card (my iphone have a public ip) work,
when connect with a wireless behind nat NOT work
when connect with a windows xp behind nat to roadwarrior-iphone work.
the error is:

an 23 20:14:05 vpnserver pluto[10098]: "roadwarrior-iphone"[2]
11.22.33.44 #1: STATE_MAIN_R3: sent MR3, ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
group=modp1024}
Jan 23 20:14:05 vpnserver pluto[10098]: "roadwarrior-iphone"[2]
11.22.33.44 #1: ignoring informational payload, type
IPSEC_INITIAL_CONTACT
Jan 23 20:14:05 vpnserver pluto[10098]: "roadwarrior-iphone"[2]
11.22.33.44 #1: received and ignored informational message
Jan 23 20:14:06 vpnserver pluto[10098]: "roadwarrior-iphone"[2]
11.22.33.44 #1: cannot respond to IPsec SA request because no
connection is known for
123.123.123.124:17/1701...11.22.33.44[192.168.2.13]:17/49156===192.168.2.13/32
Jan 23 20:14:06 vpnserver pluto[10098]: "roadwarrior-iphone"[2]
11.22.33.44 #1: sending encrypted notification INVALID_ID_INFORMATION
to 11.22.33.44:36071

The the old connection (roadwarrior) with certificate don't work and say:

an 29 17:05:27 vpnserver pluto[6105]: "roadwarrior"[26] 22.43.21.44
#36: Dead Peer Detection (RFC 3706): not enabled because peer did not
advertise it
Jan 29 17:05:27 vpnserver pluto[6105]: "roadwarrior"[26] 22.43.21.44
#36: retransmitting in response to duplicate packet; already
STATE_MAIN_R3
Jan 29 17:05:27 vpnserver pluto[6105]: "roadwarrior"[26] 22.43.21.44
#37: responding to Quick Mode {msgid:6a15fc54}
Jan 29 17:05:27 vpnserver pluto[6105]: "roadwarrior"[26] 22.43.21.44
#37: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Jan 29 17:05:27 vpnserver pluto[6105]: "roadwarrior"[26] 22.43.21.44
#37: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting
QI2
Jan 29 17:05:28 vpnserver pluto[6105]: "roadwarrior"[26] 22.43.21.44
#37: Dead Peer Detection (RFC 3706): not enabled because peer did not
advertise it
Jan 29 17:05:28 vpnserver pluto[6105]: "roadwarrior"[26] 22.43.21.44
#37: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Jan 29 17:05:28 vpnserver pluto[6105]: "roadwarrior"[26] 22.43.21.44
#37: STATE_QUICK_R2: IPsec SA established {ESP/NAT=>0x00f59a30
<0x3e0da257 xfrm=3DES_0-HMAC_SHA1 NATD=22.43.21.44:4500 DPD=none}

You say the how to resolve my problem?

The conf file:


version 2.0

config setup
        interfaces=%defaultroute
        virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!172.31.1.0/24
        nat_traversal=yes

conn %default
        keyingtries=3
        compress=no
        disablearrivalcheck=no
        authby=rsasig
        keyexchange=ike
        ikelifetime=240m
        keylife=60m

conn roadwarrior
        left=123.123.123.123
        leftcert=/etc/ipsec.d/certs/server2Cert.pem
        leftid=123.123.123.123
        leftrsasigkey=%cert
        leftnexthop=%defaultroute
        rightrsasigkey=%cert
        leftprotoport=17/1701
        rightprotoport=17/%any
        rightsubnet=vhost:%priv,%no
        forceencaps=yes
        rightca=%same
        right=%any
        dpddelay=30
        dpdtimeout=120
        dpdaction=hold
        type=transport
        auto=add
        pfs=no

conn roadwarrior-iphone
        authby=secret
        rekey=no
        keyingtries=3
        left=123.123.123.124
        leftnexthop=%defaultroute
        leftprotoport=17/1701
        right=%any
        rightprotoport=17/%any
        pfs=no
        auto=add

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


-- 
Denis Beltramo

From aespanola at arts.ucla.edu  Fri Jan 30 13:28:31 2009
From: aespanola at arts.ucla.edu (Arnel Espanola)
Date: Fri, 30 Jan 2009 10:28:31 -0800
Subject: [Openswan Users] Troubleshooting assistance on openswan 2.6.19
Message-ID: <498346CF.6090108@arts.ucla.edu>

Hello there,

I've been running this version of Openswan on Fedora 6 for a while
without a problem. And I'm using xl2tpd-1.1.11-2.fc6 for L2TP.

Linux Openswan U2.4.5/K2.6.22.14-72.fc6 (netkey)

But recently I decided to install the latest version of Openswan on
CentOS5 and I'm having issues with it and I couldn't find the solution
for it. And I installed L2TP from source, l2tpd-0.69cvs20051030-1jdl.
Not sure if the L2TP is what causing the problem.

Linux Openswan U2.6.19/K2.6.18-92.1.22.el5 (netkey)


I just copied the my ipsec.config from old version. And kept some
default config from the new version.


/etc/ipsec.conf


config setup
	# Do not set debug= options to debug configuration issues!
	# plutodebug / klipsdebug = "all", "none" or a combation from below:
	# "raw crypt parsing emitting control klips pfkey natt x509 dpd private"
	# eg:
	# plutodebug="control parsing"
	#
	# enable to get logs per-peer
	# plutoopts="--perpeerlog"
	#
	# Only enable *debug=all if you are a developer
	#
	# NAT-TRAVERSAL support, see README.NAT-Traversal
	nat_traversal=yes
	# exclude networks used on server side by adding %v4:!a.b.c.0/24
	virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%4:172.16.0.0/12
	# OE is now off by default. Uncomment and change to on, to enable.
	OE=off
	# which IPsec stack to use. netkey,klips,mast,auto or none
	protostack=netkey
	 interfaces=%defaultroute
     klipsdebug=none
     plutodebug=none
    #  overridemtu=1410
     protostack=netkey
     nat_traversal=yes
     virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16

# Add connections here


conn %default
     keyingtries=3
     compress=yes
     disablearrivalcheck=no
     authby=secret
     type=tunnel
     keyexchange=ike
     ikelifetime=240m
     keylife=60m
conn roadwarrior-all
     leftsubnet=0.0.0.0/0
     also=roadwarrior
conn roadwarrior-l2tp
     leftprotoport=17/0
     rightprotoport=17/1701
     also=roadwarrior
conn roadwarrior-l2tp-macosx
     leftprotoport=17/1701
     rightprotoport=17/%any
     also=roadwarrior
conn roadwarrior-l2tp-updatedwin
     leftprotoport=17/1701
     rightprotoport=17/1701
     also=roadwarrior
conn roadwarrior
     pfs=no
     left=192.168.1.21
     leftnexthop=192.168.1.254
     right=%any
     auto=add


and here's the log. and it seems ipsec got established but not the L2TP.
I don't see anything being logged in ppp directory.

/var/log/secure

Jan 30 09:45:25 test pluto[26674]: packet from 10.10.10.41:500: ignoring
Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
Jan 30 09:45:25 test pluto[26674]: packet from 10.10.10.41:500: ignoring
Vendor ID payload [FRAGMENTATION]
Jan 30 09:45:25 test pluto[26674]: packet from 10.10.10.41:500: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set to=106
Jan 30 09:45:25 test pluto[26674]: packet from 10.10.10.41:500: ignoring
Vendor ID payload [Vid-Initial-Contact]
Jan 30 09:45:25 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
responding to Main Mode from unknown peer 10.10.10.41
Jan 30 09:45:25 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Jan 30 09:45:25 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
STATE_MAIN_R1: sent MR1, expecting MI2
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: no NAT
detected
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
STATE_MAIN_R2: sent MR2, expecting MI3
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
Main mode peer ID is ID_IPV4_ADDR: '10.10.10.41'
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
STATE_MAIN_R3: sent MR3, ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
group=modp2048}
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
the peer proposed: 192.168.1.21/32:0/0 -> 10.10.10.41/32:0/0
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-l2tp"[3] 10.10.10.41
#10: responding to Quick Mode proposal {msgid:31e7faf3}
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-l2tp"[3] 10.10.10.41
#10:     us: 192.168.1.21<192.168.1.21>[+S=C]:17/0---192.168.1.254
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-l2tp"[3] 10.10.10.41
#10:   them: 10.10.10.41[+S=C]:17/1701
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-l2tp"[3] 10.10.10.41
#10: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-l2tp"[3] 10.10.10.41
#10: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-l2tp"[3] 10.10.10.41
#10: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Jan 30 09:45:26 test pluto[26674]: "roadwarrior-l2tp"[3] 10.10.10.41
#10: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=>0xf954264a
<0xd247dca8 xfrm=3DES_0-HMAC_MD5 NATOA=<invalid> NATD=<invalid>:500
DPD=enabled}
Jan 30 09:45:31 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
received Delete SA(0xf954264a) payload: deleting IPSEC State #10
Jan 30 09:45:31 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
deleting connection "roadwarrior-l2tp" instance with peer 10.10.10.41
{isakmp=#0/ipsec=#0}
Jan 30 09:45:31 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
received and ignored informational message
Jan 30 09:45:32 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41 #9:
received Delete SA payload: deleting ISAKMP State #9
Jan 30 09:45:32 test pluto[26674]: "roadwarrior-all"[4] 10.10.10.41:
deleting connection "roadwarrior-all" instance with peer 10.10.10.41
{isakmp=#0/ipsec=#0}
Jan 30 09:45:32 test pluto[26674]: packet from 10.10.10.41:500: received
and ignored informational message


Your help on this will be greatly appreciated. Let me know if you need
more information.

Thanks.

Arnel

From shah_utkarsh_a at yahoo.co.in  Sat Jan 31 14:27:58 2009
From: shah_utkarsh_a at yahoo.co.in (utkarsh shah)
Date: Sun, 1 Feb 2009 00:57:58 +0530 (IST)
Subject: [Openswan Users] Not able to apply natt patch on kernel 2.6.28.1
Message-ID: <677262.71526.qm@web95415.mail.in2.yahoo.com>

Hi All,
?
sorry for spamming but i was not sure in which mailing list it should go.
?
I am newbe in Linux & Openswan.
I have installed fedora9.0 and?downloaded kernel (2.6.28.1)?src from site.
?
after extracting linux source i executed command specified in README as i want to use klips
make nattpatch | (cd /usr/src/linux-2.8.28.1 && patch -p1)

it create patch but fails in case of udp.c available in net/ipv4/udp.c
?
?
then i tried using netkey for temperorary purpose.. even compilation?& installation of openswan userland failed saying xmlto command not found..
?
searched xmlto in my mc but failed.. 
?
Kindly let me know if i am not following correct steps & sujjest me correct combination of latest?kernel source & openswan source

?
Regards, 
Utkarsh Shah


      Did you know? You can CHAT without downloading messenger. Go to http://in.webmessenger.yahoo.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090201/0240a1f2/attachment-0001.html