IP not updating in Talk2M

Ewon Support
#1

We have a series of Ewon Flexy that are connected to Talk2M. We have recently changed their LAN IPs, but the new IP addresses are not reflected in eCatcher. We changed the IPs through the web interface and forced a reboot. We saw the devices go offline in eCatcher and then back online. When we connected to the Ewons, eCatcher still reflected their old LAN IPs, but the Ewon’s web interface reflected the new IP. I’ve attached a backup with support files of one of the devices impacted.

The event log is full of DNS errors, but the Ewon is successfully connecting to Talk2M using its various saved static addresses. We are looking into the DNS errors.

#3

Hi @atai

After you connect to the device on eCatcher it should update to reflect the correct IP. But if it doesn’t you can manually change this here

image
image1283×445 47.5 KB

#5

Hi Tim,

I know how to manually change it, but I was just concerned about it not updating. My understanding is that in the modern firmware versions & eCatcher versions, when the Ewon reconnects to the VPN server after a reboot, it sends its IP
to Talk2M and any changes get reflected in eCatcher. Are the DNS issues we’re having preventing that process? Is my understanding incorrect? Is there something else going on?

Angela Telerski

#6

I failed to mention, when you connect to the device in eCatcher, the IP does not update automatically so the device ends up unreachable by any IP other than the VPN IP. (Until you disconnect, manually update the IP and reconnect that is.)

Angela Telerski

#8

Hi Angela,

It does seem like there’s some kind of DNS issue that’s preventing the device from properly communicating with our server. Can you try and change one of the ethdns values to 8.8.8.8 or 1.1.1.1?

#9

This network is SUPER locked down so those addresses aren’t reachable. I think their IT is doing DNS filtering. I’m working with them to allow *.talk2m.com address resolution.

Angela Telerski

#10

Oh ok, that could be an issue then. This sheet is a good reference point to hand to their IT if they have more questions:

kb-0209-00-en-adresses-and-ports-used-by-talk2m.pdf (290.9 KB)

#11

Hi Tim,

The good news is that we’ve finally resolved the DNS issue. But we’re still running into something strange that I’m hoping you can help with. The customer allows communication over 443 to the access server, but something about the communication
is getting blocked. In the event log for a previously configured Ewon, you see a message like this:

1584026598;“12/03/2020 15:23:18”;“ovpn-OpenVPN process ended”;“openvpn”;79331;1073771437
1584026598;“12/03/2020 15:23:18”;“wanmgt-Restarting permanent WAN connection”;“wanmgt”;79336;1073772933
1584026601;“12/03/2020 15:23:21”;“wanmgt-Open WAN interface”;“wanmgt”;79336;1073772969
1584026602;“12/03/2020 15:23:22”;“ovpn-OpenVPN process start”;“wanmgt”;79336;1073771442
1584026604;“12/03/2020 15:23:24”;“t2m-T2M: Certificate verification (gk-us-hub)”;“openvpn”;79331;33244
1584026604;“12/03/2020 15:23:24”;“t2m-Talk2M: read VPN server address failed”;“openvpn”;79331;-33233
1584026605;“12/03/2020 15:23:25”;“t2m-T2M: Certificate verification (gk-us-hub)”;“openvpn”;79331;33244
1584026606;“12/03/2020 15:23:26”;“t2m-T2M: Certificate verification (gk-us-hub)”;“openvpn”;79331;33244
1584026606;“12/03/2020 15:23:26”;“muting (pattern of 1 event)”;“openvpn”;79331;-20205
1584026606;“12/03/2020 15:23:26”;“ovpn-Could not read Talk2M VPN server address, using last valid.”;“openvpn”;79331;29624

Not ideal, but again since the static address is stored in the config, we can connect to Talk2M. However, this communication issue is also preventing us from configuring devices on premise. It fails in the Talk2M wizard during the “Read
Talk2M config” stage.

I’m attaching a backup of a device that was already configured for Talk2M with its VPN debug settings moved up to medium to hopefully give you a little more info about where in the communication with the access server the process is choking.
Any idea about what IP, port, or protocol they might be blocking that is making this fail?

Thanks,

Angela

Angela Telerski

#13

Hey Angela,

I made a little document that might help narrow down which the issue based on where it’s failing in the wizard

Can’t pass VPN (Talk2M) Wizard v1.1.docx (119.7 KB)

#14

Hi Tim,

Thanks for the doc, but none of those cases that you describe fit the situation. While I don’t have a backup of the failing device, if we can figure out why we can’t read the VPN server on previously configured devices, that will go a
long way to figuring out why configuring isn’t working.

Angela Telerski

#15

Are you sure there’s nothing on their network that might be blocking OpenVPN?

#16

Given that the VPN connection itself is ok, I don’t think so, but I suppose it is possible. If we configure a device offsite and then install it at the customer site, it connects to Talk2M and we can remote in. We just see that
ovpn-Could not read Talk2M VPN server address, using last valid
message in the event log. However, we can’t configure onsite. We fail the Read Talk2M Config step which implies we’re dying while communicating with the Access Server.

The Talk2M connection checker leads us to believe we can reach the access server and the appropriate VPN servers and the IPs for the access server and VPN servers have been whitelisted in their firewall. I know
they block websockets on port 443, but I don’t know what else they might be blocking.

Angela Telerski

#17

We could potentially try and move them to a different server and see if that lets them connect. Are they sure that they whitelisted *.talk2M.com?

#18

The problem isn’t the VPN server. In fact, please DON’T move them to a new VPN server. Once the device is configured, the VPN connection is fine. And I can’t guaranteed that they’ve whitelisted all of the VPN servers.

I will get the complete list of IPs that they whitelisted for you. They didn’t whitelist all of *.talk2m.com They can only define exceptions by IP, not by domains.

Angela Telerski

#19

Ok, in theory they should only need to whitelist the one that corresponds to their server if they can’t whitelist *.talk2m.com. But if a server goes down for maintenance they may be moved to a different one temporarily.

#20

I understand the dangers of only whitelisting individual IPs and not entire domains. However, this is how the customer requires it.

These are the IPs that are whitelisted:

Destination Addresses

Client.api.talk2m.com (92.52.111.214)

Device.vpn17.talk2m.com (198.23.64.129)

Device.api.talk2m.com (92.52.111.213)

As.pro.talk2m.com (92.52.111.210)

Destination Ports

Https-443

UDP-1194

As you can see, it is the bare minimum. This network has very strict rules.

Since we cannot configure Ewons onsite, clearly something in this list is incomplete. Is there a server that we’re missing? Is there a port that we’re missing? Is there some protocol being done when the Ewon first communicates with the
access server that is commonly blocked?

Angela Telerski

#21

I can check with Belgium if there’s something else that they might be missing, but as far a I know you just need to follow that KB-0209-00 doc and make sure openvpn isn’t being blocked.

#22

Could they take a wireshark of the network when it tries to make the connection so we can see where it’s actually getting rejected?

#23

Topic closed due to inactivity.