OSPF over dynamic IPsec VPN (Expert)

Facebooktwittergoogle_plusredditpinterestlinkedinFacebooktwittergoogle_plusredditpinterestlinkedin

This example shows how to create a dynamic IPsec VPN tunnel and allowing OSPF through it.

1. Configuring IPsec in FortiGate 1

Go to System > Status to look for the CLI Console widget and create phase 1.

config vpn ipsec phase1-interface
    edit "dial-up"
        set type dynamic
        set interface "wan1"
        set mode-cfg enable
        set proposal 3des-sha1
        set add-route disable
        set ipv4-start-ip 10.10.101.0
        set ipv4-end-ip 10.10.101.255
        set psksecret
    next
end

Create phase 2.

config vpn ipsec phase2-interface
    edit "dial-up-p2"
        set phase1name "dial-up"
        set proposal 3des-sha1 aes128-sha1
    next
end

2. Configuring OSPF in FortiGate 1

Go to System > Status to look for the CLI Console widget and create OSPF route.

config router ospf
    set router-id 172.20.120.22
        config area
            edit 0.0.0.0
            next
        end
        config network
            edit 1
                set prefix 10.10.101.0 255.255.255.0
            next
        end
        config redistribute "connected"
            set status enable
        end
        config redistribute "static"
            set status enable
        end
end

 3. Adding policies in FortiGate 1

Go to Policy & Objects > Policy > IPv4 and create a policy allowing OSPF traffic from dial-up to port5.

 
 

Go to Policy & Objects > Policy > IPv4 and create a policy allowing OSPF traffic from port5 to dial-up interfaces.

 

4. Configuring IPSec in FortiGate 2

Go to System > Status to look for the CLI Console widget and create phase 1.

config vpn ipsec phase1-interface
    edit "dial-up-client"
        set interface "wan1"
        set mode-cfg enable
        set proposal 3des-sha1
        set add-route disable
        set remote-gw 172.20.120.22
        set psksecret
    next
end

Create phase 2.

config vpn ipsec phase2-interface
    edit "dial-up-client-p2"
        set phase1name "dial-up-client"
        set proposal 3des-sha1 aes128-sha1
        set auto-negotiate enable
    next
end

5. Configuring OSPF in FortiGate 2

Go to System > Status to look for the CLI Console widget and create OSPF route.

config router ospf
    set router-id 172.20.120.25
        config area
            edit 0.0.0.0
            next
        end
        config network
            edit 1
                set prefix 10.10.101.0 255.255.255.0
            next
        end
        config redistribute "connected"
            set status enable
        end
        config redistribute "static"
            set status enable
        end
end

6. Adding policies in FortiGate 2

Go to Policy & Objects > Policy > IPv4 and create a policy allowing OSPF traffic from dial-up-client to port5.

Go to Policy & Objects > Policy > IPv4 and create a policy allowing OSPF traffic from port5 to dial-up-client interfaces.

 

8. Verifying tunnel is up

Go to VPN > Monitor > IPsec Monitor to verify that the tunnel is Up.

 

 9. Results

From FortiGate 1, go to Router > Monitor > Routing Monitor and verify that routes from FortiGate 2 were successfully advertised to FortiGate 1 via OSPF.   
From FortiGate 1, go to System > Status to look for the CLI Console widget and type this command to verify OSPF neighbors.

get router info ospf neighbor

OSPF process 0:
Neighbor ID     Pri   State      Dead Time   Address         Interface
172.20.120.25     1   Full/ -    00:00:34    10.10.101.1     dial-up_0

From FortiGate 2, go to Router > Monitor > Routing Monitor and verify that routes from FortiGate 1 were successfully advertised to FortiGate 2 via OSPF.

 
From FortiGate 2, go to System > Status to look for the CLI Console widget and type this command to verify OSPF neighbors.

get router info ospf neighbor

OSPF process 0:
Neighbor ID     Pri   State   Dead Time   Address      Interface
172.20.120.22     1   Full/ - 00:00:30    10.10.101.2  dial-up-client

For further reading, check out IPsec VPN and Open Shortest Path First (OSPF) in the FortiOS 5.2 Handbook.

 

Taher Elbar

Taher Elbar

