JamesLevinworth
@embarqhsd.net
| reply to jmmilner
Re: Client that actually works with RV016?
I manage a multi-site VPN, all using RV016s.
Up front, I'll say that if it's just you looking to do remote management, then why not use the built in RDP/terminal services. For extra security, I use a non-default port and restricted use of that port in the router via a firewall rule to just my remote WAN IP. Once to my main server, I can then RDP to other workstations if I need to without opening them in the external firewall/router. Works well enough for me and a lot less buggy.
I also have QuickVPN setup for clients who travel. I had a heck of a time setting it up too, but I ran into a bug that I figured out a work around. I don't know if this bug I ran into is inherent to the latest firmware I have (3.0.0.1-tm) or not, but oddly enough I couldn't get it working until I enabled the unrelated option of turning on SSL on the router (Firewall->General) and used the :443 as the port of choice on the client.
I'll assume you created the proper certificate under 'vpn client access' and installed the client copy in the quickvpn directory. I'll also assume you added your subnet (which should be different than the subnet you are accessing) as an exception in that machine's firewall which will block you too.
Note: If you try the SSL workaround, you'll then have to use https: to remote manage the router which is one or the other (not both) in the latest firmware.
Also, don't expect to browse machines by machine name on the remote segment unless you add lmhosts to your local machine. Otherwise use \\ipaddress to access the machine from the run or explorer once connected. |
|
JamesLevinworth
@embarqhsd.net | One more thing: Not sure if you found these or not, but in the quickvpn client directory there are logs which will tell you why and for what reason (it believes) the connection failed (or not). This helped my troubleshooting quite a bit. |
|
jmmilner
join:2001-11-20
Yorkville, IL
| reply to JamesLevinworth
Thanks for the in-depth reply.
The LAN in question doesn't have a true server so I didn't consider RDP initially. I did make a later half-hearted attempt to set it up on "my" desktop on site but that PC was reassigned before I got it remotely (it did work in-house).
I'm still running 2.0.18-q50 so I don't have an explicit SSL enable on the Firewall->General page. I did catch the need to enable HTTPS (which using port 443 is really SSL/TSL) in the fine print of the latest manual. I guess it makes sense since QuickVPN is based on OpenSSL.
I've got wireshark on the client so I'll try a local capture and see what that suggests.
I've done the certificate creation & export, opened my home subnet (192.168.x.0/24) which isn't the same as the remote LAN (192.168.y.0/24), and currently use static IP addresses for the objects of interest on the LAN (PBX, VM, print servers, wireless APs).
My RV016 logs show the VPN is established ([Tunnel Negotiation Info] Quick Mode Phase 2 SA Established, IPSec Tunnel Connected), the initial web page of the LAN device is expanded in the Firefox address bar, the RV016 logs outbound (from LAN) TCP (port 80) packets to the remote client's IP address, but nothing displays. The VPN client never gets past the "Verifying Network" message and sinks 100% of the CPU. I've looked at the log.exe and wget_error.txt files on the client but I don't see anything in the way of error messages. I'm using version 1.2.11 (latest) of the client. |
|
JamesLevinworth
@embarqhsd.net
| This is the first time I've had to check in today and am in and out at the moment (busy weekend) but on the quick here's a few less than organized thoughts that came to mind reading your reply.
-When I got the 'verifying network' message hanging it was because it was waiting on a reply/verification back that it never received. This was due to me not also opening the pass throughs on the remote router (doh!) so check on that.
-Check the logs on the remote router that it's receiving.
-I'd recommend upgrading to the latest firmware as it's designed to work best with the latest client. Backup your settings first as a precaution but I've personally never had an issue doing an in place firmware upgrade with them to need to restore it.
-rather than checking if you can connect with a browser, I'd ping the local lan ip of the machine you are connecting to; or better , if you don't have it, open tcpview (set to 'always on top') and see what happens when you hit connect:
»technet.microsoft.com/en-us/sysi···437.aspx
(there are other tools to trouble shoot this also, but I'll swing back to that)
-Since you are using DSL, I'd verify your MTU settings on your DSL router and tweak your nic to match. This is the southwestern bell faq, but it's instructions apply to typical DSL settings (1492) as well as the link in the faq to VPN settings (~1400) that may also apply to you as well:
»AT&T Southeast Forum FAQ »How do I find my optimum MTU setting? |
|
JamesLevinworth
@embarqhsd.net | Also, there is another log besides wget_error.txt. I'd tell you the name but don't have the client loaded on this pc. It's in the same dir.. another .txt file. It logs all the authentication steps.
later for now...... |
|
JamesLevinworth
@embarqhsd.net
| Just thought of one more: you didn't mention if you verified your machines' firewalls or not. Verify both remote and local pcs firewall that it allows your subnet. For example, if using Windows firewall: File & Print sharing -> change scope -> custom:
192.168.x.0/255.255.255.0,192.168.y.0/255.255.255.0
over and out. |
|
jmmilner
join:2001-11-20
Yorkville, IL
| reply to JamesLevinworth
IPSec, PPTP, and L2TP are enabled on the RV016. IPSec and PPTP are enabled on my DI-624 at home (L2TP isn't an option).
Logs on the RV016 show the setup completes. Log.txt on the client shows "tunnel is connected successfully" and then "verifying network" - nothing after that.
I'll upgrade the RV016 firmware during the PM window this week.
I've got tcpview but had not considered using it - will see what it says. I'll also check into the MTU settings on the DI-624 but I don't think I have much control on the DSL modem itself (Motorola 2210-02-1002). |
|
JamesLevinworth
@embarqhsd.net
| No worries on L2TP - Not needed for this and can be disabled if you wish on the RV016.
Definitely check on the MTU - Should be under the WAN section on your DI router. Even if not this issue, it should be set appropriately per the instructions in the FAQ.
Thanks for the detailed updates. Keep me posted. |
|
jmmilner
join:2001-11-20
Yorkville, IL
| reply to JamesLevinworth
said by JamesLevinworth :
Just thought of one more: you didn't mention if you verified your machines' firewalls or not. Verify both remote and local pcs firewall that it allows your subnet. For example, if using Windows firewall: File & Print sharing -> change scope -> custom:
192.168.x.0/255.255.255.0,192.168.y.0/255.255.255.0
over and out.
I dropped the MTU (to 1356 based on some stuff in the FAQ) and just flat turned off the firewall on the client. QuickVPN still hangs "verifying network", still eats 100% of the CPU (busy waiting?) but I can now ping devices within the LAN and get access using Firefox to the web GUIs for my PBX, networked printers, and router. I'll adjust the MTU upward till it breaks the VPN and then try turning the firewall back on to see if I can keep it all together. Once I upgrade the RV016 firmware I hope the "verifying network" finally goes away and the taskbar icon turns green.
Thanks for the help. Will report back with future results. |
|
JamesLevinworth
@embarqhsd.net
| Glad to hear you are getting some success.
If you have PPoE/DSL on the RV016, make sure you at least set the MTU there at 1492. Improper MTU can really muck with you network wise in general but as for the QuickVPN, I've never personally had to set it below 1492 running on PPoE to get it going but have had to lower it down to ~1400 using other VPN clients (and over other ISPs). The FAQs and tools on this site are enormously helpful in understanding these and determining your proper numbers. It's good that you've taken them in.
Check your DL router doesn't need a firmware upgrade too.
The RV016 is a solid router but that quickvpn leaves a lot to be desired. The plus side of using the quickvpn though is being able to manage the once configured client(s) centrally through the router... such as it will now show up on the VPN summary page showing what clients are connected, date/time, etc. and also being able to change the passwords on the client access page if need be.
It's good that you've now worked around this not only to get it going but also other similar, as well as knowledge gain, which is always a plus - but I'd still consider swinging on back to RDP if for anything a fall back.
If interested in testing it out, all you'd need at this point (since you had it going previously internally and if that config has not changed) is to setup a port forward in the RV016 to port 3389 pointing at the LAN ip of choice. Then fire up the RDP client on your PC and point at the RV016's wan IP and you should be in. I personally recommend when using the RDP client is set the Options->Experience at the lowest connection type (Modem) which turns off things like loading your local pc's printers remotely, turns off themes etc and runs a lot faster. If that works, you can always secure it up later such as I described earlier but I personally wouldn't leave that port forward turned on when you aren't using it until you do.
Thanks for the update and do post future results. |
|
JamesLevinworth
@embarqhsd.net
| said by JamesLevinworth :
I personally recommend when using the RDP client is set the Options->Experience at the lowest connection type (Modem) which turns off things like loading your local pc's printers remotely, turns off themes etc and runs a lot faster.
Not knowing if you need this info but just to correct myself here, the option to turn off loading local printers remotely is under Options->Local Resources (not part of 'Experience'). If you have no plans on using it per that session then I recommend unchecking this as well since it's not only bandwidth drain, it will automatically want to install your printer's drivers on the remote machine and leaves them there until you uninstall them. |
|
