Skip to content

Latest commit

 

History

History
198 lines (149 loc) · 12 KB

advanced-usage.md

File metadata and controls

198 lines (149 loc) · 12 KB
Raw

Advanced usage

Read this in other languages: English, 简体中文.

Use alternative DNS servers

Clients are set to use Google Public DNS when the VPN is active. If another DNS provider is preferred, you may replace 8.8.8.8 and 8.8.4.4 in these files: /etc/ppp/options.xl2tpd, /etc/ipsec.conf and /etc/ipsec.d/ikev2.conf (if exists). Then run service ipsec restart and service xl2tpd restart.

Advanced users can define VPN_DNS_SRV1 and optionally VPN_DNS_SRV2 when running the VPN setup script and the IKEv2 helper script. For example, if you want to use Cloudflare's DNS service:

sudo VPN_DNS_SRV1=1.1.1.1 VPN_DNS_SRV2=1.0.0.1 sh vpn.sh
sudo VPN_DNS_SRV1=1.1.1.1 VPN_DNS_SRV2=1.0.0.1 ikev2.sh --auto

DNS name and server IP changes

For IPsec/L2TP and IPsec/XAuth ("Cisco IPsec") modes, you may use a DNS name (e.g. vpn.example.com) instead of an IP address to connect to the VPN server, without additional configuration. In addition, the VPN should generally continue to work after server IP changes, such as after restoring a snapshot to a new server with a different IP, although a reboot may be required.

For IKEv2 mode, if you want the VPN to continue to work after server IP changes, you must specify a DNS name to be used as the VPN server's address when setting up IKEv2. The DNS name must be a fully qualified domain name (FQDN). It will be included in the generated server certificate, which is required for VPN clients to connect. Example:

sudo VPN_DNS_NAME='vpn.example.com' ikev2.sh --auto

Alternatively, you may customize IKEv2 setup options by running the helper script without the --auto parameter.

Internal VPN IPs and traffic

When connecting using IPsec/L2TP mode, the VPN server has internal IP 192.168.42.1 within the VPN subnet 192.168.42.0/24. Clients are assigned internal IPs from 192.168.42.10 to 192.168.42.250. To check which IP is assigned to a client, view the connection status on the VPN client.

When connecting using IPsec/XAuth ("Cisco IPsec") or IKEv2 mode, the VPN server does NOT have an internal IP within the VPN subnet 192.168.43.0/24. Clients are assigned internal IPs from 192.168.43.10 to 192.168.43.250.

You may use these internal VPN IPs for communication. However, note that the IPs assigned to VPN clients are dynamic, and firewalls on client devices may block such traffic.

For the IPsec/L2TP and IPsec/XAuth ("Cisco IPsec") modes, advanced users may optionally assign static IPs to VPN clients. Expand for details. IKEv2 mode does NOT support this feature.

IPsec/L2TP mode: Assign static IPs to VPN clients

The example below ONLY applies to IPsec/L2TP mode. Commands must be run as root.

  1. First, create a new VPN user for each VPN client that you want to assign a static IP to. Refer to Manage VPN Users. Helper scripts are included for convenience.

  2. Edit /etc/xl2tpd/xl2tpd.conf on the VPN server. Replace ip range = 192.168.42.10-192.168.42.250 with e.g. ip range = 192.168.42.100-192.168.42.250. This reduces the pool of auto-assigned IP addresses, so that more IPs are available to assign to clients as static IPs.

  3. Edit /etc/ppp/chap-secrets on the VPN server. For example, if the file contains:

    "username1"  l2tpd  "password1"  *
"username2"  l2tpd  "password2"  *
"username3"  l2tpd  "password3"  *

    Let's assume that you want to assign static IP 192.168.42.2 to VPN user username2, assign static IP 192.168.42.3 to VPN user username3, while keeping username1 unchanged (auto-assign from the pool). After editing, the file should look like:

    "username1"  l2tpd  "password1"  *
"username2"  l2tpd  "password2"  192.168.42.2
"username3"  l2tpd  "password3"  192.168.42.3

    Note: The assigned static IP(s) must be from the subnet 192.168.42.0/24, and must NOT be from the pool of auto-assigned IPs (see ip range above). In addition, 192.168.42.1 is reserved for the VPN server itself. In the example above, you can only assign static IP(s) from the range 192.168.42.2-192.168.42.99.

  4. (Important) Restart the xl2tpd service:

    service xl2tpd restart
IPsec/XAuth ("Cisco IPsec") mode: Assign static IPs to VPN clients

The example below ONLY applies to IPsec/XAuth ("Cisco IPsec") mode. Commands must be run as root.

  1. First, create a new VPN user for each VPN client that you want to assign a static IP to. Refer to Manage VPN Users. Helper scripts are included for convenience.

  2. Edit /etc/ipsec.conf on the VPN server. Replace rightaddresspool=192.168.43.10-192.168.43.250 with e.g. rightaddresspool=192.168.43.100-192.168.43.250. This reduces the pool of auto-assigned IP addresses, so that more IPs are available to assign to clients as static IPs.

  3. Edit /etc/ipsec.d/ikev2.conf on the VPN server (if exists). Replace rightaddresspool=192.168.43.10-192.168.43.250 with the same value as the previous step.

  4. Edit /etc/ipsec.d/passwd on the VPN server. For example, if the file contains:

    username1:password1hashed:xauth-psk
