6

Trying to setup a VPN for our small business (more secure and useful than the WebDAV we currently use) - but I'm having trouble getting it to work. I've not had to setup any VPN before, so have read all the docs and guides I could find - but no luck :-/

After using the simple setup these are screenshots of what I have - blurred areas to hide specific details and show that there are correct values in there.

Wanting to simply have the router act as a VPN server for clients (ie, us at home etc) to connect in and get access to everything in the LAN.

When trying to connect from Windows7, OSX Mavericks and iOS9 it just times out and/or says the server isn't responding - port scan shows the relevant ports appear open.

Pretty sure this is me just missing something, but can't find any relevant results when searching, and trying several (dozen now?) variations of everything am asking for help from anyone who's managed this before :-)

Firmware is 1.0.4.14 (latest release)

IKE PolicyVPN Policy

Rycochet
  • 111
  • 4
  • When you ping remote.com does it gives you the correct IP address you are trying to reach? – 0r4cl3 Oct 06 '15 at 09:11
  • That remote.com is the value that the help docs tell you to put in if you're just wanting to let clients connect - you can't leave it blank or wildcards etc - the FQDN stands for "Fully Qualified Domain Name", and from what I can find that value is a magic string rather than a specific domain. – Rycochet Oct 07 '15 at 09:32
  • one simple rule with site to site vpns is all values on both sides should match exactly except of course the subnets and address which will be vice versa. Can you post those details pls – allwynmasc Nov 05 '15 at 15:29
  • It was actually one of the first things I tried - no variations were working (even identical or reversed etc) - the biggest issue was simply that the port wasn't open to anything on the outside, so nothing could connect - the company has gone back to the older router now, sadly it's an even worse Cisco managed one, so completely broken nat-traversal :-/ – Rycochet Nov 05 '15 at 17:02
  • Basic VPN Setup on RV180 and RV180W This old thing not supported any more... http://www.cisco.com/c/en/us/products/collateral/routers/small-business-rv-series-routers/eos-eol-notice-c51-733327.pdf – Ronnie Royston Aug 02 '16 at 02:20
  • I'm not surprised, it was really unable to cope with anything, even down to packet inspection on HTTP SPDY packets breaking connections after a while - when packet inspection was turned off... We binned it, and got a cheap Linksys branded one that took ten minutes to setup including a completely functional VPN - advice for anyone with the same problem - do the same... – Rycochet Aug 02 '16 at 08:44
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 12 '17 at 18:19
  • @RonMaupin Sadly not - the router has now been pushed to the back of a drawer completely unused because it seemed incapable of doing it properly - I'd rather leave this open until there is actually an answer to it that doesn't involve throwing the thing away :-/ – Rycochet Aug 12 '17 at 22:32

1 Answers1

1

I haven't worked with the Cisco RV180w, but I want to try to throw out a few suggestions based upon other VPN experience.

(1)
For starters, in your first screenshot, I'm seeing you are requesting the "Remote" side identify themselves with a FQDN, which you have filled out as "remote.com".

Usually this would be some sort of "Group Username" or "Group Identifier". I don't know what other options exist in that drop down, but look for something along those lines.

On the client side, the configuration would use the same "Group Username" as above in their username configuration. And then they would use what you have in the "pre-shared key" box as their password. Note, that multiple users will share the same username and password here. (see below on how to amend that)

(2)
You have the same setting to change in your 2nd screenshot. THe remote end point will probably identify themselves with some sort of Group Username or Password.

(3)
The "Local Traffic Selection" should be an identification of the subnet(s) that exist behind your Cisco router. If you're only network is 192.168.12.0/24, then you're fine. But if you have other subnets, you should update this.

(4)
The Remote Traffic Selection should identify the IP address that is given to the users who connect through the VPN. On Cisco Firewalls, typically an IP pool is created (it doesn't much matter what IPs you pick, just pick something that probably won't' be used at either the client end or your end). Then you configure the "remote traffic selection" as that subnet. I'm not sure the implications of leaving that set to Any. I feel that might cause potential routing issues, so I would avoid it.

(5)
Back on your first screenshot, you have XAUTH set to None. This is fine while you are testing, but in production this is a pretty big security vulnerability. For two main reasons:

5.1: All of users will now share only one Group Username and Pre-Shared Key for password.

5.2: Due to how Aggressive Mode negotiates, the packet which contains the hash of the Pre-Shared Key is sent in clear text. Which leaves you vulnerable to someone eavesdropping that packet, and running offline brute force attacks on a hash (which can be performed at relatively high speed).

Better to not leave yourself open to this. XAUTH creates a second layer of username/password challenge, but these are all transferred securely through the VPN tunnel. So I would suggest turning that on.


The last thing I would suggest, is running a packet capture on your Cisco box's outside interface, when you have a client trying to connect. The result of that would be very useful in determining why the VPN connections are not working.

Eddie
  • 15,026
  • 6
  • 44
  • 84
  • That's the suggested value and looks like a magic string - the pre-user settings are easy to add once the VPN itself is up ;-)
  • – Rycochet Oct 07 '15 at 09:35
  • Sadly already tried that. 3. I've tried with both the real subnet and a separate subnet, no change again. 4. Will try (think this is the only combination thing that I hadn't tested) - router is currently offline as it apparently randomly drops SPDY packets over https1.1 connections so we've reverted to an older router for now. 5. Was aware of this - and adding proper user logins is easy, so was keeping it simple to see it working first ;-)
  • – Rycochet Oct 07 '15 at 09:41