Has anyone successfully connected a Mac OSX vpn client to RV340 using L2TP/IPSec?

[rickrossnc]

Has anyone successfully gotten the built-in Mac OSX VPN client to connect to an RV340 using L2TP/IPSec? We have tried virtually every combination of settings we can think of, but it simply doesn't work. It seems to get close, but then complains of "Authentication Failure." We're absolutely sure we have the user credentials and the preshared-key correct, but we cannot get the built-in Mac OSX VPN client to connect to our RV340 with L2TP.

We did manage to get the built-in Mac OSX client to connect using Cisco IPSec, but we'd like to have the L2TP option working and available. We had similar problems trying to get the Windows 10 built-in VPN client using "L2TP/IPSec with pre-shared key." It won't work, either!

I suspect the problem has something to do with how the RV340 is storing and fetching the preshared-key value. We noticed log entries from signon attempts showing mangled strings for the key (almost like there are a few extra random chars added to the end of the actual, correct string!)

The RV340 has Firmware Version: 1.0.01.17

Thanks
Rick

[verysiberian]

Here's the deal with that and it's not necessarily intuitive (at least to me). In essence, you need three different LAN addressing schemes. Here is how I have this currently working as an example.

My home LAN uses Google WiFi, which defaults to a DHCP scheme of 192.168.86.X.

My office LAN (unfortunately, but I'm stuck with it for a while) uses the very common 192.168.1.X DHCP scheme.

When I connect from home to the office VPN router (a Cisco RV340), my home computer is assigned an IP address in the 192.168.27.X range.

Even with an IP address of 192.168.27.X from the VPN router, I can access everything on the office LAN that's in the 192.168.1.X range. Give it a try and I'll help out if possible. What I can guarantee won't work is if your local LAN has the same DHCP scheme as the LAN to which you're trying to connect over VPN. For example, my office manager was using hotel Wi-Fi while on vacation and stuck with a local 192.168.1.X DHCP setup. As such, she had the exact same problem you're describing -- she could connect to VPN but then not access anything on the office LAN (since it was also 192.168.1.X). It flat out doesn't work, I'm afraid.

[TimLocke97218]

I understand what you are saying about both ends having the same subnet. The router thinks the traffic is local so doesn't route it to the gateway. I don't believe this is the issue.

I previously had the VPN clients getting 192.168.1.0 addresses and they were connecting from my phone's hotspot feature (because we're in the office while testing this). I just checked and my phone is using the 192.168.43.0 subnet. I'm not sure whether the 43 changes randomly every time it is enabled or not, but it's not conflicting with anything on the router or the LAN behind it.

Once we tried while the employee was at home where they likely have a 192.168.x.x subnet and it still didn't work.

In each of these cases, not only can they not see the SMB file server, but they can't ping it either.

[verysiberian]

Darn, sorry that I wasn't able to help. The only thing I have seen produce the behavior you described is an IP address conflict caused by duplicate subnets in the person's home and in the remote office. My group has otherwise been able to connect to VPN and access all remote LAN resources without a hitch using the settings described in my earlier post. Good luck!

[rocky515]

---

@verysiberian wrote:

Update: I got this to work with my Macs and iOS devices, though it still does not fix the OP's original issue for using L2TP. Nevertheless, I am posting it here in case it helps others. Using the following procedure, I was able to get Cisco IPSec VPN working on macOS and iOS for a Cisco RV340.

On the router:

1. Do not mess with IPSec profiles at all, at least for getting your Mac and iOS clients connected. I wasted tons of time with those settings, but they do not seem to apply.

2. VPN Passthrough: be sure that IPSec is enabled.

3. Under Client-to-site, create a new group. Under Add a New Group, go with the default option, Cisco VPN Client. This threw me off big time since I'm not using the Cisco VPN Client (i.e., Cisco AnyConnect), so I wasted hours messing with the third party client settings. Don't do what I did! Keep it simple.

4. Pick your interface, e.g., WAN1, and input a pre-shared key. For User Group, click to add the admin group (or other group that you created in an earlier step).

5. Leave the default DNS server for the LAN IP of your router. 

6. In my setup, I left everything else blank and saved the settings. I did not want or need split tunnels, etc.

On the Mac or iOS device:

1. Create a new VPN connection using the built-in client. No special software needed. Select Cisco IPSec as the type.

2. Enter your router's WAN IP address (or, depending on your setup, its domain name or dynamic DNS name).

3. Enter your username and password. Click on Authentication Settings, enter the pre-shared key and group name of your client-to-site group.

4. Click Apply.

Blam, be happy, you now have IPSec VPN working on your Mac and iOS devices. In hindsight, this all seems pretty simple but I burned an entire day on realizing that you don't need to mess with some of the settings.

Cheers,

Rob

---

Hello,

Thanks for this!  I did this and I was able to successfully connect to the VPN, though I still have trouble connecting to my LAN.  There are 4 VLANs configured on my RV340, after I successfully connect to the VPN on my mac, I still cannot ping or connect to any server in my VLAN.   I haven't created a route, but if I do, what VPN subnet should I allow to the local VLAN, since the Cisco RV340 only asked a range of IP for the vpn users.

Anyone has the same problem?

Cheers,

Thanks!

[ktonev]

Hi Rick,

If the native MAC OSX VPN client is using CHAP to authenticate then this is the reason why the connection is failing. Please try using PAP and report back if the issue is still not resolved. You can also double check this in the RV34x logs.