Strongswan <--> Fortigate

[aag]

Dear people,

I'm trying to set up a Strongswan-based IPSec connection with a partner institution that uses Fortinet Fortigate.

The connection is established successfully and the packets that I send (from left to right) go through the tunnel and are seen on the other side, however, nothing seems to come back. I wonder if someone has experienced this issue before and there is something we can do to solve the problem.

This is the Strongswan  configuration I'm using for the left side server.  The "right side" is the Fortigate server.

ipsec.conf

config setup
        charondebug="all"
        uniqueids=yes
        strictcrlpolicy=no

conn %default
conn tunnel
        left=141.a.b.c
        leftsubnet=192.168.66.0/24
        lefthostaccess=yes
        leftsourceip=%config
        right=193.d.e.f
        rightsubnet=192.168.19.0/24
        ike=aes256-sha256-prfsha256-ecp521!
        esp=aes256-sha256!
        keyingtries=0
        ikelifetime=28800s
        lifetime=14400s
        dpddelay=30
        dpdtimeout=120
        dpdaction=restart
        authby=secret
        auto=start
        keyexchange=ikev2
        type=tunnel

The connection seems to be ok, both Strongswan and Fortigate show no errors:

ipsec statusall

Status of IKE charon daemon (strongSwan 5.1.3, Linux 3.12.74-60.64.124-default, x86_64):
  uptime: 21 hours, since Feb 10 16:04:02 2020
  malloc: sbrk 2838528, mmap 0, used 671024, free 2167504
  worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, scheduled: 5
  loaded plugins: charon ldap pkcs11 aes des blowfish rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt af-alg fips-prf gmp agent xcbc cmac hmac ctr ccm gcm curl soup attr kernel-netlink resolve socket-default farp stroke smp updown eap-identity eap-sim eap-sim-pcsc eap-aka eap-aka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc xauth-generic xauth-eap xauth-pam tnc-imc tnc-imv tnc-tnccs tnccs-20 tnccs-11 tnccs-dynamic dhcp certexpire led duplicheck radattr addrblock unity
Listening IP addresses:
  141.a.b.c
  192.168.66.1
Connections:
      tunnel: 141.a.b.c...193.d.e.f IKEv2, dpddelay=30s
      tunnel: local: [141.a.b.c] uses pre-shared key authentication
      tunnel: remote: [193.d.e.f] uses pre-shared key authentication
      tunnel: child: 192.168.66.0/24 === 192.168.19.0/24 TUNNEL, dpdaction=restart
Security Associations (2 up, 0 connecting):
      tunnel[4]: ESTABLISHED 6 hours ago, 141.a.b.c[141.a.b.c]...193.d.e.f[193.d.e.f]
      tunnel[4]: IKEv2 SPIs: fd1ce3e19651ea83_i b0e8873d947ad4e8_r*, pre-shared key reauthentication in 76 minutes
      tunnel[4]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_521
      tunnel[1]: CONNECTING, 141.a.b.c[141.a.b.c]...193.d.e.f[193.d.e.f]
      tunnel[1]: IKEv2 SPIs: 38a8d3b8593af26a_i* 77f1ac5ed3598059_r
      tunnel[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_521
      tunnel[1]: Tasks active: IKE_CERT_PRE IKE_AUTH IKE_CERT_POST IKE_CONFIG CHILD_CREATE IKE_AUTH_LIFETIME IKE_MOBIKE

ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:x:x:x:x:x brd ff:ff:ff:ff:ff:ff
    inet 141.a.b.c/22 brd 141.a.b.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 192.168.66.1/24 brd 192.168.66.255 scope global eth0:1
       valid_lft forever preferred_lft forever
    inet6 fe::0:f:f7:b/64 scope link
       valid_lft forever preferred_lft forever

The routing tables:

ip route list table all

192.168.19.0/24 via 192.168.66.1 dev eth0  table 220  proto static  src 192.168.66.1
default via 141.a.b.1 dev eth0
141.a.b.0/22 dev eth0  proto kernel  scope link  src 141.a.b.c
192.168.66.0/24 dev eth0  proto kernel  scope link  src 192.168.66.1
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 127.0.0.1
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 127.0.0.1
broadcast 141.a.b.0 dev eth0  table local  proto kernel  scope link  src 141.a.b.c
local 141.a.b.c dev eth0  table local  proto kernel  scope host  src 141.a.b.c
broadcast 141.a.b.255 dev eth0  table local  proto kernel  scope link  src 141.a.b.c
broadcast 192.168.66.0 dev eth0  table local  proto kernel  scope link  src 192.168.66.1
local 192.168.66.1 dev eth0  table local  proto kernel  scope host  src 192.168.66.1
broadcast 192.168.66.255 dev eth0  table local  proto kernel  scope link  src 192.168.66.1
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101
local ::1 dev lo  proto kernel  metric 256
fe80::/64 dev eth0  proto kernel  metric 256
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101
local ::1 dev lo  table local  proto none  metric 0
local f::2:f:7:b8 dev lo  table local  proto none  metric 0
ff00::/8 dev eth0  table local  metric 256
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101

It doesn't seem to be firewall-related, at least of the left side, since I disabled all rules for testing purposes.

iptables -nL

Chain INPUT (policy ACCEPT)
target prot opt source destination 

Chain FORWARD (policy ACCEPT)
target prot opt source destination 

Chain OUTPUT (policy ACCEPT)
target prot opt source destination 

Any idea about what can we do to further debug this problem?

Thanks

Alvaro

[tioeudes]

Ask the fgt administrator to check for routing or firewall policies that might be missing. Normaly this is the case.

Also, the Quick Mode Selectors on his side match your left/right side networks.

regards,

tioeudes

[emnoc]

OP your on the right track, the suggestion give earlier is correct. I would aks for the diag vpn tunnel list or gather SPIs from  your site to ensure they match.

e.g

  ipsec statusall

or   

  ipsec status tunnel

Also the FGT "policy AND routing" on that far end needs to be verified and ensure that they didn't do something hanky like enabled SNAT. They can double check traffic is coming and going via "diag sniffer packet 'route-basd-vpn-name' " you can do a ping and ask them to see if that gets to the firewall and for any replies sent back from the FGT ---->----StrongSwan

Glad to see another strongswan guy on the forum ;) 

Ken Felix

[aag]

Thank you for the feedback. Unfortunately we haven't found a solution yet and the problem is driving me crazy.

Right side swears for the almighty god that the routing on their side is properly configured and I don't see any packets being dropped on my (left) side.

Is there any other trick in the toolbox that we can try?