[Openswan Users] Simple IPSec tunnel. OpenSwan, NETKEY,
Shorewall. Connection up, but won't route.
Andy
fs at globalnetit.com
Sun Jun 18 01:27:42 CEST 2006
On Sun, 2006-06-18 at 09:23 +0800, Jim Barber wrote:
> Thanks Andy and also to Paul Wouters who suggested the same thing to me.
>
HTH
> 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.
Could be my mail client, I guess. But this mail looks better.
> I also noticed I had no subject... I swore I typed in a meaningful subject when I first sent it. :(
There's been a recurring problem with subject lines being dropped by the
mailing list server. Not your fault, I suspect.
>
> 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
>
Look fine. I don't think the rightsourceip entries will have any effect,
but they won't hurt.
> 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?
Look fine.
>
> 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?
Probably right. Did you try that yet?
Maybe first try with the firewall disabled completely. I'm not familiar
with shorewall, so I can't comment on your settings.
I also encountered this IPIP (protocol 4) thing just recently, after I
upgraded one of my VPN servers to 2.6.16.x. Probably a side effect of
the ipsec changes in 2.6.16 for iptables/ipsec policy rules. I haven't
had time to investigate it yet. Adding a permit rule for protocol 4
worked around it for me.
BTW - you only need udp/500 and esp for these conns - not udp/4500 or
ah. But you may need them later, I guess...
>
> 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,
--
Andy <fs at globalnetit.com>
More information about the Users
mailing list