[Openswan Users] Simple IPSec tunnel. OpenSwan, NETKEY,
Shorewall. Connection up, but won't route.
Jim Barber
jim.barber at ddihealth.com
Sun Jun 18 10:23:58 CEST 2006
Thanks Andy and also to Paul Wouters who suggested the same thing to me.
I'm not sure why my email is wrapped.
The original email doesn't seem wrapped in my sent folder.
I've upped my wrap setting from 132 chars to 1024 in Thunderbird, so hopefully that fixes things.
I also noticed I had no subject... I swore I typed in a meaningful subject when I first sent it. :(
My connection definitions now look like the following:
At Home:
conn ddi
authby=secret
left=%defaultroute
leftsourceip=10.1.1.1
leftsubnet=10.1.1.0/24
right=yyy.yyy.yyy.yyy
rightsourceip=10.10.0.1
rightsubnet=10.10.0.0/24
rightid=@mail.ddihealth.com
At Work:
conn gecko
authby=secret
left=yyy.yyy.yyy.yyy
leftid=@mail.ddihealth.com
leftsubnet=10.10.0.0/24
leftsourceip=10.10.0.1
right=%any
rightsourceip=10.1.1.1
rightsubnet=10.1.1.0/24
Output from 'ip route' after bringing the connections up are as follows:
At Home:
10.10.0.0/24 dev eth1 scope link src 10.1.1.1
10.1.1.0/24 dev eth0 proto kernel scope link src 10.1.1.1
xxx.xxx.xxx.0/24 dev eth1 proto kernel scope link src xxx.xxx.xxx.xxx
default via xxx.xxx.xxx.zzz dev eth1
At Work:
yyy.yyy.yyy.yyz/30 dev isp proto kernel scope link src yyy.yyy.yyy.yyy
10.10.0.0/24 dev fg proto kernel scope link src 10.10.0.1
10.1.1.0/24 dev isp scope link src 10.10.0.1
default via yyy.yyy.yyy.zzz dev isp
Does the above look okay?
The behaviour of the connection has changed, but there is progress as I think traffic is getting through now...
Pings and traceroutes appear to go nowhere at all.
Upon further investigation I notice that this is because the firewall is now getting in the way.
However it's wierd, since the traffic I see in the reject log has the public addresses in the source and destination fields.
For example, if I run a 'ping 10.10.0.1' from my home machine I get 100% packet loss.
But the firewall logs on my work machine shows the following:
Shorewall:all2all:REJECT: IN=isp OUT= MAC=00:14:6c:72:fd:41:00:12:01:3e:28:d0:08:00 SRC=xxx.xxx.xxx.xxx DST=yyy.yyy.yyy.yyy LEN=104 TOS=08 PREC=0x00 TTL=58 ID=2561 DF PROTO=4
Protocol 4 according to my /etc/protocols file is as follows:
ipencap 4 IP-ENCAP # IP encapsulated in IP (officially ``IP'')
Is this how the NETKEY IPSec tunnels appear?
ie, rather than traffic looking like it came from 10.1.1.1 to 10.10.0.1 it comes from xxx.xxx.xxx.xxx to yyy.yyy.yyy.yyy as ipencap packets?
I'm guessing I may just need to open up a firewall rule to allow protocol 4 to pass between the public addresses of the 2 end points.
I had already opened up isakmp(500), 4500, and protocol esp, and protocol ah.
Does that sound right to you guys?
Or do you think I might have something else mis-configured?
Thanks.
----------
Jim Barber
DDI Health
Andy wrote:
> Add leftsourceip=10.1.1.1 to conn ddi on your home system, and
> leftsourceip=10.10.0.1 to conn gecko on your work system.
>
> BTW - please don't use the 'route' command. Use 'ip route' instead. And
> try to set your mail client so it doesn't wrap the text.
>
>
> - Andy
>
>
> On Fri, 2006-06-16 at 14:15 +0800, Jim Barber wrote:
>
>>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:
>>
>> 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,
More information about the Users
mailing list