Unified Automation Forum

I am experiencing problems accessing OPC UA Server (.NET SDK based one) behind NAT or UTM's.
Server/Client implementation is not really bidirectional, as Server is providing services which
client consumes; so server should be on system which will be monitored,etc...
Here come problem with accessing it form outside world, I have no access to router\utm
to forward port, define DMZ. TO set-up communication client(outside world) has to connect to server(inside factory)...
but how to address it (apart form the fact that eth Class C -isn't) ??
I'm not talking about DCOM/COM problem -it's about current .NET Server/Client SDK.
I'm able to solve the problem with ssh, telnet..
any help/advice ??

Hi,

A NAT should be no problem.

There is mainly one detail you must take care about. The server certificate contains the host name or IP-Address of the server. This is used by the client to verify the URL used to connect to the server with the information in the certificate.

You must either put the outside name (outside the NAT) into the server certificate or you must turn off the host name check on the client side.

Best Regards,
Unified Automation Support Team

Hi, thx 4 answ,
, how then connect from client to server which is behind NAT
if the connection has to be initialised by client -client is in cloud/public IP
and the server is on machine ...somewhere inside customer LAN

??

Hi

The answer did not include any basic TCP/IP clarifications. It only covered what you must take care about for OPC UA if talking through a NAT.

For OPC UA Client/Server communication using the default protocol UA TCP / UA Secure Conversation / UA Binary, the server listens on a port / IP Address and the client creates a TCP/IP connection to the server.

If you use a NAT, you must configure port forwarding to your internal IP-Address / Port. This limits the number of available servers. What you can do is to run an aggregating OPC UA server (UaGateway can do this) in a DMZ. You can make this server available on a public IP or through port forwarding in the NAT. For this server in the DMZ you can configure the aggregated server in the private network.

If you are not able to configure the NAT or setup a server in the DMZ, the only option with currently available OPC UA features is to create a SSH tunnel or a VPN network.

The OPC UA working group is working on additional options for such scenarios for the next specification release.

One option is an inverse connect. In this case the server creates the connection to a well-known client. But then the client needs a reachable (public) IP Address. This option works only if one of the two communication partners is behind a firewall. This will be a simple extension to the existing protocol.

The second option is communication through a relay. In this case, client and server can be behind a firewall / NAT, only the relay must be available through a public IP Address. Clients and servers create TCP/IP connections to the relay and then logical OPC UA connections between client and server through the relay. The protocol between client and server will still be UA Secure Conversation / UA Binary. Only the transport part will be relay specific. Therefore we can still ensure end to end security defined by OPC UA. The relay protocol that is currently in prototyping is AMQP since the OPC UA working group does not invent its own relay protocol since it should be possible to use available relays / message brokers.

Best Regards,
Unified Automation Support Team

One option is an inverse connect. In this case the server creates the connection to a well-known client. But then the client needs a reachable (public) IP Address. This option works only if one of the two communication partners is behind a firewall. This will be a simple extension to the existing protocol.

Hi!

Can you clarify this option - what component establish this inverse connection (from server to client)?
This is existing SDK feature or must be done externally?

Hi,

This is a feature that is currently under definition in the OPC UA working group.

In the case of an inverse connect, the client opens a listen port and waits for the connection attempt from the server. The server tries to create a TCP/IP connection to the known client. If the TCP/IP connection is established from server to client, the rest of the connection establishment (SecureChannel, Session and Subscription) is created by the client.

Best Regards,
Unified Automation Support Team

Hi,

I am experiencing the same Problem, I am interested if there is a solution now or it is still under difinition in the OPC UA working group .
and if it must be implemented, how would you estimate the difficulty of developing such extension to enable a reverse connection between client and server?

thanks

The definition of the reverse connect feature is completed in the current OPC UA draft specification for OPC UA 1.04.
We have implemented a prototype to verify the functionality.

We are now waiting for the specification release to be able to integrate this feature in future SDK releases.
The specification release is expected for mid 2017.