Hello there,
I am a FortiGate beginner trying to create a IPsec VPN using IKEv2 between a FortiGate and a pfSense firewall.
Both sides are directly accessable from the internet, no NAT, using DynDNS.
Both IKE phases are up and running, however it can't get Ping to work between the two devices.
My local Fortigate has it's Management Interface as 10.20.1.1/24. The remote network I need to reach is 10.222.0.0/24, with 10.222.0.1 as the pfSense in that network. More routes to different networks via 10.222.0.1 will follow in the future, but that's not important at this step.
However, I don't understand where some information in the routing table comes from.
This is the output from the "get router info routing-table all" command:
S 10.222.0.0/24 [10/0] via StS-VPN-dvnetzw tunnel 10.0.0.5, [1/0]
10.0.0.5 is not at the remote side and I never configured this IP. Where does it come from and how do I need to customize the routing table entry? Shouldn't the next hop for 10.222.0.0/24 be 10.222.0.1?
I've also noticed that the Tunnel Interface beneath my wan1 Port (my Internet Access) does not have a IP configured. What do I need to configure here?
Sorry if I'm mixing up some things here, as mentioned above I am totally new to FortiGate.
Thank you for helping.
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.
Hi @Max99,
I think it(10.0.0.5) is showing your tunnel ID. When you configure the static route for the tunnel, it automatically selects the gateway. If you don't specify the IP to the interface, then it will select the tunnel ID.
You can refer the following article: https://community.fortinet.com/t5/FortiGate/Technical-Tip-IPSEC-VPN-route-shows-a-different-gateway-...
Could you please provide the output of "di vpn ike gateway list"?
Best Regards,
Maulish Shah
Hello Maulish,
thanks for your answer.
This is the output of "diag vpn ike gateway list":
vd: root/0
name: StS-VPN-dvnetzw
version: 2
interface: wan1 6
addr: <LOCAL IP ADDRESS>:500 -> <PEER IP ADDRESS>:500
tun_id: 10.0.0.5/::10.0.0.5
remote_location: 0.0.0.0
network-id: 0
virtual-interface-addr: 100.64.0.1 -> 100.64.0.2
created: 51828s ago
peer-id: <PEER IP ADDRESS>
peer-id-auth: no
PPK: no
IKE SA: created 1/3 established 1/3 time 0/23/60 ms
IPsec SA: created 1/18 established 1/18 time 0/6/60 ms
id/spi: 85620 3e14c2b0e743407f/619d0a77be610f2e
direction: responder
status: established 3208-3208s ago = 0ms
proposal: aes128-sha256
child: yes
SK_ei: c8b7fdca0f1fe53c-4a57a4b3ab3d0771
SK_er: 69ddf7da6b9eb815-6e76c555830f21a3
SK_ai: 733c4297fe24b48a-f03171e0c92488fd-3381bf0998fa41ff-212cafb8569743b5
SK_ar: c8a21a711f804a47-e7ec6bec3d6f837e-bca69ea72b63ed00-e3495a6f6b1d0919
message-id sent/recv: 0/321
lifetime/rekey: 86400/82921
DPD sent/recv: 00000000/00000000
peer-id: <IP Address>
The virtual interface address now also says "100.64.0.1", this was set by me because I tried something else. I bet this is wrong and needs to be reverted, however I can't set the tunnel's Interface address back from "manual". This should be on auto, right?
It didn't work either way (auto, custom). How can I revert this back?
Your circuit is not behind CGNAT(Carrier Grade NAT), right? I'm asking this because 100.64.x.x is CGNAT IP range. If so, the static IPSec like you configured wouldn't work.
Toshi
Hi @Max99,
Thanks for your input.
You can clearly see in the output
vd: root/0
name: StS-VPN-dvnetzw
version: 2
interface: wan1 6
addr: <LOCAL IP ADDRESS>:500 -> <PEER IP ADDRESS>:500
tun_id: 10.0.0.5/::10.0.0.5 <----- This is the tunnel ID showing under the static route gateway. This shows in the static route because you don't apply any IP address on the tunnel interface.
remote_location: 0.0.0.0
network-id: 0
virtual-interface-addr: 100.64.0.1 -> 100.64.0.2
created: 51828s ago
peer-id: <PEER IP ADDRESS>
Please let me know if you would like to know further.
Hi Maulish,
thanks again for your time.
I now started from scratch, following this youtube tutorial: https://www.youtube.com/watch?v=XwhWbaby6OU using IKEv1 and all the other security settings.
Still no luck.
This is the new output of the the command:
s-fw-p-home-fwf60e-01 # diag vpn ike gateway list
vd: root/0
name: StS-VPN-dvnetzw
version: 1
interface: wan1 6
addr: <LOCAL IP ADDRESS>:500 -> <PEER IP ADDRESS>:500
tun_id: 10.0.0.8/::10.0.0.8
remote_location: 0.0.0.0
network-id: 0
created: 371s ago
peer-id: <PEER IP ADDRESS>
peer-id-auth: no
IKE SA: created 1/1 established 1/1 time 21110/21110/21110 ms
IPsec SA: created 1/1 established 1/1 time 20/20/20 ms
id/spi: 203075 9e88f8a1ca58c649/b59c52b86638983d
direction: initiator
status: established 371-350s ago = 21110ms
proposal: aes256-sha256
key: ea0d457a073e292c-75c411f69861670b-f6634f6775cf0d98-ea6c481e26ecaee4
lifetime/rekey: 28800/28149
DPD sent/recv: 00000000/6c9a6f72
peer-id: <PEER IP ADDRESS>
This is my static route setting:
Routing table for VRF=0
S* 0.0.0.0/0 [5/0] via 91.66.139.254, wan1, [1/0]
C 10.20.1.0/24 is directly connected, lan
C 10.20.3.0/24 is directly connected, internal3
C 10.20.6.0/24 is directly connected, guestlan
C 10.20.10.0/24 is directly connected, dmz
S 10.222.0.0/24 [10/0] via StS-VPN-dvnetzw tunnel 10.0.0.8, [1/0]
C 10.253.240.0/20 is directly connected, wqt.root
Can you something wrong here?
I created to firewall rules, one for "in" traffic with source VPN, destination local subnet and source+destination+service "all", and one the other way round.
Do you have multiple IPSecs between the FGT and pfSense? That 10.x.x.x tunnel ID is assigned when there are mulitple tunnels to the same gateway IP as described below.
https://docs.fortinet.com/document/fortigate/7.0.0/new-features/649094/dedicated-tunnel-id-for-ipsec...
If you want to see a summary of all IPsec tunnels, "get vpn ipsec tun sum" would show you all. Any IPsec issues, check three things:
1. phase2 network selectors
2. route for src and dst
3. policy set
Then run sniffing "diag sniffer packet <interface> 'filter_set' opitons" to see if the traffic is going in and/or coming out of the tunnel.
Toshi
In addition, if you want to try to ping the remote gateway via tunnel, you might need an additional setting:
#exe ping-options source <IP>
-> you should set an IP here that is both an interface on the FortiGate, AND matches the local P2 selector on FortiGate; typically a LAN or mgmt interface (10.20.1.1 for example, if pfSense should be able to reach that IP via tunnel)
#exe ping 10.222.0.1
-> this should work after you have set an appropriate source IP for ping
To unset the source IP again:
#exe ping-options source auto
-> this is the default setting, and makes FortiGate use the outgoing interface's IP as source for the ping. Using the outgoing interface IP will usually NOT work if it is a tunnel interface, as by default tunnel interfaces do not have an IP
Also did you create firewall policies to allow this traffic?
You should create 2 firewall policies from LAN To Tunnel interface and from Tunnel interface to LAN. Also check if the phase 2 selectors are properly configured on both sides.
As per previous reply, you should use source IP when pinging.
exe ping-options source 10.20.1.1
exe ping 10.222.0.1
In another cli window run this sniffer and then initiate ping:
diag sniffer packet any 'host 10.222.0.1 and icmp' 4 0 l
Regards,
Varun
Also be warned that there is a bug in the FortiOS IPSec Stack which might affect you if you use a ddns remote gw on the FGT. IPSec does not update the remote gw then. So tunnel might come up and stay until remote side ip changes and then goes down and will not come up and stil show you the old gw ip. I did report this to TAC but they did never provide any solution to it.
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
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 |
---|---|
1634 | |
1063 | |
751 | |
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.