[Openswan Users] upgrade openswan on CC 4.3 box
Sven J. van Rooij
sven at digitalcarmel.net
Tue May 19 17:50:32 EDT 2009
Nick,
I think I have a routing issue...
If I do a traceroute to the IP on my VPN, it does this
traceroute to 10.205.0.148 (10.205.0.148), 30 hops max, 38 byte packets
1 12.54.126.105 (12.54.126.105) 0.723 ms 0.773 ms 0.754 ms
2 12.91.241.97 (12.91.241.97) 9.117 ms !X * 9.118 ms !X
It's going out via the gateway's IP and then just stops...
Is that normal??
Sven
From: Nick Howitt [mailto:n1ck.h0w1tt at gmail.com]
Sent: Tuesday, May 19, 2009 2:47 PM
To: Sven J. van Rooij
Cc: users at openswan.org
Subject: Re: [Openswan Users] upgrade openswan on CC 4.3 box
Sven
You may find Openswan-2.2.0 (as in CC) is using different defaults to
2.4.x. I would look at encryption algorithms and things like AH and PFS.
I have seen that from the man pages options occasionally work
differently to what has been written, for example salifetime and
lifetime do not work as aliases for keylife. Also some units of time
work but you cannot use m as the unit for ikelifetime. Perhaps it works
in 2.6.x.
I think you now need someone else to help here.
Sorry to all if I have been multiple posting. Google keeps changing my
outbound sender's address to googlemail.com rather than gmail.com, so I
have been reposting to correct it. I've now switched to an alternative
smtp server!
Nick
Sven J. van Rooij wrote:
Nick,
Yes, the 2.4.11 is due to the post... I tried the .14 as well as a
2.6.18 I believe that lead to the exact same issue...
No traffic over the VPN tunnel.
The cisco issue is not pressing... had that already working and then
they tried something else...
MAJROR issue at this moment is that the VPN that worked this morning
with the original Openswan shipped with the CC box, but when upgrading I
run into the issue that no data can go via VPN...
Sven
From: Nick Howitt [mailto:n1ck.h0w1tt at gmail.com]
Sent: Tuesday, May 19, 2009 2:23 PM
To: Sven J. van Rooij
Cc: users at openswan.org
Subject: Re: [Openswan Users] upgrade openswan on CC 4.3 box
Sven,
Any obvious reason for using 2.4.11 and not the latest 2.4 series
(2.4.14) - (except that is probably what the CC forum post says)?
Also I cannot help you with the next bit as I know nothing about setting
up to connect to a CISCO device and I've seen in some posts that they
can be tricky and use an odd (XAUTH?) setup. I suggest you post your
ipsec.conf file and hope someone else jumps in. There are instructions
for a PIX at http://wiki.openswan.org/index.php/Openswan/CiscoPIX but
they probably for not apply to you. You may also want to check out the
strongswan (sorry everyone) website as well in case they have some
pointers, but some of their config options are slightly different.
Nick
Sven J. van Rooij wrote:
Nick,
Did as you said and here's my log...
May 19 13:12:06 firewall ipsec__plutorun: Unknown default RSA hostkey
scheme, not generating a default hostkey
May 19 13:12:06 firewall ipsec__plutorun: Starting Pluto subsystem...
May 19 13:12:06 firewall pluto[17118]: Starting Pluto (Openswan Version
2.4.11 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR; Vendor ID OE{dD^fJcUvk)
May 19 13:12:06 firewall pluto[17118]: Setting NAT-Traversal port-4500
floating to on
May 19 13:12:06 firewall pluto[17118]: port floating activation criteria
nat_t=1/port_fload=1
May 19 13:12:06 firewall pluto[17118]: including NAT-Traversal patch
(Version 0.6c)
May 19 13:12:06 firewall pluto[17118]: ike_alg_register_enc():
Activating OAKLEY_AES_CBC: Ok (ret=0)
May 19 13:12:06 firewall pluto[17118]: starting up 1 cryptographic
helpers
May 19 13:12:06 firewall pluto[17118]: started helper pid=17124 (fd:6)
May 19 13:12:06 firewall pluto[17118]: Using NETKEY IPsec interface code
on 2.6.18-93.cc4
May 19 13:12:06 firewall pluto[17118]: Changing to directory
'/etc/ipsec.d/cacerts'
May 19 13:12:06 firewall pluto[17118]: Changing to directory
'/etc/ipsec.d/aacerts'
May 19 13:12:06 firewall pluto[17118]: Changing to directory
'/etc/ipsec.d/ocspcerts'
May 19 13:12:06 firewall pluto[17118]: Changing to directory
'/etc/ipsec.d/crls'
May 19 13:12:06 firewall pluto[17118]: Warning: empty directory
May 19 13:12:06 firewall pluto[17118]: loading secrets from
"/etc/ipsec.secrets"
May 19 13:12:06 firewall pluto[17118]: loading secrets from
"/etc/ipsec.CCC.secrets"
May 19 13:12:06 firewall pluto[17118]: loading secrets from
"/etc/ipsec.CHOMP.secrets"
May 19 13:12:06 firewall pluto[17118]: added connection description
"hqgateCHOMP-satnetCHOMP"
May 19 13:12:06 firewall pluto[17118]: added connection description
"CCC"
May 19 13:12:07 firewall pluto[17118]: added connection description
"hqnetCHOMP-satgateCHOMP"
May 19 13:12:07 firewall pluto[17118]: added connection description
"hqgateCHOMP-satgateCHOMP"
May 19 13:12:07 firewall pluto[17118]: added connection description
"hqnetCHOMP-satnetCHOMP"
May 19 13:12:07 firewall pluto[17118]: listening for IKE messages
May 19 13:12:07 firewall pluto[17118]: adding interface eth3/eth3
12.54.126.107:500
May 19 13:12:07 firewall pluto[17118]: adding interface eth3/eth3
12.54.126.107:4500
May 19 13:12:07 firewall pluto[17118]: adding interface eth2/eth2
10.0.0.1:500
May 19 13:12:07 firewall pluto[17118]: adding interface eth2/eth2
10.0.0.1:4500
May 19 13:12:07 firewall pluto[17118]: adding interface eth1/eth1
192.168.112.1:500
May 19 13:12:07 firewall pluto[17118]: adding interface eth1/eth1
192.168.112.1:4500
May 19 13:12:07 firewall pluto[17118]: adding interface eth0/eth0
12.54.126.106:500
May 19 13:12:07 firewall pluto[17118]: adding interface eth0/eth0
12.54.126.106:4500
May 19 13:12:07 firewall pluto[17118]: adding interface lo/lo
127.0.0.1:500
May 19 13:12:07 firewall pluto[17118]: adding interface lo/lo
127.0.0.1:4500
May 19 13:12:07 firewall pluto[17118]: adding interface lo/lo ::1:500
May 19 13:12:07 firewall pluto[17118]: forgetting secrets
May 19 13:12:07 firewall pluto[17118]: loading secrets from
"/etc/ipsec.secrets"
May 19 13:12:07 firewall pluto[17118]: loading secrets from
"/etc/ipsec.CCC.secrets"
May 19 13:12:07 firewall pluto[17118]: loading secrets from
"/etc/ipsec.CHOMP.secrets"
May 19 13:12:07 firewall pluto[17118]: "hqgateCHOMP-satnetCHOMP" #1:
initiating Main Mode
May 19 13:12:07 firewall pluto[17118]: "CCC" #2: initiating Main Mode
May 19 13:12:07 firewall pluto[17118]: "hqgateCHOMP-satnetCHOMP" #1:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set
to=106
May 19 13:12:07 firewall pluto[17118]: "hqgateCHOMP-satnetCHOMP" #1:
ignoring Vendor ID payload [FRAGMENTATION c0000000]
May 19 13:12:07 firewall pluto[17118]: "hqgateCHOMP-satnetCHOMP" #1:
enabling possible NAT-traversal with method
draft-ietf-ipsec-nat-t-ike-02/03
May 19 13:12:07 firewall pluto[17118]: "CCC" #2: ignoring unknown Vendor
ID payload [166f932d55eb64d8e4df4fd37e2313f0d0fd84510000000000000000]
May 19 13:12:07 firewall pluto[17118]: "CCC" #2: received Vendor ID
payload [Dead Peer Detection]
May 19 13:12:07 firewall pluto[17118]: "CCC" #2: ignoring Vendor ID
payload [HeartBeat Notify 386b0100]
May 19 13:12:07 firewall pluto[17118]: "hqgateCHOMP-satnetCHOMP" #1:
transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
May 19 13:12:07 firewall pluto[17118]: "hqgateCHOMP-satnetCHOMP" #1:
STATE_MAIN_I2: sent MI2, expecting MR2
May 19 13:12:07 firewall pluto[17118]: "CCC" #2: transition from state
STATE_MAIN_I1 to state STATE_MAIN_I2
May 19 13:12:07 firewall pluto[17118]: "CCC" #2: STATE_MAIN_I2: sent
MI2, expecting MR2
May 19 13:12:07 firewall pluto[17118]: "CCC" #2: I did not send a
certificate because I do not have one.
May 19 13:12:07 firewall pluto[17118]: "CCC" #2: transition from state
STATE_MAIN_I2 to state STATE_MAIN_I3
May 19 13:12:07 firewall pluto[17118]: "CCC" #2: STATE_MAIN_I3: sent
MI3, expecting MR3
May 19 13:12:07 firewall pluto[17118]: "CCC" #2: Main mode peer ID is
ID_IPV4_ADDR: '206.71.166.194'
May 19 13:12:07 firewall pluto[17118]: "CCC" #2: transition from state
STATE_MAIN_I3 to state STATE_MAIN_I4
May 19 13:12:07 firewall pluto[17118]: "CCC" #2: STATE_MAIN_I4: ISAKMP
SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192
prf=oakley_sha group=modp1024}
May 19 13:12:07 firewall pluto[17118]: "CCC" #3: initiating Quick Mode
PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#2}
May 19 13:12:07 firewall pluto[17118]: "hqgateCHOMP-satnetCHOMP" #1:
received Vendor ID payload [Cisco-Unity]
May 19 13:12:07 firewall pluto[17118]: "hqgateCHOMP-satnetCHOMP" #1:
received Vendor ID payload [XAUTH]
May 19 13:12:07 firewall pluto[17118]: "hqgateCHOMP-satnetCHOMP" #1:
ignoring unknown Vendor ID payload [206827036be3230041d197ac232e3099]
May 19 13:12:07 firewall pluto[17118]: "hqgateCHOMP-satnetCHOMP" #1:
ignoring Vendor ID payload [Cisco VPN 3000 Series]
May 19 13:12:07 firewall pluto[17118]: "hqgateCHOMP-satnetCHOMP" #1: I
did not send a certificate because I do not have one.
May 19 13:12:07 firewall pluto[17118]: "hqgateCHOMP-satnetCHOMP" #1:
NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: no NAT
detected
May 19 13:12:07 firewall pluto[17118]: "hqgateCHOMP-satnetCHOMP" #1:
transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
May 19 13:12:07 firewall pluto[17118]: "hqgateCHOMP-satnetCHOMP" #1:
STATE_MAIN_I3: sent MI3, expecting MR3
May 19 13:12:07 firewall pluto[17118]: "CCC" #3: ignoring informational
payload, type IPSEC_RESPONDER_LIFETIME
May 19 13:12:07 firewall pluto[17118]: "CCC" #3: transition from state
STATE_QUICK_I1 to state STATE_QUICK_I2
May 19 13:12:07 firewall pluto[17118]: "CCC" #3: STATE_QUICK_I2: sent
QI2, IPsec SA established {ESP=>0x5074876f <0xe6a4d1b3
xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}
May 19 13:12:08 firewall pluto[17118]: "hqgateCHOMP-satnetCHOMP" #1:
received Vendor ID payload [Dead Peer Detection]
May 19 13:12:08 firewall pluto[17118]: | protocol/port in Phase 1 ID
Payload is 17/0. accepted with port_floating NAT-T
May 19 13:12:08 firewall pluto[17118]: "hqgateCHOMP-satnetCHOMP" #1:
Main mode peer ID is ID_IPV4_ADDR: '204.179.192.22'
May 19 13:12:08 firewall pluto[17118]: "hqgateCHOMP-satnetCHOMP" #1:
transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
May 19 13:12:08 firewall pluto[17118]: "hqgateCHOMP-satnetCHOMP" #1:
STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY
cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1024}
May 19 13:12:08 firewall pluto[17118]: "hqnetCHOMP-satnetCHOMP" #4:
initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#1}
May 19 13:12:08 firewall pluto[17118]: "hqgateCHOMP-satgateCHOMP" #5:
initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#1}
May 19 13:12:08 firewall pluto[17118]: "hqnetCHOMP-satgateCHOMP" #6:
initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#1}
May 19 13:12:08 firewall pluto[17118]: "hqnetCHOMP-satgateCHOMP" #6: can
not start crypto helper: failed to find any available worker
May 19 13:12:08 firewall pluto[17118]: "hqgateCHOMP-satnetCHOMP" #7:
initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#1}
May 19 13:12:08 firewall pluto[17118]: "hqgateCHOMP-satnetCHOMP" #7: can
not start crypto helper: failed to find any available worker
May 19 13:12:08 firewall pluto[17118]: "hqnetCHOMP-satnetCHOMP" #4:
transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
May 19 13:12:08 firewall pluto[17118]: "hqnetCHOMP-satnetCHOMP" #4:
STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x2500faab
<0x9f6adb8c xfrm=3DES_0-HMAC_MD5 NATD=none DPD=none}
May 19 13:12:24 firewall pluto[17118]: initiate on demand from
12.54.126.106:0 to 204.179.196.30:0 proto=0 state: fos_start because:
acquire
May 19 13:12:24 firewall pluto[17118]: "hqgateCHOMP-satnetCHOMP" #8:
initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#1}
So I'm not sure how it went from working in the version shipped on the
CC box and now I can't get even a ping!
Sven
From: Nick Howitt [mailto:n1ck.h0w1tt at googlemail.com]
Sent: Tuesday, May 19, 2009 12:57 PM
To: Sven J. van Rooij
Cc: users at openswan.org
Subject: Re: [Openswan Users] upgrade openswan on CC 4.3 box
Sven,
Those errors are not key to setting up Openswan. I had my tunnels
working despite the errors. However, to fix them you need to edit
/etc/sysctl.conf.
Change:
net.ipv4.ip_forward = 0 -> 1
net.ipv4.conf.default.rp_filter = 1 -> 0
Add:
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
(there may be a better way to do it)
Save the file and reload it using:
sysctl -p
sysctl -w net.ipv4.route.flush=1
As I said before, VPN traffic goes through the tunnel LAN-LAN, but I
have problems with anything to the gateway.
Sometimes I can ping the far router from the gateway, sometimes I
cannot. If I cannot, if I set up a continuous ping it will generally
start working within a minute or two. I also have a problem getting the
far router to ping the LAN address of the CC box (unpredictably
unreliable), but it can ping everything behind the CC box.
If I set up a virtual LAN interface on the CC box (eth1:0, 192.168.2.10)
I can always ping the far router with the command "ping -I 192.168.2.10
192.168.20.1" even if pinging 192.168.20.1 directly fails. I am trying
to find out if my brother can browse the Samba shares using
\\192.168.2.10\xyz instead of \\192.168.2.1\xyz (after adding the
interface eth1:0 to smb.conf).
If anyone can help me (us?) with this one, I'd love to hear. If not,
I'll wait for CC5 before asking again.
Regards,
Nick
Sven J. van Rooij wrote:
Nick,
Thanks for the quick response.
So I did do the upgrade and same issue...
I get my tunnels up, but now no traffic seems to go across the tunnel.
Pings time out.
And the ipsec verify gives me this
Checking your system to see if IPsec got installed and started
correctly:
Version check and ipsec on-path [OK]
Linux Openswan U2.4.9/K2.6.18-93.cc4 (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 [OK]
Two or more interfaces found, checking IP forwarding [OK]
Checking NAT and MASQUERADEing
Checking for 'ip' command [OK]
Checking for 'iptables' command [OK]
cat: ipsec.*.conf: No such file or directory
Opportunistic Encryption Support
[DISABLED]
Cannot execute command "which iptables": No such file or directory
cat: ipsec.*.conf: No such file or directory
Even though I have disabled the send and accept redirects....
Any ideas??
Sven
From: Nick Howitt [mailto:n1ck.h0w1tt at googlemail.com]
Sent: Tuesday, May 19, 2009 10:51 AM
To: Sven J. van Rooij
Cc: users at openswan.org
Subject: Re: [Openswan Users] upgrade openswan on CC 4.3 box
Sven,
The instructions in this
<http://forums.clarkconnect.com/showthreaded.php?Cat=0&Number=103109&pag
e=0&vc=1> thread in the CC forums work fine for Openswan-2.4.14. I
could not make it work with 2.6.18 or 2.6.21. 2.6.18 may compile but
won't run. 2.6.21 will not compile.
I have Openswan working fine as a VPN gateway/router. I just cannot get
the file server to work properly through the VPN, not can I get pings to
and from the gateway work reliably through the tunnel. LAN-LAN traffic
through the gateway is OK.
I was going to wait until CC5 (Openswan-2.6.14) is released before
troubleshooting this any further.
Nick
Sven J. van Rooij wrote:
An anyone direct me towards a good set of instructions on how to upgrade
openswan on a clark connect box.
Regardless which version (besides the original) I choose, I end up with
a tunnel, but no traffic on it.
PLEASE HELP!
Thanks,
Sven
________________________________
_______________________________________________
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/20090519/a85a2513/attachment-0001.html
More information about the Users
mailing list