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.
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.
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.
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.
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.
Following the TCP Stream we saw that the client basically does everything twice, like a 6-way handshake.
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.
Thank you for your support.
We are also about to embark on a project to connect our Nokia Nuage E200s to Zscaler using IPsec. We are being told by our network partner that the E200s do not support NULL encryption. Is this true, can anyone confirm this? If it is not true, can anyone provide a screenshot of the setting showing NULL in use?
at least one issue that caused a static port setting to fall back to “auto” after a reboot - and causing a port misconfiguration - was solved in release 20.10.6.2 of NSG firmware.
