Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
OPC UA Client connection Problem by using of NAT (GetEndpointsRequest, GetEndpointResponse)
March 23, 2021
12:35, EET
Avatar
Oleksandr
Member
Members
Forum Posts: 31
Member Since:
February 14, 2020
sp_UserOfflineSmall Offline

Hi,
We have an OPC UA client application that was developed with the Prosys Java SDK 4.0.2-808. Our customer uses a NAT switch in the workshop. This leads to the problem that no communication from the OPC UA client to the Siemens PLC is possible.

Example from Siemens:
The OPC UA client sends a “GetEndpointsRequest” with the destination IP address (DNAT) 240.19.17.56.
The NAT router changes the destination IP of the packet to 192.168.1.2 in order to route the packet to the OPC UA server.
The OPC UA server generates a “GetEndpointResponse” that includes its own IP address (192.168.1.2) among other things and sends the message back to the client via the NAT router. For the client to be able to assign the message, the router has to change the source IP address (SNAT) of the packet to 240.19.17.56.
The client starts to establish a connection (“OpenSecureChannel”) to the IP address that is in the “GetEndpointResponse” of the server.
The IP address of the response message cannot be reached directly from the client. The result is that the connection cannot be established.

https://support.industry.siemens.com/cs/document/109766709/what-are-the-causes-when-connection-to-an-opc-ua-server-fails-?dti=0&lc=en-AO

The possible sollution from Siemens are to replace the IP address of the “GetEndpointResponse” with the IP address of the “GetEndpointRequest”. Can we configer this at the Prosys Java SDK 4.0.2-808 for the OPC UA client application?

Best regards
Oleksandr

March 23, 2021
13:54, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 983
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

Hi,

Is that example related to our SDK, or in general?

Could you show a stacktrace or a Statuscode when the error happens?

In general, it is sort of a known issue that there might be troubles if there is a NAT, though, for this purpose UaClient will use the original connection address, thus this should not be a problem. Though not ruling out bugs or edge-cases. Does the port number change (not sure would it matter, but I sort of recall that it might have been a problem in the past, though not sure why if we just use the original address anyway)?

