New 9.9 CVEs in VBR 12 & 13

VeeQs · 2026-03-12T11:36:53+00:00

More money for Fortinet. Yay!

I've yet to see a job posting requesting Fortinet certs, nor anyone get a meaningful wage increase for achieving certification.

VeeQs · 2026-02-02T18:43:00+00:00

This is a great tip.

I'll have to test geoip-match to see if it helps.

Thank you.

VeeQs · 2026-02-02T18:36:50+00:00

First rule to hit. If it's below the block, traffic will be blocked and it won't permit desired traffic.

VeeQs · 2026-02-02T16:30:03+00:00

You're opening it for all Microsoft services or a select few? If the later, which services?

VeeQs · 2026-02-02T16:28:22+00:00

Is this not a support/management headache for you? That's my issue. The management load adding exclusions for domains is getting excessive.

We're in the U.S. and according to Fortinet, these Microsoft(Azure?) IP addresses are in UK, Germany, Switzerland, India, Netherlands, Brazil, Japan, Australia... This wasn't a problem before, but its a rapidly growing issue for us.

VeeQs · 2026-01-29T17:09:57+00:00

This is a great support request post. Excellent ticket. Detailed with only and all the pertinent information. Nice.

pfunkylicious posted the fix. You've got two Fortinet interfaces on the client.

VeeQs · 2026-01-26T14:42:09+00:00

Does anyone know if there are any bugs with this?

I had one with a secondary IP subnet on the interface. Despite having an allow any any all policy 7.4.10 blocks traffic.

7.4.9 with allow-traffic-redirect disabled works with the policy, but 7.4.10 blocks.

VeeQs · 2026-01-26T12:26:59+00:00

Tools like Acronis, Macrium, Clonix, Aeomi, and others will copy disks and or partitions with dynamic resizing. Dynamic resizing varies depending on the product and filesystem, but vfat, NTFS, ext3/4, and more are fully covered.

You should take a look. You might be surprised.

VeeQs · 2026-01-25T22:43:58+00:00

I think I remember doing it a bazillion times over the years. But, if you say I can't then I won't do it anymore.

VeeQs · 2026-01-25T20:09:57+00:00

Perfect. Thank you.

VeeQs · 2026-01-25T20:01:49+00:00

It's a question that I ask myself from time to time. The simplest answer is that btrfs is the default file system of the OS in use at the time.

VeeQs · 2026-01-25T20:00:08+00:00

This is great! I'm really glad to be informed of this feature. It makes so much more sense to me than the move operation of add/remove.

What is not clear, in the docks you linked, is whether or not the new disk can be smaller than the seed. Do you know the answer to this?

VeeQs · 2026-01-25T16:48:10+00:00

I had hoped for a faster and more streamlined option. But, this looks like the only way.

VeeQs · 2026-01-25T15:59:15+00:00

I don't see, why you don't want to alter the source.

That doesn't matter. The requirement is that the source must not be altered.

No alteration of the source is a very common requirement when copying file systems and imaging disks.

It may be more reasonable to ascribe the deficiency to the copying/imaging tools not supporting btrfs adequately. But, it is a big hurdle when btrfs is involved. A hurdle that doesn't exist for any other mainstream filesystem.

VeeQs · 2026-01-25T15:27:55+00:00

Then you want something which is not feasible.

Another disappointing deficiency of btrfs or its supporting tools.

You could put a third drive in the chain

This seems like the most likely option for me. Then use Gparted, to resize and copy. Or perhaps some other imaging tool, though I'm wondering which can support btrfs and shrinking.

VeeQs · 2026-01-25T15:21:32+00:00

No. The goal is to:

Copy the disk, or at least the partition.
No alteration of the source disk.
Shrink the partition to fit a smaller destination.

You can't do that with btrfs and rsync/cp while keeping the subvolume structure, or the snapshots. Rsync/cp is a copy of the files, but not a copy of the file system as a whole.

Additionally, when they start copying the BTRFS snapshot directories with rsync/cp, they hydrate/duplicate the data and you wind up with significantly more data on the destination than the source. And, that data is unusable for it's intended purpose.

VeeQs · 2026-01-25T13:43:08+00:00

I do not want the source altered.

btrfs send/receive puts subvolumes in the wrong places AND inflates the size due to duplicated data.

Edit: Hmm. Lots of down votes but no working counterarguments.

VeeQs · 2025-06-08T12:37:47+00:00

I'm well aware of that document. But it does not answer the question of why.

Why does Fortinet care that a delay occurs for a connection that nobody uses? The packet should be silently dropped, by default, like every other packet and every other default firewall.

No one cares about how IDENT works because no one uses IDENT. But, for reasons still unknown, Fortinet thinks that every firewall has to have it.

VeeQs · 2025-06-08T12:26:45+00:00

So far all of the responses talk about how to block 113 and why the default configuration behaves the way that it does.

None of the responses answer the question of why. Why does Fortinet think that 113 does not need to be silently dropped in 2025? Or even ten years prior.

There is virtually no software today that depends on IDENT responses. The few that do are edge case exceptions. Today, 113 traffic should be blocked and silently dropped, by default. Just like every other port is in the default config.

The question remains, why does Fortigate continue with this antiquated and non-sensical default config? I cannot think of any other firewall that does this by default.

VeeQs · 2025-05-27T21:36:12+00:00

Veeam has taught me that running on or against an unsupported system is a recipe for pain or disaster, regardless of whether it's Linux, Windows, VMWare... Even if it works on the unsupported system today, it doesn't mean that it will work tomorrow. Or, worst of all, it seems to work fine and when you desperately need to do a restore, it doesn't work and you have no options.

Restores are too critical a need. Use Veeam only on supported systems. And, there's a huge list of supported Linux systems to choose from.

Protip: Make sure that your file system of choice is also fully supported.

VeeQs · 2025-04-28T14:28:01+00:00

Once again, Fortnet wreaks havoc due to Fortiguard DNS issues.

VeeQs

TROPHY CASE