I'm beating my head against a brick wall with an IPSec VPN configuration. Here's the basic topology:
192.168.x.x (my lan) --> [FortiGate 20c] --> 10.1.10.x (wan) --> [Cisco/Comcast Router] --> 50.1.1.1 (my public IP) --> [*Internet*] --> 50.2.2.2 (peer's public IP) --> [Linux StrongSwan] --> 172.16.x.x (peer's lan)
I have put my FG (10.1.10.10) in the DMZ on the Comcast router to try and eliminate problems there.
My FG has a functioning tunnel-mode VPN already configured and working. I'm adding a second, but interface mode.
So, I've read a LOT of the manuals and forum posts, etc, but can't seem to make this go.
I have:
ThisVPN Phase 1
IP Address: 50.2.2.2 (peer's public IP)
Local Interface: wan
Authentication method: Preshared Key
Pre-shared Key: xxxxxxxxxxxx (matches with peer)
Enable IPsec Interface Mode: enabled
IKE Version: 1
Local Gateway IP: Main Interface IP (can I / should I put my public Internet IP here instead?)
P1 Proposal: AES128 / SHA512 (matches peer)
DH Group: 2, 5 (unknown if matches peer)
Keylife 86400 seconds (matches peer)
Local ID: 50.1.1.1 (my public IP, seems to be what peer expects)
XAuth: Disabled
Nat Traversal: Enabled
DPD: Enabled
ThisVPN_P2 Phase 2
P2 Proposal: AES128 / SHA512 (matches peer)
Replay detection: enabled
PFS: disabled (matches peer)
Keylife: 86400 seconds (matches peer)
Keep alive: enabled
Auto-negotiate: enabled
Selectors: all zeroes (allow everything)
Static route:
172.16.x.x --> ThisVPN
Policies:
lan --> ThisVPN
Source: MySubnet
Dest: PeerSubnet
Sched: always
Service: all
Action: allow
ThisVPN --> lan
Source: PeerSubnet
Dest: MySubnet
Sched: always
Service: all
Action: allow
When I look at some of the debug output from the CLI, I see:
IPsec SA connect 4 10.1.10.10 -> 50.2.2.2:500
If the peer has NAT-T as I do, they will be getting an IKE request from 10.1.10.10, no? How do I fix this?
Thanks in advance for any and all help!
-Terry
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.
Hello Terry,
Your IKE traffic should be source natted with 50.1.1.1 (your public IP)
Here's a vpn t-shoot guide
http://socpuppet.blogspot.com/2013/10/site-2-site-routed-vpn-trouble-shooting.html
Here's swan guide
http://socpuppet.blogspot.com/2015/07/openswan-cmds-you-should-get-use-to.html
Quick observation:
qaud 0s is probably not going to work ( aka 0.0.0.0:0 ) for phase2 and a open/strongswan
the linux host has tcpdump, run it from the bash shell on the FGT_peer-ID
dun the diagnostic commands for ike/ipsec on the fortigate
That should lead you in the right direction.
PCNSE
NSE
StrongSwan
One of the docs I read said quad 0's was the way to allow everything. Not so?
I'll try it with my Public IP and his Private Subnet as the selectors.
-T
Again here's working openswan example
http://socpuppet.blogspot.com/2014/05/openswan-to-fortigate-route-based-vpn.html
Follow that above reference and change the lef/right to match your networks and define the PSK and enable NAT-T on the fortigate . Ensure porks 500/4500 is open on the linux side of things and ESP protocols.
1 > tcpdump on the linux side, 2> run diag cmd 3> review logs
e.g
tcpdump -i em0 "udp port 500 or 4500"
tcpdump -i em0 "proto 50"
It's really that easy.
Ken
PCNSE
NSE
StrongSwan
Thanks everyone for your help!
What ended up being the critical issues were these:
- On the Strongswan side, he had to set "rightid=%any" in ipsec.conf
- On my FG side, I had to set the P2 Quick Mode Selector Source address to my internal subnet, rather than my public IP, and the Destination address to the peer's internal subnet.
Working like a charm now!
-Terry
Terry C wrote:Hi Terry, Could you share your complete config file along with FG configuration? I'm having currently same issue and can't force it to work :( ThanksThanks everyone for your help!
What ended up being the critical issues were these:
- On the Strongswan side, he had to set "rightid=%any" in ipsec.conf
- On my FG side, I had to set the P2 Quick Mode Selector Source address to my internal subnet, rather than my public IP, and the Destination address to the peer's internal subnet.
Working like a charm now!
-Terry
Shouldn't the "Local Gateway IP" setting take care of this? It's currently set to the WAN IP, but I could set it to the Public IP instead.
The reasons I wonder about this are two:
1 There is a functioning IPsec tunnel-mode VPN on this FortiGate already, to a different vendor, with no special natting.
2 Per ALL the docs and examples, I have my Phase 1 set with NAT-T enabled. Wouldn't that defeat this?
Thanks!
-Terry
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 |
---|---|
1714 | |
1093 | |
752 | |
447 | |
232 |
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.