Low speed on IPSec tunnels with Nuagenetworks nsg e200/e300

Hi,
we are currently implementing ZIA on over 190 locations. The locations are using NuageNetworks NSG e200/e300 device to establish IPSec tunnels to Zscaler.
On almost all locations we are facing massive speed issues when using IPSec. Most often we get just 50% of the link speed or less; sometimes either upload or download is OK, but never both.
When we are using “plain pac files” everything works perfectly well with full speed.

Has anyone seen similar issues or an idea how to solve this.

Best regards
Andreas

Hello Andreas,
What is the speed/throughput you’re seeing without IPSec?

Generally when I see this it’s MTU/MSS related. Please take a look at the linked help article on validating MTU values.

https://help.zscaler.com/zia/determining-the-optimal-mtu-for-gre-or-ipsec-tunnels

If that doesn’t resolve it, on some firewalls I’ve also seen issues where IPSec is being done in a mode that the firewall does not prefer (HW vs Software), etc. So check that your Phase 2 encryption is NULL if available, try IKEv1 vs IKEv2 etc.

Mike

Hi,
thank you for your hints. I am trying to get the MTU/MSS settings confirmed. But this seems not so easy for the NSG colleagues. I am happy, if I get the captures from Zscaler side (hopefully tomorrow) since that often helped.
We are using IPSec IKEv2 (according to tunnel logs) with null encryption.
However we are using FQDN+PSK for authentication and not IP+PSK.
Has this a drawback?
Best regards
Andreas

I’m not familiar with the Nuage NSG products directly though I know we have some folks who’ve worked with them in the past. If you have the ability to open a support ticket with our TAC, they will be able to take packet captures to understand if we are seeing fragmentation.

As far as FQDN/PSK auth, generally that should be perfectly fine unless the NSG has any particular issue around it. The NSG may have differences btw IKEv1/v2 for example.

I suggest starting with a TAC ticket though, and they can help with determining if MTU is an issue.

Hi,
thank you again. I will share results here, if we identify the cause.

best regards
Andreas

Andreas,

I don’t know your specific firewall - but with other devices (Merakis for example) if ANY other security is happening at the device we can see speeds drop in half from what is expected. Worth looking at.

v/r
Trace

Hi,
thank you, I will check this with my colleauge if the NSG devices do stuff like this, I am at least not aware of, when it comes to security.

We also had our troubleshooting session. Unfortunately there if been some issues on Zscaler side to perform the captures and the one I received I cannot match, which means that I do not see any of the involved IP addresses, I expect.

I also got traces from the NSGs, which look quite “red/black” in wireshark. As far as I understand the traces (with only little TCP knowledge) I see that the client sends many DUP ACK within the IPSec tunnel, indicating missing packets, despite the fact I can see that the sequence numbers look OK. This triggers at least some (fast) re transmissions, that I consider unnecessary.

Best regards
Andreas

1 Like

Hi,
we most likely identified the issue. With help of Zscaler support we got good captures:

Following the TCP Stream we saw that the client basically does everything twice, like a 6-way handshake. :wink:

We could exclude the client itself as reason. Nokia then checked the port setting of the internal lan-port (NSG<->Switch) and they found out that it was “auto-negotiated” to 100-half duplex. The issue disappeared, when they hard-coded 100-full duplex.
For some reason, the auto-negotiation failed. We saw this before on WAN side, but obviously nobody paid attention to LAN side, as this usually works here.
We had similar issues on other locations, were the issues just disappeared. Now, I guess that this happened when “auto” accidentally started to work correctly. :slight_smile:
Thank you for your support.

Best regards
Andreas

1 Like