Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    VPN Site-to-Site between Fortigate (AWS) and Netgate SG-1100 (PfSense)

    Scheduled Pinned Locked Moved IPsec
    4 Posts 2 Posters 1.1k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • R
      ricardo.aybar
      last edited by

      Hey guys, I have a problem with a VPN between a Fortigate (AWS) and a PfSense (Netgate SG-1100) at home. The VPN was working, but after I rebuild the Fortigate, the VPN is not working anymore. I'm getting this error:

      "16[IKE] <bypasslan|957> IKE_SA bypasslan[957] state change: CONNECTING => DESTROYING" in the PfSense.
      I've tried with different encryptions, hashes, IKE versions and modes with no success.

      Here are the information of both devices (configuration screenshots, log files, and debug ike -1 results).
      https://drive.google.com/drive/folders/14DUkGRDEo21XYyEsRUvis79-1RT7az0S?usp=sharing

      After debugging, I noticed both devices are behind NAT. I know if the remote peer is behind NAT, I have to use a dialup connection, but I was able to make it work for two weeks with no issue (site-to-site VPN).

      Regarding the PfSense, I have two rules allowing 4500 and 500 udp/tcp ports.

      I've been working in this issue for two weeks with no success.

      Thank you beforehand for your help!

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        @ricardo-aybar said in VPN Site-to-Site between Fortigate (AWS) and Netgate SG-1100 (PfSense):

        16[IKE] <bypasslan|957> IKE_SA bypasslan[957]

        When you see something matching bypasslan like that it means it's not matching any other phase 1 config which basically means it's not matching.

        In this case it is not matching at phase 1 because the Fortigate is sending it's internal IP as it's identifier and you have have the connection set to use 'Peer IP address' in pfSense.

        PfSense_logs_ipsecfail1.png

        Either set pfSense to use as remote Identifier: IP Address 172.31.11.165
        Or set the Fortigate to use it's actual external IP as the identifier.

        You have the pfSense IPSec logging level set far too high to be useful, you should reset the logging levels back to default.

        You don't need firewall rules to pass IPSec traffic. Traffic from the configured remote IP is passed by default.

        Steve

        1 Reply Last reply Reply Quote 1
        • R
          ricardo.aybar
          last edited by

          @stephenw10 You can't imagine how happy I am right now. After two weeks, hitting my head against a wall, I finally got the VPN up. You hit the nail on the head. I set the FG internal IP address as "Peer identifier", and voilà!

          I opened a service ticket with Fortinet (TAC), and they couldn't figure out what was causing this problem. The recommendations that they provided was mainly rebuild everything. I didn't like this option because I won't be able to do that in a production environment, and if I do so, my downtime could be huge. I posted the same problem in several forums and Facebook groups of PfSense and Fortinet, respectively, with no success. By the way, several guys thought in a NAT-T or Phase 1 misconfiguration.

          Anyone can thinks this issue is trivial, but nobody has the same expertise, and knowledge. Thank you soooooo much for your help, Steve. What you are doing here, it's so important, beyond you can even imagine. Thank you for your service, life saver!

          Screenshot_3.png

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            No problem. 👍

            1 Reply Last reply Reply Quote 1
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.