Anyway, it is not a good idea to “just replace the IP”. The original EndpointUrl would have to be retained. This is because it must appear as-is as part of the Hello opc.tcp message (https://reference.opcfoundation.org/v104/Core/docs/Part6/7.1.2/#7.1.2.3). Failing to give the server the original url would most likely fail with Bad_TcpEndpointUrlInvalid, unless the server is aware of every possible NAT etc. connection address to itself (I think that is how it is worded in the specification sort of, but there is also some parts that say that client should be able to deal with the problem). Though, then it would also know to give us back the correct variation of the EndpointDescriptions in the first place.

Thus what would happen in most of the cases is that we will open the socket to the original address, and send the EndpointUrl that was received as part of the Hello. If that doesn’t happen, then I would say it is a bug. Or I might have misunderstood how you use the SDK. If you for some reason have used the low-lvl “stack layer” APis (e.g. com.prosysopc.ua.stack.application.Client), then it would be sort of mis-using the SDK as those should nowadays be considered as internal and only some variations of their overloads will result in the orginal address being used.

March 29, 2021
10:24, EEST
Avatar
Oleksandr
Member
Members
Forum Posts: 31
Member Since:
February 14, 2020
sp_UserOfflineSmall Offline

Hi,
thanks for your quick reply.

It is example related in general, not to my SDK.
I saved communication with Wireshark:
709 8.888892 10.63.36.133 10.63.58.221 OpcUa 113 Hello message
712 8.899553 10.63.58.221 10.63.36.133 OpcUa 82 Acknowledge message
715 8.908386 10.63.36.133 10.63.58.221 OpcUa 186 OpenSecureChannel message: OpenSecureChannelRequest
716 8.911028 10.63.58.221 10.63.36.133 OpcUa 190 OpenSecureChannel message: OpenSecureChannelResponse
717 8.919509 10.63.36.133 10.63.58.221 OpcUa 288 UA Secure Conversation Message: GetEndpointsRequest
727 8.924553 10.63.58.221 10.63.36.133 OpcUa 1416 UA Secure Conversation Message: GetEndpointsResponse
728 8.926770 10.63.36.133 10.63.58.221 OpcUa 111 CloseSecureChannel message: CloseSecureChannelRequest
735 8.936085 10.63.36.133 10.63.58.221 OpcUa 113 Hello message
737 8.959465 10.63.58.221 10.63.36.133 OpcUa 82 Acknowledge message
738 8.960444 10.63.36.133 10.63.58.221 OpcUa 186 OpenSecureChannel message: OpenSecureChannelRequest
740 8.971438 10.63.58.221 10.63.36.133 OpcUa 190 OpenSecureChannel message: OpenSecureChannelResponse
741 8.973563 10.63.36.133 10.63.58.221 OpcUa 404 UA Secure Conversation Message: CreateSessionRequest
747 8.991710 10.63.58.221 10.63.36.133 OpcUa 661 UA Secure Conversation Message: CreateSessionResponse
749 8.995856 10.63.36.133 10.63.58.221 OpcUa 111 CloseSecureChannel message: CloseSecureChannelRequest

I noticed the following:

The server GetEndpointsResponse with 6: EndpointDescription in the tree EndpointUrl: opc.tcp://192.168.10.1:4842 and DiscoveryUrls: opc.tcp://192.168.7.10:4842 but thea are different.
Can it be the cause of the failure?

Frame 727: 1416 bytes on wire (11328 bits), 1416 bytes captured (11328 bits) on interface \Device\NPF_{E1E9E174-F013-47D2-A7DB-C099E913AA84}, id 0
Ethernet II, Src: CheckPoi_3e:20:85 (00:1c:7f:3e:20:85), Dst: VMware_95:5e:98 (00:50:56:95:5e:98)
Internet Protocol Version 4, Src: 10.63.58.221, Dst: 10.63.36.133
Transmission Control Protocol, Src Port: 4842, Dst Port: 49683, Seq: 8925, Ack: 426, Len: 1362
[7 Reassembled TCP Segments (10122 bytes): #718(1460), #719(1460), #721(1460), #722(1460), #724(1460), #725(1460), #727(1362)]
OpcUa Binary Protocol
Message Type: MSG
Chunk Type: F
Message Size: 10122
SecureChannelId: 1094961932
Security Token Id: 1
Security Sequence Number: 52
Security RequestId: 2
OpcUa Service : Encodeable Object
TypeId : ExpandedNodeId
NodeId EncodingMask: Four byte encoded Numeric (0x01)
NodeId Namespace Index: 0
NodeId Identifier Numeric: GetEndpointsResponse (431)
GetEndpointsResponse
ResponseHeader: ResponseHeader
Endpoints: Array of EndpointDescription
ArraySize: 6
[0]: EndpointDescription
EndpointUrl: opc.tcp://192.168.7.10:4842
Server: ApplicationDescription
ApplicationUri: urn:192.168.7.10:OPC-UA Embedded Server
ProductUri: OPC-UA Embedded Server
ApplicationName: LocalizedText
ApplicationType: ClientAndServer (0x00000002)
GatewayServerUri: [OpcUa Null String]
DiscoveryProfileUri: [OpcUa Null String]
DiscoveryUrls: Array of String
ArraySize: 1
[0]: DiscoveryUrls: opc.tcp://192.168.7.10:4842
ServerCertificate: 308204fc308203e4a00302010202045f6c89ac300d06092a864886f70d01010505003074…
MessageSecurityMode: None (0x00000001)
SecurityPolicyUri: http://opcfoundation.org/UA/SecurityPolicy#None
UserIdentityTokens: Array of UserTokenPolicy
TransportProfileUri: http://opcfoundation.org/UA-Profile/Transport/uatcp-uasc-uabinary
SecurityLevel: 0
[1]: EndpointDescription
[2]: EndpointDescription
[3]: EndpointDescription
ConfusedEndpointUrl: opc.tcp://192.168.10.1:4842
Server: ApplicationDescription
ApplicationUri: urn:192.168.7.10:OPC-UA Embedded Server
ProductUri: OPC-UA Embedded Server
ApplicationName: LocalizedText
ApplicationType: ClientAndServer (0x00000002)
GatewayServerUri: [OpcUa Null String]
DiscoveryProfileUri: [OpcUa Null String]
DiscoveryUrls: Array of String
ArraySize: 1
Confused [0]: DiscoveryUrls: opc.tcp://192.168.7.10:4842
ServerCertificate: 308204fc308203e4a00302010202045f6c89ac300d06092a864886f70d01010505003074…
MessageSecurityMode: None (0x00000001)
SecurityPolicyUri: http://opcfoundation.org/UA/SecurityPolicy#None
UserIdentityTokens: Array of UserTokenPolicy
TransportProfileUri: http://opcfoundation.org/UA-Profile/Transport/uatcp-uasc-uabinary
SecurityLevel: 0
[4]: EndpointDescription
[5]: EndpointDescription

Best regards,
Oleksandr

March 29, 2021
14:30, EEST
Avatar
Matti Siponen
Moderator
Members

Moderators
Forum Posts: 321
Member Since:
February 11, 2020
sp_UserOfflineSmall Offline

Hello,

Could you send your WireShark capture to uajava-support@prosysopc.com so that we could take a closer look at it? In addition, could you send logs from your Client application?

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 518

Currently Online:
15 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

hbrackel: 135

pramanj: 86

Francesco Zambon: 81

rocket science: 77

ibrahim: 75

Sabari: 62

kapsl: 57

gjevremovic: 49

Xavier: 43

fred: 41

Member Stats:

Guest Posters: 0

Members: 677

Moderators: 16

Admins: 1

Forum Stats:

Groups: 3

Forums: 15

Topics: 1467

Posts: 6259

Newest Members:

DonaldPooma, fidelduke938316, Jan-Pfizer, DavidROunc, fen.pang@woodside.com, aytule, rashadbrownrigg, christi10l, ahamad1

Moderators: 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: 321, Lusetti: 0, Ari-Pekka Soikkeli: 5

Administrators: admin: 1