iSCSI storage performance drops after firewall rule changes – anyone else?

M

mohsin045

New Member
Jun 19, 2026
11
1
3
Innovista Indus IT Park, DHA Phase II Ext., Karach
vertex-hcm.com
Now we're seeing random performance drops on the iSCSI connections – latency spikes, occasional timeouts. The VMs are still running but storage performance is inconsistent.
What we've checked:

  • iSCSI network is on a separate VLAN
  • Firewall rules are allowing all traffic on that VLAN (no restrictions)
  • Jumbo frames are still enabled
  • No changes to switch config
What we're seeing:

  • Latency jumps from 1ms to 100ms+ randomly
  • iSCSI session resets during high IO
  • No errors in syslog that point to a clear cause
We're working with Syniix on some new storage hardware, and they're helping us debug, but we wanted to check if anyone here has seen similar issues.

Questions:

  1. Could the firewall changes have affected something else indirectly (like MTU)?
  2. Are there specific Proxmox settings we should check after firewall updates?
  3. Any recommended tools for deeper iSCSI diagnostics?
Appreciate any suggestions.
 
Prove jumbo frames are working.

No matter how clever we think we are, something always gets missed out somewhere! For jumbo frames to work, everything along the path needs to be setup, NICs, bonds etc and switch ports. The setting is called the Maximum Transmission Unit or MTU and you can test it with ping.

ping imposes an overhead of 28 bytes and when specifying the ping size, that is actually the payload, ie what is transferred by ping. So let's suppose we want to prove that 9000 byte frames can be transferred. 9000 - 28 = 8972 bytes. Also we must make sure that the pings are not fragmented. On Linux that means using the -M do switch and parameter to ping.

The routing table will normally make sure that the correct interface is pinged from, but with iSCSI it is possible to have multiple IPs on the same subnet bound to different NICs - for example when dealing with an Equallogic. The other (more common) networking method in use by iSCSI targets is to have a separate subnet per NIC/SAN interface pair. Its all about how to distribute traffic across NICs and when you are new to this stuff makes little sense initially!

This is an example from an actual running system. Here pve1 has an IP of 192.168.100.61 and vmbr0 is a bridge on a bond of two NICs. The MTU has been set to 9000 on the two NICs, the bond and the bridge. Also, the switch ports that the NICs are connected to are set to an MTU of 9128 (from memory) which is normal with switches - they just have to be set to the same or larger than the Proxmox gear.

Code: 
root@pve1:~# ping -s 8972 -I vmbr0 -M do 192.168.100.62
PING 192.168.100.62 (192.168.100.62) from 192.168.100.61 vmbr0: 8972(9000) bytes of data.
8980 bytes from 192.168.100.62: icmp_seq=1 ttl=64 time=0.231 ms
...

The actual proof is the (9000) in the first line of the output from ping.

You need to ping all links from all devices that you can run ping from to prove the system. You can also run a carefully configured tcpdump and run it up in Wireshark.
 
You must log in or register to reply here.
Top Bottom
Back