IGEL OS websocket connectivity to ICG


Does anyone know if it’s possible from IGEL OS to perform a websocket connectivity test to ICG.

Learn more, read the entire thread inside the IGEL Community o Slack

We are currently in PoC stage and have ran into an issue where we think our Cloud DDoS service is terminating the websocket connection. We currently have our DDoS provider looking at this and also IGEL DevProduct Management. We will shortly bypass the DDoS Protection service temporarily tomorrow and was wondering if the following site could be used to perform connectivity testing:

www.websocket.org/echo.html www.websocket.org/echo.html

Our devices are connecting, but then frequently toggling state between online and offline until after a certain period of time going into unlicensed state until I reboot both UMS and ICG servers


Long time since I had to test, but there I used Curl. Can‘t find my initial commands but this one might help in a first step:

gist.github.com/htp/fbce19069187ec1cc486b594104f01d0 gist.github.com/htp/fbce19069187ec1cc486b594104f01d0


Hey, I owuld recomend removing the DDoS protection. If you ever run into issues with ICG IGEL will not be able to provide support until you have 8443 traffic open from ICG to all your IGEL devices.

Our protocol often gets flagged by security monitoring systems


Thanks, What ICG page should we connect to to test?

I think behind the scenes Gordon may have been in touch with you about this problem we have with ICG and DDoS protection

We are going to bypass the DDoS Proxy tomorrow and then if it still doesn’t work, will bypass SSL Bridge VIP’s. Our DDoS isn’t seeing the IGEL ICG connection as any sort of attack, we think it just isn’t allowing the websocket keepalive to get back to endpoint so connection gets terminated at timeout value on proxy


Could be. On the SSL Bridge is it a one-to-one bridge?

or do you have multiple ICG’s begind the single VIP?


We have a corporate requirement to have all public facing addresses behind DDoS protection service

One to one mapping from SSL Bridge at Site A to ICG at Site A and then SSL Bridge at Site B to ICG at Site B. No load balancing at all

The only element of load balancing is the initial DNS request into the virtual name, but we have already bypassed GSLB and made requests direct to DDoS Proxy Front end address and also took one site out the load at a time. At the moment, am gutted by this issue as the connection into VDI with MS Team Optimisation is working a treat, this issue just makes the solution unviable for us currently.


A few suggestions

1. Move the port off of 8443. It is not uncommon for load balancers and other equipment to try and “help” by tagging the packets or adjusting the TLS payload — f5 has “extra helper” for port 8443

2. ICG’s use of TLS, especially with the self signed certs and the data can look very funky to security monitoring tools, especially edge devices that are looking for ransomware payloads

3. Because ICG uses Java web services, there will always be broken connections and resets — especially on smaller sized servers. You will want to customize log4j to monitor the app for errors. The default ICG logging config is kinda useless

4. Make sure you have tuned the stack. monitor TCP efficiency

5. Schedule resets of ICG every 24 hours t


Thanks Matthew for your suggestions, but I’m likely to require more detail to progress those.

We are initially going to bypass DDoS and potentially SSL Bridge VIP’s to ensure the underlying UMS and ICG is setup correctly and then add SSL Bridge and DDoS back in one at a time. Will likely require assistance from IGEL after this point.

We did engage with a partner for the ICG install, but this issue is likely to be out of scope although frustrating as it was known that we had to place ICG behind DDoS proxy right from the start.

Really hoping IGEL Dev/PM can help is find a solution that would then allow this PoC to be a success so we can then offer this as home working solution.


Good luck with your POC. I hope it works out. Our POC was anything but smooth, the results were worth the effort.


We have heard from our DDoS Proxy provider that they are adding support for HTTP WebSocket profile in an upcoming release, but this will require the SSL cert to be uploaded and a Full Proxy mode as opposed to Generic TCP.

I understand that even with this upcoming release, it is still unlikely to work.

Can someone explain if we use the same certificate to what is installed on ICG, why this would break ICG. I understand ICG will detect an anomaly as it will think the DDoS Proxy is a MiTM attack.

How do others protect their internet connection from a DDoS attack if it isn’t possible to place ICG behind such a service in the cloud?

I’m starting to wonder if we need to consider migrating ICG up to public cloud as a solution, but at added cost

Continue reading and comment on the thread ‘IGEL OS websocket connectivity to ICG’.  Not a member? Join Here!

Learn more, search the IGEL Knowledge Base



Ask a question or comment on the above message thread?

Join or log in to the IGEL Community to ask us anything and meet other IGEL customers, partners, and EUC enthusiasts.

Submit a question, or Join Today!


Popular Message Threads


Categories & Tags: