Client Jump Box with 10.10.0.0/24 Private IP Range Cannot Access SSPI but Can Access SSP

Products

• VMware vDefend Firewall
• VMware vDefend Firewall with Advanced Threat Prevention

Issue/Introduction

In some deployments, a client jump box using the private IP range 10.10.0.0/24 is unable to access the SSPI node, while:

• The same jump box can access SSP

• The jump box can access other systems in the same subnet

• The jump box may briefly be able to ping the SSPI node during early boot

• Connectivity is lost once the SSPI node completes boot

• Packet capture shows ping is received but not reply

This behavior is observed consistently when the jump box IP range overlaps with the Antrea Pod network used internally by SSPI.

Environment

• SSPI: 5.0, 5.1

• CNI: Antrea (internal to SSPI)

• Jump Box IP Range: 10.10.0.0/24

• Observed OS Route: 10.10.0.0/24 dev antrea-gw0

Cause

SSPI uses Antrea as the Kubernetes Container Network Interface (CNI) for internal service communication.

By default, Antrea reserves and programs the Pod CIDR 10.10.0.0/24 inside the SSPI node.
During boot, Antrea creates an internal kernel route that takes ownership of this subnet.

Example routing table on SSPI:

 

root@sspixxx:~# ip route default via 10.91.x.x dev eth0 proto static 10.10.0.0/24 dev antrea-gw0 scope link src 10.10.0.1 10.91.x.x/24 dev eth0 proto kernel scope link src 10.91.x.1

Once this route is installed:

• All traffic destined for 10.10.0.0/24 is treated as internal Pod network traffic

• Packets are forwarded to the antrea-gw0 interface

• External client traffic originating from the same CIDR becomes unreachable

Why access works briefly during boot

• Before Antrea initializes, the route does not yet exist

• Traffic is temporarily handled by the default interface (eth0)

• Once Antrea starts, the route is installed and connectivity is lost

---

Why SSP Is Not Affected

• SSP management services are not bound to the Antrea Pod CIDR

• SSP uses standard management networking

• Therefore, access to SSP remains functional even when the jump box IP overlaps with the Antrea network

Resolution

• The jump box must not use an IP range that overlaps with the Antrea Pod CIDR used by SSPI.

  Recommended actions:

  • Move the jump box to a different private subnet, for example:

    • 10.20.0.0/24

    • 10.91.0.0/24

    • 172.16.0.0/16

  • Ensure no overlap with:

    • Antrea Pod CIDRs

    • Internal Kubernetes service networks

  The Antrea Pod CIDR is internal and not user-configurable in SSPI.

• This is different than the SSP CIDR;

  "secop_capi_pod_cidr_list": "172.21.0.0/16, 172.17.0.0/16, 172.23.0.0/16, 100.64.0.0/10, 10.90.0.0/16, 10.190.0.0/16, 10.42.0.0/16, 10.44.0.0/16, 10.46.0.0/16",

Additional Information

• Additional Notes

  • This behavior is by design due to Antrea networking architecture

  • Manual modification of SSPI routing tables is unsupported

  • Overlapping CIDRs can result in:

    • Asymmetric routing

    • Silent packet drops

    • Intermittent access during startup only