Siemens TIA PLC device discovery with Teltonika VPN

[btecjoep]

Hello,

Like already asked quite a few times on this forum, but never clearly answered, I am also looking to make the Siemens device discovery (layer 2, profinet DCP) work trough the Teltonika VPN.

When the IP adresses are already assigned, a TUN VPN with masquerading will work, no problem.
When a device is new (no IP adress assigned), the Siemens software relies on a layer 2 profinet DCP broadcast, which is not getting through.

The nice lady on the phone asked me to open this post, because there would be a solution Teltonika could share with me here. I am really curious, because all of the other post with the same issues were closed without a proper conclusion other than that it just didn’t work.

I already set up a TAP VPN hub in RMS. The clients weirdly get IP adresses assigned by the VPN hub in the 192.168.255.0/24 subnet, rather than getting them assigned by the router. Teltonika told me that they were not able to change this right now, but this is an issue as well.
For this moment, I could overcome it by assigning the LAN IP of the router in the same 192.168.255.0/24 subnet.

I was also able to assign the VPN to the LAN bridge on the router (all of the examples online do not match current firmware, please update them!).
The router itself is now reachable by it’s LAN IP through the TAP VPN, but not through the VPN client IP (but that’s not a problem per se), but the Siemens software still shows no devices discovered.

It’s totally not understandable how the issues with Siemens PLC’s seem to get ignored by Teltonika. These PLC’s are the most used brand in Europe and probably the rest of the world, Teltonika will really benefit from integrating them easily with their products!

Please help me out as quickly as possible, if I’m not able to fix the issue remotely I will have to travel to the customer tomorrow, which will cost me a whole day and will mess me up.

[michiel]

Hi,

Good question, difficult answer. I do not have an easy solution to you. Did you ask Siemens? I never have seen a solution from them, but maybe I missed it?

L2 vpn should work in theory: vpn tap, l2tp, vxlan. But I never tried. Getting profinet real-time traffic and multicast correct locally with (non-/) Siemens nw stuff is already ‘suprisingly’ complex? . The idea to get that wokring over a vpn just make me puke. Imho that dcp l2 config stuff is a mistake… But prove me wrong!

Easiest work around is to have a local ‘TIA station’ which you can connect to over a vpn by vnc/rdp.

Good luck.

[btecjoep]

Hello Michiel,

thank you for your response. Asking Siemens for support with their own products is already like squeezing water out of a stone. Asking Siemens for support with this will be more difficult than bringing humans to Mars I’m afraid. Since it’s clear what should work, I also don’t see any sense in contacting Siemens. Teltonika should provide info how to enable L2 broadcasts on TAP VPN’s, it’s not something that Siemens can tell us?

I must agree with you, this whole search stuff in TIA is a great way of making things difficult, but I’m afraid we can’t get around it, Siemens does its own way even if they know it’s the wrong way.

A local TIA station is not an option, I will just have to go to the customer then. Usually, we only use the Teltonika VPN for support afterwards (and that works just fine), but in this case the cabinet was rushed out while I was busy working on another project, so all the devices are still totally empty.

Since I have the TAP VPN up and running already, it’s just the question: why are the L2 broadcasts not coming through? Teltonika is the only company that has the background information on their platform to help us further… They actually said on the phone that there should be solution, they just need to tell us about it (which they didn’t on other similar topics, so I’m really curious, hoping for the best, but anticipating on not getting a solution either…).

PS: are you dutch as well Michiel? Your name sounds dutch at least…

[michiel]

In that case I suggest to get a openvpn, l2tp or vxlan solution running locally first with plenty of bandwidth. If you succeed, implementing it with Teltonika’s is easy.

Indeed the L2 broad/multicasts is main the issue here. And that can of L2 worms called profinet. Ask yourself the question what happens if your L2 bc/mc traffic exceeds your L3 bandwidth/latency. Right, blocking, timeouts etc. Do you think you get real-time traffic over you high latency link? So you need to choos between which L2 traffic you block and which not to prevent saturation of your link… good luck with that and hence the suggestion to try locally first.

