Jump to content

Recommended Posts

Posted

Pretty sure I've asked this before on here somewhere, but can't find it at the moment...

 

We have a user working from home that cannot access FMS due to a recent version update.

 

Although both SIMS/FMS work over the VPN, SOLUS just can't seem to contact the agent on the laptop and push the update to it.

 

Possibly due to a DNS issue with the laptop being on a VPN (different I.P. than the one SOLUS has in it's DB)?

 

I can see the laptop registered in DNS with the 'new' I.P. so I'm failing to see why SOLUS can't get it's head around it...

Posted (edited)

Thanks, might be a little further along...

 

The actual message now is:

 

SOLUS.jpg

 

Although not known for their ease of understandable error messages (usually being very cryptic) could it actually be the firewall?

 

I can't tell right now and don't know the answer, but does a VPN use a different connection type?

 

If so, I wonder if the SOLUS ports that we open might only be for DOMAIN network connections and PUBLIC/PRIVATE ones aren't included.

 

EDIT: Scratch that, I've just looked and those ports appear to be open in Public/Private firewall options too...

Edited by Koldov
Posted (edited)

ESS says "The following ports must be open on the firewalls of all devices in the deployment environment:

 TCP port 52965 (this port can be changed when installing the Deployment Service)

 TCP port 52966 (this port can be changed when installing the Deployment Service)

 TCP port 8739.

The following ports must be open on the firewalls of all devices in the Deployment Environment to enable browsing of the network (NetBios):

 TCP port 139

 UDP port 138

 UDP port 137."

 

can you ping the machine by computer name and can you browse to the c$ share on the computer from the SIMS server when it is on VPN?

Edited by Esteban_Child_of_the_Sun
  • Thanks 1
Posted

I've tried putting in all those ports on all 3 network profiles, on TCP & UDP.... the firewall has so many holes in now it looks like a sieve...

 

Then I even tried with the firewall completely off, still no luck so maybe not even firewall related and more to do with the VPN.

 

DNS might be the thing (it registers in Forward but not Reverse zones - I even manually added a PTR but no help) but I also think the VPN itself might an issue (Cisco)... I ping the laptop's 10.132. address and get a TTL expired in transit from a 172.30 address...

 

I found my old post from exactly 1 year ago... didn't manage to get it to work back then either!

Posted

Did you manage to connect to the c$ share based on the IP as mentioned above? I think you're going down the right avenue though. Solus will just go on whatever DNS it's pointed to unless you have something in the hosts file. Does the agent connect when the service starts and then drop offline after a few minutes? If yes, then it's working from client to server but just not the other way around. If you're not getting any initial connection then it's probably an issue in both directions.

 

Don't forget that you can manually update FMS to get the user up and running. Just export the update to a shared directory.

  • Thanks 1
Posted (edited)

Hi, thanks for the input!

 

I tried last night from home as trying to test VPN from inside the school network, out and back in again is going to cause some crazy NAT and skew the results apparently...

 

I cannot connect to c$ (from the SIMS server, through SOLUS - 'Open network path in explorer')... forgot to try via IP but I figure this should have worked if the connection from SOLUS to the client was good?

 

I can ping both ways by hostname and IP (so ruling out DNS?)...

 

I briefly turned off the firewall on both the server and the client and it made no difference (so probably ruling that out as well)...

 

Would the user on the client need admin rights to install the FMS update manually?

 

Anyway, last night I reached out to our ISP (LGfL) for support with the VPN and also to ESS for support with SOLUS to see if I can get enough information from their collective support to see how SOLUS works and if the VPN or our connection needs any extra configuration.

 

I received a reply from LGfL at just after 08:00 to supply them with a MIP request... so for SOLUS to work through our ISP firewall do I just give them the IPs quoted in the post by @Esteban_Child_of_the_Sun ?

 

LGfL have always been quite good with their support, but the problem is sometimes you seem to have to already know what the problem is and how to fix it, then just ask them to do it and 99.9% of the time they will. The problem comes when you don't have a clue and then it becomes a little more tricky to get things done...

 

So, from the MIP request spreadsheet they've sent me does anyone know what I am putting and in which section? The way it's worded to me seems like it's a one-way thing in each section, but it also doesn't seem that's the way it should work? I presume if a port is open, it's open right (?), but the way the spreadsheet looks to me is that I have to fill one in for the server > out and then the other section for the client > in.... I'm a bit disappointed LGfL don't have this as a config, ready to go really...

 

[ATTACH=CONFIG]67870[/ATTACH]

 

ESS have also got back to me and (with the caveat that it isn't a supported configuration) in summary:

 

IP of the workstation incorrectly being a local network IP and not a remote/VPN IP - I think this is working OK as DNS shows remote IP.

 

The ports you will need to allow though are 52965, 52966 and 8739, these are all TCP - Are these the only ones I need to advise LGfL about, or best to go with the full list?

 

Recommend adding specific allow rules for the ports as I have seen this fix issues even when the firewall shows as off in the UI. - I will see what happens when LGfL open the ports before I look at our server/client firewalls again.

 

EDIT: If it turns out all this could have been fixed in 5 minutes by sorting the LGfL firewall.... :mad:

Edited by Koldov
Posted

Looked at this a while ago and our our sims support official stance is "don't even try to get this working... not even you psydii"

 

The trouble I have with the LGfL firewall/VPN/MIP system is that how it actually works is fully obscured by their management system, so without experience/knowledge of the underlying tools and systems and how they are configured, working out the correct config for unusual requirements is next to impossible.

 

That said LGfL firewall and filtering is one reason I can sleep at night.

 

Trying to figure this out... Is you SOLUS server in an LGFL subnet or do you double NAT? Do the remote computers, when connected to the VPN, present with IP's from your internal subnets or a VPN sepcific LGfL-managed subnet?

Posted

Yeah, I have to say we don't need many unusual requirements, so I don't need to deal with this very often....

 

I too am quite glad the responsibility for the firewall configuration isn't on my shoulders, but as you say it does sometimes make a simple request more complicated.

 

Our SIMS/SOLUS server is on a VLAN from within an IP range specified by LGfL.

 

The VPN clients get an IP from a specific LGfL-managed subnet.

 

I'm not completely up on the fine detail of how it all actually works, but simply put, our remote client uses a school laptop, this is configured with pre-auth (before Windows auth), so in effect they are signing-in to the VPN and then signing into Windows so the laptop should act as if they were at the school, I can see the remote (VPN) IP address in DNS with the correct hostname.

 

Quite literally EVERYTHING else works, file share access is OK, SIMS/FMS clients work (if a little slower than on-site), our WSUS server can see the client, even printing... just not SOLUS.

 

I'm going to bet on it being a port that needs opening in the LGfL firewall, it just seems to make sense now. I seem to remember hearing they run it along the lines of 'close everything and then open what's needed only when requested' (which in all honesty is fair enough)... otherwise I doubt the support response would have been, 'fill out a spreadsheet and let us know what ports you need open'. Although I would have thought they would have some database with what schools use for an MIS (like they have done with O365 & Google) and what ports they need open I suppose it isn't every school that needs this part configuring as it really is meant to be an internal network function, but ESS said they had lots of support requests about this over lockdown. Still I guess it comes down to 'even if we know, you are still going to have to request it'... and I can see their point .

 

It probably should have been my first 'port' of call, instead of spending so much time trying to work out if it's a problem at my end... but I also seem to remember someone saying that previously they've had issues with the blame being put on the local network configuration... and I guess you can never actually tell when doing remote support.

Posted

Would have thought a rule to allow SOLUS to contact devices on the VPN subnet as per the documentation should fix it.

 

 

In csv:

SIMSSERVER10.x.x.xIP, VPNnetwork/netmask,Protocol(TCP/UDP),PortThatSolus/WorskationNeedsToBeContactableUpon

 

e.g.

 

10.10.1.125, 10.11.23.0/24,TCP,52965

10.10.1.125, 10.11.23.0/24,TCP,52966

10.10.1.125, 10.11.23.0/24,TCP,8739

 

 

except that 10.11.23.0/24 is a network address an not valid in the firewall config doc.

 

Also I'd have to pop wireshark on a client and deploy solus to know what ports in which direction are actually required. There are other windows management ports that would need to be open tcp 135, 139, 445, 5985, 5986 and UDP 137,138 spring to mind. You might also want to check the vpn clients can reach your DCs on tcp port 88.

Posted
It may not be related, but I had issues with SIMS/FMS over the VPN because all our paths were using the NetBIOS names, rather than FQDN. Once we changed those in GPOs and VPN configurations, SIMS and FMS started working fine.
Posted

I know the answer :) I have responded to your PM however for other users in LGfL, the VPN is one-way.

 

Outside(VPN address) to Inside(School range) = perfectly fine.

(School range)Inside to Outside(VPN address) = denied by ACL on the school firewall.

 

VPN addresses are provided via DHCP from a large range allocated on the VPN firewall. We just handle the routes and ACL on the inbound side, so you get access to your chosen routes from the support site config.

You cannot talk from school to VPN address as it would mean you could talk to anyone on that VPN range, which is a security risk.

  • Thanks 2

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...