[Openswan Users]
Fail to route between simple IPSec tunnel with Netkey, on Debian,
and using Shorewall.
Jim Barber
jim.barber at ddihealth.com
Fri Jun 16 15:15:45 CEST 2006
Hi all.
I've read a lot of people having a similar problem to me, but I haven't
been able to get things working based on suggestions they've been given.
I've got two Debian systems that I am trying to create a simple IPSec
tunnel between using pre-shared keys.
One system is my home system and is running Debian unstable.
The other system is at my work place and it running Debian testing.
Both systems are directly on the Internet and so don't use NAT.
They do however provide NAT services for the internal LANs.
The two systems seem to correctly establish the tunnel, however I can't
route the traffic between the two.
I'm not sure how to even debug the problem because NETKEY seems to hide
everything that goes on since it doesn't create an ipsec0 interface...
Both systems are running the following versions of software:
ipsec-tools 0.6.5-6
shorewall 3.0.7-1
iptables 1.3.5
The iptables is self compiled because Debian only has a 1.3.3 package
that doesn't support ipsec policy matching.
My home system (called gecko) uses:
openswan 2.4.5+dfsg-0.2
linux kernel 2.6.16.17
While the system at work uses:
openswan 2.4.4-3.1
linux kernel 2.6.16.13
The network looks like the following:
(home/gecko)
10.1.1.0/24===xxx.xxx.xxx.xxx...yyy.yyy.yyy.yyy===10.10.0.0/24 (work)
xxx.xxx.xxx.xxx is a dynamic IP address that I get assigned by my ISP.
It is pretty stable but can change after a number of weeks.
yyy.yyy.yyy.yyy is a static IP address that's been assigned to my
workplace.
In both cases, xxx.xxx.xxx.xxx and yyy.yyy.yyy.yyy are bound directly to
the network interface on the appropriate Linux gateway.
The config on my home system is as follows:
/etc/ipsec.conf:
version 2.0
config setup
conn %default
auto=add
compress=yes
keyingtries=1
conn ddi
authby=secret
left=%defaultroute
leftsubnet=10.1.1.0/24
right=yyy.yyy.yyy.yyy
rightsubnet=10.10.0.0/24
rightid=@hostname.ddihealth.com
# Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf
/etc/shorewall/hosts:
#ZONE HOST(S) OPTIONS
ddi $NET_IF:0.0.0.0/0
/etc/shorewall/tunnels:
#TYPE ZONE GATEWAY GATEWAY ZONE
ipsec net yyy.yyy.yyy.yyy ddi
/etc/shorewall/zones:
#ZONE TYPE OPTIONS IN OPTIONS
OUT OPTIONS
ddi ipsec
/etc/shorewall/rules:
#ACTION SOURCE DESTINATION
ACCEPT net:$WORK fw udp
isakmp,4500
ACCEPT fw net:$WORK udp
isakmp,4500
ACCEPT net:$WORK fw ah
ACCEPT net:$WORK fw esp
ACCEPT fw net:$WORK ah
ACCEPT fw net:$WORK esp
Ping/ACCEPT fw ddi
Ping/ACCEPT ddi fw
Trcrt/ACCEPT fw ddi
The config on my work system is as follows:
/etc/ipsec.conf:
version 2.0
config setup
conn %default
auto=add
compress=yes
keyingtries=1
conn gecko
authby=secret
left=yyy.yyy.yyy.yyy
leftid=@hostname.ddihealth.com
leftsubnet=10.10.0.0/24
right=%any
rightsubnet=10.1.1.0/24
# Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf
/etc/shorewall/hosts:
#ZONE HOST(S) OPTIONS
gecko $NET_IF:0.0.0.0/0
/etc/shorewall/tunnels:
#TYPE ZONE GATEWAY GATEWAY ZONE
ipsec net 0.0.0.0/0 gecko
/etc/shorewall/zones:
#ZONE TYPE OPTIONS IN OPTIONS
OUT OPTIONS
gecko ipsec
/etc/shorewall/rules:
#ACTION SOURCE DESTINATION
ACCEPT net fw udp
isakmp,4500
ACCEPT net fw ah
ACCEPT net fw esp
Ping/ACCEPT fw gecko
Ping/ACCEPT gecko fw
Trcrt/ACCEPT fw gecko
Both systems have the same pre-shared key set up like so:
/etc/ipsec.secrets:
: RSA /etc/ipsec.d/private/appropriate_cert_file.pem
: PSK "0x A Nice Long Hex String Here"
When starting up Openswan (/etc/init.d/ipsec start), I get the following
logs on my home system:
ipsec__plutorun: Starting Pluto subsystem...
pluto[20371]: Starting Pluto (Openswan Version 2.4.5 X.509-1.5.4
LDAP_V3 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR; Vendor ID OEGfuJ[Ye{Ah)
pluto[20371]: Setting NAT-Traversal port-4500 floating to off
pluto[20371]: port floating activation criteria nat_t=0/port_fload=1
pluto[20371]: including NAT-Traversal patch (Version 0.6c) [disabled]
pluto[20371]: ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok
(ret=0)
pluto[20371]: starting up 1 cryptographic helpers
pluto[20371]: started helper pid=20382 (fd:6)
pluto[20371]: Using Linux 2.6 IPsec interface code on 2.6.16.17
pluto[20371]: Changing to directory '/etc/ipsec.d/cacerts'
pluto[20371]: loaded CA cert file 'lizardnet-cert.pem' (1367 bytes)
pluto[20371]: Changing to directory '/etc/ipsec.d/aacerts'
pluto[20371]: Changing to directory '/etc/ipsec.d/ocspcerts'
pluto[20371]: Changing to directory '/etc/ipsec.d/crls'
pluto[20371]: Warning: empty directory
pluto[20371]: added connection description "ddi"
pluto[20371]: listening for IKE messages
pluto[20371]: adding interface eth1/eth1 xxx.xxx.xxx.xxx:500
pluto[20371]: adding interface eth0/eth0 10.1.1.1:500
pluto[20371]: adding interface lo/lo 127.0.0.1:500
pluto[20371]: loading secrets from "/etc/ipsec.secrets"
pluto[20371]: loaded private key file
'/etc/ipsec.d/private/server-key.pem' (887 bytes)
When starting up Openswan (/etc/init.d/ipsec start), I get the following
logs on my work system:
ipsec__plutorun: Starting Pluto subsystem...
pluto[17437]: Starting Pluto (Openswan Version 2.4.4 X.509-1.5.4
PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR; Vendor ID OEz}FFFfgr_e)
pluto[17437]: Setting NAT-Traversal port-4500 floating to off
pluto[17437]: port floating activation criteria nat_t=0/port_fload=1
pluto[17437]: including NAT-Traversal patch (Version 0.6c) [disabled]
pluto[17437]: ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok
(ret=0)
pluto[17437]: starting up 1 cryptographic helpers
pluto[17437]: started helper pid=17446 (fd:6)
pluto[17437]: Using Linux 2.6 IPsec interface code on 2.6.16.13
pluto[17437]: Changing to directory '/etc/ipsec.d/cacerts'
pluto[17437]: loaded CA cert file 'ddi_perth-cacert.pem' (1387 bytes)
pluto[17437]: Changing to directory '/etc/ipsec.d/aacerts'
pluto[17437]: Changing to directory '/etc/ipsec.d/ocspcerts'
pluto[17437]: Changing to directory '/etc/ipsec.d/crls'
pluto[17437]: Warning: empty directory
pluto[17437]: added connection description "gecko"
pluto[17437]: listening for IKE messages
pluto[17437]: adding interface isp/isp yyy.yyy.yyy.yyy:500
pluto[17437]: adding interface fg/fg 10.10.0.1:500
pluto[17437]: adding interface lo/lo 127.0.0.1:500
pluto[17437]: loading secrets from "/etc/ipsec.secrets"
pluto[17437]: loaded private key file
'/etc/ipsec.d/private/gwKey.pem' (1675 bytes)
Note that the eth0, eth1, etc have been renamed on my work machine, with
'isp' being the interface connected to the Internet.
After a fresh start, and before the tunnel is bought up, the 'ipsec auto
--status' command returns the following on my home system:
000 interface lo/lo 127.0.0.1
000 interface eth0/eth0 10.1.1.1
000 interface eth1/eth1 xxx.xxx.xxx.xxx
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=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=251, name=(null), keysizemin=0,
keysizemax=0
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 "ddi":
10.1.1.0/24===xxx.xxx.xxx.xxx...yyy.yyy.yyy.yyy[@hostname.ddihealth.com]===10.10.0.0/24;
unrouted; eroute owner: #0
000 "ddi": srcip=unset; dstip=unset; srcup=ipsec _updown;
dstup=ipsec _updown;
000 "ddi": ike_life: 3600s; ipsec_life: 28800s; rekey_margin:
540s; rekey_fuzz: 100%; keyingtries: 1
000 "ddi": policy: PSK+ENCRYPT+COMPRESS+TUNNEL+PFS; prio: 24,24;
interface: eth1;
000 "ddi": newest ISAKMP SA: #0; newest IPsec SA: #0;
000
000
For my work system, the output looks as follows (it doesn't have the
same warning, probably because Openswan is just a little older):
000 interface lo/lo 127.0.0.1
000 interface fg/fg 10.10.0.1
000 interface isp/isp yyy.yyy.yyy.yyy
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=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=251, name=(null), keysizemin=0,
keysizemax=0
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 "gecko":
10.10.0.0/24===yyy.yyy.yyy.yyy[@hostname.ddihealth.com]...%any===10.1.1.0/24;
unrouted; eroute owner: #0
000 "gecko": srcip=unset; dstip=unset; srcup=ipsec _updown;
dstup=ipsec _updown;
000 "gecko": ike_life: 3600s; ipsec_life: 28800s; rekey_margin:
540s; rekey_fuzz: 100%; keyingtries: 1
000 "gecko": policy: PSK+ENCRYPT+COMPRESS+TUNNEL+PFS; prio: 24,24;
interface: isp;
000 "gecko": newest ISAKMP SA: #0; newest IPsec SA: #0;
000
000
Now if I bring the tunnel up from my home system using 'ipsec auto --up
ddi' I get the following messages:
104 "ddi" #1: STATE_MAIN_I1: initiate
003 "ddi" #1: ignoring unknown Vendor ID payload
[4f457a7d4646466667725f65]
003 "ddi" #1: received Vendor ID payload [Dead Peer Detection]
106 "ddi" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "ddi" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "ddi" #1: STATE_MAIN_I4: ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_md5
group=modp1536}
117 "ddi" #2: STATE_QUICK_I1: initiate
004 "ddi" #2: STATE_QUICK_I2: sent QI2, IPsec SA established
{ESP=>0x6a4aaea0 <0x0d7e3501 xfrm=AES_0-HMAC_SHA1 IPCOMP=>0x0000acd0
<0x0000c7ea NATD=none DPD=none}
Which looks like a successful connection...
The logs on my work system show the following when this link is being
bought up:
packet from xxx.xxx.xxx.xxx:500: ignoring unknown Vendor ID payload
[4f454766754a5b59657b4168]
packet from xxx.xxx.xxx.xxx:500: received Vendor ID payload [Dead
Peer Detection]
"gecko"[1] xxx.xxx.xxx.xxx #1: responding to Main Mode from unknown
peer xxx.xxx.xxx.xxx
"gecko"[1] xxx.xxx.xxx.xxx #1: transition from state STATE_MAIN_R0
to state STATE_MAIN_R1
"gecko"[1] xxx.xxx.xxx.xxx #1: STATE_MAIN_R1: sent MR1, expecting MI2
"gecko"[1] xxx.xxx.xxx.xxx #1: transition from state STATE_MAIN_R1
to state STATE_MAIN_R2
"gecko"[1] xxx.xxx.xxx.xxx #1: STATE_MAIN_R2: sent MR2, expecting MI3
"gecko"[1] xxx.xxx.xxx.xxx #1: Main mode peer ID is ID_IPV4_ADDR:
'xxx.xxx.xxx.xxx'
"gecko"[1] xxx.xxx.xxx.xxx #1: I did not send a certificate because
I do not have one.
"gecko"[1] xxx.xxx.xxx.xxx #1: transition from state STATE_MAIN_R2
to state STATE_MAIN_R3
"gecko"[1] xxx.xxx.xxx.xxx #1: STATE_MAIN_R3: sent MR3, ISAKMP SA
established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192
prf=oakley_md5 group=modp1536}
"gecko"[1] xxx.xxx.xxx.xxx #2: responding to Quick Mode {msgid:6d778f2a}
"gecko"[1] xxx.xxx.xxx.xxx #2: transition from state STATE_QUICK_R0
to state STATE_QUICK_R1
"gecko"[1] xxx.xxx.xxx.xxx #2: STATE_QUICK_R1: sent QR1, inbound
IPsec SA installed, expecting QI2
"gecko"[1] xxx.xxx.xxx.xxx #2: transition from state STATE_QUICK_R1
to state STATE_QUICK_R2
"gecko"[1] xxx.xxx.xxx.xxx #2: STATE_QUICK_R2: IPsec SA established
{ESP=>0x0d7e3501 <0x6a4aaea0 xfrm=AES_0-HMAC_SHA1 IPCOMP=>0x0000c7ea
<0x0000acd0 NATD=none DPD=none}
It all looks good to me...
Now the end of the 'ipsec auto --status' command output looks like the
following on my home system:
000 "ddi":
10.1.1.0/24===xxx.xxx.xxx.xxx...yyy.yyy.yyy.yyy[@hostname.ddihealth.com]===10.10.0.0/24;
erouted; eroute owner: #2
000 "ddi": srcip=unset; dstip=unset; srcup=ipsec _updown;
dstup=ipsec _updown;
000 "ddi": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s;
rekey_fuzz: 100%; keyingtries: 1
000 "ddi": policy: PSK+ENCRYPT+COMPRESS+TUNNEL+PFS+UP; prio: 24,24;
interface: eth1;
000 "ddi": newest ISAKMP SA: #1; newest IPsec SA: #2;
000 "ddi": IKE algorithm newest: 3DES_CBC_192-MD5-MODP1536
000
000 #2: "ddi":500 STATE_QUICK_I2 (sent QI2, IPsec SA established);
EVENT_SA_REPLACE in 27584s; newest IPSEC; eroute owner
000 #2: "ddi" esp.6a4aaea0 at yyy.yyy.yyy.yyy esp.d7e3501 at xxx.xxx.xxx.xxx
comp.acd0 at yyy.yyy.yyy.yyy comp.c7ea at xxx.xxx.xxx.xxx
tun.0 at yyy.yyy.yyy.yyy tun.0 at xxx.xxx.xxx.xxx
000 #1: "ddi":500 STATE_MAIN_I4 (ISAKMP SA established);
EVENT_SA_REPLACE in 2747s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0)
000
The end of the 'ipsec auto --status' command output looks like the
following on my work system:
000 "gecko":
10.10.0.0/24===yyy.yyy.yyy.yyy[@hostname.ddihealth.com]...%any===10.1.1.0/24;
unrouted; eroute owner: #0
000 "gecko": srcip=unset; dstip=unset; srcup=ipsec _updown;
dstup=ipsec _updown;
000 "gecko": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s;
rekey_fuzz: 100%; keyingtries: 1
000 "gecko": policy: PSK+ENCRYPT+COMPRESS+TUNNEL+PFS; prio: 24,24;
interface: isp;
000 "gecko": newest ISAKMP SA: #0; newest IPsec SA: #0;
000 "gecko"[1]:
10.10.0.0/24===yyy.yyy.yyy.yyy[@hostname.ddihealth.com]...xxx.xxx.xxx.xxx===10.1.1.0/24;
erouted; eroute owner: #2
000 "gecko"[1]: srcip=unset; dstip=unset; srcup=ipsec _updown;
dstup=ipsec _updown;
000 "gecko"[1]: ike_life: 3600s; ipsec_life: 28800s; rekey_margin:
540s; rekey_fuzz: 100%; keyingtries: 1
000 "gecko"[1]: policy: PSK+ENCRYPT+COMPRESS+TUNNEL+PFS; prio: 24,24;
interface: isp;
000 "gecko"[1]: newest ISAKMP SA: #1; newest IPsec SA: #2;
000 "gecko"[1]: IKE algorithm newest: 3DES_CBC_192-MD5-MODP1536
000
000 #2: "gecko"[1] xxx.xxx.xxx.xxx:500 STATE_QUICK_R2 (IPsec SA
established); EVENT_SA_REPLACE in 27952s; newest IPSEC; eroute owner
000 #2: "gecko"[1] xxx.xxx.xxx.xxx esp.d7e3501 at xxx.xxx.xxx.xxx
esp.6a4aaea0 at yyy.yyy.yyy.yyy comp.c7ea at xxx.xxx.xxx.xxx
comp.acd0 at yyy.yyy.yyy.yyy tun.0 at xxx.xxx.xxx.xxx tun.0 at yyy.yyy.yyy.yyy
000 #1: "gecko"[1] xxx.xxx.xxx.xxx:500 STATE_MAIN_R3 (sent MR3, ISAKMP
SA established); EVENT_SA_REPLACE in 2752s; newest ISAKMP;
lastdpd=-1s(seq in:0 out:0)
000
Does the above all look okay so far?
My route tables with the connection up looks like the following at home:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref
Use Iface
10.10.0.0 0.0.0.0 255.255.255.0 U 0
0 0 eth1
10.1.1.0 0.0.0.0 255.255.255.0 U 0
0 0 eth0
xxx.xxx.xxx.0 0.0.0.0 255.255.255.0 U 0
0 0 eth1
0.0.0.0 xxx.xxx.xxx.zzz 0.0.0.0 UG 0
0 0 eth1
My route tables with the connection up looks like the following at work:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref
Use Iface
yyy.yyy.yyy.yyz 0.0.0.0 255.255.255.252 U 0
0 0 isp
10.10.0.0 0.0.0.0 255.255.255.0 U 0
0 0 fg
10.1.1.0 0.0.0.0 255.255.255.0 U 0
0 0 isp
0.0.0.0 yyy.yyy.yyy.zzz 0.0.0.0 UG 0
0 0 isp
So there are routes for each other's networks.
Pings and Traceroutes from home to work fail:
PING 10.10.0.1 (10.10.0.1) 56(84) bytes of data.
From xxx.xxx.xxx.xxx icmp_seq=2 Destination Host Unreachable
From xxx.xxx.xxx.xxx icmp_seq=3 Destination Host Unreachable
From xxx.xxx.xxx.xxx icmp_seq=4 Destination Host Unreachable
--- 10.10.0.1 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time
3002ms
traceroute to 10.10.0.1 (10.10.0.1), 30 hops max, 40 byte packets
1 xxx.xxx.xxx.xxx 3002.387 ms !H 3003.668 ms !H 3003.714 ms !H
And vice-versa:
PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data.
From yyy.yyy.yyy.yyy icmp_seq=2 Destination Host Unreachable
From yyy.yyy.yyy.yyy icmp_seq=3 Destination Host Unreachable
From yyy.yyy.yyy.yyy icmp_seq=4 Destination Host Unreachable
--- 10.1.1.1 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time
4000ms
traceroute to 10.1.1.1 (10.1.1.1), 30 hops max, 40 byte packets
1 yyy.yyy.yyy.yyy 3002.629 ms !H 3003.971 ms !H 3003.985 ms !H
Output from the 'ipsec verify' command on my home machine is as follows:
Checking your system to see if IPsec got installed and started
correctly:
Version check and ipsec on-path [OK]
Linux Openswan U2.4.5/K2.6.16.17 (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]
Output from the 'ipsec verify' command on my work machine is as follows:
Checking your system to see if IPsec got installed and started
correctly:
Version check and ipsec on-path [OK]
Linux Openswan U2.4.4/K2.6.16.13 (netkey)
Checking for IPsec support in kernel [OK]
Checking for RSA private key (/etc/ipsec.secrets) [FAILED]
ipsec showhostkey: no default key in "/etc/ipsec.secrets"
Checking that pluto is running [OK]
Two or more interfaces found, checking IP forwarding [OK]
Checking NAT and MASQUERADEing
Checking for 'ip' command [OK]
Checking for 'iptables' command [OK]
Checking for 'setkey' command for NETKEY IPsec stack support [OK]
Opportunistic Encryption Support
[DISABLED]
Originally these had failures because I needed to 'echo 0 >' to the
following files:
/proc/sys/net/ipv4/conf/all/accept_redirects
/proc/sys/net/ipv4/conf/all/send_redirects
/proc/sys/net/ipv4/conf/default/accept_redirects
/proc/sys/net/ipv4/conf/default/send_redirects
/proc/sys/net/ipv4/conf/fg/accept_redirects
/proc/sys/net/ipv4/conf/fg/send_redirects
/proc/sys/net/ipv4/conf/isp/accept_redirects
/proc/sys/net/ipv4/conf/isp/send_redirects
/proc/sys/net/ipv4/conf/lo/accept_redirects
/proc/sys/net/ipv4/conf/lo/send_redirects
I'm not sure if I needed to do it to all of them or not, however it made
no difference (even after restarting all the daemons and connections).
This has had me pulling my hair out for a while, and reading through the
mailing list archives it always looks like I might get the answer, but
everything I've read and tried doesn't work...
I also tried to use 'forceencaps=yes' on both sides which made the
traffic route through port 4500 UDP encapsulated, but that didn't work
either...
I also tried to set the following extra parameters:
home:/etc/ipsec.conf
leftnexthop=%defaultroute
rightnexthop=yyy.yyy.yyy.zzz
work:/etc/ipsec.conf
leftnexthop=yyy.yyy.yyy.zzz
No rightnexthop for the work setting since I can't know what the next
hop is for my dynamic IP assignment at home.
That results in a successful connection that still won't talk.
Pings get totally lost:
PING 10.10.0.1 (10.10.0.1) 56(84) bytes of data.
--- 10.10.0.1 ping statistics ---
18 packets transmitted, 0 received, 100% packet loss, time 16999ms
And the traceroutes for the private networks tries to go out via the
Internet rather than the tunnel...
traceroute to 10.10.0.1 (10.10.0.1), 30 hops max, 40 byte packets
1 203.59.14.16 23.104 ms 17.895 ms 17.915 ms
2 203.215.4.32 20.052 ms 17.943 ms 16.570 ms
3 203.215.4.255 76.074 ms * 184.551 ms
4 *
So I backed these extra parameters out again since they look wrong to me.
Any ideas what is going wrong?
I've tried to include as much information as possible which probably
looks daunting, but it's the kind of info that is always requested, so I
figured that I should lay it all out now.
Regards,
--
----------
Jim Barber
DDI Health
More information about the Users
mailing list