Directory Server and LF Server on different Subnet

asked on October 4, 2018

Hi,

I have a Laserfiche 10.3 installation where we have three LF servers. Unfortunately two of them are on the same subnet with the Directory server but the third one is on a different subnet. The server on the different subnet is not able to be registered on the Directory server. It registers on installation but when you run the lookup in DS it posts an error that in cannot contact the LF server. The LF server is now not able to run because the license is stale.

We checked all the ports that are required to be opened and they are all open. On further investigation by the Network team, they traced the communiction between the concerned LF server and the DS server and we noticed that it uses the port number 49669 and after opening it the server was able to communicate to the DS. Unfortunately after some time we found that the port changed to another port meaning that the port changes. Would someone explain how I can solve this issue or are there additional ports that need to be opened in the case of differing subnets?

Regards,

Mark

0 0

replied on October 4, 2018 • Show version history

Are you filtering outbound ports or established traffic with your firewall? Typically the client side of a connection will grab a random port (usually a high number) and try to contact the host application on a known listening port. Most firewalls are configured to block incoming requests, but they do not block outbound or established connections.

So to walk through a typical scenario, LF Server starts up and attempts to validate against LFDS. It will grab a random, unused port (usually above 40000) and attempt to contact LFDS on the known listening port of 5048. A typical firewall, not blocking any outbound traffic, will allow this to leave the LF Server and attempt to route it to the LFDS server. At this point, the firewall will then check whether the inbound port 5048 is allowed for the LFDS server. If yes, the packet is delievered and if no, it is dropped. In the event that it is delivered, the LFDS server receives the message and sends a reply back. This reply is treated as established traffic, and so it is typically allowed through the firewall without any further rule checks (meaning that it does not need to check whether it is allowed outbound from the LFDS server on port 5048, and it does not need to check whether it is allowed inbound on whichever random port was chosen by LF Server when it started up).

So without knowing any real details about your network, it sounds like you either have some outbound rules, or a problem with applying rules to established traffic. Your networking folks should be able to dig deeper. So far as I know, there is no way to control the client-side port for most applications. I think the software would have to be specially designed for that.

0 0

View 3 previous replies

replied on October 4, 2018

Besides ports 5048,5049 & 5051 between servers all traffic/ports inbound and outbound are restricted.

Yes we would be filtering outbound ports or established traffic. We need to know how and on which ports is the communication is established between the LFDS server and other servers

Mark

0 0

replied on October 4, 2018

As I said, I don't think there is anything you can do to configure which port the client side application is using (in this case LF Server is acting as a client to LFDS). The only workaround is that your network team would have to make more permissive rules. You can still make it restrictive in other ways by making the rule specific to your a particular machine, interface, application, etc... It's not so much a Laserfiche issue at this point, but a networking/firewall issue. Sorry if that's not the answer you were hoping for!

I'm actually a little surprised you haven't run into trouble with other applications because this kind of behavior is really common for outbound ports from client applications.

0 0

replied on October 4, 2018

Hi Scot,

thanks for the explanation of the port communications in the scenario above from the LF server to the LFDS. Would you be kind enough to explain how the communication works when I initiate a lookup from the LFDS to the LF server?

Mark

0 0

replied on October 5, 2018

You're asking about when doing a hardware fingerprint lookup to add an application?

LF doesn't give much information out about this process. From what I have been able to piece together, LFDS acts as the client in this case and makes a Remote Procedure Call to port 135 of the target machine. There is some correspondence, and then the LFDS server attempts to connect to the target machine using Winmgmt/WMI. On the target machine WMI uses a dynamic listening port, and that the initial traffic on 135 helps the LFDS server figure out what this dynamic listening port is.

I would think this is more challenging to allow through your firewall, especially since you want it to be so locked down... I'd highly recommend just running showhwfp on the target machine, then entering that value manually in LFDS.

0 0

replied on October 5, 2018

Scott, the LFS still needs to talk to the LFDS or the license becomes stale, so they need to create the conduit/tunnel between the servers.

0 0

replied on October 5, 2018

Sure, that's covered in the lengthy answer above about 5048... I was just talking about how I wouldn't bother trying to get HWFP lookups to work if they're trying to keep the firewall tight.

0 0

Question

Question

Directory Server and LF Server on different Subnet

Replies

Sign in to reply to this post.