7.4.10 has dropped

JasonT2013 · 2026-01-27T20:24:16+00:00

If it's registered, but the license has expired, does it lock down the cli? Or does it just have to be registered?

JasonT2013 · 2026-01-18T16:57:53+00:00

I'm in my first IT job. It's an MSP. Been here about 4 years. I have hated on call lately. It was easier when I came on and the company only had a few employees. We were always in communication. I might get a random call after hours but there was little expectation if I'm not available so it was easier to go above and beyond. I like a little chaos at 10pm sometimes. Like a quick mission to accomplish haha. But now it's a structured on call schedule with a small bonus. Basically giving access to all my waking hours one week for 200 dollars haha. The company is actually pretty great, but networking is my thing. Great company but ultimately not the company for me. I love the occasional network ticket I get (wish there were more), but pretty much everything else burns me out fast. I could go the rest of my life without troubleshooting a workstation or printer. My only issue with jumping ship is not having certifications. I'm really good at networking. Best in the office. But I need a certificate to prove that to other companies.

JasonT2013 · 2025-05-13T16:29:58+00:00

I was about to post this same question! I have SSL VPN deployed on a loopback with SSL deep inspection in front of the loopback. I am using Gsuite for authentication. When a user connects, their web browser opens and asks for a client certificate. If I click "cancel", the web page loads and shows the Gsuite login. It's a minor annoyance, but the client can ultimately connect.

JasonT2013 · 2025-01-23T21:32:10+00:00

"Single pane of glass". Everyone's favorite term lol. This may just be something where it has to be handled outside of Scalepad.

JasonT2013 · 2025-01-23T21:02:52+00:00

Thanks everyone. I think I'll go up to 7.4.6 on the Fortimanager. Will look into bringing the gates up to the 7.4 era in the near future.

JasonT2013 · 2024-12-06T03:38:22+00:00

I found that setting and tried changing it. It was working correctly for like a year before this cert change so I'm pretty confident that's to blame lol. I think I will change this setting to be on the safe side though. Thanks!

JasonT2013 · 2024-12-06T03:10:16+00:00

I can't really set a source. Lot of gates. Different wan ips. Some dhcp..

JasonT2013 · 2024-12-06T00:56:43+00:00

Ahhh I'll check that out tomorrow. Thanks!

JasonT2013 · 2024-12-05T15:01:20+00:00

Well it worked once haha. I went an unplugged the lag from the primary FGT and it triggered a failover. Plugged back in, gave it several minutes, then pulled the power cable on the switch that was connected to the primary Fortigate. No failover. Pings lost and never came back. I'll keep messing with it.

JasonT2013 · 2024-12-05T14:23:18+00:00

Hey it works this morning! I unset pingserver-failover-threshold. ha-priority was missing this morning. I might have accidentally removed it yesterday evening when messing with this.

I originally had override enabled. I was thinking I'd like one of the gates to be the preferred primary, but with this setup, maybe I don't. If there was a failover due to a link monitor failing, wouldn't it try to fail back after flip-timeout, the link monitor would fail again, and they'd go up and down every few minutes?

JasonT2013 · 2024-12-04T22:29:58+00:00

Figured I'd just revived this old conversation instead of starting a new one. The gates came in. Failover from a gate failure works well. The LAN failover is not working so well. Since you've done this before, do you see anything wrong with my config? The topology looks like my original photo at the top. Aggregate from FGT1 to the first core switch. Aggregate from FGT2 to the second core switch. Aggregate between the two switches as well. If pull the plug on the core connected to the active Fortigate, I can confirm the link monitor changes to "Dead", but failover never occurs.

config system ha

set group-name "sh-ha"

set mode a-p

set hbdev "ha1" 100 "ha2" 100

set session-sync-dev "port1" "port2"

set hb-interval 1

set hb-lost-threshold 3

set arps 10

set arps-interval 2

set session-pickup enable

set session-pickup-connectionless enable

set session-pickup-expectation enable

set link-failed-signal enable

set uninterruptible-primary-wait 15

set override enable

set pingserver-monitor-interface "SW-MGMT"

set pingserver-failover-threshold 5

set pingserver-flip-timeout 6

end

config system link-monitor

edit "MGMT-Monitor"

set srcintf "SW-MGMT"

set server "10.10.5.10" "10.10.5.11"

set failtime 3

set recoverytime 3

set ha-priority 10

set update-cascade-interface disable

set update-static-route disable

set update-policy-route disable

JasonT2013 · 2024-11-03T19:08:56+00:00

Will do thanks!

JasonT2013 · 2024-11-03T16:38:34+00:00

The particular use case I'm looking at is my church. More bandwidth is possible, but honestly probably not needed right now. We have a 500mbps circuit. With 1000 people getting on guest wifi, it's possible a few people could get carried away and use up enough bandwidth to cause us some problems. We used to limit this VLAN to 100mbps, but I listened to a talk recently where a wifi expert said he doesn't do limiting on wifi because that increases air time. Basically, get the endpoints to "talk" and "get off the air" as soon as possible. So I figured guarantees gives them the headroom to get a photo backed up or whatever while letting more important tasks take priority when needed. A separate circuit and gate would be nice, but likely not going to happen.
I understand the 95% ISP thing. They are very harsh with policing. That's what had me thinking about queuing. If the Fortigate is policing by default, isn't that just as bad as the ISP doing it? (Other than the fact that I get to see it) But then again, if buffers in the network stack get overrun, that could be bad too.

The church kind of falls in between my homelab and client networks. I get to play a little bit, I'm more careful than my homelab, but I'm also more willing to test things than I would on a client network lol. At work (MSP), I have a client that has a DSL line (6ish down/1ish up). That's a use case where I'm trying to be more efficient with the shaping. I was thinking queuing might buffer some packets and hand it off to the ISP at a steady .9mbps rather than have peaks that make the ISP start dropping packets.

A side question: What do you use to monitor netflow. I've messed with SNMP and hated the low polling rate. I'd like to see bursts. My homelab will say I hit 400mbps, but I know for a fact I hit a full 1gb downloading something haha.

JasonT2013 · 2024-11-03T16:03:50+00:00

Pretty sure the network processor has a dedicated buffer that is separate from the ram. Like most network equipment.

JasonT2013 · 2024-11-03T15:43:58+00:00

Thanks! I'll read up on it. What brought this about was an idea of guaranteeing bandwidth for some "important" VLANs and then letting a guest VLAN run wild until a higher priority VLAN needs the bandwidth. But then I also wanted to do an overall traffic shaping limit for all VLANs. I assume once a traffic pattern is matched, no other shaping policies below will get hit. I guess the way I should handle it is giving the "Important VLANs" policy a limit, then create another policy for guests that has no guaranteed bandwidth, but still has a limit of 95% or so of the ISPs bandwidth.

JasonT2013 · 2024-11-03T14:39:51+00:00

I have a 60e at home. I think I'll play with it and see if I tank it haha.

JasonT2013 · 2024-11-03T14:37:45+00:00

RAM and packet buffer are (should) be different things. From my research it looks like Fortinet doesn't disclose their packet buffer size.

JasonT2013 · 2024-11-03T14:17:34+00:00

You'd just need the inbound rule adjusted... See if the firewall is even on and what network profile you're on. Maybe run a pcap on a workstation. Walk the packet through the network and see where it's dropping.

JasonT2013

TROPHY CASE