Invalid SPI when communicating with Openswan

[olympian]

Hi all, I would like to know if Fortiwifi 60C is OK to use with a Openswan Linux server by IPSec. I tried to use the Openswan to collect the Fortiwifi, the tunnel is up and everything seems OK. However when I tried to ping on either side, I got " Invalid SPI" error in the Foriwifi VPN log. However, if I want to connect the Linux from the Fortigate (put the link up on Fortigate, or I should say auto=start from the Fortigate), IPSec SA Phase I is established but not Phase II. No Phase II action is logged/seen in both Fortigate and Linux log. Is there anything I' m missing...? Thanks! Regards, Jason

[emnoc]

wow 1st what' s your config looking like? FGT and Openswan? fo a working openswan cfg; conn linux2fgtA nat_traversal=yes ike=3des-sha1 authby=secret esp=3des-sha1 auto=add pfs=no left=10.198.1.1 leftsubnet=10.200.20.0/24 leftnexthop=%defaultroute right=10.198.1.1 rightsubnet=10.212.1.0/24 rightnexthop=%defaultroute auto=start You need to figure out your reasons for the bad SPI and correct it. I would use wireshark tshark to monitor the SPI if you have bad or no connectivity. ( -R ' esp.spi' ) .You can also dump with -vvv and tcpdump and see the SPIs also, both parties should match for both sets IN>>>OUT OUT<<IN As far as how to add it, I have a script that checks for the tunnel down and if it' s down we ipsec up the named connection connection. It runs under cron very minute or so. Also make sure you iptable rules are enabling the left/right subnets. I ' ve seen alot of engineer beat their heads over the conf file and find out it' s just plain old misconfigured iptables. From your description, I would guess it' s a rule on either side. So I would double check the fwpolicies for the left/right

[olympian]

Here is the config file in Linux side: Openswan, 2.6.29-1 version 2.0 # conforms to second version of ipsec.conf specification # basic configuration config setup # Debug-logging controls: " none" for (almost) none, " all" for lots. # klipsdebug=none # plutodebug=" control parsing" # For Red Hat Enterprise Linux and Fedora, leave protostack=netkey protostack=netkey nat_traversal=no virtual_private=%v4:192.168.0.0/16 oe=off # Enable this if you see " failed to find any available worker" nhelpers=0 conn %default compress=no disablearrivalcheck=yes type=tunnel conn twghnet pfs=yes authby=secret right=219.76.177.121 rightnexthop=%defaultroute rightsourceip=192.168.20.1 rightsubnet=192.168.20.0/24 left=175.45.62.182 leftnexthop=175.45.62.181 leftsourceip=192.168.0.1 leftsubnet=192.168.0.0/24 esp=3des-sha1 ike=3des-sha1 auto=add keyexchange=ike ikelifetime=2h keylife=8h Note: For PFS, it is the same if it is on or off. Of course I made the same setting in Fortigate. The Invalid SPF problem appears right after the connection is established. When I try to ping to another network, the problem arise whenever there is packet go thru. It is no use to set DPD on. Also the tunnel will go up and down for newer firmware. If you need I can also provide configuration screenshot of the Fortigate configuration on VPN and Policy. Once again, thanks for your reply! Regards, Jason

[emnoc]

What does your diag pvn tunnel show ? And more so on the ipsec SPIs? And yes the relevant FGT ipsec config? fwiw: I would 1st disable pfs to make it simple ( on both devices ) and the run some diagnostic and pcap captures from the linux host. And compare SPIs from the two devices.

[olympian]