In my experience it is best to do profinet config locally. Once setup the rest is easy to do remotely. Any config changes need to be done locally. Now that you know, plan for that.

But prove me wrong and do not expect tt get you an answer.

doei!

[Laura]

Hello, @btecjoep!

Thank you for your post.

As mentioned, here is the workaround we hope will work for your case. Please follow these instructions to set it up:

RMS VPN Tap mode.zip (516.3 KB)

This 2-layer RMS TAP setup will allow a broadcast through DCP.

Additionally, you will also need to set up a VLAN 0 as well, so the TIA portal can communicate with the PLC device.
OpenWRT supports setting VLAN 0 on devices; the only limitation is that only untagged VLANs can be used with VLAN 0.
Basically, the only thing that needs to be done is to update the switch_vlan and br_lan sections:

config device ‘br_lan’
option name ‘br-lan’
option type ‘bridge’
list ports ‘eth0.0’

config switch_vlan
option device ‘switch0’
option vlan ‘0’
option vid ‘0’
option ports ‘1 6t’

Kind regards,
Laura

[btecjoep]

Hello Laura, Michiel,

Thank you for your responses.

I see what you mean Michiel, making the VPN fully layer 2 transparent will mean to pass all the other Profinet messages trough the VPN. Of course this is not needed, intended nor desired. I will for now just try to have it that way temporarily, until I managed to assign all the IP’s. For now I will just leave the PLC in stop state until I can revert to the TUN VPN as usual. For this installation, there is only one profinet device, so I may still get away with it.

Laura, your PDF shows what I found already, but adding ‘tap+’ to the LAN bridge seems wrong, since the GUI already added ‘tap_c_YcrzgX2’ or is + a wildcard character?
In the webbased GUI I can assign the bridge when I enable parsing on the VPN configuration, that seems to work.
I now also get what you mean by altering the IP adresses. For now, I will stick to the range that the VPN hub assigns, but you should definitely fix this, so that the DHCP server from the device is used on VPN clients! It makes no sense having a separate DHCP server on a TAP VPN.

I also can’t connect to the CLI through the routers web interface, but I can do so by SSH or by using the RMS function, so that’s not much of an issue.

For the VLAN: I already have two switch_vlan sections, I think this is for the WAN/LAN separation?
Right now I have this:

config switch
option name ‘switch0’
option reset ‘1’
option enable_vlan ‘1’

config switch_vlan
option device ‘switch0’
option vlan ‘1’
option vid ‘1’
option ports ‘1 6t’

config switch_vlan
option device ‘switch0’
option vlan ‘2’
option vid ‘2’
option ports ‘0 6t’

Does this mean I will have to change the first vlan and vid to 0 only?

When I issue the command /etc/init.d/network restart, I always get the message: Command failed: Not found, but I did not find any clues in any of the logs yet.

Trying all of this, I’m still not successful “finding” my devices with the Siemens software, so I’m quite certain I will be having a road trip tomorrow…

Regards,
Joep

[mesrik]

Hello all,

Just a quick thing I found bit looking around Google search & it’s AI mode.

But first, I’ve never directly worked with these DCP talking things, so I’m not going to be able help you too much. But while searching I came across following python3 package

Client Challenge

" PROFI-DCP
A simple Python library to send and receive messages with the Profinet Discovery and basic Configuration Protocol (DCP) protocol. It can send requests and parse the corresponding responses to identify devices over the network, get and set their parameters or reset them to factory settings. Documentation can be found here and in the examples directory.

This is a fork from pnio_dcp.
"
… etc.

(Some links in that packace page left column seems to require logins etc. Links in description work for me better)

There is a some kind of cli tool included, which is very rudimentary (unhelpful), but package library could be possibly be a starting point for someone willing to try writing tool they perhaps can use.

