u/Massive-Valuable3290

Hi,

we have a bare metal Veeam Backup Server and a Synology NAS that are each connected through dual 10GbE NIC (LAG) to our coreswitch. Our current setup involves the NAS as a SMB repository for Backup copy jobs.

The NAS has a capacity of 110 TB and a full backup consumes around 10 TB. We are struggling to keep our retention policy of 12 monthly restore points due to capacity problems, that's why I wanted to switch from SMB to ReFS in order to utilize fast clone for synthetic fulls.

When asking around, iSCSI with fast clone is always the preferred method. But also with a NAS?

I read in multiple forums that ReFS should not be used on iSCSI on "consumer / prosumer" grade hardware, e. g. a Synology NAS. Is there some truth to it? I'm referring to:

• Veeam ReFS Repository on iSCSI Targets
• ReFS is not supported on SAN-attached storage - R&D Forums
• ISCSI ReFS LUN suddenly RAW Format - Administrator
• REFS formated drive connected using iSCSI is presented as RAW

>That means you’re not supposed to format a volume with ReFS as long as it is located on a SAN/NAS device. While reading deeper into the subject, I found out that this sentence might be limited to shared SAN storage. 

I did some testing and created the LUN. First thing I noticed is the lower write speed. With SMB, I got around 500 - 600 MB/s, with iSCSI only around 390 MB/s. That wouldn't be huge pain point though, as we'd benefit in terms of storage capacity in comparison to SMB.

So final question - should I stick so SMB or is it safe to migrate to ReFS on Synology iSCSI? The NAS is currently formatted on ext4 and not Btrfs, so this is not an "advanced lun". I can't reformat the NAS because we do not have the spare capacity to copy existing backup copies back and forth.

While DoT is still down, FortiDDNS now has problems as well. Interestingly, there are SSL errors when trying to connect. If there are problems with OCSP or general SSL certificate validity, this might also explain the DoT outage:

2026-06-01 11:00:20 [365] __ssl_crl_verify_cb: Cert error 19, self-signed certificate in certificate chain. Depth 2

2026-06-01 11:00:20 fgt_ddns_verify_peer()-715: Certificate verification failed, error 19 (self-signed certificate in certificate chain) depth 2 for '/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA'

2026-06-01 11:00:20 [1078] ssl_connect: SSL_connect failes: error:0A000086:SSL routines::certificate verify failed

2026-06-01 11:00:20 __ddns_ssl_connect()-669: ssl_res=-1

2026-06-01 11:00:20 ddns_sock_ssl_connect()-754: failed to establish SSL connection

As per Troubleshooting Tip: DNS unreachable when configured with DNS over TLS on FortiGate after upgarde to v7.4.10 there seems to be an issue with Fortinet DNS over TLS on these Firmware versions. Unfortunately,

>The known issue is scheduled to be fixed in v7.4.12

did not turn out to be true. On multiple branches they are still unreachable, especially after upgrading to 7.4.12:

https://preview.redd.it/3oan6yug6g4h1.png?width=739&format=png&auto=webp&s=db00dfa602623e34611292a2db8c8c9eb5291870

Before anyone asks: no, this particular branch does not use SD WAN and fancy local out settings, it's all default. When using DoT from Quad9, it instantly works. Changing it back to Fortinet, it becomes unreachable. Of course the box was rebooted.

Some branches reach our hub through a dynamic FQDN peer gateway addres for S2S, taking them completely offline. They are reachable but don't perform IPsec negotiation because they can't map the incoming proposal to the configured FQDN gateway. This is kinda my own fault, I will switch the branches IPsec gateway config back to static IP and move to other DNS providers for better reliability.

I know these IPs are using AnyCast routing, so maybe this might also be a Geo issue, not a firmware bug. This is happening in Germany for anyone interested.

We have a server farm at our HQ serving multiple branch offices. They are all connected via S2S IPsec. Setup is always the same. One central firewall cluster at Hub and smaller branch office firewalls.

At one location, we got a 300 Mbit/s line but only get 10 Mbit/s down from our Windows Servers over IPsec, no matter the protocol (SMB, Iperf, TCP, UDP, doesn't matter). Download at the branch location from Linux servers on the same VLAN at HQ, we get the full 300 Mbit/s.

Other branch offices do not have these problems. They get the full speed off of Windows Servers. I can't wrap my head around this because:

• Both downloads from Linux & Windows server VMs use the same IPsec tunnel, same policy stack, no UTM features enabled, same traffic path, same hardware, same LAGs, same everthing, no asym routing or anything
• We suspected Windows Defender network realtime inspection service but other locations do get the full download speed from the same Windows server
• The exact location of the servers don't matter, e. g. DMZ behind peimeter firewall or on LAN behind ISFW
• We suspected the firewalls and switches in between at HQ but when using a Windows laptop as an iperf server on one of the VLANs, we got full speed at branch as well
• Topology: Branch firewall → IPSec → Hub firewall → LAG → ISFW → LAG → Servers

It can't be the Windows server in general, every other location has full speeds. It can't be the branch firewall, every other service (even tunneled WAN through HQ) gets full saturation.

We already checked with TAC but they're clueless as well. They want us to do a port mirror on the coreswitch at HQ because they suspect the Switch to be the culprit but I don't think that makes sense.

It might be some TCP tuning on Windows Server but then again - other locations (one location even has the same ISP with the same bandwidth) do not have any problems, even with same tunnel config and everything (MTU, IPsec P1 & P2 are identical).

I really have no idea what to do next. Packet captures have been done mutliple times but they did not reveal anything really.