[Openswan Users] site to site VPN hangs at phase 1 openswan/ubuntu

Thu Oct 7 00:12:23 EDT 2010

hi - thanks for the help.  nothing happened on the SF machine (running 'ipsec auto --replace SF-To-Trenton').  on the trenton box i got:

@ellis:~$ sudo ipsec auto --replace SF-To-Trenton
003 "SF-To-Trenton": netlink recvfrom() of response to our XFRM_MSG_DELPOLICY message for policy eroute_connection delete inbound was too long: 100 > 36
003 "SF-To-Trenton": netlink recvfrom() of response to our XFRM_MSG_DELPOLICY message for policy eroute_connection delete inbound was too long: 100 > 36
@ellis:~$

..i then re-ran the 'ipsec auto --up SF-To-Trenton' command on both boxes.  nothing happened.  running 'ipsec auto verify' yielded (same on both boxes):

@ubuntuFW:~$ sudo ipsec auto --status
000 using kernel interface: netkey
000 interface lo/lo ::1
000 interface lo/lo 127.0.0.1
000 interface lo/lo 127.0.0.1
000 interface eth0/eth0 69.xx.xx.xx
000 interface eth0/eth0 69.xx.xx.xx
000 interface eth1/eth1 192.168.0.1
000 interface eth1/eth1 192.168.0.1
000 interface eth2/eth2 10.0.0.1
000 interface eth2/eth2 10.0.0.1
000 %myid = (none)
000 debug none
000
000 virtual_private (%priv):
000 - allowed 3 subnets: 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12
000 - disallowed 0 subnets:
000 WARNING: Either virtual_private= was not specified, or there was a syntax
000          error in that line. 'left/rightsubnet=%priv' will not work!
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=6, name=ESP_CAST, ivlen=8, keysizemin=40, keysizemax=128
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=13, name=ESP_AES_CTR, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=14, name=ESP_AES_CCM_A, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=15, name=ESP_AES_CCM_B, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=16, name=ESP_AES_CCM_C, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=18, name=ESP_AES_GCM_A, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=19, name=ESP_AES_GCM_B, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=20, name=ESP_AES_GCM_C, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=22, name=ESP_CAMELLIA, 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=8, name=AUTH_ALGORITHM_HMAC_RIPEMD, keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=9, name=AUTH_ALGORITHM_AES_CBC, keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=251, name=(null), keysizemin=0, keysizemax=0
000
000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=131
000 algorithm IKE encrypt: id=3, name=OAKLEY_BLOWFISH_CBC, blocksize=8, keydeflen=128
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 encrypt: id=65004, name=OAKLEY_SERPENT_CBC, blocksize=16, keydeflen=128
000 algorithm IKE encrypt: id=65005, name=OAKLEY_TWOFISH_CBC, blocksize=16, keydeflen=128
000 algorithm IKE encrypt: id=65289, name=OAKLEY_TWOFISH_CBC_SSH, 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 hash: id=4, name=OAKLEY_SHA2_256, hashsize=32
000 algorithm IKE hash: id=6, name=OAKLEY_SHA2_512, hashsize=64
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: {curr_cnt, total_cnt, maxsz} :context={0,0,0} trans={0,0,0} attrs={0,0,0}
000
000 "SF-To-Trenton": 192.168.0.0/24===69.xx.xx.xx<69.xx.xx.xx>[@sf.XXX.com,+S=C]---69.xx.xx.xx...173.xx.xx.xx<173.xx.xx.xx>[@trenton.XXX.com,+S=C]===192.168.10.0/24; unrouted; eroute owner: #0
000 "SF-To-Trenton":     myip=unset; hisip=unset;
000 "SF-To-Trenton":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "SF-To-Trenton":   policy: PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+lKOD+rKOD; prio: 24,24; interface: eth0;
000 "SF-To-Trenton":   newest ISAKMP SA: #0; newest IPsec SA: #0;
000
000 #11: "SF-To-Trenton":500 STATE_MAIN_I1 (sent MI1, expecting MR1); EVENT_RETRANSMIT in 40s; nodpd; idle; import:admin initiate
000 #11: pending Phase 2 for "SF-To-Trenton" replacing #0
000
@ubuntuFW:~$

-matt
----- "Paul Wouters" <paul at xelerance.com> wrote:

> On Thu, 7 Oct 2010, matt.bazan at comcast.net wrote:
> 
> > hi all - seeing the following after attempting to bring up my site
> to
> > site tunnel between two ubuntu server (10.0.4) boxes.  see same
> output
> > on both tunnel endpoints.  what should i check for?
> 
> I dont see anything, what does this say:
> 
> ipsec auto --replace SF-To-Trenton
> ipsec auto --up SF-To-Trenton
> 
> > note - the leftid@ entry in ipsec.conf is not a valid DNS name
> > (meaning it cannot be publicly resolved).  does this matter?
> 
> The "@" means it is a string, not a hostname,
> 
> > also, the servers have different version of openswan even though
> ive
> > updated both of them and they are fresh openswan installs.  left
> > server has openswan U2.6.22/K2.6.31-14.  right server is
> > U2.6.23/K2.6.32-24.  again, should this matter?
> 
> Should work fine.
> 
> Paul