More and more employees are working from home these days. That means they use Remote Desktop and need a VPN. Oh there are other ways, but I'm not going to allow employees to use GoToMyPC.com or logmein.com on my network. Sorry, I'm responsible for security so I'll control that access myself, thank you very much.I don't even like to use PCAnyWhere. I mean, why should you pay for something that is built-in to Windows - Remote Desktop? The thing that makes it all works is the VPN. A virtual private network is just a secure method of getting through the company firewall. It's not a big deal to setup a VPN and Remote Desktop. I've done it dozens of times.
That's why I was really frustrated when our HR manager could not get it set up following the standard instructions that have worked for every other employee that has needed it. Now I don't give remote access to just anybody. They have to have a job that requires it or just can't get enough of work so they take it home with them.
I must have spent four or five hours working on this issue over several months. We tried everything. Sometimes the VPN would connect but the majority of the time it wouldn't. We could never get Remote Desktop to work when the VPN said it was working. So I did something I rarely do - I offered to make an on-site visit to her home to get it working.
Of course the HR Manager was over-joyed. She had shared her frustration with her husband who happens to have his own business and his own computer guy. She suggested that the other computer guy meet us there. All we needed to have a full complement of tech guys was to invite a tech from AT&T to join us. It turns out we didn't need him.
The router was setup to get it's IP address using DHCP. That's not a problem - either DHCP or static works fine and has worked for lots of other employees. The only problem was the gateway it was getting - 192.168.0.1. I would have expected an outside address from the ISP. So we got into the SpeedStream modem at that address. Ah ha! It was running PPPoE.
I've noticed this on a few modems setup by SBC (now AT&T) here in Southern California. My first thought was to change the IP address of the modem to 192.168.1.1. The DHCP on the router was handing out addresses in that range so it only made sense to make the modem the first address in that subnet. We decided to try something else instead.
The modem can run PPPoE, pass-through PPPoE or can be put into a complete bridge mode. We used the second option because the WRT54G router can also be programmed for PPPoE. It worked! The funny thing is that the modem reports that it has no connectivity. I suppose that's because it's PPPoE circuitry has been bypassed. Whatever - it works.
Conclusion: Sometimes it just takes an on-site visit to make things work. I confess I've been spoiled over the past few years because I've been able to support all our remote locations via Remote Desktop without having to physically go there. I like that. Remote Desktop is the greatest single thing on Windows for an IT Manager with multiple locations to support.
2 comments:
The original problem might be able to be solved by replacing the router to a switch. I guess.
Since the Modem from SBC (AT&T) is intergrated with Router function.
Am I right?
When using PPPoE in bridged mode you will require to setup Port Forwarding on Port 3389 from the Modem's interface to the NIC's interface. Subsequently, if the router is assigning IP addresses via DHCP, you will most likely always get the same address. However, as soon as more than one PC connects to the modem, you could end up with another IP address and Remote Desktop would no longer work since you would be forwarding to the incorrect interface IP address. This is why why I always recommended that a static IP address be used.
Post a Comment