eCatcher Connectivity Issue On Customer Network

Ewon Support Software
#1

Hello,

We normally have no issues as the whitelisting is straightforward but we are working with customer with a very locked down environment. We can connect through eCatcher to devices at their site without issue, but they cannot connect eCatcher from their own devices. Their employees use computers with always on VPNs with no admin rights so even out of the office they have the same issue and they lack the ability to disable their corporate VPN. Their IT and cyber security team who we have worked with extensively believe they have allowed the traffic and it’s a subnet overlap issue but we disagree. They do use a 10.X.X.X/16 subnet but it does not overlap with the 10.27.0.0/16 VPN network and from our experience the client would call this out if it did.

Would there be any way someone could review the below log files and confirm our findings? It appears the initial 443 connection to the access server succeeds but something is blocking the openVPN tunnel like firewall DPI or application level filtering.

Log files error screenshots → ShareFile

#2

Hello @donnelb ,

I can confirm your finding the connection checker is not able to establish a VPN connection to the servers over both the TCP port (443) and the UDP port (1194).

2022-02-22 09:28:32.1741 TestThread INFO 0/28 UDP connections succeeded.
2022-02-22 09:28:32.1741 TestThread INFO 0/28 TCP connections succeeded.
2022-02-22 09:28:32.1741 TestThread ERROR Could not connect to any VPN 
server.
2022-02-22 09:28:32.3400 MainThread INFO Success - Connection to Internet 
OK. Your public IP = 107.0.159.254
2022-02-22 09:28:32.3400 MainThread INFO Success - Connection to the 
Talk2M Access Server successful.
2022-02-22 09:28:32.3470 MainThread INFO Fail - Could not connect to any 
Talk2M VPN server.

As long as they are also not using 10.27.0.0/16 you there would not be an over lap They may have something explicitly blocking openVPN connections or the VPN Servers them selves.

kb-0209-00-en-adresses-and-ports-used-by-talk2m.pdf (windows.net)

#4

Understood, I am seeing if I can further confirm their subnetting. I see they have a few different 10.X.X.X/16 in use at locations so I want to make sure they are not using the full 10.0.0.0/8. If they are, are there any options for a VPN server that uses another private IP range?

#5

Also if all else fails, M2Web seems like it may be a good option. The main purpose here is to connect to devices behind the Ewon which this would allow. From my understanding, you only need eCatcher to configure the IP devices initially which we could do on our side, then it’s all web based and eCatcher is not need to connect correct?

#6

If they are using the full 10.0.0.0/8 subnet this could be an issues with adding a route to the VPN. From the connection checker screen shot it looks like they use 10.94.0.0/16 so i dont think this is the issue.

Ecatcher gives you a VPN connection with a route to that subnet. Ecatcher is really only going to give you access though the browser. So applications on the PC would not be able to connect.

#7

Their IT actually confirmed they use all of the 10.0.0.0/8. It’s not a flat network, they have it broken up into many subnets so the test will show just the /16 at this location, but 10.0.0.0/8 and 172.16.0.0/12 is in use internally across their locations and cloud resources. Are there any VPN servers available that use other IP ranges? I’ve only ever seen 10.X.X.X/16 networks with eCatcher.

I am seeing if I can make M2Web work for their needs, that will only allow them to reach the devices on specific protocols and things like robot teach pendants fail to work with error “To protect your security, us4.m2web.talk2m.com will not allow Firefox to display the page if another site has embedded it. To see this page, you need to open it in a new window.” so it’s not looking great.

#8

It does not look like M2Web will work as they are trying to use RSlinx.

This is not something we have ever run in to, this customer is a very large global company and there is no way they will change their subnetting. Please let me know if there are any VPN servers that can use a class C range.

#9

As long as the PC’s have an IP address assigned in a /16 subnet this should not cause an issue. It would only be an issue if the ewon VPN IP was in the exact same /16 subnet. I don’t think this is the issue they are running into right now.

What are the error messages seen in ecatcher when they connect? Can you provide a copy of the logs?
From settings you will see a button in the top left that will generate a .zip.

image
image959×393 17.6 KB

#10

You can find the customer’s eCatcher log here ShareFile

There error they see is at the original link I provided to start the thread. It’s called “EWON error.png”

#11

The messages in the logs point towards the open VPN connection being blocked.

