During our development I've been running a V5.19 Kepware Server with UA access. This has been working fine until our Server machine (Windows 7) suddenly restarted. Now none of our applications can connect via UA - BadRequestTimeout error is returned. DA access is OK, it's just the UA clients that cannot connect.
I've done the usual Google and no useful information is returned other than telling me what the numerical value of the error code is, which I already knew.
The UA configuration of the server looks fine - i.e. it hasn't changed. None of the clients have changed.
Can someone please shed some light on this?
Thanks
Steve
The Server's UA Configuration had Trusted Server and Trusted Client entries (both of which were unnecessary).
I removed both of these and suddenly UA connections were allowed.
Not sure why removing these made any difference - these had been in place for a long time, when the server was initially installed.
Related
Has anyone seen anything on Windows Server 2019 that would prevent browsing the network in a Active Directory domain environment to find available OPC servers on remote hosts when all other OPC communications seem to be functioning normally and file share browsing seems to also be functioning?
There is something I'm missing here, but I cannot find it. Since the core OPC functions are working, tools like OPC Expert are not showing any errors and guides for DCOM settings from OSIsoft, KEPware, and OSI Institute are all being used to no avail. None of the DCOM settings seem to be addressing the CLSID network browsing. If a client has the ability to supply a remote host and query that host, the OPC services enumeration works just fine. The problem is that we are attempting to use clients that do not have any features to manually define the servers and solely relies on the network browsing functions.
Please tell me someone else has seen this behavior. I suspect that it is some network security feature of Windows Server 2019, but I can't find any documentation that points to what might be causing this function to fail. Worse, the function is completing normally, but with zero results, so I don't even have error messages to track the issue down with.
It really depends on the application you are using. There are many ways for an OPC Client to find the remote OPC Server. Most clients will use a combination of the folowing:
OPCEnum. In particular the heavy lifting is done using EnumClassesOfCategories which is part of Component categories Manager. Does not crawl through registry.
GetOPCServers(). This is a method is available as part of an interface called IOPCAutoServer which comes from the OPC foundation itself (via OPCDAAuto.dll)
CLSIDFromProgID() first to get the CLSID and then does the CoCreateInstanceEx().
When CLSIDFromProgID() fails, it falls back to using OPCEnum to list all OPC servers before making a connection.
That means that you would first need to find out what your client application is using to list the OPC Servers.
Then, on the Windows Security side of things, depending on the OS version of both nodes, you may need to disable Simple File Sharing mode (that is the case for Windows XP and older)
If it uses OPCEnum, you will need to configure DCOM for OPCEnum as well, which is the recommended method to list remote OPC Servers.
If the application only supports remote registry lookup to find the OPC Server, then you will need to grant access to the account connecting from the client to the Server
I have an Ubuntu VM installed on a client's VMware system. Recently, the client's IT informed us that his firewall has been detecting consistent potential port scans to our VM's internal IP address (coming from 87.238.57.227). He asked if this was part of a known package update process on our VM.
He sent us a firewall output where we can see several instances of the port scan, but there are also instances of our Ubuntu VM trying to communicate back to the external server on port 37258 (this is dropped by the firewall).
Based on a google lookup, the hostname of the external IP address is "feris.postgresql.org", with the ASN pointing to a European company called Redpill-Linpro. As far as I can tell, they offer IT consulting services, specializing in open source software (like PostgreSQL, which is installed on our VM). I have never heard of them before though and have no idea why our VM would be communicating with them or vice-versa. I'm also not sure if I'm interpreting the IP lookup information correctly: https://ipinfo.io/87.238.57.227
I'm looking for a way to confirm or disprove that this is just our VM pinging for a standard postgres update. If that's the case I'd like to restrict this behaviour. We would prefer to do these types of updates manually and limit the communication outside of the VM to what is strictly necessary for the functionality of our application.
Update
I sent an email to Redpill's abuse account. They responded quickly saying that the server should not be port scanning anyone and if it appears that way, something is wrong.
The server is part of a cluster of machines that serves apt.postgresql.org among other postgres download sites. I don't think we have anything like ansible or puppet installed that would automatically check for updates but I will look into that to make sure. I'm wondering if Ubuntu reaching out to update the MOTD with the number of available packages would explain why our VM is trying to reach out to the external postgres server?
The abuse rep said in any case there should only be outgoing connections from the VM, not incoming. He asked for some additional info so I will keep communicating with him and try to update this post accordingly
My communication with the client's IT dropped off so I did not get a definitive answer on this, but I'll provide some new details:
I reached out to the abuse email for Redpill-Linpro. He got back to me and confirmed the server corresponding to the detected IP address is part of a cluster that hosts postgres download sites, including apt.postgresql.org. He was surprised to learn we had detected a port scan from their server and seems eager to figure out why that is happening.
He asked if the client IT could pass along some necessary info for them to set up tracking on that server. But the client IT never got back to me. I think he was satisfied that it wasn't malicious and stopped pursuing it.
Here's one of the messages the abuse rep sent me that may be relevant:
That does look a lot like the tcp to the apt download server yes. It's
strange that your firewall reports that many incoming connections, but
they could be fallout from some connection tracking that's not
operating as intended. The timing appears to be matching up more or
less perfectly. And there should definitely not be any ping-back
connections from it.
Since you appear to be using the http version of the server (and not https) bringing the data in cleartext, they should be able to just
dump the TCP connection contents and verify exactly what it does. But
I bet they are going to see a number of http requests initiated by the
apt client that is checking for updates.
Given these 2 installations:
A machine with 3 OPC UA servers.
A machine with 3 OPC UA servers and a LDS.
What is the difference in functionality? In particular, I would like to know:
Is the installation of a LDS mandatory?
What is the practical difference between discovering a server, then connecting to it, and directly connecting to the endpoint of the server without discovery?
What does installing an LDS enable to do?
(All this, with proper OPC UA specification references where applicable, please)
Is the installation of a LDS mandatory?
No, the installation of an LDS is purely optional. Especially on small / embedded devices you might not even be able to install anything else than the OPC UA server.
What is the practical difference between discovering a server, then connecting to it, and directly connecting to the endpoint of the server without discovery?
With the LDS running on a standarized port (4840) it is possible to discover all servers on the computer without knowing their endpoint URLs. Without an
LDS there is no way to connect to a server without knowing the URL.
As already commented, having the LDS makes discovery (very) slightly slower, as a connection to both LDS and server has to be established.
If only one server is running on the computer one might want to set the port of this server to 4840, so clients discovering on the computer find the server without needing to know a custom port.
What does installing an LDS enable to do?
It simply allows to discover all servers running on the computer without knowing all their different endpoint URLs.
Future versions will contain enhancements, broadcasting this information via Zeroconf, so every LDS would have the list of all OPC UA servers on the local network.
We can't get our PLC to reliably connect with KEPServerEX (OPC).
I was wondering if anyone else here at SOF has experience working with PLC and OPC. If so do they have any tips on making a reliable connection with our OPC Server. We currently use KEPServerEX for our OPC, but if anyone knows a better program to use we are open to suggestions.
I use Kepware OPC server for MODBUS TCP, Simatic S7 and Yokogawa for more then 5 years on 4 servers in industrial environment without any problems. It was easy to set up and showed no problems during exploatation. Actually, it was so nice that we decided to not use it only when it doesn't support the device we have (which is rare, and mostly happens when I have to develop custom OPC server). Kepware OPC server is even able to use reserved PG connection for connection to Siemens PLCs (unlike Simatic OPC Server, this is good if you have limited number of connections like in CP343 LEAN version communication module). It will also save you $$$$$ if you use data from it in some historian like OsiSoft PI which charges per OPC server connections, since all Kepware OPC servers will show as single OPC server to Osisoft PI. The only thing that made me angry was that after some trial time it stopped without warning all servers (including licenced ones) when I was evaluating one new OPC server I was supposed to try out. Have you tried Kepware technical support? Have you checked your cabling? Are you aware that trial version will stop after some time?
As an alternative you can try Matrikon OPC servers. They are also very good and run without problems.
Recently we got a new server at the office purely for testing purposes. It is set up so that we can access it from any computer.
However today our ip got blocked from one of our other sites saying that our ip has been suspected of having a virus that sends spam emails. we learned this from the cbl http://cbl.abuseat.org/
So of course we turned the server off to stop this. The problem is the server must be on to continue developing our application and to access the database that is installed on it. Our normal admin is on vacation and is unreachable, and the rest of us are idiots(me included) in this area.
We believe that the best solution is to remove it from connecting to the internet but still access it on the lan. If that is a valid solution how would this be done or is there a better way? say blocking specified ports or whatever.
I assume that this server is behind a router? You should be able to block WAN connections to the server on the router and still leave it open to accepting LAN connection. Or you could restrict the IPs that can connect to the server to the development machines on the network.