Forticlient IPSec Dialup Timing out

[AZFortinetMember335]

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

[AEK]

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.

[AZFortinetMember335]

@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]

@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]

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

[AZFortinetMember335]

@AEK 

Makes sense will do that.

[AZFortinetMember335]

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]

Denied by what? Can you share the log?

[AZFortinetMember335]

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

[AEK]

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.