With shared storage such as NFS, SAN or Ceph RBD, both the source and destination nodes already have access to the VM disks. The migration therefore focuses mainly on transferring the running state and memory of the virtual machine.

With local storage, the situation is different.

The destination node does not already have the VM disks, so Proxmox must transfer the storage as part of the migration.

This has practical consequences:

• More network traffic

• Longer migration windows

• Greater dependency on storage performance

• Higher importance of a dedicated migration network

This becomes particularly important with large workloads.

Moving a small utility VM is very different from moving a multi-terabyte application server that continues generating writes while the migration is running.

Shared storage is therefore not simply a technical requirement.

It is an architectural decision.

A company that already owns a SAN may be able to reuse it when migrating from VMware to Proxmox.

A new three-node deployment may prefer Ceph.

A smaller environment may use local ZFS and accept longer migrations.

The correct design depends on RPO, RTO, capacity, performance, maintenance requirements and budget.

Another important distinction is Live Migration vs High Availability.

Live Migration requires the source host to remain operational.

HA is designed to recover protected workloads after a host failure.

They solve different problems and should not be treated as interchangeable features.

Full technical guide:

https://sistro.net/proxmox-live-migration-storage-compartido

#Proxmox #Virtualization #DevOps #Homelab #VMware

“Does it still work after the license expires?”

“Works” can mean several different things.

It may still forward packets.

NAT may still function.

VPN may still connect.

But threat intelligence may be frozen.

Cloud classification may disappear.

Security engines may stop.

Or, depending on the platform, the device itself may eventually become non-operational.

Fortinet illustrates one model.

A physical FortiGate can keep performing core firewall functions after FortiGuard expiration, while security intelligence stops updating and cloud-dependent category filtering is affected.

SonicWall illustrates another.

Many appliances can operate hardware-only, while individual security services are subscription-dependent.

Meraki represents a third model.

Cloud licensing is part of the operational platform, so expiration eventually becomes a network-availability issue rather than merely a reduction in threat protection.

The useful lesson is vendor-neutral:

Before a subscription expires, create a dependency map.

Feature
   ↓
License
   ↓
Expiration behavior
   ↓
Operational impact

Do this before renewal week.

Not after users start reporting problems.

Practical comparison:

https://sistro.net/que-pasa-si-vence-licencia-firewall

Tags: firewall cybersecurity networking sysadmin

Consider this architecture:

Two ISPs
Two firewalls
One core switch

Is it redundant?

At the firewall layer, yes.

At the network level, no.

The switch remains a single point of failure.

SonicWall Active/Standby HA is a useful example of how one layer of redundancy works.

Two identical appliances form a pair.

One is Active.

The other remains Standby and can assume network responsibilities when a failure is detected.

But session behavior depends on the HA mode.

Stateless failover provides appliance redundancy, while existing connections may need to be rebuilt.

Stateful synchronization continuously transfers dynamic session information to the secondary appliance, reducing the impact of failover.

That distinction matters for long-lived connections such as:

VPNs
RDP
voice
persistent applications

Another important idea is monitoring.

A physical interface being UP doesn't necessarily mean the network behind it is healthy.

Logical monitoring can provide a better signal for certain failure scenarios.

The general engineering principle:

Redundancy must be designed at every critical layer.

WAN
Firewall
Switching
Power
Applications

Duplicating only one component improves resilience.

It doesn't create complete High Availability.

Practical SonicWall example:

https://sistro.net/sonicwall-high-availability-active-standby-stateful-ha

Tags: networking high-availability firewall sysadmin

Not interface count.

Consider a hypervisor with two 10 GbE NICs.

Both are bonded.

Both cables connect to the same switch.

A NIC failure is survivable.

A switch failure isn't.

This is why network architecture matters in virtualization.

Proxmox uses standard Linux networking concepts:

Linux bridges
VLANs
Bonds
Routing

That simplicity is powerful.

But it also means engineers need to understand the topology underneath the GUI.

Corosync is a good example.

Cluster communication doesn't consume massive bandwidth, but it needs consistent latency.

