Hello,
I currently have two Fortinet firewall devices : a 60D called VPN-SERVER and a 60C called VPN-CLIENT. I wish to setup an IPSEC tunnel between these two devices. Due to circumstances beyond my control, VPN-CLIENT must be located behind a NAT which means that I must resort to IPSEC Dialup mode.
The setup of the tunnel itself works perfectly fine. I am able to ping each end and I see green lights in the IPSEC monitor.
The next step that I would like to achieve is to propagate routes in between these two devices using OSPF. I have configured it using IPSEC-INTERFACE on both sides but this does not work at all. As a fallback/testing method, I have tried using static routes but they do not take effect on VPN-SERVER but show up fine on the VPN-CLIENT.
The problem seems to be that on VPN-SERVER, the IPSEC interface does not show up as IPSEC-INTERFACE but as IPSEC-INTERFACE_0. This seems to mean that any configuration (static routes or OSPF interfaces) that I try to apply to this the IPSEC interface does not apply to IPSEC-INTERFACE_0.
This is obviously a huge problem since this means that I have no means to propagate routes to and from my VPN endpoint.
How can I avoid this "_0" ghost interface altogether ? How can I use OSPF to propagate routes to and from a dialup VPN client ? Is it even possible ?
If I look at this Fortigate documentation video (https://www.youtube.com/watch?v=AMVkOVPzOCw#t=407) it surely seems possible. Also on this video you don't see the "_0" interface...
Thank you in advance for your help,
Antoine, Next-IT
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.
Where are you seeing the INTERFACE_0 at? ( get sys interface )
What do you mean by
I have tried using static routes but they do not take effect on VPN-SERVER but show up fine on the VPN-CLIENT.
Can you post the route table as-is and explain the routes you want to populate?
Ken
PCNSE
NSE
StrongSwan
On 60C side (client) if you are doing port forwarding (udp 500 and 4500) on upstream device you can create vpn in main mode and there is no need to go to dialup mode.
On 60D (server) vpn phase1 configuration you will have to mention remote gateway as the upstream public ip of 60C.
Also you need to configure local-id on 60C as the public ip (upstream ip). If you don't do this 60C will send it's private ip as identity and 60D will not accept it as we have configured remote ip as public ip.
With above main mode configuration you will be able to do do ospf between them.
In dialup it is expected to see ipsec-interface_0 becuase it is designed for multiple vpn client connection. So suppose if there are three users connecting the virtual ipsec interface for for fist user will be ipsec-interface_0 and for second ipsec-interface_1 and so on.
Hope this Solves your requirement.
@ashukla_FTNT:
Doesn't that assume that the client's public IP address is static?
2) Is it a FortiOS special feature that if the peerID is identical to the Remote Gateway address main mode can be used? IMHO you have to resort to Aggressive mode if you are using peerID/remoteIDs in a situation like this.
Indeed we got it to work with the NAT port forwarding.
Your remark is very valid regarding the remote ID. The IP can vary. We thought that we could use DynDNS to solve this. Can the remote ID but an FQDN ?
Dyndns does work with OSPF and other routing protocols. I have a tunnel with Dyndns on both ends. Works fine.
Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com
nextit wrote:Indeed we got it to work with the NAT port forwarding.
Your remark is very valid regarding the remote ID. The IP can vary. We thought that we could use DynDNS to solve this. Can the remote ID but an FQDN ?
If ip is dynamic best option is DynDNS.
Yes you can set FQDN as remote id.
Also another important point is in phase1 the default setting is "Accept any peer id" so if you are ok with this setting you don't need to change peer id on remote site.
ede_pfau wrote:@ashukla_FTNT:
Doesn't that assume that the client's public IP address is static?
That's an important point and I assumed that there is static public ip so if there is dynamic ip then we should use dynamic dns.
ede_pfau wrote:2) Is it a FortiOS special feature that if the peerID is identical to the Remote Gateway address main mode can be used? IMHO you have to resort to Aggressive mode if you are using peerID/remoteIDs in a situation like this.
I have worked with sonicwall, Juniper and Foritiage and in all of these firewalls by default if you don't specify any peer, Firewall expects the remote device to send local id as the Remote gateway address.
In Fortigate we can use Main mode even if we are not setting Remote gateway ip (by selecting diaup user) but i believe other vendors force us to use aggressive mode.
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 |
---|---|
1733 | |
1106 | |
752 | |
447 | |
240 |
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.