Skip to main content
AZFortinetMember335
AZFortinetMember335
New Member
August 12, 2025
Solved

Forticlient IPSec Dialup Timing out

  • August 12, 2025
  • 7 replies
  • 4339 views

So we trying to setup a new Dialup IPSec tunnel but we keep getting a connection time out message. We rebuild the tunnel and policies multiple times thinking we missed a step but from the videos we found online this should be the simplest thing to do. I can see the traffic make it to the firewall and I see in the local traffic logs that the traffic is denied (even though we setup local-in-polices) to allow the IKE traffic. 

 

So we are stumped and we are hoping that we are missing something simple that a more experienced person setting these things up might clue us in on. Our firewalls are running 7.4.8 and we are running Forticlient 7.4.3 (We've also tried 7.0.9 and 7.2.9 since some posts we stating older versions worked vs the latest version).

 

I feel something is blocking the traffic on the Firewall I'm just not sure what it could be. Thanks for all and any help.

 

Phil

Best answer by AZFortinetMember335

Ok, I figured out what was going on. This is an obvious setting looking back, but for someone setting up for the first time and coming from IKEv1 this could hang you up. If you are just testing proper tunnel setup. Make sure on the Forticlient side of things that you select 'Disable' for "Authentication (EAP)". This was causing the mismatch because we have not setup EAP yet. So an easy gotcha if you are starting from scratch. If this was already setup than you wouldn't have run into the issue I ran into. Thanks for the help. 

7 replies

AEK
SuperUser
AEK
SuperUser
August 12, 2025

Does the WAN interface on which you configured IPsec have multiple IP addresses? In that case you may need to specify in phase 1 config which IP address is listening.

AEK
    AZFortinetMember335
    AZFortinetMember335Author
    New Member
    August 12, 2025

    @AEK 

    Thanks for the suggestion. We did set the tunnel to a 'Secondary IP' address in the VPN config. We also used the 'Primary IP' with the same results. Traffic from the remote computer does show up to both IPs (depending on which IP address we select on the remote computer).

     

    In the Local Traffic logs I see the message 'Connection Failed' with an Application Name of 'IPSec' with a Service of 'IKE'. In the local-in Policy I allowed the 'IKE' service which I assume would allow the connection. Do I need to add 'IPSec' to the allow rule. I wouldn't see why but figured I'd ask.

    AZFortinetMember335
    AZFortinetMember335Author
    New Member
    August 12, 2025

    @AEK 

    I had a ah-ha moment and I realized after looking through the Local-In logs that the traffic was being denied by the catch-all deny rule for the IKE service. The source address was set to the range of IP that the computers would be assigned once connected. My misunderstanding on when the rule applies. So if we don't know where the traffic is coming from is having the source set to "all" acceptable and secure?

    The client is still getting a timeout but at least we are past the first block.

    AEK
    SuperUser
    AEK
    SuperUser
    August 12, 2025

    I'd specify a GeoIP object (e.g.: from your country only), which is better for security than "all".

    AEK
      AZFortinetMember335
      AZFortinetMember335Author
      New Member
      August 13, 2025

      We were able to get connected just fine using IKEv1. When we tried using IKEv2 it was denied again. Though this time the local-in logs were not pointing to a local-in policy, just that access was denied. I do see the traffic making it to the firewall though.

      AEK
      SuperUser
      AEK
      SuperUser
      August 13, 2025

      Denied by what? Can you share the log?

      AEK
      AZFortinetMember335
      AZFortinetMember335Author
      New Member
      August 13, 2025

      I was looking at the GUI side of the logs. Is there a particular command to pull those logs?

      AEK
      SuperUser
      AEK
      SuperUser
      August 13, 2025

      Try reproduce the issue and take a screenshot on the logs, + log details on right pan when you double-click on the related log record.

      AEK
      AZFortinetMember335
      AZFortinetMember335Author
      New Member
      August 14, 2025

      @AEK 

      I'll try and get to that next week. Since IKEv1 is up we are working on getting the routing setup. Running into issues with that but trying to work through it. Once we get that aspect solved I can move back to the IKEv2 issue.

      AZFortinetMember335
      AZFortinetMember335Author
      New Member
      August 26, 2025

      So it looks like it is trying to negotiate Phase1 Key Exchange but is failing. This is what I see in the logs when the client tries to connect (invalid IKE request SPI). I see 2 different Auth IDs trying to negotiate the exchange but fails. I verified that both setting on the firewall and Forticlient match. Any ideas what to check for?

      AZFortinetMember335
      AZFortinetMember335AuthorAnswer
      New Member
      August 26, 2025

      Ok, I figured out what was going on. This is an obvious setting looking back, but for someone setting up for the first time and coming from IKEv1 this could hang you up. If you are just testing proper tunnel setup. Make sure on the Forticlient side of things that you select 'Disable' for "Authentication (EAP)". This was causing the mismatch because we have not setup EAP yet. So an easy gotcha if you are starting from scratch. If this was already setup than you wouldn't have run into the issue I ran into. Thanks for the help. 

        Terms & ConditionsAccessibility statement