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
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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
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
PCNSE
NSE
StrongSwan
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?
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1547 | |
1031 | |
749 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.