Putting Corosync on the same congested path used for storage recovery or backup can create a failure mode where the physical link is technically online but cluster communication becomes unreliable.

Another common misconception involves LACP.

Two 10 GbE interfaces in an 802.3ad bond can increase aggregate capacity, but a single TCP flow normally doesn't become a 20 Gbps flow.

The hashing strategy distributes different conversations across members.

The broader rule:

Build network redundancy around what can fail together.

NIC
Cable
Switch port
Switch
Power
Uplink

Only then decide how bridges, VLANs and bonds should map onto the physical network.

Practical Proxmox example:

https://sistro.net/proxmox-networking-bridge-vlan-bonding-lacp

Tags: proxmox networking linux virtualization

1. Upgrade the firewall

2. Discover a remote-access feature disappeared

3. Start designing the replacement while users are calling FortiOS 7.6.3 provides a useful change-management example. SSL VPN tunnel mode is no longer part of the platform. Organizations using it should build and validate their replacement IPsec design before upgrading. The lesson is bigger than Fortinet. Infrastructure upgrades should include: Feature dependency inventory What functionality does production actually depend on? Compatibility analysis What disappears or changes? Pilot deployment Can a representative user group work? Application validation Does DNS, RDP, ERP and file access work? Rollback Can the previous state be restored? A connected VPN icon isn't a successful migration. Successful migration means the user's workflow still works.

4. Practical FortiGate example: https://sistro.net/fortigate-ssl-vpn-ipsec-fortios-7-6-3

5. Tags: fortinet networking vpn sysadmin

“How many users?”

It's probably the most common firewall sizing question.

But users don't generate sessions.

Devices and applications do.

Consider one employee:

Laptop
Phone
VoIP handset
Several SaaS applications
Dozens of browser connections

Now add:

Cameras
APs
Printers
IoT
Servers

Suddenly a 30-user office is not a 30-device network.

VPN topology adds another dimension.

Ten devices connecting to twenty remote branches can create a more complex edge workload than fifty devices sitting behind one Internet connection.

A better sizing process considers:

Device count

Concurrent connections

WAN

VPN topology

Physical interfaces

Growth

This applies regardless of vendor.

I used Salix Lion 20A, 50A and 150A as a practical sizing example:

https://sistro.net/salix-lion-20a-vs-50a-vs-150a

The broader lesson:

User count is a useful input. It is not an architecture.

Tags: networking firewall sysadmin infrastructure

10 Gbps firewall throughput.

Excellent.

But what happens when you enable:

IPS?

TLS inspection?

Malware protection?

Application control?

VPN?

Performance metrics exist because those are different workloads.

The correct sizing process should start with the architecture:

WAN speed
→ traffic mix
→ security features
→ sessions
→ VPN
→ growth

Only then should you choose the appliance.

A firewall isn't simply a router with an impressive benchmark.

It is a security processing system.

Full practical example:

https://sistro.net/blog-tienda-sistro/que-firewall-necesito-internet-1-gbps

Tags: firewall network-security sysadmin capacity-planning

When it fails completely, failover is obvious.

When it remains barely functional, users may suffer for hours.

A useful SD-WAN policy therefore watches quality rather than link state alone.

Latency, jitter and packet loss provide different signals.

And the acceptable values depend on the workload.

The objective isn't to change paths constantly.

It is to keep applications on a path that meets their requirements.

Practical SonicWall example:

https://sistro.net/blog-tienda-sistro/sonicwall-sd-wan-dual-wan-sla-probes

Reason 1:
It is old

Reason 2:
A newer model exists

Neither tells us whether replacement is justified.

Consider a firewall.

It still works perfectly.

But since deployment:

WAN moved from 200 Mbps to 1 Gbps.

Most applications moved to SaaS.

TLS inspection was enabled.

Three branches were added.

VPN usage tripled.

The hardware didn't fail.

The workload changed.

Now consider another firewall of the same age.

WAN is still 200 Mbps.

CPU utilization is low.

The environment hasn't grown.

