Hi
For L2TP-with-IPsec tunneling, there are 2 components in play here
1. The actual L2TP tunnel that is established between the L2TP-server and the remote L2TP-client
a) By design the L2TP tunnel does not have encryption/protection of its own, so its just a plain insecure
[external-ip-header[udp-port-1701[ppp-header[Internal-IP packet]]]]
b) Here becos the L2TP tunneling uses ppp to encapsulate the internal-ip-packet, during l2tp tunnel negotiation to establish the "l2tp-tunnel" the ppp user-authentication is done....so here on RV340 CHAP is also supported and this requires a Radius-Server (connected in lan-network of RV340) for offloading the chap user-authentication process
- If you want to use chap-auth, then you will need to create a user-group and user-accts in the Radius-server and just create the user-group ONLY in RV340 (and select this user-group in the l2tp-server config page)
- If you want to use just PAP, then you will need to create a user-group and local-user-accounts (in the user-accounts page) on RV340
2. Becos the L2TP TUNNEL is insecure by design, it was decided to use IPSec Tunnel "to protect the L2TP-TUNNEL"
a) So this IPSec-Tunnel protecting the L2TP-tunnel (completely from L2tp-tunnel negotiation and the subsequent l2tp-data channel after the l2tp-tunnel is UP) uses transport mode...
- it is becos the IPsec tunnel policy is to protect ALL traffic using udp-1701 port (which is what is used by L2TP-tunnel inside the ipsec tunnel)
So when both L2TP-Tunnel and IPsec Tunnel are configured and ready on both L2TP-client and L2TP-server gateways....when the l2tp-client starts to initiate the tunnel connection for negotiation...the first udp-1701 packet from the l2tp-client service will trigger the initiation and establishment of the IPsec tunnel between the windows/Linux L2TP-client Peer and the RV340-l2tp-server
- after the IPsec tunnel is established (it takes about 3.5 to 4 seconds to come up), the L2TP-tunnel negotiation resumes and during this l2tp-tunnel negotiation process going on inside the IPsec tunnel, the L2tp-ppp-user-authentication takes place...and this could be using PAP or CHAP (if user has selected Radius-based user-group and configured Radius on RV340)
- And after the ppp-user-auth, the L2TP-server will assign a virtual-ipaddress to the L2TP-client..
- Then once all the negotiation of the L2TP-tunnel is finished, all the L2tp-encapsulated data traffic (with source ipaddr as the virtual-ipaddr on l2tp-client) is protected by the IPsec tunnel between the client-pc and RV340...
So in summary, yes....if you want a native pure IPsec tunneling between the Windows-Client and the RV340...you can use the Client-to-Site config-page
a) to configure a IKEv1 IPSec VPN-Server on RV340, and then use either Greenbow or Shrewsoft vpn client to establish a IKEv1-based IPSec Tunnel. Please note this tunnel will be tunne-mode and there will also be a user-auth process which is XAUTH...and therefore Local-user-accounts in Local-User-Groups can be used on the RV340
- else if you have Radius configured, you may offload the IKEv1 Xauth user-auth to a Radius server connected in the lan-side of RV340
Note: Windows does NOT have a built-in IKEV1 pure IPsec client built-in. It has ONLY L2TP-with-IPsec client which uses ONLY IKEv1
b) to configure a IKEv2-based IPSec VPN Server on RV340, and then use the built-in IKEv2 IPsec client on Windows. This uses EAP-authentication for user-auth
- therefore for EAP-auth support, the Radius configuration is definitely required on RV340...local-accounts cannot be used for EAP-auth..
hope this is useful
