IPsec VPN with strongSwan to FortiGate

ipsecstrongswanvpn

I'm trying to connect to a FortiGate and access our continuous integration server via an IPsec VPN tunnel.

I have no control over the FortiGate's configuration.

On my laptop running Windows 10, I successfully used FortiClient to reach the integration server at http://ourCIserver:8080.

Now with my other laptop running Arch Linux 4.14.15, I'm using strongSwan 5.6.1 to establish the IPsec tunnel.

Encouragingly, the tunnel seems to be established when calling sudo ipsec restart, judging from the last part of sudo ipsec statusall:

Status of IKE charon daemon (strongSwan 5.6.1, Linux 4.14.15-1-ARCH, x86_64):
  uptime: 8 seconds, since Feb 14 15:45:58 2018
  malloc: sbrk 2789376, mmap 0, used 869600, free 1919776
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 5
  loaded plugins: <omitted>
Listening IP addresses:
  10.0.0.1
Connections:
         myConn:  %any...vpn.the-vpn-server.com  IKEv1 Aggressive, dpddelay=30s
         myConn:   local:  [theuser] uses pre-shared key authentication
         myConn:   local:  [theuser] uses XAuth authentication: any
         myConn:   remote: uses pre-shared key authentication
         myConn:   child:  dynamic === 10.7.0.0/24 TUNNEL, dpdaction=clear