Technical Product Specialist at Fortinet
After a Bachelor degree in Telecommunications from university of Geneva, Taher began his career in software development, then moved to System/Network administration followed by Security Support Engineer. With over 10 years of experience, Taher is writing various Technical documentation for Fortinet.
Taher Elbar
  • Was this helpful?
  • Yes   No
  • Annika

    Hi
    It is a bit confusig why you use “port 5” in policies even though we can asume it is the “LAN” port (or one of them). Bit since you are redistributing static and connected it would be great if you can add ports and nets to the picture.
    Otherwise good article.
    Best regards

  • Mario

    GOOD AFTERNOON.
    I’VE DONE THE STEP-BY-STEP GUIDE AND I HAVE A PROBLEM.
    I HAVE A 200B AS A SERVER VPN THAT HAS STATIC IP AND WITH 40 TEAMS 60C THAT ARE CLIENTS AND ARE BEHIND A NAT.
    THE PROBLEM I HAVE IS THE LOSS OF PACKETS BETWEEN THE LAN THAT IS BEHIND THE SERVER VPN AND THE LAN THAT IS BEHIND THE CLIENTS AND VICE VERSA.
    THE TESTS I DID ARE:
    1. DISCONNECT THE CLIENTS AND CONNECT A WINDOWS NOTEBOOK DIRECTLY TO THE INTERNET MODEM AND PING THE GATEWAY VPN AND IT ARRIVES PERFECTLY WITHOUT LOSS OF PACKAGES, AND IN PARALLEL I CONNECTED TO THE 60C A NOTEBOOK WITH WINDOWS AND I PING THE LAN THAT IS BEHIND OF THE VPN SERVER AND LOSES PACKETS INSIDE THE TUNNEL.
    2. I DID THE SAME TEST, BUT WITH A MACHINE WITH LINUX AND DO NOT LOSE ANY PACKAGES, LEAVE THE WINDOWS MACHINE IN PARALLEL AND THE WINDOWS NOTEBOOK IF YOU LOSE PACKAGES.
    3. I PING FROM THE SERVER VPN (200B) TO THE CLIENT (TO THE PORT THAT IS AGAINST THE LAN) AND ARRIVES WITHOUT PROBLEMS, THE SAME FROM THE CLIENT TO THE VPN SERVER.
    IT IS VERY RARE BECAUSE FROM LINUX MACHINES DOES NOT LOSE ANY PACKAGE, AND FROM WINDOWS ITSELF.
    I HOPE THEY CAN HELP ME SINCE ALL THE MACHINES BEHIND THE CLIENTS ARE WINDOWS.
    FROM ALREADY THANK YOU VERY MUCH, GREETINGS.

    PS: I HOPE TO EXCUSE MY ENGLISH, USE THE GOOGLE TRANSLATE.

    • Taher Elbar

      Hi Mario,

      This recipe is for advertising OSPF routes between FortiGates over a dynamic IPsec VPN, If you need to have machines behind each FortiGate to talk to each other through the vpn, then you need to set a Site-to-site IPsec VPN with two FortiGates : http://cookbook.fortinet.com/site-to-site-ipsec-vpn-with-two-fortigates-5-4/
      Regards,
      Taher.

      • Mario

        HI, TAHER.

        FIRST OF ALL, THANK YOU VERY MUCH FOR ATTENDING MY CONSULTATION.
        WELL, WHAT GOOD IS IT FOR ME TO SHARE ROUTES IF I CAN NOT SEND TRAFFIC ON THOSE ROUTES?
        USE YOUR GUIDE BECAUSE MY MAIN PROBLEM IS THAT I NEEDED TO HAVE BI-DIRECTIONAL TRAFFIC THROUGH VPN ON COMPUTERS THAT ARE BEHIND A NAT (LIKE A HOMEBOUND REUTER THAT PROVIDES A LOCAL ISP), YOUR GUIDE THAT IS TO SEND OSPF TRAFFIC SERVED ME PERFECT FOR WHICH I WANTED, SINCE THE VPN CONNECTS AS A CLIENT DYNAMICALLY AND WHEN IT SHARES THE ROUTES WITH OSPF HAPPENS TO BE LIKE A SITE TO SITE.
        ALL THIS IS PERFECT, I JUST HAVE THE PROBLEM OF PACKET LOSS. IF I COULD SOLVE THIS PROBLEM THIS RECIPE WOULD BE PERFECT.
        IF IT IS NOT POSSIBLE TO USE THIS RECIPE FOR WHAT I NEED YOU WOULD RECOMMEND ME?

        THANK YOU AGAIN AND A VERY MERRY CHRISTMAS. THANKS.

        • bonnyfused

          Hi Mario,
          first of all – you’re SCREAMING here, which is really not needed. Please unlock your caps-lock 😉 Where are you from?
          Secondly… packet loss has nothing to do with VPN “per se”. As you already stated, Linux computers do not lose packets, Windows (you didn’t mention any version) are losing packets. Also, you didn’t mention if you’re using WLAN or a cable connection (RJ45).
          Anyway: I might presume (I don’t know) that the Windows PC is busy doing other things, thus doesn’t send/reply to pings. Did you try the same Linux on the Windows PC (like with a “live distribution”)?
          I wanted to point you towards MTU size, but ping packets are usually small enough to pass through without suffering fragmentation.

          • Mario

            Hello, gentlemen, a very merry Christmas for all, I hope you had a good time with your loved ones.
            Sorry for yelling, it is not my intention , I do not know how to unlock the caps-lock.

            I am from Argentina, and as you will know in many places of my country we do not have ISPs that can give us static addresses and we have the need to have two-way traffic with our clients that are in areas such as those mentioned. This is why this solution is ideal for us.
            Regarding the versions of Windows, the tests I made with Windows 7, 10 and server 2012, Linux are had 8 and FortiOS of fortigate and all connections are wired with twisted pair.
            I have not tried the same Linux on Windows PC, regarding the MTU also occurred to me, but Windows handles 32bytes while Linux 64bytes, I tried uploading the Windows MTU to 64bytes and it does the same.
            The truth is a serious problem because the internal services we have become intermittent.
            I’ve looked at how to debug the traffic, but I can not find anything. Can anyone guide me to be able to detect where the packet loss is?

            Thanks for your help, regards.

          • Mario

            good afternoon.

            I bring a little more information about my problem to see if it is something of this. Punctually the problem is in the clients, since connecting the fortigate 60c in addition to losing packets inside the ipsec tunnel also loses packages using the internet of the local supplier, and removing the fortigate does not lose packages.

            |pc client|-> internal 1(switch “lan-172.19”) ->| 60c | ->wan 1->modem isp ->|internet| (Lose packages)

            |pc client|-> internal 1(switch “lan-172.19”) ->| 60c | ->wan 1 -> |tunel ipsec| (Lose packages)

            Internal 1 is part of a software switch between the internal1 internal2 and internal3 ports (called “lan-172.19”).
            I made a debug of the ports to see the mtu and I throw this.

            60c-CLIENTE (root) # diagnose netlink interface list

            if=lo family=00 type=772 index=1 mtu=16436 link=0 master=0
            ref=4 state=present fw_flags=0 flags=loopback

            if=dummy0 family=00 type=1 index=2 mtu=1500 link=0 master=0
            ref=1 state=present fw_flags=0 flags=broadcast noarp

            if=eth0 family=00 type=1 index=3 mtu=1500 link=0 master=0
            ref=3 state=present tx_sched fw_flags=0 flags=broadcast multicast

            if=wan1 family=00 type=1 index=4 mtu=1500 link=0 master=0
            ref=7 state=start present tx_sched fw_flags=0 flags=up broadcast allmulti multicast

            if=wan2 family=00 type=1 index=5 mtu=1500 link=0 master=0
            ref=98 state=start present fw_flags=0 flags=up broadcast run allmulti multicast

            if=dmz family=00 type=1 index=6 mtu=1500 link=0 master=0
            ref=10 state=start present fw_flags=0 flags=up broadcast run promsic allmulti multicast

            if=internal5 family=00 type=1 index=7 mtu=1500 link=0 master=0
            ref=8 state=start present fw_flags=0 flags=up broadcast run allmulti multicast

            if=internal4 family=00 type=1 index=8 mtu=1500 link=0 master=0
            ref=9 state=start present fw_flags=0 flags=up broadcast run promsic allmulti multicast

            if=internal3 family=00 type=1 index=9 mtu=1500 link=0 master=0
            ref=8 state=start present tx_sched fw_flags=0 flags=up broadcast promsic allmulti multicast

            if=internal2 family=00 type=1 index=10 mtu=1500 link=0 master=0
            ref=8 state=start present tx_sched fw_flags=0 flags=up broadcast promsic allmulti multicast

            if=internal1 family=00 type=1 index=11 mtu=1500 link=0 master=0
            ref=9 state=start present fw_flags=0 flags=up broadcast run promsic allmulti multicast

            if=modem family=00 type=512 index=12 mtu=1500 link=0 master=0
            ref=7 state=present fw_flags=0 flags=p2p noarp allmulti multicast

            if=root family=00 type=772 index=15 mtu=16436 link=0 master=0
            ref=56 state=start present fw_flags=0 flags=up loopback run

            if=ssl.root family=00 type=512 index=16 mtu=1500 link=0 master=0
            ref=7 state=start present fw_flags=0 flags=up p2p run noarp multicast

            if=VSAT family=00 type=772 index=17 mtu=16436 link=0 master=0
            ref=15 state=start present fw_flags=0 flags=up loopback run

            if=VSAT-ROOT0 family=00 type=1 index=19 mtu=1500 link=0 master=0
            ref=7 state=present fw_flags=0 flags=broadcast multicast

            if=VSAT-ROOT1 family=00 type=1 index=20 mtu=1500 link=0 master=0
            ref=10 state=start present tx_sched fw_flags=0 flags=up broadcast promsic multicast

            if=LAN-172.19 family=00 type=1 index=21 mtu=1500 link=0 master=0
            ref=93 state=start present fw_flags=3800 flags=up broadcast run multicast

            if=VPN_DNG family=00 type=768 index=22 mtu=65535 link=0 master=0
            ref=6 state=start present tx_sched fw_flags=0 flags=up p2p noarp multicast

            if=VPN_DNG2 family=00 type=768 index=23 mtu=1438 link=0 master=0
            ref=49 state=start present fw_flags=0 flags=up p2p run noarp multicast

            if=vsys_ha family=00 type=772 index=25 mtu=16436 link=0 master=0
            ref=12 state=start present fw_flags=0 flags=up loopback run

            if=port_ha family=00 type=1 index=26 mtu=1496 link=0 master=0
            ref=7 state=start present fw_flags=0 flags=up broadcast run multicast

            if=VSAT.b family=00 type=1 index=27 mtu=1500 link=0 master=0
            ref=13 state=start present fw_flags=0 flags=up broadcast run multicast

            if=vsys_fgfm family=00 type=772 index=28 mtu=16436 link=0 master=0
            ref=12 state=start present fw_flags=0 flags=up loopback run

            I hope to serve you, greetings

          • Taher Elbar

            Hi Mario,
            Since with Linux machine there was not a packet loss, I presume that the issue is not related to the IPsec VPN. I recommend you to open a ticket with our Technical support at https://support.fortinet.com/

            Regards,
            Taher.

  • bonnyfused

    Hi Taher and thanks for your articles – pretty good ones!
    Now, in this one you’re creating policies with “OSPF” as the service being allowed from/to VPN interface to port5.
    1. What is port5 actually? There’s no mention in the article.
    2. The policies are only needed for the VPN to be negotiated, no OSPF traffic is passing through them. I used “dmz” instead of port5, where my dmz port is not connected to anything and it still worked! I presume this comes from the fact that OSPF will use the OSPF configured network (10.10.101.0/24 in this example) which actually corresponds to the IPs the VPN interfaces are getting when VPN is up.

    Can you comment on the above?
    Thanks,
    Flavio.

    • Taher Elbar

      Hi Flavio,
      1. Port5 is actually facing the internal network, this is needed when you create a Firewall policy as if you do not select inbound/outbound port, the policy won’t be created. It can be any other interface.

      2. Now, Yes the policies are needed for the VPN tunnel to be UP, and OSPF traffic is encrypted inside the tunnel. But at each end of the tunnel (dial-up/dial-up-client interfaces) the OSPF traffic is encrypted/decrypted, then the FortiOS Firewall component checks for this traffic if it’s allowed. That’s why I used the service as OSPF if you need to redistribute OSPF traffic sourced from the internal network (port5, or any other port name used).

      3. As you mentioned, in this example, The OSPF uses the same VPN network (10.10.101.0/24) when it’s UP, and you do not even need to go through the FortiOS firewall component. The FortiOS router component advertise the OSPF routing table via the IPsec tunnel (same network) without traversing the FortiOS Firewall. You can test this by choosing a different service, except ALL, in the policies. It should still work.
      Let me know the results.
      Regards,
      Taher.

      • bonnyfused

        Hi Taher,
        many thanks for your feedback. I now understand that you used OSPF service only because you were supposing having some other routers “behind” the Fortigate, which would want to talk OSPF through the VPN tunnel.
        But for the main purpose of having OSPF between the two FGTs, that’s not necessary.
        All the rest is clear!
        Thanks,
        F.