Hi emnoc, The command (diag vpn tunnel show) is not working, here is the diag vpn tunnel list instead. name=Jason ver=1 serial=2 0.0.0.0:0->175.*.*.*:0 lgwy=dyn tun=tunnel mode=auto bound_if=5 proxyid_num=1 child_num=0 refcnt=7 ilast=344 olast=344 stat: rxp=0 txp=0 rxb=0 txb=0 dpd: mode=active on=0 idle=5000ms retry=3 count=0 seqno=36393 natt: mode=none draft=0 interval=0 remote_port=0 proxyid=TestJason proto=0 sa=1 ref=2 auto_negotiate=0 serial=12 src: 0:192.168.10.0/255.255.255.0:0 dst: 0:192.168.0.0/255.255.255.0:0 SA: ref=3 options=0000000d type=00 soft=0 mtu=1280 expire=6815 replaywin=0 seqno=1 life: type=01 bytes=0/0 timeout=7150/7200 dec: spi=e30e81f4 esp=3des key=24 2f2005f432d5808a7a769ef4ab75357f6b129e3f086dcef3 ah=sha1 key=20 eee8b5f7917d1e6093782d5fa55479b8917f73d3 enc: spi=88081883 esp=3des key=24 e862a4412b8fe4f9e08b6bb01c362f129ffd8b3c71910a70 ah=sha1 key=20 df3c7aaa9cfecb0b8ef13f43b53fb83020facbdd npu_flag=00 npu_rgwy=175.*.*.* npu_lgwy=0.0.0.0 npu_selid=c, dec:pkts/bytes=0/0, enc:pkts/bytes=0/0 Wireshark (tethereal) tethereal -i eth1 -R esp.spi 0.000000 175.*.*.* -> 116.48.*.* ESP ESP (SPI=0xe30e81f4) 1.000096 175.*.*.* -> 116.48.*.* ESP ESP (SPI=0xe30e81f4) 1.999981 175.*.*.* -> 116.48.*.* ESP ESP (SPI=0xe30e81f4) 2.999971 175.*.*.* -> 116.48.*.* ESP ESP (SPI=0xe30e81f4) 3.999999 175.*.*.* -> 116.48.*.* ESP ESP (SPI=0xe30e81f4) in /var/log/secure Jul 17 23:03:33 localhost pluto[31358]: " twghnet" #5: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4 Jul 17 23:03:33 localhost pluto[31358]: " twghnet" #5: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1536} Jul 18 00:41:42 localhost pluto[31358]: " twghnet" #5: DPD: received old or duplicate R_U_THERE Jul 18 00:41:47 localhost pluto[31358]: " twghnet" #5: DPD: received old or duplicate R_U_THERE Jul 18 00:41:52 localhost pluto[31358]: " twghnet" #5: received Delete SA payload: deleting ISAKMP State #5 Jul 18 00:41:52 localhost pluto[31358]: " twghnet" #6: responding to Main Mode Jul 18 00:41:52 localhost pluto[31358]: " twghnet" #6: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1 Jul 18 00:41:52 localhost pluto[31358]: " twghnet" #6: STATE_MAIN_R1: sent MR1, expecting MI2 Jul 18 00:41:52 localhost pluto[31358]: " twghnet" #6: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2 Jul 18 00:41:52 localhost pluto[31358]: " twghnet" #6: STATE_MAIN_R2: sent MR2, expecting MI3 Jul 18 00:41:52 localhost pluto[31358]: " twghnet" #6: ignoring informational payload, type IPSEC_INITIAL_CONTACT msgid=00000000 Jul 18 00:41:52 localhost pluto[31358]: " twghnet" #6: Main mode peer ID is ID_IPV4_ADDR: ' 116.*.*.*' Jul 18 00:41:52 localhost pluto[31358]: " twghnet" #6: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3 Jul 18 00:41:52 localhost pluto[31358]: " twghnet" #6: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1536} Jul 18 01:16:10 localhost pluto[31358]: " twghnet" #6: ignoring informational payload, type INVALID_SPI msgid=00000000 Jul 18 01:16:10 localhost pluto[31358]: " twghnet" #6: received and ignored informational message Jul 18 01:16:13 localhost pluto[31358]: " twghnet" #6: ignoring informational payload, type INVALID_SPI msgid=00000000 Jul 18 01:16:13 localhost pluto[31358]: " twghnet" #6: received and ignored informational message For Fortigate Setting Thanks very much for your help! B. Regards, Jason

[emnoc]

Yeah that was the diag command output I wanted ; What you need todo is monitor the keylife and when the SA re-neg a new SPI seen if fortinet and OpenSwan matches ( ipsec status and ipsec spi ) What keylife are you running on Openswan? Your fgt side is set for 2hrs nd iirc the keylife on openswan is like 1hour, but I ' m not 100% sure. I would hardcode theopenswan to match the FGT for keylife and ikekeylife or identify what OpenSwan is running for that version and match the FGT. Everytime that SPI counts down, a new SPI will be generated and once again your transmit SPI is the other guy receive SPI. Both should match.

[olympian]