2022-02-23T12:45:35,299  WARN - start client.vpn43.talk2m.com 443 "C:\Users\bsidwell\AppData\Roaming\.talk2M\temp\6a4f80f6-945b-47b1-8b59-553c3cfd055f" tap TCP netsh 
2022-02-23T12:45:35,325  INFO - ConnectionWorkerProgressStatus : Connecting Talk2M: Opening VPN tunnel... - 20 %
2022-02-23T12:45:35,896  WARN - OK
2022-02-23T12:45:36,398  WARN - > INFO: OpenVPN Management Interface Version 1 -- type 'help' for more info
2022-02-23T12:45:36,398  WARN - > HOLD: Waiting for hold release:0
2022-02-23T12:45:36,399  WARN - > LOG: 1645638336,D,MANAGEMENT: CMD 'hold release'
2022-02-23T12:45:36,553  WARN - > LOG: 1645638336,,MANAGEMENT: >STATE:1645638336,RESOLVE,,,,,,
2022-02-23T12:45:36,553  WARN - > STATE: 1645638336,RESOLVE,,,,,,
2022-02-23T12:45:36,553  INFO - ConnectionWorkerProgressStatus : null - 32 %
2022-02-23T12:45:36,553  WARN - > LOG: 1645638336,I,TCP/UDP: Preserving recently used remote address: [AF_INET]184.173.179.90:443
2022-02-23T12:45:36,554  WARN - > LOG: 1645638336,,Socket Buffers: R=[65536->65536] S=[65536->65536]
2022-02-23T12:45:36,554  WARN - > LOG: 1645638336,I,Attempting to establish TCP connection with [AF_INET]184.173.179.90:443 [nonblock]
2022-02-23T12:45:36,554  WARN - > LOG: 1645638336,,MANAGEMENT: >STATE:1645638336,TCP_CONNECT,,,,,,
2022-02-23T12:45:36,554  WARN - > STATE: 1645638336,TCP_CONNECT,,,,,,
2022-02-23T12:45:36,554  INFO - ConnectionWorkerProgressStatus : null - 44 %
2022-02-23T12:45:37,552  WARN - > LOG: 1645638337,I,TCP connection established with [AF_INET]184.173.179.90:443
2022-02-23T12:45:37,553  WARN - > LOG: 1645638337,I,TCP_CLIENT link local: (not bound)
2022-02-23T12:45:37,553  WARN - > LOG: 1645638337,I,TCP_CLIENT link remote: [AF_INET]184.173.179.90:443
2022-02-23T12:45:37,553  WARN - > LOG: 1645638337,,MANAGEMENT: >STATE:1645638337,WAIT,,,,,,
2022-02-23T12:45:37,553  WARN - > STATE: 1645638337,WAIT,,,,,,
2022-02-23T12:45:37,553  INFO - ConnectionWorkerProgressStatus : null - 56 %
2022-02-23T12:46:35,899  WARN - shutdown
2022-02-23T12:46:35,903  WARN - > LOG: 1645638395,I,SIGTERM[hard,] received, process exiting
2022-02-23T12:46:35,903  WARN - > LOG: 1645638395,,MANAGEMENT: >STATE:1645638395,EXITING,SIGTERM,,,,,
2022-02-23T12:46:35,903  WARN - > STATE: 1645638395,EXITING,SIGTERM,,,,,
2022-02-23T12:46:35,904  INFO - ConnectionWorkerProgressStatus : null - 68 %
2022-02-23T12:46:35,909  WARN - OK
2022-02-23T12:46:35,913  WARN - StartConnectionWorker cannot establish vpn tunnel. retriyng

We can see here everything making a connection up to establishing the VPN when something external seems to be killing the connection.

#12

Thank you for reviewing the logs. I will re-engage with them.

#13

You’re welcome, Let me know if there is anything else i can help with.

#14

Afternoon, sorry to bump this. I just wanted to 100% make sure there is no option for a different class subnet? As their IT is not budging we will likely have them provide access through their internal VPN solution rather then the Ewon but before that change they wanted me to confirm there is no option for other subnets.

#15

I do not believe this issue has anything to do with the subnet. It seems most likely associated with the firewall blocking the connection. I would check what white list rules they are adding to allow the ewon’s to connect and ensure the PC’s trying to connect have the similar rules but for the ecatcher VPN IP addresses.