The platform remains supported.

Replacing that device may provide almost no business value.

This leads to a better refresh model:

Lifecycle

Is the platform still supported?

Capacity

Does it handle today's security workload?

Headroom

Can it handle expected growth?

Features

Can it support the architecture we plan to deploy?

Economics

What does renewal cost compared with replacement?

This applies to servers, storage, switches and firewalls.

Technology refresh should be triggered by risk and workload.

Not fashion.

Practical FortiGate example:

https://sistro.net/blog-tienda-sistro/cuando-reemplazar-fortigate-serie-f-por-serie-g

Tags: infrastructure networking sysadmin capacity-planning

• one or two ISPs

• several VLANs

• local Internet

• corporate applications

• SaaS applications

• failover requirements Now add: a second data center. The challenge becomes maintaining topology rather than choosing an encryption algorithm. This is why SD-WAN overlays are useful. They abstract many individual tunnels into a managed connectivity fabric. Cisco Meraki Auto VPN is a practical example. Branches can join the VPN domain as spokes. Data centers can become hubs. Routes and tunnel information are distributed automatically. But good architecture still requires answers to: Which subnets belong in the overlay? Should SaaS traffic use local breakout? How large must the hub be? Do we need multiple hubs? Can the LTE backup connection traverse NAT correctly? How do we restrict branch-to-branch access? The most important idea is: VPN automation scales configuration. Architecture scales the business. Practical example: https://sistro.net/blog-tienda-sistro/cisco-meraki-auto-vpn-sucursales-sd-wan

• Tags: networking sdwan vpn sysadmin

Imagine a distributed storage system maintaining three copies of every block.

A disk fails.

No problem.

A host fails.

Still okay.

Then an administrator deletes the wrong virtual machine.

The storage system performs its job perfectly.

The deletion is reflected across the infrastructure.

Redundancy worked.

Recovery didn't.

This is why we need to separate four concepts:

High Availability
Keeps workloads available after infrastructure failures

Replication
Maintains redundant copies of current data

Snapshots
Provide convenient points in time inside a storage or virtualization system

Backup
Provides independent recovery points

Proxmox VE + Ceph + Proxmox Backup Server provides a useful real-world example of these layers.

PBS also adds an interesting efficiency model.

Data is transferred incrementally and deduplicated server-side, while each backup snapshot still represents a complete logical recovery point.

But the technology isn't the hard part.

The hard questions are:

What is the RPO?

What is the RTO?

Where is the second copy?

Who can delete backups?

When was the last restore test?

Backup architecture starts with those questions.

Practical example:

https://sistro.net/blog-tienda-sistro/proxmox-backup-server-respaldo-recuperacion

Tags: backup proxmox disaster-recovery sysadmin

Requirement A:

Process a lot of encrypted traffic very quickly.

Requirement B:

Terminate hundreds of VPN tunnels and manage a large topology.

They sound similar.

They are not.

The first is primarily a dataplane performance problem.

The second is a scalability problem.

A newer appliance can outperform an older one in packet processing while supporting fewer topology objects.

FortiGate 90G vs 100F is an interesting example.

90G provides higher published security throughput and session creation performance.

100F supports substantially more gateway-to-gateway VPN tunnels and more physical connectivity.

This is why infrastructure engineers should avoid treating a firewall family as a simple vertical ladder.

A better decision model is:

Performance
How much traffic?

Security workload
How much inspection?

Scale
How many tunnels, policies and devices?

Connectivity
How many physical and high-speed interfaces?

Availability
Do we need HA?

Roadmap
What will change in three years?

The correct firewall is the one whose bottleneck appears after your projected workload, not before it.

Practical Fortinet example:

https://sistro.net/fortigate-90g-vs-100f

Tags: network-security sysadmin firewall infrastructure

Firewall A can handle the bandwidth.

Firewall B can also handle the bandwidth.

So they are equivalent?

Not necessarily.

Ask another set of questions:

How many TLS sessions are being decrypted?

How many new connections arrive per second?

How many VPN tunnels terminate here?