Hi emnoc, Here is more findings: FWF60C3G12008615 # diag vpn tunnel list list all ipsec tunnel in vd 0 ------------------------------------------------------ name=LOffice ver=1 serial=1 116.*.*.*:0->*.*.*.*:0 lgwy=dyn tun=tunnel mode=auto bound_if=1118 proxyid_num=1 child_num=0 refcnt=7 ilast=3 olast=3 stat: rxp=0 txp=0 rxb=0 txb=0 dpd: mode=active on=1 idle=5000ms retry=3 count=0 seqno=1411736 natt: mode=none draft=0 interval=0 remote_port=0 proxyid=KongWahtoLongPing proto=0 sa=0 ref=1 auto_negotiate=0 serial=1 src: 0:0.0.0.0/0.0.0.0:0 dst: 0:0.0.0.0/0.0.0.0:0 ------------------------------------------------------ name=Jason ver=1 serial=2 0.0.0.0:0->175.*.*.*:0 lgwy=dyn tun=tunnel mode=auto bound_if=5 proxyid_num=1 child_num=0 refcnt=8 ilast=1 olast=1 stat: rxp=0 txp=0 rxb=0 txb=0 dpd: mode=active on=1 idle=5000ms retry=3 count=0 seqno=55290 natt: mode=none draft=0 interval=0 remote_port=0 proxyid=TestJason proto=0 sa=1 ref=2 auto_negotiate=0 serial=12 src: 0:192.168.10.0/255.255.255.0:0 dst: 0:192.168.0.0/255.255.255.0:0 SA: ref=3 options=0000000d type=00 soft=0 mtu=1280 expire=6982 replaywin=0 seqno=1 life: type=01 bytes=0/0 timeout=7153/7200 dec: spi=e30e8225 esp=3des key=24 64105d34883f8e02d8b480c44d9725c4f2113fb01cc9bd81 ah=sha1 key=20 153b47eb5b860f2749ac72d3b5b2bfb21ce7461c enc: spi=810a5863 esp=3des key=24 321584d1f8381dec76d0189aef6f861ee052f0682d6a2dbf ah=sha1 key=20 0a429b93bc3e2aaed786588b746de3a79d41f113 npu_flag=00 npu_rgwy=175.45.62.182 npu_lgwy=0.0.0.0 npu_selid=c, dec:pkts/bytes=0/0, enc:pkts/bytes=0/0 ====== First thing first, why in my tunnel (the upper tunnel is for another office), there is a 0.0.0.0 IP point to my 175.*.*.* server instead of 116.*.*.* => 175.*.*.* (which 116.*.*.* is the main Fortigate). Also from the SPI value from Wireshark: 10.303062 175.*.*.* -> 116.*.*.* ESP ESP (SPI=0xe30e8225) EDIT: I don' t think the SPI is not correct: [Linux (Openswan)]# ip xfrm state src 116.48.149.137 dst 175.45.62.182 proto esp spi 0x810a5863 reqid 16385 mode tunnel replay-window 32 flag 20 auth hmac(sha1) 0x0a429b93bc3e2aaed786588b746de3a79d41f113 enc cbc(des3_ede) 0x321584d1f8381dec76d0189aef6f861ee052f0682d6a2dbf src 175.45.62.182 dst 116.48.149.137 proto esp spi 0xe30e8225 reqid 16385 mode tunnel replay-window 32 flag 20 auth hmac(sha1) 0x153b47eb5b860f2749ac72d3b5b2bfb21ce7461c enc cbc(des3_ede) 0x64105d34883f8e02d8b480c44d9725c4f2113fb01cc9bd81 The SPI is the SAME as the Fortigate tunnel dec(decode) SPI! So how invalid it could be.. LOL..! Fortigate Log Screenshot: Thanks for your great help emnoc! B. Regards, Jason

[olympian]

Sorry is there any solution yet...?

[olympian]

Hi all, Finally the myth is solved eventually. First of all, Phase I: As my Linux server set auto=start, in Fortigate please set Remote Gateway to Dialup User instead of Static IP Phase II: Tick: Autokey Keep Alive Leave Quick Mode Selector blank. I don' t know which one solve my case but anyway, it is solved.. =) Of course remember to set those Firewall Policy, as in the Fortigate Manual Thanks everyone Jason

[emnoc]

Glad that worked out for you. What do you mean QM blank? Can you post a copy of your vpn phase2-interface cli cmds.? I would have thought you would mapped the left/right subnet in your phase2 cfg.