→ Applies to: Hyperion 9.x and above

IMPORTANT
The fix is applied directly on the Syneto host. Disabling security on the SonicWall is not required.

Symptom

TCP connections between VMs on separate VLANs intermittently drop or fail to establish, returning the error: "packet sequence number not recognized". Inter-VLAN traffic is routed through a central SonicWall firewall with TCP Sequence Number Randomization enabled.

Direct testing on the host confirmed:

• Traffic always passes symmetrically through the SonicWall (same MAC, same physical path via bond0)
• No local shortcut exists
• Anti-spoofing settings (rp_filter, arp_ignore, etc.) are correctly configured

SynetoOS runs an embedded Kubernetes on the same host kernel. To make that work, the kernel has net.bridge.bridge-nf-call-iptables = 1 set. This causes even VM-to-VM traffic that merely traverses the bridge (without the host being an endpoint) to be pushed through the Linux conntrack engine (stateful connection tracking, normally used by iptables / kube-proxy).

What happens technically:

• The two VMs are on the same physical host but on different VLANs, so their traffic must leave to the SonicWall and re-enter the host (hairpin).
• The host bridge therefore sees two copies of the same packet with the same IP 5-tuple:
  • copy A: VM1 → SonicWall (original sequence number S)
  • copy B: SonicWall → VM2 (randomized sequence number S')
• With nf_conntrack_tcp_be_liberal = 0 (strict window checking, the default), conntrack sees copy B with an out-of-window sequence number and marks it INVALID.
• A kube-proxy rule drops all INVALID traffic: KUBE-FORWARD ... ct state invalid -> DROP

Result: copy B is discarded, breaking the connection. When randomization is disabled on the SonicWall, both copies carry the same sequence number, look like a harmless duplicate, and pass — which is why disabling it "fixes" the symptom without addressing the actual cause.

NOTE
L2/L3 routing is clean. This is not a routing path issue.
UDP has no sequence numbers, so this specific mechanism does not explain UDP problems. If UDP interruptions are also reported, they must be investigated separately (possibly a similar conntrack issue on hairpin duplicates, but not confirmed).

Solution

Step 1. Connect to SynetoOS appliance via SSH as admin

ssh admin@<your_ip_address_or_hostname>

Step 2. Get root privileges

sudo su -

Step 3. Set conntrack to tolerate sequence window variance

sysctl -w net.netfilter.nf_conntrack_tcp_be_liberal=1

Step 4. Force the module to load at boot

echo "nf_conntrack" > /etc/modules-load.d/nf_conntrack.conf

Step 5. Create the persistent sysctl file

cat > /etc/sysctl.d/99-conntrack-liberal.conf << 'EOF'
net.netfilter.nf_conntrack_tcp_be_liberal = 1
EOF

Step 6 (Optional). Reboot to verify the setting persists

reboot

sysctl net.netfilter.nf_conntrack_tcp_be_liberal