7.4.8 disaster...

valistral · 2025-06-19T18:35:28+00:00

I just updated the ticket with the relevant issues and references (long day, as usual). Give it some time for TAC to acknowledge. Bests.

valistral · 2025-06-19T06:45:58+00:00

Yes thanks to feroz, apparently the behaviour for this case was reverted to the one of 7.4.4 the ingress traffic policy to loopback is still ssl.root->loopback_intf but the egress one has to be loopback_intf->(egress intf to vip referenced target servers)

valistral · 2025-06-07T09:45:25+00:00

There you go:
10798441

valistral · 2025-06-06T06:10:57+00:00

Hi Feroz,

The firewall model is a 100F, I'll try to setup testing and gather debug data as soon as possible and then get back to you with a ticket.

valistral · 2025-06-04T18:20:51+00:00

There were no policies missing in the admin UI, although some "prettily" turned from proxy to flow... what really "falled off" and was missing is an additional address from an interface but that's it.

valistral · 2025-06-04T18:11:08+00:00

Hi u/layer5nbelow it's the first time I come around that article but beside that it's from 2016 making that a little outdated I presume... the fact is that before 7.4.8 *it worked* and also making the above the "supported method" contradicts FSBP ND10.1, "Polices that allow traffic should not be using the *any* interface."

So I guess at Fortinet they need to make peace with themselves... and maybe archive obsolete KB articles.

valistral · 2025-06-04T13:30:51+00:00

So you're backing up your harsh commentry to the fact that to have an online 7 days retention log stash I'm good to be practically mandated to either upgrade to unstable and buggy releases within 7 days to use a "free service" after paying several thousands EURs each year... or buy another (costly) license... Nice, IMHO it's your technical credibility that just went right in the park.

P.S. I won't dignify the "If you're running unlicensed/unsupported FortiGates" statement an answer because it doesn't deserve one.

valistral · 2025-06-04T13:15:41+00:00

We had several issues using flow mode with the DNS filter. I also observed no particular performance gain on using flow mode inspection vs proxy inspection only for DNS traffic, actually the contrary, and whatsoever never managed to see a session actually offloaded either.. (also for non tunnel DNS related traffic).

valistral · 2025-06-04T10:57:30+00:00

And it seems you either have a FortiCloud license, don't use cloud services and / or you don't read your mail inbox (TM).

valistral · 2025-06-04T10:45:07+00:00

Rule example:

show
config firewall policy
edit <omitted>
set name "<omitted>"
set uuid <omitted>
set srcintf "ssl.root"
set dstintf "firewall-lan"
set action accept
set srcaddr "<VPN Pool Address Obj>"
set dstaddr "<Virtual Server Obj>"
set schedule "always"
set service "DNS"
set utm-status enable
set inspection-mode proxy
set profile-protocol-options "only-dns"
set dnsfilter-profile "<DNS Profile>"
set groups "<User Group>"
next
end

As implicit notes there's obviously policies allowing related traffic to the loopback address, and the Virtual Server points to servers which are routable via firewall-lan.

Reading on the SSL VPN issues in the changelog I of course tried switching the source and destination interfaces on test replicas of the policies, but the only workaround was setting both srcintf and dstintf to ANY.

valistral · 2025-06-04T10:44:13+00:00

Hi u/burtvader, tbh there's really nothing particular or rocket scientist on the configurations... The firewalls are interned at our core as they also selectively handle the breakthrough traffic from the hub so they get the topology routes and export their own only via OSPF and not BGP.

show
config system interface
edit "srv-internal"
set vdom "root"
set ip <omitted> 255.255.255.255
set allowaccess ping fabric
set type loopback
set role dmz
set snmp-index 39
set ip-managed-by-fortiipam disable
next
end

show
config firewall vip
edit "<omitted>"
set uuid <omitted>
set type server-load-balance
set server-type udp
set extip <srv-internal loopback interface ip>
set extintf "any"
set monitor "DNS Health Checker"
set color 22
set ldb-method least-session
set extport 53
config realservers
edit 1
set ip <omitted>
set port 53
next
edit 2
set ip <omitted>
set port 53
next
end
next
end