Shunted Connections:
Bypass LAN 10.0.0.0/24:  10.0.0.0/24 === 10.0.0.0/24 PASS
Bypass LAN ::1/128:  ::1/128 === ::1/128 PASS
Bypass LAN fe80::/64:  fe80::/64 === fe80::/64 PASS
Security Associations (1 up, 0 connecting):
         myConn[1]: ESTABLISHED 7 seconds ago, 10.0.0.1[theuser]...83.xxx.xxx.xx[83.xxx.xxx.xx]
         myConn[1]: IKEv1 SPIs: 9ecabd502184611d_i* 1e7f83412c3aa933_r, pre-shared key+XAuth reauthentication in 7 hours
         myConn[1]: IKE proposal: <encryption-hash-diffie-hellman-group>
         myConn{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: cf636a4c_i 98552ddb_o
         myConn{1}:  <encryption-hash-diffie-hellman-group>, 0 bytes_i, 0 bytes_o, rekeying in 12 minutes
         myConn{1}:   10.0.0.1/32 === 10.7.0.0/24

Although the connection is up, I can't connect to http://ourCIserver:8080, which is what I'd like to achieve.

I suspect I'm missing some configuration in iptables or DNS.

Speaking of DNS, there's this part in the configuration of FortiClient (Windows) that I couldn't translate into the format of /etc/ipsec.conf:

<use_vip>1</use_vip>
<virtualip>
    <type>dhcpoveripsec</type>
    <ip>0.0.0.0</ip>
    <mask>0.0.0.0</mask>
    <dnsserver>0.0.0.0</dnsserver>
    <winserver>0.0.0.0</winserver>
</virtualip>

System Configuration

What follows is the configuration of my system that I consider relevant; let me know what else to post.

iptables-save

# Generated by iptables-save v1.6.1 on Wed Feb 14 16:31:09 2018
*filter
:INPUT ACCEPT [5889:5448467]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [4843:436153]
-A INPUT -s 10.7.0.0/24 -d 10.0.0.1/32 -i wlp3s0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A OUTPUT -s 10.0.0.1/32 -d 10.7.0.0/24 -o wlp3s0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
COMMIT
# Completed on Wed Feb 14 16:31:09 2018

ip route

default via 10.0.0.138 dev wlp3s0 src 10.0.0.1 metric 303 
10.0.0.0/24 dev wlp3s0 proto kernel scope link src 10.0.0.1 metric 303

ip link

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:1e:33:a8:53:c6 brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
    link/ether 00:22:fa:91:3e:02 brd ff:ff:ff:ff:ff:ff

sudo ip xfrm policy

src 10.0.0.1/32 dst 10.7.0.0/24 
        dir out priority 371327 
        tmpl src 10.0.0.1 dst 83.xxx.xxx.xx
                proto esp spi 0x98552dde reqid 1 mode tunnel
src 10.7.0.0/24 dst 10.0.0.1/32 
        dir fwd priority 371327 
        tmpl src 83.xxx.xxx.xx dst 10.0.0.1
                proto esp reqid 1 mode tunnel
src 10.7.0.0/24 dst 10.0.0.1/32 
        dir in priority 371327 
        tmpl src 83.xxx.xxx.xx dst 10.0.0.1
                proto esp reqid 1 mode tunnel
src fe80::/64 dst fe80::/64 
        dir fwd priority 134463 
src fe80::/64 dst fe80::/64 
        dir in priority 134463 
src fe80::/64 dst fe80::/64 
        dir out priority 134463 
src ::1/128 dst ::1/128 
        dir fwd priority 68927 
src ::1/128 dst ::1/128 
        dir in priority 68927 
src ::1/128 dst ::1/128 
        dir out priority 68927 
src 10.0.0.0/24 dst 10.0.0.0/24 
        dir fwd priority 175423 
src 10.0.0.0/24 dst 10.0.0.0/24 
        dir in priority 175423 
src 10.0.0.0/24 dst 10.0.0.0/24 
        dir out priority 175423 
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket out priority 0 
src ::/0 dst ::/0 
        socket in priority 0 
src ::/0 dst ::/0 
        socket out priority 0 
src ::/0 dst ::/0 
        socket in priority 0 
src ::/0 dst ::/0 
        socket out priority 0

/etc/ipsec.conf

config setup
  charondebug = "dmn 1, mgr 1, ike 2, chd 1, job 1, cfg 3, knl 2, net 2, enc 1, lib 1"

conn myConn
  keyexchange = ikev1

  ike = <encryption-hash-diffie-hellman-group>
  esp = <encryption-hash-diffie-hellman-group>

  aggressive = yes

  ikelifetime = 28800s

  right = 83.xxx.xxx.xx
  #right = vpn.the-vpn-server.com
  rightsubnet = 10.7.0.0/24
  rightid = %any
  rightauth = psk
  rightdns = 0.0.0.0,8.8.8.8,8.8.4.4

  left = %defaultroute
  leftauth = psk
  leftauth2 = xauth
  xauth_identity = "theuser"

  auto = start

/etc/ipsec.secrets

# ipsec.secrets - strongSwan IPsec secrets file
: PSK "secret_preshared_key"
: XAUTH "secret_xauth_password"

Connecting without DNS ✔️

Following the advice of user roaima, I contacted the CI server by its IP address: http://10.7.0.50:8080/

Going DNS-less worked after removing this part from /etc/ipsec.conf:

lifebytes = 5120

lifebytes makes the security association expire after transmitting a certain amount of bytes. Client and server were unable to reconnect in my case.

In the log, the expiration caused by lifebytes shows up as

[KNL] received a XFRM_MSG_EXPIRE

I'm now able to download the HTML of our CI server's dashboard via wget -O- --header 'Host: ourCIserver' 10.7.0.50:8080/.

Even more useful, Firefox can connect to the CI server using the IP address and render that HTML.

This means that the connection works now and allows for HTTP traffic, which is great news.

Connecting with DNS

I added

rightdns = 0.0.0.0,8.8.8.8,8.8.4.4

to /etc/ipsec.conf but ping ourCIserver fails with

Name or service not known

No luck yet with traceroute ourCIserver

ourCIserver: Name or service not known
Cannot handle "host" cmdline arg `ourCIserver' on position 1 (argc 1)

This is DNS-related configuration for FortiClient on Windows where DNS worked:

<virtualip>
    <type>dhcpoveripsec</type>
    <ip>0.0.0.0</ip>
    <mask>0.0.0.0</mask>
    <dnsserver>0.0.0.0</dnsserver>
    <winserver>0.0.0.0</winserver>
</virtualip>

I can work around the DNS issue by providing the IP/host mapping in /etc/hosts, but of course it would be preferable to get DNS using the server at the other end of the tunnel.

#<ip-address>   <hostname.domain.org>   <hostname>
10.7.0.50       ourCIserver             ourCIserver

Conclusion

I'm able to connect to the VPN using the contents of /etc/ipsec.conf above. DNS does not work but that's ok for me.

I've distilled an answer from these endeavors, for those who want to connect to FortiGate using strongSwan.

Best Answer

I've blogged about that when I needed it last. The main trick is that Fortinet requires aggressive mode, so the configuration parameters need to match closely already in the beginning.

For reference, my configuration is

conn fortinet
    left=%any
    leftauth=psk
    leftid=""
    leftauth2=xauth
    xauth_identity="your username"
    leftsourceip=%config
    right=gateway IP address
    rightsubnet=VPN subnet
    rightauth=psk
    keyexchange=ikev1
    aggressive=yes
    ike=aes128-sha1-modp1536!
    esp=aes128-sha1-modp1536!
    auto=add

You also need to configure the PSK and XAUTH secrets.

This was 2016, so the ike and esp modes could have been updated to use longer keys -- note that I enforce a particular cipher for each.

System Configuration

Connecting without DNS ✔️

Connecting with DNS

Conclusion

Best Answer

Related Solutions

StrongSwan – gives error “no known IPsec stack detected, ignoring!”

Freebsd – NAT outbound IPSEC packets using pf on FreeBSD 11 and StrongSwan x FortiGATE

Related Question