Log In
Register
Forum
Topic RSS
11:42, EET
September 21, 2018
Offline
Hi
We try to connect the opc ua server via a VPN tunnel.
The port number for this connection is dynamically assigned and forwarded to the correct port of the server via “port forwarding”.
Since port forwarding does not affect the url endpoint, no connection can be established.
Is there a solution for this problem?
Best regards,
Manfred
13:37, EET
April 3, 2012
Offline
Hi,
Since it is a VPN, cannot the client just use the internal address of the server? Or am I missing something here? (my knowledge of VPNs is somewhat limited).
Anyway, is the client making the connection done as well with our SDK, or something different?
If yes: I think in the distant past we had this problem, but in anything modern SDK versions it should basically “just work” (you can e.g. try with https://www.prosysopc.com/products/opc-ua-browser/), because the UaClient basically ignores the endpointUrl and uses the original connection address (given in the constructor) in this case. If it doesn’t I would consider that as a bug (but I did a quick test for this and it would seem to just work)
In practice our opinion has been that the endpointUrl is not suitable as a “connection address”, only sort of an URN (i.e. marker) for the endpoint specifically for these cases. Though, there is some wording in the spec that the server should “magically know” it it would be accessed via a NAT and include those endpoints. But there should also be at somewhere that basically the clients must be prepared to “rewrite” the endpointurls in some cases. At least nowadays there is, https://reference.opcfoundation.org/GDS/v105/docs/A.1
“Note that Servers may not be aware of all HostNames which can be used to access the Server (i.e. a NAT firewall) so Clients need to handle the case where the URL used to access the Server is different…”
While the hostname is different from the port, I would say about the same thing applies.
So, if it wasn’t done with our SDK it is something the client manufacturer should fix. The only other option would be to ensure the port doesn’t change in the forwarding, but that might not be an option here (as I think in this case it would limit it to 1 connection if all get unique port).
P.S.
Also in some cases it is possible to use Reverse Connections, where the client opens the port and the server initiates the connection. The SDK does support that and you can test with https://www.prosysopc.com/products/opc-ua-browser/ and https://www.prosysopc.com/products/opc-ua-simulation-server/.
16:16, EET
September 21, 2018
Offline
Hi Bjarne,
Thank you very much for the quick reply.
Yes, we are using the Prosys stack (OPC UA SDK for Java) for client and server.
Here our topology: [UA client] –> [VPN server] –> [UA server on a machine (at port 4840)]
The VPN server manages all open connections (tunnels) to machines.
For every machine the VPN server assigns a port number.
So, a client connects to the machine via IP of VPN server and port assigned to the machine.
Via port forwading (NAT) the IP and port is mapped to the IP of the machine and the port 4840.
The UaClient takes the endpoint url as an argument:
e.g. UaClient client = new UaClient(“opc.tcp://172.18.31.63:30000/OPCUA/SampleServer”);
Where 172.18.31.63 is the IP of the VPN server and 30000 is the port assigned to the machine.
Via port forwarding the VPN server maps IP and port to the IP of the machine and port 4840.
We observe that a connection on tcp level is established but not on application level.
Port forwading affects on tcp level the IP and port number but not the original endpoint url.
Which is not a problem as long as the original url is not sent to and checked by the UA server.
BTW: For our test we used UaExpert as a client.
Best regards,
Manfred
7:47, EEST
April 3, 2012
Offline
Hmm.. odd. Maybe I missed something, I think we’ll have to continue via email.
EDIT: Yes, I did: this might actually be a server-side SDK issue, in my quick test I didn’t use our SDK for the server (probably should have tested also this).
10:52, EEST
April 4, 2023
Offline
Hi,
I believe we’ve also encountered similar issue. Server developed using the Prosys SDK. There are no problems when connecting from within the same network, but come up when using a proxy, or SSH tunnel. It seems to be that the server handles fallback and accepts connection if the host in Endpoint url mismatches, but fails to do so if port is different.
F.e.:
opc.tcp://localhost:8080/Path -> ssh tunnel -> server:8080 – works
opc.tcp://localhost:8081/Path -> ssh tunnel -> server:8080 – doesn’t work
A workaround we’ve found was defining additional endpoint urls with required ports. So, in this example, defining another endpoint with port 8081 helps even if it’s not actually used for communication and connection can be estabilished. This however has downsides as server tries to bind to additional ports, which is problematic because on the target environment the port we’d have to add for the proxy to work clashes with another service. Any way to work around this without configuration changes?
Best regards,
M
14:06, EEST
Moderators
February 11, 2020
Offline
Hello,
We have a beta version of the SDK available that contains a fix to this port forwarding issue. Please contact uajava-support@prosysopc.com and let us know which edition of the SDK you’re using. We can then send you a download link to that edition so that you can test if the fix solves the issue in your environment.
Most Users Ever Online: 518
Currently Online:
22 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
hbrackel: 135
pramanj: 86
Francesco Zambon: 81
rocket science: 76
ibrahim: 75
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
fred: 41
Member Stats:
Guest Posters: 0
Members: 685
Moderators: 16
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1467
Posts: 6257
Newest Members:
Jan-Pfizer, DavidROunc, fen.pang@woodside.com, aytule, rashadbrownrigg, christi10l, ahamad1, Flores Frederick, ellenmoss, harriettschererModerators: Jouni Aro: 1009, Otso Palonen: 32, Tuomas Hiltunen: 5, Pyry: 1, Petri: 0, Bjarne Boström: 983, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Jimmy Ni: 26, Teppo Uimonen: 21, Markus Johansson: 42, Niklas Nurminen: 0, Matti Siponen: 320, Lusetti: 0, Ari-Pekka Soikkeli: 5
Administrators: admin: 1
