Multiple FGT initiate VPN to StrongSwan inside AWS

[jlozen]

I found this thread (https://forum.fortinet.com/tm.aspx?m=115012) and it helped me get a little closer (I think) to getting a VPN working from multiple sites in a hub and spoke setup but I still can't seem to get there. I have multiple Fortigates with varous public IP addresses that I need to connect back to a static IP StrongSwan server hosted inside Amazon Web Services (AWS).

Here are a few other resources I found useful in case anyone else finds this post and is having similar VPN woes

http://socpuppet.blogspot.com/2013/10/site-2-site-routed-vpn-trouble-shooting.html

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

http://docs-legacy.fortinet.com/fos50hlp/50/index.html#page/FortiOS%205.0%20Help/TestandMonitor.129....

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

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

At this point I've tried all the combinations of public/private IP address I could think of, and have had so many different configs in place at one point or another I'm not sure if what's posted below really makes sense but it's the current state of the devices nonetheless.

I attached a txt file with the debug outputs for both the FGT and StrongSwan server, I couldn't attach multiple files so I tacked the FGT debug onto the very end of the file. I believe the lines of interest for the StrongSwan output are lines 9-26 but I included the full exchange just in case it helps.

StrongSwan config

conn %default
keyingtries=%forever
keyexchange=ikev2
conn dialup
left=10.1.1.50
leftid=VPNDOMAINNAME
leftsubnet=10.1.0.0/16
leftauth=psk
leftfirewall=yes
right=%any
rightauth=psk
rightsourceip=10.1.0.0/24
auto=start
ike=aes128-sha1-modp2048

FGT config

config vpn ipsec phase1-interface

edit "dialup-vpn01"
set interface "wan1"
set ike-version 2
set proposal aes128-sha1
set localid "PUBLIC-IP-B"
set dpd disable
set comments "towards strongswan"
set dhgrp 14
set remote-gw PUBLIC-IP-A
set psksecret ENC SECRET
next
end

config vpn ipsec phase2-interface

edit "dialup-vpn01"
 set phase1name "dialup-vpn01"
 set proposal aes128-sha1
 set pfs disable
 set replay disable
 set keepalive enable
 set auto-negotiate enable
 set dst-addr-type ip
 set keylifeseconds 3600
 set src-subnet 10.1.0.0 255.255.255.0
 set dst-start-ip 10.1.1.50
 next
end

edit: added image of network layout

[emnoc]

here's what  i would do,

1st you have a  overlap in your  src/dst subnets ( 10.1.x.x. /24 /16 )

2nd on the swan side  just add your subnets like this;

[I

leftsubnet=10.1.0.0/16,10.2.0.0/16

Or build 2 connection profiles with the left/right-subnets in connection#1 and connection#2

On the  fortigate side it's too is flexibile like strongswan. But I would typically do is just define two phase2-interface

config vpn ipsec  phase2-interface

edit "dialup-vpn01"  set phase1name "dialup-vpn01"  set proposal aes128-sha1  set pfs disable  set replay disable  set keepalive enable  set auto-negotiate enable  set keylifeseconds 3600  set src-subnet 10.1.0.0 255.255.255.0  set dst-subnet 10.1.0.0 255.255.0.0  next end edit "dialup-vpn01-2"  set phase1name "dialup-vpn01"  set proposal aes128-sha1  set pfs disable  set replay disable  set keepalive enable  set auto-negotiate enable  set dst-addr-type ip  set keylifeseconds 3600  set src-subnet 10.1.0.0 255.255.255.0  set dst-subnet 10.2.0.0 255.255.0.0  next end

So as you can see, the fortigate works similar like the  strongswan implementation.

Ken

[jlozen]

It looks like 'set dst-subnet' isn't a valid command in firmware 5.2 it's apparently changed to 'set dst-start-ip' I've changed the environment to simplify things but am still having issues :(

I changed the AWS side to only involve the 10.1.0.0/16 network and changed the FGT side lan to be 192.158.5.0/24 but am still having issues getting a tunnel to come up. I posted the configs and strongswan debug logs. I'm still getting the same 'failed cp_required' errors on strongswan

FGT config

fgt (phase2-interface) # show

config vpn ipsec phase2-interface
edit "dialupvpn-p2"
set phase1name "dialupvpn"
set dhgrp 5
set dst-addr-type ip
set keylifeseconds 3600
set src-subnet 192.168.5.0 255.255.255.0
set dst-start-ip 10.1.1.50
next
end

StrongSwan config

conn dialup

left=10.1.1.50
leftid=VPNDOMAINNAME
leftsubnet=10.1.0.0/16
leftauth=psk
leftfirewall=yes
right=%any
rightauth=psk
rightsourceip=192.168.5.0/24
auto=start
ike=aes128-sha1-modp2048
keyingtries=%forever
keyexchange=ikev2

StrongSwan debug log

Jan 8 04:39:21 05[IKE] <dialup|5599> IKE_SA dialup[5599] state change: CONNECTING => ESTABLISHED

Jan 8 04:39:21 07[JOB] next event in 99ms, waiting
Jan 8 04:39:21 05[IKE] <dialup|5599> scheduling reauthentication in 10113s
Jan 8 04:39:21 07[JOB] next event in 99ms, waiting
Jan 8 04:39:21 05[IKE] <dialup|5599> maximum IKE_SA lifetime 10653s
Jan 8 04:39:21 05[IKE] <dialup|5599> expected a virtual IP request, sending FAILED_CP_REQUIRED
Jan 8 04:39:21 05[ENC] <dialup|5599> added payload of type NOTIFY to message
Jan 8 04:39:21 05[CFG] <dialup|5599> looking for a child config for 10.1.0.0/16 === 192.168.5.0/24
Jan 8 04:39:21 05[CFG] <dialup|5599> proposing traffic selectors for us:
Jan 8 04:39:21 05[CFG] <dialup|5599> 10.1.0.0/16
Jan 8 04:39:21 05[CFG] <dialup|5599> proposing traffic selectors for other:
Jan 8 04:39:21 05[CFG] <dialup|5599> dynamic
Jan 8 04:39:21 05[IKE] <dialup|5599> traffic selectors 10.1.0.0/16 === 192.168.5.0/24 inacceptable
Jan 8 04:39:21 05[ENC] <dialup|5599> added payload of type NOTIFY to message
Jan 8 04:39:21 05[IKE] <dialup|5599> failed to establish CHILD_SA, keeping IKE_SA
Jan 8 04:39:21 05[ENC] <dialup|5599> added payload of type NOTIFY to message
Jan 8 04:39:21 05[ENC] <dialup|5599> order payloads in message
Jan 8 04:39:21 05[ENC] <dialup|5599> added payload of type ID_RESPONDER to message
Jan 8 04:39:21 05[ENC] <dialup|5599> added payload of type AUTH to message
Jan 8 04:39:21 05[ENC] <dialup|5599> added payload of type NOTIFY to message
Jan 8 04:39:21 05[ENC] <dialup|5599> added payload of type NOTIFY to message
Jan 8 04:39:21 05[ENC] <dialup|5599> added payload of type NOTIFY to message
Jan 8 04:39:21 05[ENC] <dialup|5599> generating IKE_AUTH response 1 [ IDr AUTH N(AUTH_LFT) N(FAIL_CP_REQ) N(TS_UNACCEPT) ]
Jan 8 04:39:21 05[ENC] <dialup|5599> insert payload ID_RESPONDER into encrypted payload
Jan 8 04:39:21 05[ENC] <dialup|5599> insert payload AUTH into encrypted payload
Jan 8 04:39:21 05[ENC] <dialup|5599> insert payload NOTIFY into encrypted payload
Jan 8 04:39:21 05[ENC] <dialup|5599> insert payload NOTIFY into encrypted payload
Jan 8 04:39:21 05[ENC] <dialup|5599> insert payload NOTIFY into encrypted payload
Jan 8 04:39:21 05[ENC] <dialup|5599> generating payload of type HEADER

[emnoc]

I wanted to address this;

It looks like 'set dst-subnet' isn't a valid command in firmware 5.2 it's apparently changed to 'set dst-start-ip' I've changed the environment to simplify things but am still having issues :(  

You need to change the dst addr type to subnet in your phase2 cfg;

set dst-addr-type subnet     IPv4 subnet. range      IPv4 range. ip         IPv4 IP. name       IPv4 firewall address or group name. subnet6    IPv6 subnet. range6     IPv6 range. ip6        IPv6 IP. name6      IPv6 firewall address or group name.

Change it and then apply the dst-subnet and it should come up.

Ken

[ede_pfau]

May I point out that the peerIDs do not match. If using a dialup VPN the remote IP address cannot be used for authentication. Thus, you need to provide peer IDs.

You do but they don't match.

Agreed on the dest subnet Quick Mode selector. The FGT debug messages point to this as well.

And finally, check the DH group. Group 5 is 1536 bits whereas 2048 bits is group 14. You have it either way in your 2 posts.

[emnoc]

Good catch , but his earlier  original-posted config has  set pfs disable in ph2 and he was using dhgrp 14  on ph1. So if he enable pfs than we would have a 2nd key change based on the proposal enabled.

phase1

set dhgrp 14

He should clean  up the cfg.

[ede_pfau]

Do you agree on the peerID topic?

[emnoc]

This is a l2l type ipsec, so there's no need for peerId nor have I ever used one in a static l2l ipsec vpn.

Ken

[jlozen]

THANK YOU to everyone with your help! I have tunnels up!

Now I can start the process of getting traffic routed properly. After spending so much time on this I figured the solution would be something stupid, after changing 'rightsourceip' to 'rightsubnet' in the strongswan config the tunnels came up right away.

I have firewall rules in place to allow traffic in/out of the vpn but they aren't catching any packets and I can't seem to communicate across the VPN so I'm going to start troubleshooting the routing issues and i will update on that as issues arise.

Here are the working configs I have currently running with tunnels showing up on both the strongswan and FGT.

StrongSwan

conn dialup

left=10.1.1.50
leftsubnet=10.1.0.0/16
leftauth=psk
leftfirewall=yes
right=%any
rightauth=psk
rightsubnet=192.168.5.0/24
auto=start
ike=aes128-sha1-modp2048
keyingtries=%forever
keyexchange=ikev2

FGT

config vpn ipsec phase1-interface

edit "vpn20c"
set interface "wan"
set ike-version 2
set keylife 3600
set dhgrp 14
set remote-gw PUBLIC-IP-A

next

config vpn ipsec phase2-interface
edit "vpn20c-p2"
set phase1name "vpn20c"
set dhgrp 14
set src-subnet 192.168.5.0 255.255.255.0
set dst-subnet 10.1.0.0 255.255.0.0
next
end

[emnoc]

Ok good job, now to further trouble-shoot this you need to do a few work

One you need to compare the  ispec sa status and details ( look for match SPI from>>>>to   to>>>> from )

FGT

diag vpn tunnel list name < fgt  phase1 name >

You need get a packet sniffer on the tunnel interface ( you have a route-based vpn  so you have a interface)

diag sniffer paccket < name> "any"

Diag debg flow will come in handy and tell you 9 out of 10 times what the problem is or direct you to the problem

diag debug reset

diag debug flow filter < insert a host that's carried over the vpn>

diag debug show console enable

diag debug en

diag debug flow trace start 100

Things that's bit me in the past,

1: fail to have a static route

config router static

   edit xxxx ( pick a unused number )

        set dev "phase#1 name "

        set dst  x.x.x.x/24

    end

2: bad or incorrect policies, the diag debug flow will shed light on that

On linux you need the following

ipsec status

ipsec statusall

ip xfrm state

ip xfrm policy

Like FGT tcpdump/tshark will come in handy

tcpdump -i eth0 -nnnnvvvv proto 50 host a.a.a.a. or b.b.b.b

And finally just review iptables  ( fwpolicies)

I've been working with openswan like for  over 7 years and not so much with strongswan.

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

Good luck