[Openswan Users] openswan fortigate stuck in EVENT_PENDING_PHASE2
Johannes Scholz
js at vinci-info.com
Sun Jan 9 14:26:24 EST 2011
Hallo,
I am trying to establish an ipsec connection between a Fortigate 50 and openswan on centos (Linux Openswan U2.6.21/K2.6.18-194.32.1.el5 (netkey)).
The setup of the fortigate:
Internet <> ADSL router (80.14.x.x, 192.168.5.254) <> Fortigate 50B (wan iface 192.168.5.11, lan iface 192.168.10.0/24)
The fortigate is in the dmz of the adsl router, all packages arrive directly on the fortigate, however, the fortigate uses 192.168.5.254 (the adsl router) as default gw (static route 0.0.0.0 to 192.168.5.11).
The computer running centos is directly connected to the internet. Config:
conn vinci
authby=secret # Key exchange method
left=213.239.x.x # Public Internet IP address of the LEFT VPN device
leftsubnet=192.168.0.0/24 # Subnet protected by the LEFT VPN device
leftnexthop=%defaultroute # correct in many situations
right=80.14.x.x # Public Internet IP address ofthe RIGHT VPN device
rightsubnet=192.168.10.0/24 # Subnet protected by the RIGHT VPN device
rightnexthop=%defaultroute # correct in many situations
rightid=@ipsectest.example.com # needed, because if I use id address, the fortigate will send 192.168.5.11
auto=add
Now phase one seems to be successful, an SA gets established:
Jan 9 20:14:05 neoen pluto[20906]: packet from 80.14.x.x:500: received Vendor ID payload [RFC 3947] method set to=109
Jan 9 20:14:05 neoen pluto[20906]: packet from 80.14.x.x:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 109
Jan 9 20:14:05 neoen pluto[20906]: packet from 80.14.x.x:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 109
Jan 9 20:14:05 neoen pluto[20906]: packet from 80.14.x.x:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 109
Jan 9 20:14:05 neoen pluto[20906]: packet from 80.14.x.x:500: ignoring unknown Vendor ID payload [16f6ca16e4a4066d83821a0f0aeaa862]
Jan 9 20:14:05 neoen pluto[20906]: packet from 80.14.x.x:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Jan 9 20:14:05 neoen pluto[20906]: packet from 80.14.x.x:500: received Vendor ID payload [Dead Peer Detection]
Jan 9 20:14:05 neoen pluto[20906]: "vinci" #1: responding to Main Mode
Jan 9 20:14:05 neoen pluto[20906]: "vinci" #1: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Jan 9 20:14:05 neoen pluto[20906]: "vinci" #1: STATE_MAIN_R1: sent MR1, expecting MI2
Jan 9 20:14:05 neoen pluto[20906]: "vinci" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): peer is NATed
Jan 9 20:14:05 neoen pluto[20906]: pluto_do_crypto: helper (0) is exiting
Jan 9 20:14:05 neoen pluto[20906]: "vinci" #1: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Jan 9 20:14:05 neoen pluto[20906]: "vinci" #1: STATE_MAIN_R2: sent MR2, expecting MI3
Jan 9 20:14:05 neoen pluto[20906]: pluto_do_crypto: helper (0) is exiting
Jan 9 20:14:05 neoen pluto[20906]: "vinci" #1: ignoring informational payload, type IPSEC_INITIAL_CONTACT msgid=00000000
Jan 9 20:14:05 neoen pluto[20906]: "vinci" #1: Main mode peer ID is ID_FQDN: '@ipsectest.example.com
Jan 9 20:14:05 neoen pluto[20906]: "vinci" #1: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Jan 9 20:14:05 neoen pluto[20906]: "vinci" #1: new NAT mapping for #1, was 80.14.x.x:500, now 80.14.x.x:4500
Jan 9 20:14:05 neoen pluto[20906]: "vinci" #1: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1024}
After that pretty much nothing happens, if i set the debug to all, the logs show this:
*SNIP*
Jan 9 20:16:42 neoen pluto[21482]: | emitting 4 zero bytes of encryption padding into ISAKMP Message
Jan 9 20:16:42 neoen pluto[21482]: | encrypting 56 using OAKLEY_3DES_CBC
Jan 9 20:16:42 neoen pluto[21482]: | NSS: do_3des init start
Jan 9 20:16:42 neoen pluto[21482]: | NSS: do_3des init end
Jan 9 20:16:42 neoen pluto[21482]: | next IV: c0 37 1d e5 af eb 2b e9
Jan 9 20:16:42 neoen pluto[21482]: | emitting length of ISAKMP Message: 84
Jan 9 20:16:42 neoen pluto[21482]: | sending 84 bytes for ISAKMP notify through eth0:4500 to 80.14.x.x:4500 (using #1)
Jan 9 20:16:42 neoen pluto[21482]: | 00 00 00 00 dd 67 ed 5d 0a 5e d7 08 18 67 9d ba
Jan 9 20:16:42 neoen pluto[21482]: | fa 89 3d 5a 08 10 05 01 86 bb b6 0f 00 00 00 54
Jan 9 20:16:42 neoen pluto[21482]: | bb 3b 4b e6 03 00 7a 0c 3a 4b 1b a7 fd 54 b1 50
Jan 9 20:16:42 neoen pluto[21482]: | 25 ae a6 5e 1f 12 85 13 c8 4f 88 44 72 c6 29 53
Jan 9 20:16:42 neoen pluto[21482]: | 64 31 0a 14 08 47 31 a5 13 4d 58 c8 d2 6f 41 c1
Jan 9 20:16:42 neoen pluto[21482]: | c0 37 1d e5 af eb 2b e9
Jan 9 20:16:42 neoen pluto[21482]: | complete state transition with STF_IGNORE
Jan 9 20:16:42 neoen pluto[21482]: | * processed 0 messages from cryptographic helpers
Jan 9 20:16:42 neoen pluto[21482]: | next event EVENT_PENDING_PHASE2 in 63 seconds
tcpdump shows me this:
20:17:28.675840 IP (tos 0x0, ttl 50, id 56015, offset 0, flags [none], proto: UDP (17), length: 116) 80.14.x.x.ipsec-nat-t > 213.239.x.x.ipsec-nat-t: NONESP-encap: isakmp 1.0 msgid 46fe2d46: phase 2/others ? inf[E]: [encrypted hash]
20:17:28.722280 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 116) 213.239.x.x.ipsec-nat-t > 80.14.x.x.ipsec-nat-t: NONESP-encap: isakmp 1.0 msgid 5e9b6007: phase 2/others ? inf[E]: [encrypted hash]
the fortigate log just keeps repeating this:
ike 0:neoen_server: link is idle 5 192.168.5.11->213.239.x.x:4500 dpd=1 seqno=787
ike 0:neoen_server:64: send IKEv1 DPD probe, seqno 1927
ike 0:neoen_server:64: confirmed nat-t RFC 3947
ike 0:neoen_server:64: sent IKE msg (R-U-THERE): 192.168.5.11:4500->213.239.x.x:4500, len=84
ike 0: comes 213.239.x.x:4500->192.168.5.11:4500,ifindex=5....
ike 0: IKEv1 exchange=Informational id=dd67ed5d0a5ed708/18679dbafa893d5a:02b4a1a5 len=84
ike 0: found neoen_server 192.168.5.11 5 -> 213.239.x.x:4500
ike 0:neoen_server:64: notify msg received: R-U-THERE-ACK
I am running out of ideas here. Unfortunately I am not able to take the adsl router out of the connection chain and connect the fortigate directly.
Looking forward to your replies.
Regards,
Johannes Scholz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4755 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/users/attachments/20110109/0a34de71/attachment.bin
More information about the Users
mailing list