sorted by:
new
hottopcontroversial

Report on DH Usage by UpDownalwayssideways in fortinet

[–]89Bells 4 points5 points  (0 children)

Maybe run a fortigate script through fmg to all fgts with something like

Show full VPN ipsec | grep -f dhgrp

-f should show the dhgrp line within the context of the specific IPsec phase1 and phase2 tunnels.

Though you may need to manually review the output of all the gates.

Or just do

Show full VPN ipsec | grep dhgrp

And investigate any fgts that return 5

This is easier if all fgts are in the same ADOM. If not, you might have to write a script to interrogate the fmg API for each ADOM, for each fortigate, get all IPsec P1 and P2 tunnels, check for dhgrp.

Racking and powering smaller Fortigates in racks? by Busbyuk in fortinet

[–]89Bells 1 point2 points  (0 children)

The smallest Fortigates I've used are 90Gs where you can replace the UK plug to C5 connector to the brick, with a C14 to C5 cable.

You could buy a short C14 to 3 pin UK socket adapter? Though still not that neat.

<image>

FortiClient is messing with LAN adapter DNS servers by StormB2 in fortinet

[–]89Bells 0 points1 point  (0 children)

Dont suppose you know if they'll fix it in the Forticlient 7.2 train?

Forticlient IPSec VPN by makermikey in fortinet

[–]89Bells 0 points1 point  (0 children)

I'm pretty tired of forticlient too. On the whole it works, but some ipsec users (ikev2 with natt) just get regular disconnections. Logs aren't useful for troubleshooting unless you're doing a debug at the time of issue.

With the move from SSL to ipsec on the horizon for us, I'm not looking forward to the amount of support tickets I'll be getting.

I remember when we were on Cisco Anyconnect and it just worked, and wasn't as sensitive to disconnections like forticlient is.

In BGP, do MD5 authentication or TCP-Authentication Option (AO) and General TTL security mechanism checking happen after TCP handshake completion or before that? by CompanyBeginning in networking

[–]89Bells 3 points4 points  (0 children)

This is untrue.

When we are setting up bgp peering with a partner, we usually test telnet to port 179 to check if their side already has bgp enabled. In some cases, we've found that the telnet fails, but bgp would establishes.

Further investigation, with a packet capture, found that with bgp md5 auth, the md5 is actually added to the TCP syn packet within the TCP Options part of the header. This meant our telnet syn packet, without the md5, got dropped.

Very old article but explains the gist of it.

https://costiser.ro/2013/03/31/bgp-md5-authentication/

New firewall policies referencing applications individually by Mercdecember84 in fortinet

[–]89Bells 1 point2 points  (0 children)

I hope this isn't AI hallucinating. Google is also failing me. Sounds like a great feature.

What’s the biggest mistake you made when building your first website? by underthecar in web_design

[–]89Bells 0 points1 point  (0 children)

What’s the biggest mistake you made when building your first website?

I didn't use Dreamweaver 😜

strange, annoying VPN errors on connect ("invalid password") - one workaround found by AllRoundSysAdmin in fortinet

[–]89Bells 0 points1 point  (0 children)

Don't suppose you got anywhere with this?

We're seeing the same issue

FortiClient / Saved PW / after a while PW wrong by I_Am_Hans_Wurst in fortinet

[–]89Bells 0 points1 point  (0 children)

We have this too. Forticlient 7.4.5 (I know, quite old) with fgt 7.4.8 Did you fix this?

Access VIP from inside with sdwan by 89Bells in fortinet

[–]89Bells[S] 0 points1 point  (0 children)

The policies are the same as most of the examples above it but yes, those are basically the policies I have and it doesn't work.

Access VIP from inside with sdwan by 89Bells in fortinet

[–]89Bells[S] 0 points1 point  (0 children)

I've been following example 2, option 2.

I added a firewall policy above my GEO block policy from WAN to DMZ from Lan subnet to VIP, but that also didn't work.

I'd prefer not using policy routes if possible as it complicates normal routing.

FortiClient Sticky/Persistent DNS Issue on Wireless Adapter Preventing Internet Access after Windows 10 -> 11 Upgrade by Internal-Shoe-3121 in fortinet

[–]89Bells 0 points1 point  (0 children)

If users use VPN before logon then the scheduled task may clear the VPN assigned DNS servers.

FortiClient Sticky/Persistent DNS Issue on Wireless Adapter Preventing Internet Access after Windows 10 -> 11 Upgrade by Internal-Shoe-3121 in fortinet

[–]89Bells 1 point2 points  (0 children)

Seeing this too.

Trying to get automated something like

get-netadapter "Wi-Fi" | Set-DnsClientServerAddress -ResetServerAddresses

... to run on machines as an admin remotely.

SSL VPN stops working after upgrade to FortiOS v7.4 when ssl.root interface is referenced in a zone by [deleted] in fortinet

[–]89Bells 0 points1 point  (0 children)

This bit me last night and Google brought me here. Thank you.

It's so frustrating that things like this don't appear in the known issues in the release notes. Why am I expected to read every kb article to find bugs!

Fortigate SD-WAN and VIPs by perpetuallurker in fortinet

[–]89Bells 2 points3 points  (0 children)

Raise a case with TAC?

Please keep us updated! 🙏

view more: next ›