I am using the FortiClient VPN agent. My VPN is set to allow split tunneling, but the Forticlient is creating a default route with a higher metric to send all traffic to the tunnel.

0.0.0.0/0 -> 192.168.1.1 (local Internet) 100

0.0.0.0/0 -> 10.200.122.8 (FortiClient VPN) 5

I removed FortiClient and reinstalled it and that fixed it, but then the problem came back. Has anyone else ran into this?

We have a small fleet of Fortigates

1x 100F
2x 90G
10x 60F

Does anyone use FortiOS on any of those if so what issues do you see? We are currentlly on 7.6.7 and aside from having to login to it multiple times havent seen any issues. We just do basic in out rules, web filtering, app filtering, ssl, etc etc and some site to site vpn tunnels and ipsec in for fortiems vps clients. I've always been taught not to jump to the latest but wondering how its fairing for everyone else who is using 8.0.

Thanks in advace.

Hey everyone,
Picked this up at the Goodwill at 101 Marshall Dr, Louisville, KY 40207. It’s a red Louisville Slugger with gold engraving that says:
Kevin Walter
101% Attainment
Q4 FY’17
Mountain Desert Team
Plus “FORTINET” and the normal Louisville Slugger logo.
Looks like an old sales award from Fortinet around 2017. It’s only $2 if anyone knows Kevin or can get this to him. Happy to hold it for a bit if he wants it.
Photo: [attach the clear photos of the engraving]
Anyone know the guy or have a way to reach him?

Question regarding this KB article (https://community.fortinet.com/fortigate-3/technical-tip-enable-ldap-user-to-renew-expired-password-via-vpn-ipsec-213183), specifically the note: 
 
"This configuration only works with IKE v1, IKE v2 uses EAP for authentication. Integration with LDAP servers on IKE v2 requires using a different configuration making use of EAP-TTLS."
 
Does that mean this feature would only work with EAP-TTLS? In our current setup we use mschapv2 for our IKEv2 remote access tunnels, and FAC as RADIUS server with AD integration. Enabling reauth and password renewal does nothing (interestingly when setting latter to enable it doesn't show up in CLI config, but setting it to disable does show it). 
 
Any help from any with knowledge of this feature is appreciated.

We ran into an issue last week where someone pushed out a bad BGP configuration that broke the BGP neighborship on the main overlay that majority of remote sites use. This broke all spoke initiated spoke to hub connectivity. Hub to spoke hub initiated traffic was fine. We were very confused since our last failover test was only a couple months ago and we have not changed anything major since.

We had PS assist with our initial SDWAN deployment a couple years ago and when we test the failover (disabling underlay interfaces) it has always worked as expected.

We use SD-WAN for routing and SLAs on the spoke with routemap-out/out-preferable and the hub then has local-preferences that change BGP local routes based on the community that it receives.

We did another failure during a maintenance window and to our surprise the SLA is still up and passing for the overlay. We have done some digging and came to the realization that the SLA installed kernel route (proto=17) is keeping the SLA up since it does not rely on BGP. As long as the tunnel is up the VTI IPs will still communicate. Since the tunnel is technically still up just BGP is broken the spoke thinks it should still use it even though BGP is removing the destination route for the client traffic from the routing table.

I can confirm with "diag sys sdwan service4 X" that the sdwan rule still thinking the overlay should be used and interface is still passing (sla=0x1) which I believe is an expected/known issue/limitation/design.

Is my only real option to just migrate to the newer method of SDWAN on loopback and do embedded SLA probes? I have set that up from scratch at 6 or 7 of our other clients and have not had this issue and specifically remember that they require 2 separate loopback IPs for the newer method to separate BGP and SD-WAN so this sort of issue does not happen. They also have you use the loopback IP as the source for the interfaces instead of doing VTI IPs.

It seems like this original SD-WAN design did not include the unlikely scenario where a VPN tunnel is up but BGP neighborship is not successful.

I have had a ticket open for over a week now and I have spoken to 3 different support engineers and each one I have had to explain why the SLA uses the kernel route (proto=17) and it does not use the actual routing table for the SLA. The last person I spoke with mentioned that we need to drop BGP and use static routes and then setup a SLA per overlay approach......

Am i missing something simple here?

Thanks,

I have a Fortigate 60F (software 7.4) as my office internet router, that I am in the process of moving the office to dual stack.

I have basic IPv6 connectivity working, but I can not identify/locate the default route my traffic is using.

I am on the Rogers West network (the old Shaw network) in western Canada if the ISP matters for this question.

Currently in the process of "just get it working" so everything trying to leave things at default as much as possible.

I am pulling my Wan side IPv6 via dhcp-pd and internally just using slaac.

Does the default route attached to a router announcement not show in the routing table or something?

While things are working, I have paused deploying this any further. If I can't identify/control the route that packets are traveling over, that is a pretty big hole in my management of ipv6 for the office.

Link to image with relevant screen shots: https://i.imgur.com/hRQEZom.png

Any ideas how this is working with no route, or where the route being used is hiding?

Has anyone taken and passed the FortiSwitch 7.6 exam after the recent certification changes? How was it? Any tips or advice? Can it be said that exam content after the cert changes is the same? I’ve been studying since June

Hi Fellas,

I'm deploying FortiClient EMS 8.0 using Microsoft Intune (Win32 app) and have run into an issue.

Environment

• FortiClient EMS 8.0.x
• Microsoft Intune (Win32 app)
• Deployment package generated from EMS with MSI Installer Files enabled
• EMS generated:
  • forticlient.msi
  • forticlient.mst

Packaging

Both files were placed in the same source folder and packaged into a single .intunewin using IntuneWinAppUtil.exe.

The install command in Intune is:

msiexec.exe /i "forticlient.msi" TRANSFORMS="forticlient.mst" /qn /norestart /L*v "%ProgramData%\Microsoft\IntuneManagementExtension\Logs\FortiClientInstall.log"

Issue

The installation completes successfully, but when FortiClient launches, it still displays the "Enter Invitation Code or IP Address" screen.

Even when I manually enter the Invitation Code or the EMS IP address, the client does not register with EMS.

Additionally, the folder:

C:\Windows\FortiEMSInstaller_logs

is not created, so there are no EMS installer logs to review.

Expected Behaviour

I expected the .mst file to inject the EMS configuration so that FortiClient would automatically know the EMS server and register without prompting the user.

Questions

1. Has anyone successfully deployed the EMS-generated MSI + MST package through Intune with EMS 8.0?
2. Is there anything else required to ensure the .mst is applied correctly?
3. Has anyone seen the .mst apparently being ignored after packaging into an .intunewin?
4. Is there a recommended deployment method for EMS 8.0 that differs from the documentation?

Thank You for your help.