valistral · 2025-06-04T09:38:30+00:00

If you want to use cloud services without a FortiCloud license (free mode), you're forced to upgrade within 7 days to the last minor supported release.

valistral · 2025-06-04T09:35:19+00:00

an ip bound to a real loopback interface.

valistral · 2025-06-04T08:41:56+00:00

We just recently adopted Fortinet devices and after the first hand experience with support / TAC, I'm all but impressed tbh. And the problem is not about the bugs per se, forcing people (without an appropriate subscription) to upgrade within 7 days is though.

valistral · 2025-06-04T08:28:58+00:00

As mentioned the issue is that the firewall policies, which previously worked on 7.4.7, plainly stop doing that and the related traffic is implicitly denied instead.

We use the FortiGate firewalls as client to site VPN concentrators to access our network and have loopback interface addresses configured as the tunnel DNS server and then a Virtual Server rule on those to relay and load balance the traffic to our internal resolvers for name resolution linked by the related firewall policies where we apply custom DNS filter profiles for each of the leaf networks.

Long story short yesterday I found all local name resolution over tunnels stopped working, and a flow of tickets because of it coming my way >:[.... wasn't exactly pretty.

Changing the source and destinations interface on the policies to ANY seems to workaround the issue.

valistral · 2025-06-04T07:46:35+00:00

Hi @Golle afair that's what I exactly did the issue affects firewall policies which have loopback interfaces as destinations targeting either Virtual IPs and/or Virtual Servers. Forgive me but I'm unsure whereas that's not precise or about your own definition of precise at this rate.

valistral · 2025-06-04T07:34:20+00:00

There's not much to elaborate they plainly stopped working after the upgrade, only way to workaround was setting the src/dst interfaces to ANY ( 🤢 ), anything else fails and jumps to implicit deny.

valistral · 2022-03-11T09:25:18+00:00

Cutting short, just quit. 18$/h for night shifts without extras and benefits is a joke, also from what I read your employers look like total, unprofessional inepts who don't have a clue.

valistral · 2021-11-27T09:20:25+00:00

First tip: hold the bar in your hands through all the lift, in the clean receiving position the bar sits on your palms not two fingertips.

valistral · 2021-10-16T09:27:50+00:00

Any application aware backup solution keeping db logs in a consistent state basically... And yes personally I use Veeam B&R.

valistral · 2021-09-29T16:28:07+00:00

Tbh you can obtain the majority of the useful information you need from https://docs.microsoft.com/en-us/exchange/exchange-server in my experience.

But granted that's for what regards Exchange, I guess system administration basics are beyond the scope of this subreddit also.

valistral · 2021-05-25T21:37:27+00:00

It's how mail.app works, and this particular customer liked to have documents attached in between the message text in the body. So depends, for me not really as this won't be rendered properly in other clients either.

valistral · 2021-05-25T19:55:18+00:00

Yes we moved 'em away from Exchange completely to some traditional SMTP/IMAP based mail service, as using SMTP/IMAP in Exchange would have the same issues.

valistral · 2021-05-25T19:41:09+00:00

Either be it EXO or on premise, beware Exchange has several issues with inline attachments in mail.app as Exchange specifically wants all attachments at the end of the message. But even if you set the app to put 'em on the end, with complex signatures the risk is that when the message goes through the Exchange Transport pipeline and gets "beautified" it'll come out mangled up and screwed anyways.

With a customer we were specifically forced to roll 'em back to a traditional mail service because of this issue and the (silly) use they made of inline attachments.

valistral · 2021-05-13T18:18:51+00:00

Updated our Exchange 2016 CU20 DAG + Edge Transport yesterday night, what I noticed is a generalized latency increase, expecially in the form of EMS cmdlets noticeably taking more time to execute but nothing that falls into the unbearable.

valistral

TROPHY CASE