[Openswan Users]
Jim Barber
jim.barber at ddihealth.com
Fri Jun 16 16:37:27 CEST 2006
Just an update...
I upgraded openswan on the work server to the same as what is at home
since it just moved into Debian testing...
So both servers are running the openswan 2.4.5+dfsg-0.2 debian package.
This still hasn't fixed my problem though...
----------
Jim Barber
DDI Health
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 (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,
More information about the Users
mailing list