u/Alive_Drummer_6779

Hey all, looking for some opinions from people who’ve actually done this in production.

I’m setting up two Veeam Backup for Proxmox VE servers on a dedicated Dell R740xd2 with 116TB usable RAID60. It’s a single Proxmox host, not part of a cluster, and it’s only used to host the two Veeam servers + their repos.

I know best practice is to run Veeam B&R on bare metal, but we don’t have a 2nd physical server to host the second Veeam B&R — so virtualizing it on this Proxmox host is the realistic option for us.

The host isn’t running any production VMs — but we keep it sized/configured so we could spin up a few critical VMs on it in emergencies (e.g. if both production clusters we back up go down at the same time).

Plan is roughly:

• carve the RAID60 into LVM
• give each Veeam repo a 40TB chunk
• format XFS with reflink for fast clone

The thing I’m trying to decide is the actual server type for the Veeam repos.

I’ve gone back and forth between:

1. LXC with bind mounts — broke immediately, Veeam fails block alignment check because no real block device inside container.
2. LXC with LVM block passthrough — works in theory, but needs privileged containers, ioctl can be weird in namespaces, and Veeam doesn’t officially support it.
3. VMs with raw LVM-backed disk passthrough (virtio-scsi, raw, iothread) — full Linux kernel, proper block device, XFS + reflink works natively, Veeam happy, minimal overhead.

Right now I’m leaning towards option 3 because:

• basically near-native performance
• no weird namespace / ioctl issues
• still get XFS fast clone
• can extend LV + xfs_growfs later
• behaves like a real Linux server?

But part of me still wonders if LXC + LVM passthrough is "good enough" since the box is dedicated and not running production workloads.

A few questions for anyone running similar setups:

• Are you running Veeam repos as VMs on Proxmox? Any regrets?
• Anyone running them as LXC long-term and not regretting it?
• Any real-world numbers between LXC vs VM repo performance on similar hardware?
• Anything you’d do differently if you were starting from scratch?

Not chasing absolute max performance — bottleneck during backups is the source side anyway. Just want a setup that’s clean, reliable, and won’t bite me in a year.

Appreciate any input 🙏

Hi all,

I’m troubleshooting a remote access IPsec issue on a FortiGate 200F running FortiOS 7.4.12 and wanted to see if anyone else has run into something similar.

When NAT-T is enabled, remote users get noticeable packet loss / stalls over the tunnel during normal traffic — pings, file transfers, throughput tests, that kind of thing. When NAT-T is disabled, it gets a lot better.

A few things I’ve already confirmed:

• the tunnel comes up fine
• the issue is reproducible when NAT-T is enabled
• the issue improves significantly when NAT-T is disabled
• I tested with NPU offload both enabled and disabled
• with offload enabled, tunnel error counters were higher on the problematic tunnel
• with offload disabled, those RX errors were much lower or zero in my captures, but the user-visible stalls still weren’t fully explained by the lower-level counters
• PDQ snapshots looked balanced during testing
• HPE dropping stayed at 0 in the snapshots I collected
• anomaly-drop output was empty
• we also contacted our ISP and they ruled out any issues on their side
• this is not happening with just one VPN client — we’re seeing it across multiple VPN clients, so it does not look like a single client ISP / local connection problem

At this point I’m mostly trying to figure out if anyone else has seen FG-200F / SoC4 / 7.4.12 behave badly specifically with NAT-T enabled on IPsec, where the tunnel stays up and traffic partially works, but there are intermittent stalls or packet loss under load.

I already have a TAC case open, so I’m not trying to bypass support — just curious whether anyone else has seen the same pattern, or knows of a bug / workaround related to it.

Thanks.