How many 10 GbE uplinks are needed?

What happens when traffic doubles?

This is where firewall sizing becomes architecture rather than shopping.

SonicWall NSa 2800 and 3800 are a useful example.

The 3800 doesn't merely increase raw throughput.

It increases TLS inspection capacity, VPN performance, connection rate and physical connectivity.

But that doesn't automatically make it the correct choice.

If workload fits comfortably inside a smaller appliance, spending the same budget on:

two firewalls in HA

may create more business value than:

one larger firewall

This is why capacity and availability should be designed together.

The broad principle is vendor-neutral:

The best firewall isn't the largest one. It's the one that satisfies both workload and failure requirements.

Practical SonicWall example:

https://sistro.net/sonicwall-nsa-2800-vs-nsa-3800

Tags: network-security sysadmin firewall infrastructure

WAN1 link state: UP
Gateway ping: works
Packet loss: 8%
Latency: 280 ms
Jitter: 110 ms

Is the WAN available?

Technically, yes.

Would you want your VoIP calls using it?

Probably not.

This exposes an important distinction:

Availability ≠ Quality

A more useful WAN decision includes several variables:

Reachability

Can we reach the destination?

Latency

How long does traffic take?

Jitter

How stable is that latency?

Packet loss

How much traffic disappears?

Application

What is the workload sensitive to?

SD-WAN can combine these signals to choose a better path before an ISP completely fails.

But health checks also introduce risks.

Bad probe targets can create false failovers.

Aggressive thresholds can cause route flapping.

Immediate failback can make unstable links even more disruptive.

The objective isn't to switch links as often as possible.

It's to keep applications on a path that meets their requirements.

I used FortiGate Performance SLA as the practical example here:

https://sistro.net/fortigate-dual-wan-failover-performance-sla

Tags: networking sdwan sysadmin infrastructure

Then one node fails.

Suddenly:

VMs need resources on surviving hosts.

Storage replicas need recovery.

Data starts moving between nodes.

CPU utilization increases.

Network utilization increases.

Latency increases.

This is the moment architecture matters.

Ceph makes this particularly visible because storage performance depends heavily on the network connecting the OSDs and clients.

Fast NVMe drives connected through an undersized network can create an expensive bottleneck.

There is another subtle issue:

Cluster communication such as Corosync is latency sensitive.

Storage recovery traffic is bandwidth hungry.

Putting both onto the same saturated path can turn a storage problem into a cluster problem.

A better design treats these as separate failure domains and traffic classes.

The main lesson is not specific to Ceph:

Distributed storage must be designed around failure behavior, not benchmark behavior.

And remember:

Replication is not backup.

I expanded the idea using Proxmox + Ceph here:

https://sistro.net/proxmox-ceph-cuando-conviene-hci

Tags: ceph proxmox sysadmin distributed-systems

“The application worked yesterday.”

You enabled TLS inspection.

Today it fails.

The application isn't necessarily broken.

The firewall isn't necessarily broken either.

The trust model changed.

With normal TLS:

Client → Server Certificate → Trusted CA

With TLS interception:

Client → Inspection Gateway Certificate → Enterprise CA

Some applications accept the new trust chain.

Others use stronger assumptions, including certificate pinning.

Those applications may reject the connection.

This is why TLS inspection deployments require more than networking knowledge.

You need to think about:

PKI

Can you distribute the enterprise CA?

Endpoint ownership

Do you control the device?

Application behavior

Does it use certificate pinning?

Exceptions

Can you bypass only the exact service that fails?

Performance

Can the security gateway handle the decryption workload?

The best TLS inspection policy is rarely:

Inspect everything.

It is:

Inspect what provides meaningful security value and document every exception.

I used SonicWall DPI-SSL as the practical implementation example here:

https://sistro.net/sonicwall-dpi-ssl-inspeccion-https

Tags: tls cybersecurity sysadmin network-security

39 Gbps

That number looks great.

But what exactly was being measured?

Raw packet forwarding?

IPS?

NGFW?

Malware inspection?

