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

8
  • When you ping remote.com does it gives you the correct IP address you are trying to reach?
    – 0r4cl3
    Commented Oct 6, 2015 at 9: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
    Commented Oct 7, 2015 at 9: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
    Commented Nov 5, 2015 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
    Commented Nov 5, 2015 at 17:02
  • Basic VPN Setup on RV180 and RV180W This old thing not supported any more... cisco.com/c/en/us/products/collateral/routers/… Commented Aug 2, 2016 at 2:20

1 Answer 1

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.

2
  • 1. 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
    Commented Oct 7, 2015 at 9:35
  • 2. 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
    Commented Oct 7, 2015 at 9:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.