How is VPN traffic calculated?

Ewon Support
#1

Hi,

I’m curious about how VPN traffic is being calculated for the new Talk2M Free+/Pro data limits? We have some accounts that are being flagged as high data users. (And they totally are. We’re in the process of converting them to Pro accounts). However, I don’t understand all of the data numbers on the Connection log. If you look at the attached report, it shows ~360MB of traffic for machines that haven’t uploaded any data points to the DataMailbox, haven’t had any eCatcher or M2Web connections, and haven’t had any M2Web API calls made to them. See MH-Line32-Bead1 as an example. Where is this data coming from?

Thanks,
Angela

#3

Hi Angela,

Could you send a PM with temporary access to this account so I can try to take a look at what might be using so much data?

-Tim

#5

It doesn’t really look like that one is polling any data, and you’re not using KPIs, have you been using this Flexy to download configurations to a PLC over Studio 5000 or anything like that?

#6

Nope. We’ve done nothing with it. That’s why I’m so confused.

#7

That’s really strange, I’m going to check with the Belgian team and see if there’s anything else that would cause a device to use a lot of data

#8

Did you enable PLC discovery?

#9

I’m having an identical issue on one of my accounts, usual traffic is less than 1Gb but last month it was 9Gb and this month its already gone past it’s limit.
Under the connections on the account the traffic is still the same around 1Gb.

PLC discovery is enabled. And this hasn’t been an issue in the past.

#10

Not as far as I’m aware. Since we don’t typically use these devices for remote access of the PLCs, we don’t enable PLC discovery as part of the standard configuration.

#12

We could try and schedule a teamviewer session and take a wireshark capture of the WAN side to see if we can narrow down what’s causing these issues

#13

I doubt my customer would let us do that. However, that brings up a good point – these devices are configured to allow traffic on the WAN port. There may be some misdirected WAN to LAN messages. I’ll do some experimentation on one of my test systems.

In the meantime, could you check with BE about whether or not there’s a way they could tell if there was a pattern to the data usage? By that I mean, was it a little every day or none and then a giant spike somewhere? Since there’s nothing on the connection log that would indicate the source, maybe understanding the pattern could help me figure out the source. There might not be that level of logging on the servers, but if they have that information it could be really useful.

#14

Unfortunately we don’t really have that level of logging on the servers to know what might’ve been done with the data at that time, but the BU told me they’re working on a document that can help better explain where some of the VPN data usage comes from

#15

I believe they said this document should be finished by the end of the week, I’ll check in with my colleague tomorrow and let you know what I find out

#16

Great! Thanks!

#17

They’re still working on the document, but in the meantime I can give you this info

When UDP is used: Number of bytes used for an OpenVPN ping: 84 bytes Number of bytes used for a TLS key negotiation: ± 6400 bytes in and 5800 bytes out

Quantity of data used for the maintain of the VPN connection during 1 hour: Incoming traffic: Ping: 60/10 * 60 * 84 = 30240 TLS negotiation = 6400 Total = 36640 bytes / hour Outgoing traffic: Ping: 60/10 * 60 * 84 = 30240 TLS negotiation = 5800 Total = 36040 bytes / hour

B) When TCP is used: Number of bytes used for an OpenVPN ping: 110 bytes for the request and 55 bytes for the Ack Number of bytes used for a TLS key negotiation: ± 12000 bytes in and 10000 bytes out

Quantity of data used for the maintain of the VPN connection during 1 hour: Incoming traffic: Ping: 60/10 * 60 * (110 + 55) = 59400 TLS negotiation = 12000 Total = 71400 bytes / hour

Outgoing traffic: Ping: 60/10 * 60 * (110 + 55) = 59400 TLS negotiation = 10000 Total = 69400 bytes / hour

#18

Thanks for this, Tim.

I understand about the keep alive, but there has to be something else going on with these units. If my math is right, then worst case, the keepalive is around 3.5 MB of data per day. But I’m seeing something closer to 46 MB of data per day for devices that have zero eCatcher or M2Web connections, no tags so no KPI over M2Web, no API calls, no emails – nothing except connections to Talk2M.

I’m going to see if the customer’s IT department will help me capture some network traffic information to see if we can figure out the source of all this mystery data.

Thanks,

Angela

#19

Yeah something about that amount of data usage seems weird. Could you let me know what you find out from their IT about this?

#20

Hey Angela, just wanted to check in on this and see if you heard anything back about the data on their network?

Best Regards,
-Tim

#21

Hi Tim,

The customer hasn’t done any captures for me yet, but I do have a theory about what’s going on. This site has always had something about it that prevents communication to the Talk2M access server. There’s an exception for it in their firewall, there’s no deep packet filtering, and it always passes during the Talk2M connection checker, but something about the communications get blocked. We can’t configure Ewons on site and the logs always says ovpn-Could not read Talk2M VPN server address, using last valid. Is it possible that all of the failed attempts to communicate with the Access server are causing the data bloat? The realtime log is FULL of failed connection attempts. (I’ve attached a backup w/ support logs if it helps. If it doesn’t come through, let me know).

If that seems like a possible source, any ideas WHAT might be configured/misconfigured about their network that is preventing us from successfully negotiating with the Access server?

MOVED TO STAFF NOTE (347 KB)

#23

Have they already gone through and whitelisted our servers?

Also is there any chance that their firewall might be killing the OpenVPN connection sometimes?

#24

Yes, all the servers are whitelisted. And the OpenVPN traffic gets through fine. It is the initial negotiation with the Access server – determining which VPN server to use, etc – that fails.