
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-13-2009 10:22 PM
Hello, I'm not sure there's anything you can do to help with this but I thought I would bring it up anyway.
I have 2 offices separated by a VPN that uses NAT. It appears that I cannot use lsclient over the VPN as the NAT changes the IP of the requesting machine to that of the gateway on the local side. This causes the scan to fail because the required services are not present on the gateway.
The recurring error I get is:
Wmierror The RPC server is unavailable. (Exception from HRESULT: 0x800706BA) SOLANGE (192.168.1.1)
Solange is the correct host, but the IP is that of the gateway.
It appears that when you request a scan via LSCLIENT it basically says, "Hey, scan me on the ip you see this request coming from". Since this IP is changed to appear to be coming from the IP of my gateway/firewall it doesn't work.
Is there a work around for this? A nslookup of the hostname making the request and then a scan attempt on the IP that is returned as a result of that scan would work I think?
Thanks!
PS: We are going to be going with the premium version I think, but I'm still not sure I'd want to use the active scanning based on some of the problems (not sure if they're resolved) I've glanced at while looking over the forums, so I think I may have this problem with the premium version as well.
I have 2 offices separated by a VPN that uses NAT. It appears that I cannot use lsclient over the VPN as the NAT changes the IP of the requesting machine to that of the gateway on the local side. This causes the scan to fail because the required services are not present on the gateway.
The recurring error I get is:
Wmierror The RPC server is unavailable. (Exception from HRESULT: 0x800706BA) SOLANGE (192.168.1.1)
Solange is the correct host, but the IP is that of the gateway.
It appears that when you request a scan via LSCLIENT it basically says, "Hey, scan me on the ip you see this request coming from". Since this IP is changed to appear to be coming from the IP of my gateway/firewall it doesn't work.
Is there a work around for this? A nslookup of the hostname making the request and then a scan attempt on the IP that is returned as a result of that scan would work I think?
Thanks!
PS: We are going to be going with the premium version I think, but I'm still not sure I'd want to use the active scanning based on some of the problems (not sure if they're resolved) I've glanced at while looking over the forums, so I think I may have this problem with the premium version as well.
Labels:
- Labels:
-
Archive
4 REPLIES 4

Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-22-2009 10:19 PM
In the next version there will be a switch for lsclient "/scanonhostname" this sould solve this problem.

Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-14-2009 12:41 AM
Just to give you a better understanding (no harm since it's all private IPs, but I'll modify them to fictitious numbers )
Office #1
Lansweeper Server (192.168.1.361)
Firewall/Gateway (192.168.1.1)
Office #2
Solange (192.168.2.375)
Firewall/gateway (192.168.2.1)
I remotely connect to solange and run: lsclient 192.168.1.361 (I've tried it with the hostname of the server as well)
So traffic will go 192.168.2.375 => 192.168.2.1 => 192.168.1.1 => 192.168.1.361
It comes back with success in the command prompt on Solange, but of course it gives me RPC Server Unavailable on 192.168.1.361.
In the website ont he lansweeper server dashboard it shows the error message given a couple of posts up with the IP of the Office #1 firewall associated to Solange (instead of solange's IP)
BTW - from the lansweeper server I have tried the connection tester to solange and all 4 tests pass.
Office #1
Lansweeper Server (192.168.1.361)
Firewall/Gateway (192.168.1.1)
Office #2
Solange (192.168.2.375)
Firewall/gateway (192.168.2.1)
I remotely connect to solange and run: lsclient 192.168.1.361 (I've tried it with the hostname of the server as well)
So traffic will go 192.168.2.375 => 192.168.2.1 => 192.168.1.1 => 192.168.1.361
It comes back with success in the command prompt on Solange, but of course it gives me RPC Server Unavailable on 192.168.1.361.
In the website ont he lansweeper server dashboard it shows the error message given a couple of posts up with the IP of the Office #1 firewall associated to Solange (instead of solange's IP)
BTW - from the lansweeper server I have tried the connection tester to solange and all 4 tests pass.

Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-14-2009 12:10 AM
There is a VPN tunnel between sites connecting them - unfortunately we have NAT turned on in order to facilitate connectivity with a couple of devices between offices. It's necessary.
nslookups based on FQDN do resolve to the proper IP. The IP of the gateway that is being assigned to the remote host (solange in this case) is not associated in any wins or dns records of any kind. This is why I assumed it must be a way in which the scan request is made that uses the IP that 'sent' the request, instead of doing a lookup on the hostname of the requester. ...if that makes any sense =). Essentially if it did a nslookup or attempted to just initiate a connection to the hostname (which would involve a DNS lookup - so long as the Lansweeper service doesn't have some sort of internal DNS cache), I believe that would resolve the issue.
Great program and quick reply for support - thank you!
nslookups based on FQDN do resolve to the proper IP. The IP of the gateway that is being assigned to the remote host (solange in this case) is not associated in any wins or dns records of any kind. This is why I assumed it must be a way in which the scan request is made that uses the IP that 'sent' the request, instead of doing a lookup on the hostname of the requester. ...if that makes any sense =). Essentially if it did a nslookup or attempted to just initiate a connection to the hostname (which would involve a DNS lookup - so long as the Lansweeper service doesn't have some sort of internal DNS cache), I believe that would resolve the issue.
Great program and quick reply for support - thank you!

Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-13-2009 10:45 PM
We have build in the reverse lookup error as a warning because when the reverse lookup is wrong mostly WMI access will fail due to security errors.
In the next version we will first try on ip address, if this fails on FQDN.
In your case this would still fail because the FQDN would probably point to an old IP address. (or an ip not reachable through the NAT)
Maybe a possible solution would be to use some sort op vpn/ipsec tunnel to connect both sites.
In the next version we will first try on ip address, if this fails on FQDN.
In your case this would still fail because the FQDN would probably point to an old IP address. (or an ip not reachable through the NAT)
Maybe a possible solution would be to use some sort op vpn/ipsec tunnel to connect both sites.