And sure, if you decide to take stab, help yourselves with some decent AI it can speed things considerably. The Google search engine AI mode works quite well and doesn’t cost anything but your time with it. Just remember, guide and direct it with proper prompts, telling first what you are about to try doing. What are constrains, ie. environment where script is about to run (Teltonika xxx device, OS version yyyy), language you are using and its version (python -V in this case). Start small, first test something simple, then expand bit by bit until you get what you need. Just for a record, I have recently written with it python scripts which are few hundred lines long and already quite complex to write from scratch. I’d estimate that it cut my time writing it under 1/10’th of the time I would have had to write it all by myself alone.

Now that’s about all I can say this now, but remember I’ve not worked with Siemens PLC’s directly and I did not verify that the python module is well written and all around fine. It could be or not. This is just a something like if I were in situation where I need what OP asked I would at some point try. And I wouldn’t definitely not try developing that script directly in Teltonika router, I would set up possibly Raspberry Pi in lab first, write that script there first. Then when I get it working, I would study more how to port it to Teltonika router first myself and when that is working I would likely contact Teltonika if they were interested adding that python module to be installable with WebUI & opkg. and if they have interest to the script which I wrote and would share with others. Unless my contractual issues would prevent that any code I write is owned by not me but my employer or contracting party. I’ve been in that situation (not fun), but later I did share some ideas and hints which let others accomplish same what I did with management approval too.

OK, so this became again quite long and bit of a rant. Apologies for that and bear with me, I rather not just write short few lines comments which lead guessing what actually I was trying to convey.

Cheers,

riku

ps. So this was not attempt to give short advise how to get this issue solved quickly just now, but a something for someone having time to delve in.

[btecjoep]

Hello Riku,

thank you for your input, while it is really interesting, it will cost me a lot more time than driving along the customer, even if it’s a 2,5 hour single way.
I’ve learned my lesson for now and will never ever ship a cabinet again without at least some basic configuration loaded, when I’m not sure I will visit the installation site in person.

It would be really cool though if Teltonika picked this up and could add it to their package library. I think there is a huge industrial market waiting for Teltonika to provide an easy and cost efficient solution for Siemens PLC’s remote access.

Regards,
Joep

[mesrik]

@btecjoep

… cost me a lot more time than driving along the customer, even if it’s a 2,5 hour single way.

Very much so, I have had same thing long time ago. Even branch office telco guys were always helpful and mostly available, but anything more complicated would require getting there myself. Later in other kind non telco world I usually built separate remote access console system, which I could then reach any devices which I had to. Past 10 years Raspberry Pi’s and now already not any more available PC-Engines APU’s (industrial pc) were quite handy platform to make such device that regard in my work. Just slab USB-serial adapter or whatever needs there and off you go, can make fixing almost all issues remotely

Building things first local “Staging lab”, before shipping to remote sites very much the best practise whenever possible, even then it’s more work, usually more costs, etc. But also brings more control securing better outcome remote install without major issues.

[Laura]

Hello!

Thank you for your response, and our apologies for the late response.

Regarding the step you mentioned within the PDF, it is slightly outdated and does not need to be done. All you need to do instead is enable parsing, and the bridge is created automatically.

Regarding the IP addresses, if you do not wish to change the RUT LAN network to be the same as the VPN tunnel, you can enable a static IP on the VPN client - this is shown on the last page of the PDF.

Additionally, the VLAN IDs in your case should also be adjusted.

From:
config switch_vlan
option device ‘switch0’
option vlan ‘1’
option vid ‘1’
option ports ‘1 6t’

To:
config switch_vlan
option device ‘switch0’
option vlan ‘0’
option vid ‘0’
option ports ‘1 6t’

The configuration of the br_lan interface should also look like this instead:

config device ‘br_lan’
option name ‘br-lan’
option type ‘bridge’
list ports ‘eth0.0’

And lastly, /etc/init.d/network restart may show an error, but the network should restart nonetheless.

Let us know if you have any additional questions.

Kind regards,
Laura.