rvardel (Customer) asked a question.
BX-DM1E issue with VPN
This is not a question since I solved the problem, but presented as information that may help someone. I had a BX-DM1E running firmware version 2.7 and working fine with VPN. After upgrading to firmware version 2.8, I was no longer able to connect to the BX-DM1E over VPN. Local connections were unaffected, working normally with either firmware version. Downgrading the BX-DM1E to firmware version 2.7 restored connectability over VPN. Perhaps it's something specific to my installation, but if you upgrade firmware and lose VPN, this may help you.
Thanks for the information.
Garry
In 2.8 there were changes to the networking to add support for the ECOMEX and DHCP. Not sure why any of those changes would affect VPN function, but I don't think rolling back is a good long term solution. If anyone else is having similar problems, and is willing to work with us on getting a proper resolution, please give me a shout.
I am at the site now and able to assist with troubleshooting the issue if you are available.
Sincerely,
Ric Vardel
IPC,Inc.
(949) 291-8940
rvardel@ipcengineering.net
Bob O.
I am having this exact same issue with the same model Do-More as rvardel. I spoke with Jim yesterday in your tech support department. I then went to the site and I was IMMEDIATELY able to connect to the PLC once my laptop was on the local Wi-Fi. So, this means that the inability to communicate is only NOT working when trying to access the same PLC via VPN. Prior to my upgrade to 2.8 on the PLC, I had been communicating with this PLC via VPN for about 10 months without any issues. After finishing my changes, I then came home and tried accessing again via VPN. Again, it would NOT work.
So, something was BROKEN going from 2.7 to 2.8 that is affecting VPN access. We need this resolved ASAP. Please report this bug to the Do-More team. Please respond to me here if possible as well. Thank you.
Matteo Giovanetti
CseaTec LLC
If someone can get us a Wireshark trace of the packets going to (and hopefully from) the PLC, along with IP addresses of all of the relevant devices (PLC, source PC, VPN/gateway, etc), we would stand a much better chance of solving this.
One major change for 2.8 was the addition of the secondary Ethernet port option. That changed the way the PLC routes packets. While I suspect that to be the issue, until I know exactly what the PLC is doing, it's going to be tough to fix.
One thing I am curious about. In a VPN setup, is the PLC's gateway set to the VPN's local address?
Hello Bob,
I realize that you may already be gone for the Christmas break, so you may not see this today. First, I wanted to say THANK YOU for taking this one seriously. I assure you that it is a real issue that needs attention.
Although it's not easy for me to access the PLC since it involves travel, I will commit to doing whatever it takes for you and Automation Direct to get this resolved. I desperately need the VPN access to work again.
I can answer some of your questions now. Within the on-site LAN, the PLC is at a fix IP at 10.1.1.244. When my PLC comes to life on their Wi-Fi network, it gets an assigned address within the same subnet (10.1.1.x). I do not know the gateway that the PLC is using on the local LAN, nor do I know what my PC was using (i.e. I have to travel back there first). However, when I login via the VPN, it does appear my PC ends up on another subnet (10.4.1.45, with a subnet mask of 255.255.255.255 and a gateway of 0.0.0.0). This may be typical for VPNs, and this configuration has always been the case, and it worked fine with OS 2.7 in my BX-DM1E PLC. I'm not sure if this is where the issue is now stemming from, given the changes you mentioned in OS 2.8. Unfortunately, I can't I can change too much on the VPN remotely since access to its configuration tool (Cisco) is controlled by my customer.
If you can specify precisely what you need, I can schedule a trip to this site next week, and gather up the information for you and the Do-More team.
Thanks again and Merry Christmas.
V/R
Matteo
I'll be in and out, but Host is officially shut down until the new year.
Programming communications use UDP packets. If the PLC receives a UDP request, it responds. To respond, it first must determine where to send the packet by using ARP. If the ARP request succeeds, it sends the packet to the local address that answered. If ARP fails, it sends the packet to the gateway for it to route. Some of that routing behavior changed for 2.8.
Seeing the request packet and the PLC's answer (in a Wireshark trace) will give us a very good chance of knowing what's different between 2.7 and 2.8 with regard to VPNs. I'm sure there is an answer, and we'll keep at it until we get it. We want this to work as much as you do.
We also aren't opposed to trying to set up a similar VPN installation here, but there is a huge range of VPN hardware, and some of it is quite expensive. I think some low cost switches even have VPN functions, so we may see if we can set that up.
Hello again Bob,
I hope you had a nice Christmas.
I installed Wireshark, logged into the VPN, started a capture, pinged the PLC successfully, then started the Do-More Designer, opened my project, saw the failed attempt at connecting to the PLC, then clicked "RETRY" 3 more times. Then, I stopped the capture.
I did two captures, one with the PLC address (10.1.1.244) unfiltered, and one with it filtered. Obviously, the former has a LOT more traffic captured, which may be useless to you. Attached are both captures. I see that the PLC port (28784) that the Do-More designer is trying to access is correct, and it is the same as as it was previously assigned before I did the PLC OS upgrade to 2.8.
Please let me know if you need anything else to figure this out.
Thank you.
Matteo
BRX VPM V2.8 Failure Captures
It's using local administered MAC addresses (Host addresses are in the range 00 E0 62 XX XX XX). That is new to me and I'm not sure of the implications of that. The change probably isn't routing, as I suspected, but probably related to the local MAC. To support the new Ethernet/IP adapter feature, we turned on IP multicast support, and I'm wondering if that might be where the issue is.
I need to study this a bit.
I've studied Locally Administered Addresses (LAAs) a bit more, but I'm not sure I know anything more than I did.
LAAs are used in network virtualization, which makes sense with a VPN. Not all hardware supports them, and I see no evidence that Host equipment does or ever did. Which then make me wonder what the change is...were we somehow handling LAAs in 2.7 (don't know how) or has 2.8 given the VPN the impression that we can. No clue. Seeing a Wireshark of a successful connection would provide more insight, but I hate to keep running you around. I see that something is answering the ping, but since the MAC address isn't the PLC's default address, it could be anything.
This whole thing is wandering over into the some of the more arcane details of IT management, and the info isn't super clear or readily available. I'll poke around some more.