TLS decryption?

Those are different workloads.

Consider a security gateway doing this:

Client
→ TLS Decryption
→ Firewall Policy
→ IPS
→ Application Control
→ Malware Inspection
→ Internet

Each stage consumes resources.

This is why vendors publish multiple performance metrics.

Fortinet's 120G provides a useful example:

Raw firewall throughput is far higher than its Threat Protection throughput.

That is expected because the latter represents substantially more security processing.

The broader engineering lesson is simple:

Size for the feature set you will actually enable.

Also consider architecture:

• interface speeds

• concurrent sessions

• VPN workload

• power redundancy

• physical form factor

• growth

A firewall is not simply a packet-forwarding benchmark.

It is a security processing platform.

Practical FortiGate comparison:

https://sistro.net/fortigate-70g-vs-90g-vs-120g

Tags: network-security firewall sysadmin infrastructure

Both are rated at 1 Gbps.

Are they equivalent?

Not necessarily.

One might support 50,000 concurrent sessions.

The other 125,000.

One might support 75 VPN tunnels.

The other 200.

This matters because modern traffic is not simply a stream of bytes.

A single user can maintain simultaneous connections to:

• SaaS

• collaboration tools

• cloud storage

• web applications

• APIs

• update services

The firewall must track those flows.

VPN architecture creates another scaling dimension.

A branch with 20 users and 80 site-to-site tunnels may present a different problem than an office with 100 users and only one tunnel.

Cisco Meraki MX75 and MX85 provide a useful example.

Both have similar published throughput figures, but very different session and VPN scaling characteristics.

The broader lesson is vendor-neutral:

Bandwidth tells you how much traffic moves.
Session capacity tells you how complex that traffic can become.

A good firewall sizing exercise needs both.

Practical Meraki comparison:

https://sistro.net/cisco-meraki-mx75-vs-mx85

Tags: networking firewall infrastructure sysadmin

The SHA-256 hash isn't in a threat database.

There is no existing signature.

The filename looks normal.

Static inspection doesn't reveal enough.

Should it be trusted?

Not necessarily.

This is where behavioral analysis becomes useful.

Run the file inside an isolated environment and observe:

Processes

What does it execute?

Memory

Does it unpack or inject code?

Network

Where does it connect?

Persistence

Does it attempt to survive reboot?

Files

Does it modify, delete or encrypt data?

The file now has to behave like malware to accomplish its objective.

Sandbox systems use this property to complement signature-based defenses.

SonicWall's Capture ATP provides one implementation using multiple analysis techniques and Real-Time Deep Memory Inspection (RTDMI).

But the important concept isn't the vendor.

It's this:

Signatures identify what we already know. Behavior helps investigate what we don't.

Sandboxing is therefore another layer, not a replacement for EDR, IPS, segmentation or backups.

I expanded this using SonicWall Capture ATP as the practical example:

https://sistro.net/sonicwall-capture-atp-rtdmi-ransomware-zero-day

Tags: cybersecurity malware security sysadmin

Browsers work.

Then one mobile application suddenly stops connecting.

Why?

One common reason is certificate pinning.

Normal TLS trust asks:

“Do I trust the CA that signed this certificate?”

Pinned applications can ask something closer to:

“Is this the exact certificate or key I expected?”

When a security appliance performs TLS interception, it presents a dynamically generated certificate to the client.

A browser that trusts the enterprise CA may accept it.

A pinned application may not.

This is why a real TLS inspection deployment needs:

PKI

Endpoints must trust the inspection CA.

Application inventory

Pinned or proprietary applications must be identified.

Exception management

Bypasses should be specific rather than broad.

Capacity planning

Decryption adds workload to the firewall.

Segmentation

Managed endpoints and guest/BYOD devices may require different policies.

TLS inspection is therefore not just a firewall feature.

It is an architecture decision involving endpoints, certificates and applications.

I used FortiGate as a practical example here:

https://sistro.net/fortigate-ssl-deep-inspection-cuando-conviene

Tags: network-security tls cybersecurity sysadmin