username2:password2hashed:xauth-psk
username3:password3hashed:xauth-psk

    Let's assume that you want to assign static IP 192.168.43.2 to VPN user username2, assign static IP 192.168.43.3 to VPN user username3, while keeping username1 unchanged (auto-assign from the pool). After editing, the file should look like:

    username1:password1hashed:xauth-psk
username2:password2hashed:xauth-psk:192.168.42.2
username3:password3hashed:xauth-psk:192.168.42.3

    Note: The assigned static IP(s) must be from the subnet 192.168.43.0/24, and must NOT be from the pool of auto-assigned IPs (see rightaddresspool above). In the example above, you can only assign static IP(s) from the range 192.168.43.1-192.168.43.99.

  5. (Important) Restart the IPsec service:

    service ipsec restart

Client-to-client traffic is allowed by default. If you want to disallow client-to-client traffic, run the following commands on the VPN server. Add them to /etc/rc.local to persist after reboot.

iptables -I FORWARD 2 -i ppp+ -o ppp+ -s 192.168.42.0/24 -d 192.168.42.0/24 -j DROP
iptables -I FORWARD 3 -s 192.168.43.0/24 -d 192.168.43.0/24 -j DROP

Split tunneling

With split tunneling, VPN clients will only send traffic for specific destination subnet(s) through the VPN tunnel. Other traffic will NOT go through the VPN tunnel. Split tunneling has some limitations, and is not supported by all VPN clients.

Advanced users can optionally enable split tunneling for the IPsec/XAuth ("Cisco IPsec") and/or IKEv2 modes. Expand for details. IPsec/L2TP mode does NOT support this feature.

IPsec/XAuth ("Cisco IPsec") mode: Enable split tunneling

The example below ONLY applies to IPsec/XAuth ("Cisco IPsec") mode. Commands must be run as root.

  1. Edit /etc/ipsec.conf on the VPN server. In the section conn xauth-psk, replace leftsubnet=0.0.0.0/0 with the subnet(s) you want VPN clients to send traffic through the VPN tunnel. For example:
    For a single subnet: 
    leftsubnet=10.123.123.0/24
    For multiple subnets (use leftsubnets instead): 
    leftsubnets="10.123.123.0/24,10.100.0.0/16"
  2. (Important) Restart the IPsec service: 
    service ipsec restart
IKEv2 mode: Enable split tunneling

The example below ONLY applies to IKEv2 mode. Commands must be run as root.

  1. Edit /etc/ipsec.d/ikev2.conf on the VPN server. In the section conn ikev2-cp, replace leftsubnet=0.0.0.0/0 with the subnet(s) you want VPN clients to send traffic through the VPN tunnel. For example:
    For a single subnet: 
    leftsubnet=10.123.123.0/24
    For multiple subnets (use leftsubnets instead): 
    leftsubnets="10.123.123.0/24,10.100.0.0/16"
  2. (Important) Restart the IPsec service: 
    service ipsec restart

Access VPN server's subnet

After connecting to the VPN, VPN clients can generally access services running on other devices that are within the same local subnet as the VPN server, without additional configuration. For example, if the VPN server's local subnet is 192.168.0.0/24, and an Nginx server is running on IP 192.168.0.2, VPN clients can use IP 192.168.0.2 to access the Nginx server.

Please note, additional configuration is required if the VPN server has multiple network interfaces (e.g. eth0 and eth1), and you want VPN clients to access the local subnet behind the network interface that is NOT for Internet access. In this scenario, you must run the following commands to add IPTables rules. To persist after reboot, you may add these commands to /etc/rc.local.

# Replace eth1 with the name of the network interface
# on the VPN server that you want VPN clients to access
netif=eth1
iptables -I FORWARD 2 -i "$netif" -o ppp+ -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -I FORWARD 2 -i ppp+ -o "$netif" -j ACCEPT
iptables -I FORWARD 2 -i "$netif" -d 192.168.43.0/24 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -I FORWARD 2 -s 192.168.43.0/24 -o "$netif" -j ACCEPT
iptables -t nat -I POSTROUTING -s 192.168.43.0/24 -o "$netif" -m policy --dir out --pol none -j MASQUERADE
iptables -t nat -I POSTROUTING -s 192.168.42.0/24 -o "$netif" -j MASQUERADE

IKEv2 only VPN

Libreswan 4.2 and newer versions support the ikev1-policy config option. Using this option, advanced users can set up an IKEv2-only VPN, i.e. only IKEv2 connections are accepted by the VPN server, while IKEv1 connections (including the IPsec/L2TP and IPsec/XAuth ("Cisco IPsec") modes) are dropped.

To set up an IKEv2-only VPN, first install the VPN server and set up IKEv2 using instructions in the README. Then check Libreswan version using ipsec --version, and update Libreswan if needed. After that, edit /etc/ipsec.conf on the VPN server. Append ikev1-policy=drop to the end of the config setup section, indented by two spaces. Save the file and run service ipsec restart. When finished, you can run ipsec status to verify that only the ikev2-cp connection is enabled.

Modify IPTables rules

If you want to modify the IPTables rules after install, edit /etc/iptables.rules and/or /etc/iptables/rules.v4 (Ubuntu/Debian), or /etc/sysconfig/iptables (CentOS/RHEL). Then reboot your server.

License

Copyright (C) 2021 Lin Song View my profile on LinkedIn

Creative Commons License
This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License
Attribution required: please include my name in any derivative and let me know how you have improved it!