Can not connect vpn ewon endpoints, see picture:
Any idea how to solve?
Actually this happens at only 1 client workstation, all others are okay and working correctly.
Already done:
Is this computer on the same network (behind same firewall) as the others?
Does it have the same firewall/antivirus software?
Try going to “Settings” on the eCatcher Log In page (you must log out), select ‘VPN Driver Settings’, and change that to DHCP. Then try again and see if you get the same error.
Is this computer on the same network (behind same firewall) as the others?
yes
Does it have the same firewall/antivirus software?
yes
Try going to “Settings” on the eCatcher Log In page (you must log out), select ‘VPN Driver Settings’, and change that to DHCP.
i tried it, same error
Further test done with success, but why?
When i deactivate IPv6 prot on network card, it works as it should!, but that could not be the solution,
as i need IPv6 on other services, as mention in the screenshot, you see that the connection takes as best an IPv4 adress and later on try it connects to an IPv6 adress, that could not be correct.
That is strange indeed. Do the other PCs have IPv6 disabled? Are they running a different OS or version?
Do the other PCs have IPv6 disabled?
No
Are they running a different OS or version?
No, all Windows 10 Prof. with latest updates
A mentioned in Logfile:
Ecatcher check for best endpoint → result → IPv4 adress,
but then later on connection establishment it calls an IPv6 adresse, why?
Further Test done:
On a further different machine, normally without IPv6, just activated IPv6 and test it, works,
only different between both machines:
The second machine prefers IPv4 instead IPv6 by windows registry entry
See Prefer IPv4 over IPv6 in prefix policies at
Microsoft IPv6 Settings
Yes, at this time, eCatcher is not compatible with IPv6, so you should set the PC to prefer IPv4.
Yes, at this time, eCatcher is not compatible with IPv6, so you should set the PC to prefer IPv4.
Really? thx for the clear answer, but this is unbelievable
Thats is no solution, it can not be my part to tell Windows to prefer IPv4 in case of your application is not able to handle IPv6, you should better tell your application, not to use IPv6, when not able to do so.
After some researches, whats about simple Java code like this:
java.net.preferIPv4Stack=true
Sorry, but your developers never heard about it? i can not believe this, rly
As your solution ist not practicable for us, we’ll need to search better solution.
I’m not a developer of eCatcher, sir, but thank you so much for your suggestion! I will report this to them. Have a great day!
Today morning the next client stops with same problem,
turned ipv6 off on network interface and on tunnel interfaces, all works as expected.
As mentioned, this could not be the solution - so fix it
Hi,
Thank you for using our forum. Due to the nature of this request and to better assist you with the troubleshooting of this issue, please create a support ticket using our support portal.
https://support.hms-networks.com/hc/
This forum is run by the Americas market unit of HMS Networks. Like @Zach_HMS mentioneed, if you create a support request, it can be properly routed to the Ewon developers. I have already informed them of this issue, but it would beneficial to have a support case on file for proper tracking.
Why i need to register again at support.hms.networks.com?
Same company, different subdomains, different logins? rly?
Here is a response from the developers:
Regarding the IPv6 “issue” of eCatcher Desktop. R&D thinks there is actually no issue.
First, the customer advises some Java modification while his problem is the VPN service which is not developed in Java. The Java eCatcher interface is actually working well on his PC… So no Java issue.
Here is what they state:
Client has a double ipv6 /ipv4 stack with a double network exit path. This happen, shouldn’t be a problem
The ipv6 is provided by DNS64/NAT64 in his enterprise network, which is a mechansism that volontuary shadow ipv4 infrastructure. This one is returning fake IPV6 addresses for ou vpn servers that are to be handled by their NAT64 system.
Openvpn is using the ipv6 pathway because it’s OS is telling it that ipv6 and ipv4 are both ok. Normally, this shouldn’t be a problem for us. Because ecatcher and service are exchanging domain name, not ip, this is different from ecatcher log which show ipv4. Again, if both ip are declared correct by os, choice is implementation dependent and shouldn’t affect the final result, that could explain differences from desktop to desktop.
The ipv6 pathway is firewalled on client side, while the ipv4 pathway is not. This would also explain why stopping ipv6 on desktop is allowing access, as openvpn is not using the ipv4 stack and thus another path
So it becomes impossible to connect to talk2m vpn servers on dedicated port and we end with a timeout waiting initial TLS negociations #
Conclusion: Client should contact his IT departement and get the ipv6 firewall sorted out. Problem most likely at client site and has nothing to do with our potential support of ipv6 or not.
Dear Kyle,
thanks for your support.
First of all, i am the head of IT in our IT department.
secondly, the client then should be capabell using IPv6 and/or Dual-Stack,
thirdly, i’m needed to smile 
about the suggested solution points.
1. State:
NO, thats not given.
2. State:
NO, it is not shadowed, all client get public IPv6 which is ping-able from the world wide web,
if i allow incoming ICMP packets on firewall from wan side. (tested it also with a small webserver)
3. State:
Windows, Linux = all prefer IPv6, normal default, i tested also only IPv6
4. State:
NO, the error also occurs when firewall is switched completly off
Further:
On eastern hollidays i hopefully will have time to check and test and debug it again, after this you got a detailed report,
then we hopefully get productable answers from R&D based on new informations.
Hi @gadmin,
Thank you for your response. I have forwarded it to the developers.
We appreciate any additional info that you can provide, so I will wait for that and let you know if devs have any other questions.
Best Regards,
Kyle
By the way, you will probably get an email from our ticketing system because I was asked to create a ticket for this issue.
