Fortigate to Strongswan tunnel, failing phase 1

[bain64]

Good morning. I'm having trouble getting a tunnel between a Fortigate 100D and Strongswan running on TomatoUSB. I've tried so many different combinations and have probably complicated this more than it should be.. Would you please help point me in the right direction? 

Fortigate Phase 1 & 2

config vpn ipsec phase1-interface
    edit "VPN1"
        set interface "wan1"
        set keylife 28800
        set proposal 3des-sha1
        set localid "vpn.fortigate123.org"
        set dpd disable
        set dhgrp 14 5 2
        set remote-gw w.x.y.z
        set psksecret not_my_actual_password
    next

end

config vpn ipsec phase2-interface

edit "Ph2_VPN1"
set phase1name "VPN1"
set proposal aes128-sha1
set pfs disable
set replay disable
set keepalive enable
set auto-negotiate enable
set keylifeseconds 3600
set src-subnet 192.168.1.0 255.255.255.0
set dst-subnet 192.168.5.0 255.255.255.0
next
end

Strongswan file /etc/ipsec.conf

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup
        # strictcrlpolicy=yes
        # uniqueids = no

conn %default
    ikelifetime=8h
    keylife=1h
    rekeymargin=3m
    keyingtries=%forever
    keyexchange=ikev1
    authby=psk
    ike=3des-sha1-modp2048
    esp=3des-sha1-modp2048
    forceencaps=yes

conn VPN1
    type=tunnel
    authby=secret
    auto=start
    keyexchange=ikev1
    ike=3des-sha1-modp2048
    left=w.x.y.z
    leftsubnet=192.168.5.0/24
    leftid=@bain.strongswan123.org
    leftfirewall=no
    right=a.b.c.d
    rightsubnet=192.168.1.0/24
    rightid=@vpn.fortigate123.org
    compress=no
    esp=aes128-sha1
    keyingtries=%forever

Strongswan file  /etc/ipsec.secrets 

  /etc/ipsec.secrets - strongSwan IPsec secrets file
@bain.strongswan123.org @vpn.fortigate123.org : PSK not_my_actual_password

diag vpn ike gateway list

name: VPN1
version: 1
interface: wan1 26
addr: a.b.c.d:500 -> w.x.y.z:500
created: 19s ago
IKE SA: created 1/1
IPsec SA: created 1/1

  id/spi: 7369 2bbd1198da4e8cd5/0000000000000000
  direction: responder
  status: connecting, state 3, started 19s ago

diagnose debug app ike 255

WCUFGT02 # ike 0:V:7417: negotiation timeout, deleting

ike 0:Site-Site-MCB: connection expiring due to phase1 down
ike 0:Site-Site-MCB: deleting
ike 0:Site-Site-MCB: flushing
ike 0:Site-Site-MCB: flushed
ike 0:Site-Site-MCB: deleted
ike 0:Site-Site-MCB: schedule auto-negotiate
ike 0:Site-Site-MCB:7418: initiator: main mode is sending 1st message...
ike 0:Site-Site-MCB:7418: cookie 65d55c36e44631e2/0000000000000000
ike 0:Site-Site-MCB:7418: out 65D55C36E44631E200000000000000000110020000000000000002CC0D0001E40000000100000001000001D80101000C0300002801010000800B0001000C00040001518080010007800E008080030001800200048004000E0300002802010000800B0001000C00040001518080010007800E00808003000180020004800400050300002803010000800B0001000C00040001518080010007800E010080030001800200048004000E0300002804010000800B0001000C00040001518080010007800E01008003000180020004800400050300002405010000800B0001000C0004000151808001000580030001800200048004000E0300002406010000800B0001000C000400015180800100058003000180020004800400050300002807010000800B0001000C00040001518080010007800E008080030001800200028004000E0300002808010000800B0001000C00040001518080010007800E00808003000180020002800400050300002809010000800B0001000C00040001518080010007800E010080030001800200028004000E030000280A010000800B0001000C00040001518080010007800E0100800300018002000280040005030000240B010000800B0001000C0004000151808001000580030001800200028004000E000000240C010000800B0001000C000400015180800100058003000180020002800400050D0000144A131C81070358455C5728F20E95452F0D0000147D9419A65310CA6F2C179D9215529D560D000014CD60464335DF21F87CFDB2FC68B6A4480D00001490CB80913EBB696E086381B5EC427B1F0D00001416F6CA16E4A4066D83821A0F0AEAA8620D0000144485152D18B6BBCD0BE8A8469579DDCC0D000014AFCAD71368A1F1C96B8696FC775701000D0000144048B7D56EBCE88525E7DE7F00D6C2D30D0000184048B7D56EBCE88525E7DE7F00D6C2D3C0000000000000148299031757A36082C6A621DE0005029E
ike 0:Site-Site-MCB:7418: sent IKE msg (ident_i1send): a.b.c.d:500->w.x.y.z:500, len=716, id=65d55c36e44631e2/0000000000000000
ike 0:Site-Site-MCB:7418: out 65D55C36E44631E200000000000000000110020000000000000002CC0D0001E40000000100000001000001D80101000C0300002801010000800B0001000C00040001518080010007800E008080030001800200048004000E0300002802010000800B0001000C00040001518080010007800E00808003000180020004800400050300002803010000800B0001000C00040001518080010007800E010080030001800200048004000E0300002804010000800B0001000C00040001518080010007800E01008003000180020004800400050300002405010000800B0001000C0004000151808001000580030001800200048004000E0300002406010000800B0001000C000400015180800100058003000180020004800400050300002807010000800B0001000C00040001518080010007800E008080030001800200028004000E0300002808010000800B0001000C00040001518080010007800E00808003000180020002800400050300002809010000800B0001000C00040001518080010007800E010080030001800200028004000E030000280A010000800B0001000C00040001518080010007800E0100800300018002000280040005030000240B010000800B0001000C0004000151808001000580030001800200028004000E000000240C010000800B0001000C000400015180800100058003000180020002800400050D0000144A131C81070358455C5728F20E95452F0D0000147D9419A65310CA6F2C179D9215529D560D000014CD60464335DF21F87CFDB2FC68B6A4480D00001490CB80913EBB696E086381B5EC427B1F0D00001416F6CA16E4A4066D83821A0F0AEAA8620D0000144485152D18B6BBCD0BE8A8469579DDCC0D000014AFCAD71368A1F1C96B8696FC775701000D0000144048B7D56EBCE88525E7DE7F00D6C2D30D0000184048B7D56EBCE88525E7DE7F00D6C2D3C0000000000000148299031757A36082C6A621DE0005029E
ike 0:Site-Site-MCB:7418: sent IKE msg (P1_RETRANSMIT): a.b.c.d:500->w.x.y.z:500, len=716, id=65d55c36e44631e2/0000000000000000
ike 0:Site-Site-MCB:7418: out 65D55C36E44631E200000000000000000110020000000000000002CC0D0001E40000000100000001000001D80101000C0300002801010000800B0001000C00040001518080010007800E008080030001800200048004000E0300002802010000800B0001000C00040001518080010007800E00808003000180020004800400050300002803010000800B0001000C00040001518080010007800E010080030001800200048004000E0300002804010000800B0001000C00040001518080010007800E01008003000180020004800400050300002405010000800B0001000C0004000151808001000580030001800200048004000E0300002406010000800B0001000C000400015180800100058003000180020004800400050300002807010000800B0001000C00040001518080010007800E008080030001800200028004000E0300002808010000800B0001000C00040001518080010007800E00808003000180020002800400050300002809010000800B0001000C00040001518080010007800E010080030001800200028004000E030000280A010000800B0001000C00040001518080010007800E0100800300018002000280040005030000240B010000800B0001000C0004000151808001000580030001800200028004000E000000240C010000800B0001000C000400015180800100058003000180020002800400050D0000144A131C81070358455C5728F20E95452F0D0000147D9419A65310CA6F2C179D9215529D560D000014CD60464335DF21F87CFDB2FC68B6A4480D00001490CB80913EBB696E086381B5EC427B1F0D00001416F6CA16E4A4066D83821A0F0AEAA8620D0000144485152D18B6BBCD0BE8A8469579DDCC0D000014AFCAD71368A1F1C96B8696FC775701000D0000144048B7D56EBCE88525E7DE7F00D6C2D30D0000184048B7D56EBCE88525E7DE7F00D6C2D3C0000000000000148299031757A36082C6A621DE0005029E
ike 0:Site-Site-MCB:7418: sent IKE msg (P1_RETRANSMIT): a.b.c.d:500->w.x.y.z:500, len=716, id=65d55c36e44631e2/0000000000000000
ike 0:Site-Site-MCB:7418: negotiation timeout, deleting
ike 0:Site-Site-MCB: connection expiring due to phase1 down

Any help would be appreciated! 

[emnoc]

I would investigate more on your diagnostic but I've crafted this openswan guide on my blog;

http://socpuppet.blogspot.com/2014/05/openswan-to-fortigate-route-based-vpn.html

Keep in mind that  strongswan will issues multiple proposals in the initial contact. I would specify just the one you want on both the FGT and swan side of things.

( dh-grp, ciphers,etc... ) so drop all of the dhgrp and specify just one.

Also  early 2.6 kernels depending on   linux rls seens to be problematic from my experiences

e.g

     rightsubnet=192.0.2.0/24

     leftsubnet=192.0.3.0/24      ike=aes128      esp=aes128      ikelifetime=28800s      keyexchange=ike      pfs=no      

Lastly, ensure  you specify the  src/dst-subnet to match exactly and not use the  0.0.0.0/0:0 on your phase2 settings in t he fortigate config which you seem to have done on the FGT side. The strongswan side needs to match.

btw: I never used the localid ( leftid/righid ) setting, you shouldn't need  these imho. So I would drop these

authby=secret
    auto=start
    keyexchange=ikev1
    ike=3des-sha1-modp2048
    left=w.x.y.z
    leftsubnet=192.168.5.0/24
    #leftid=@bain.strongswan123.org
    leftfirewall=no
    right=a.b.c.d
    rightsubnet=192.168.1.0/24
    #rightid=@vpn.fortigate123.org
    compress=no
    esp=aes128-sha1
    keyingtries=%forever

Outside of that you look good

[bain64]

Thanks emnoc, I'll update my config to your recommendations and continue testing.. However I may have just found my initial problem, it doesnt look like ipsec is starting on strongswan. 

root@unknown:/opt/ # ipsec reload Reloading strongSwan IPsec failed: starter is not running

I've found from other things this is usually a poorly formatted file on my part, like ipsec.conf in this case.. I fixed my spacing errors and still can't get ipsec to start, nor find a log file that indicates why. Is there a debug command for ipsec on strongswan?  

[emnoc]

None that I'm aware of but what I would do;

remove the  ipsec package and reinstall

(e.g debian style )

sudo apt-get remove strongswan

sudo apt-get install strongswan

And  then B4 you configure anything;

sudo ipsec statusall

It should show a nake systems with no SAs & tell you you have all of the goodies for strongswan.

Then rebuilt the ipsec.secret and conf file and see what happens. Ensure you have support for ike in the kernel.

And my next dumb question you are restarting the service as "root" ? ( I had to ask )  ;)

btw: imho I 've seen less openswan issues and prefer it over strongswan just my opinion

[bain64]

Yes I am running as root, and always ask that question because I've lost time on that before too! 

I'm running Entware to allow strongswan.. I'm not sure if openswan is supported but I'll look into it. 

I wiped the USB drive hosting entware, and reinstalled the Strongswan packages, but still get no output for a 'ipsec statusall' and the same error message about ipsec not being started when attempting to restart its service.. 

BTW.. I started with this guide, http://tomatousb.org/forum/t-677831/tutorial-ipsec-site-to-site-vpn-with-strongswan  but have been using your blog post and forum posts to troubleshoot for the last 5 days or so. I was hoping you would be the guy to reply to my post! Thanks for all your help to the community emnoc..  I'm going to keep troubleshooting why I cannot start the darn ipsec services... 

[emnoc]

Ok cool

I just remember from the past and my mind is foggy ;) , but I had to rebuilt my kernel and support in linux on certain  releases and these are all older 2.x.x.

So this might be a issue and I'm not 100% sure if modprobe or something else can confirm support for ipsec. So you mind want to double/triple check that.

The ipsec statusall should always show you what ipsec version, ike, ciphers ,etc......So if that's fails on a nake configuration, than I would look deep into your  kernel support.

[bain64]

I finally got this going. To document for others (or future me) here is what I had to do to get ipsec going. The following line needs to be commented out. 

/opt/etc/strongswan.conf

# load_modular = yes

It's in the default file upon install. And after commenting this line, I get responses with 'ipsec status' and the other ipsec commands. VPN came up just fine. Set higher encryption key exchanges and VPN came right back up. 

I  downgraded Strongswan to 5.1.3 before getting this to work; but it might also work on the current 5.3.2. The release I used was the latest I could confirm others had Strongswan working on Tomato, so that's the base I started from. 

-Bain

[emnoc]

I never like modular anything this is has always been an issue in the past and will always be a problem in the future imho. Take a look at this blog post on a few  ipsec cmds that could be very helpful

http://socpuppet.blogspot.com/2015/07/openswan-cmds-you-should-get-use-to.html

FWIW: The very 1st one wold be interesting to see the output of the verify option b4 and after your changes.

[bain64]

I was going to test the 'ipsec verify' before and after to report back, but it is not a known command on this flavor.

root@tomato:/opt# ipsec --help
Usage: ipsec command argument ...
where command is one of:
        start|restart arguments...
        update|reload|stop
        up|down|route|unroute <connectionname>
        status|statusall [<connectionname>]
        listalgs|listpubkeys|listcerts [--utc]
        listcacerts|listaacerts|listocspcerts [--utc]
        listacerts|listgroups|listcainfos [--utc]
        listcrls|listocsp|listcards|listplugins|listall [--utc]
        listcounters|resetcounters [name]
        leases [<poolname> [<address>]]
        rereadsecrets|rereadgroups
        rereadcacerts|rereadaacerts|rereadocspcerts
        rereadacerts|rereadcrls|rereadall
        purgeocsp|purgecrls|purgecerts|purgeike
        scepclient
        secrets
        starter
        version
        stroke

I also want to test upgrading back to 5.3.2 and see if commenting/deleting the modular line would make that version work as well; but ipsec is UP and I'm not ready to break the tunnel down for testing just yet. 

[emnoc]

A good point & great catch. There's a few differences in  ipsectool for openswan vrs strongwan

i.e

root@view1:/usr/lib/ipsec# ipsec --versioncode U4.5.2/K3.8.0-29-generic

( strongswan )

root@view1:/usr/lib/ipsec# ipsec verify /usr/sbin/ipsec: unknown IPsec command `verify' (`ipsec --help' for list)  

 You can use the  strongswan check.sh and ensure that charon & pluto is also running

https://wiki.strongswan.org/projects/strongswan/wiki/KernelModules

https://wiki.strongswan.org/attachments/download/237/check.sh

ken