strongSwan

Tobias Brunner wrote:

The one thing I did notice that could be messing me up is I'm using venet0 interface and not eth0.

OpenVZ is definitely known to cause problems with IPsec. But if the SAs get installed OK, and you can e.g. reach other clients via VPN I guess it shouldn't be a problem.

You should have a look at ForwardingAndSplitTunneling, you probably need to NAT the virtual IPs to your public IP.

Just noticed that I've been getting this error

root@wickedlizerd:~# sudo netfilter-persistent save
run-parts: executing /usr/share/netfilter-persistent/plugins.d/15-ip4tables save
run-parts: /usr/share/netfilter-persistent/plugins.d/15-ip4tables exited with return code 1
run-parts: executing /usr/share/netfilter-persistent/plugins.d/25-ip6tables save
run-parts: /usr/share/netfilter-persistent/plugins.d/25-ip6tables exited with return code 1
root@wickedlizerd:~# sudo netfilter-persistent reload
run-parts: executing /usr/share/netfilter-persistent/plugins.d/15-ip4tables start
Warning: skipping IPv4 (no rules to load)
run-parts: executing /usr/share/netfilter-persistent/plugins.d/25-ip6tables start
Warning: skipping IPv6 (no rules to load)

Could this have something to do with it?
Note: I've been using DigitalOcean's tutorial on how to setup on Ikev2 VPN on Ubuntu (Linked below)

https://www.digitalocean.com/community/tutorials/how-to-set-up-an-ikev2-vpn-server-with-strongswan-on-ubuntu-16-04

Could this have something to do with it?

Maybe that's just because you don't have any rules configured (that's at least what the output of iptables-save you posted indicates). But you'd probably have to look at the scripts to see what they do and what exactly fails.

Tobias Brunner wrote:

Could this have something to do with it?

Maybe that's just because you don't have any rules configured (that's at least what the output of iptables-save you posted indicates). But you'd probably have to look at the scripts to see what they do and what exactly fails.

So I've played around with this more, and now clients can no longer connect.

Here's my new iptables-save output

# Generated by iptables-save v1.6.0 on Wed May 30 10:56:42 2018
*nat
:PREROUTING ACCEPT [1:48]
:POSTROUTING ACCEPT [92:5482]
:OUTPUT ACCEPT [92:5482]
-A POSTROUTING -s 10.10.10.0/24 -o venet0 -m policy --dir out --pol ipsec -j ACCEPT
-A POSTROUTING -s 10.10.10.0/24 -o venet0 -j MASQUERADE
COMMIT
# Completed on Wed May 30 10:56:42 2018
# Generated by iptables-save v1.6.0 on Wed May 30 10:56:42 2018
*raw
:PREROUTING ACCEPT [330:63068]
:OUTPUT ACCEPT [327:64687]
COMMIT
# Completed on Wed May 30 10:56:42 2018
# Generated by iptables-save v1.6.0 on Wed May 30 10:56:42 2018
*mangle
:PREROUTING ACCEPT [330:63068]
:INPUT ACCEPT [330:63068]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [327:64687]
:POSTROUTING ACCEPT [327:64687]
-A FORWARD -s 10.10.10.0/24 -o venet0 -p tcp -m policy --dir in --pol ipsec -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
COMMIT
# Completed on Wed May 30 10:56:42 2018
# Generated by iptables-save v1.6.0 on Wed May 30 10:56:42 2018
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [255:53963]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -p udp -m udp --dport 4500 -j ACCEPT
-A INPUT -p udp -m udp --dport 80 -j ACCEPT
-A INPUT -p udp -m udp --dport 443 -j ACCEPT
-A INPUT -j DROP
-A FORWARD -s 10.10.10.0/24 -m policy --dir in --pol ipsec --proto esp -j ACCEPT
-A FORWARD -d 10.10.10.0/24 -m policy --dir out --pol ipsec --proto esp -j ACCEPT
-A FORWARD -j DROP
-A OUTPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate ESTABLISHED -j ACCEPT
COMMIT
# Completed on Wed May 30 10:56:42 2018

I also have a script for my setup process. I did make it, so please don't cringe too hard. Thanks.
My setup script

sudo apt-get purge strongswan strongswan-plugin-eap-mschapv2 moreutils iptables-persistent
sudo apt-get install strongswan strongswan-plugin-eap-mschapv2 moreutils iptables-persistent
echo Done Installing Software!
mkdir vpn-certs
cd vpn-certs
rm -r *
echo Created new directory!
ipsec pki --gen --type rsa --size 4096 --outform pem > server-root-key.pem
chmod 600 server-root-key.pem
ipsec pki --self --ca --lifetime 3650 \
--in server-root-key.pem \
--type rsa --dn "C=CA, O=Dombi.me VPN, CN=VPN Server Root CA" \
--outform pem > server-root-ca.pem
ipsec pki --gen --type rsa --size 4096 --outform pem > vpn-server-key.pem
ipsec pki --pub --in vpn-server-key.pem \
--type rsa | ipsec pki --issue --lifetime 1825 \
--cacert server-root-ca.pem \
--cakey server-root-key.pem \
--dn "C=CA, O=Dombi.me VPN, CN=168.235.70.66" \
--san server_name_or_ip \
--flag serverAuth --flag ikeIntermediate \
--outform pem > vpn-server-cert.pem
sudo cp ./vpn-server-cert.pem /etc/ipsec.d/certs/vpn-server-cert.pem
sudo cp ./vpn-server-key.pem /etc/ipsec.d/private/vpn-server-key.pem
sudo chown root /etc/ipsec.d/private/vpn-server-key.pem
sudo chgrp root /etc/ipsec.d/private/vpn-server-key.pem
sudo chmod 600 /etc/ipsec.d/private/vpn-server-key.pem
sudo cp /etc/ipsec.conf /etc/ipsec.conf.original
echo Created and copied certificates!
echo '' | sudo tee /etc/ipsec.conf
cp ../ipsec.conf /etc/ipsec.conf
echo Configured ipsec.conf
sudo ipsec reload
sudo ufw disable
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -F
iptables -Z
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate ESTABLISHED -j ACCEPT
sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A INPUT -p udp --dport  500 -j ACCEPT
sudo iptables -A INPUT -p udp --dport 4500 -j ACCEPT
sudo iptables -A INPUT -p udp --dport   80 -j ACCEPT
sudo iptables -A INPUT -p udp --dport  443 -j ACCEPT
sudo iptables -A FORWARD --match policy --pol ipsec --dir in  --proto esp -s 10.10.10.10/24 -j ACCEPT
sudo iptables -A FORWARD --match policy --pol ipsec --dir out --proto esp -d 10.10.10.10/24 -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 10.10.10.10/24 -o venet0 -m policy --pol ipsec --dir out -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 10.10.10.10/24 -o venet0 -j MASQUERADE
sudo iptables -t mangle -A FORWARD --match policy --pol ipsec --dir in -s 10.10.10.10/24 -o venet0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
sudo iptables -A INPUT -j DROP
sudo iptables -A FORWARD -j DROP
echo Setup IP Tables!
iptables-save > /etc/iptables/rules.v4
ip6tables-save > /etc/iptables/rules.v6
sudo netfilter-persistent reload
echo Done! Rebooting...
sudo reboot

Is there anything super wrong in my script? Thanks.

So I've played around with this more, and now clients can no longer connect.

What happens instead?

Tobias Brunner wrote:

What happens instead?

When trying to connect from my phone it just hangs on “Connecting...” for a few moments and then just goes to disconnected. Running ipsec status says 0 connected and 0 connecting.

What happens instead?

When trying to connect from my phone it just hangs on “Connecting...” for a few moments and then just goes to disconnected. Running ipsec status says 0 connected and 0 connecting.

Check the server log. If no message is received, your firewall rules are most likely the problem (although they look OK in regards to IKE ports), otherwise, there should be an error message (at least if the problem is on the server).

Tobias Brunner wrote:

What happens instead?

When trying to connect from my phone it just hangs on “Connecting...” for a few moments and then just goes to disconnected. Running ipsec status says 0 connected and 0 connecting.

Check the server log. If no message is received, your firewall rules are most likely the problem (although they look OK in regards to IKE ports), otherwise, there should be an error message (at least if the problem is on the server).

journalctl -u strongswan output

-- Logs begin at Wed 2018-05-30 10:56:37 EDT, end at Wed 2018-05-30 11:28:51 EDT. --
May 30 10:56:38 wickedlizerd systemd[1]: Starting strongSwan IPsec services...
May 30 10:56:38 wickedlizerd ipsec[349]: Starting strongSwan 5.3.5 IPsec [starter]...
May 30 10:56:38 wickedlizerd ipsec_starter[349]: Starting strongSwan 5.3.5 IPsec [starter]...
May 30 10:56:38 wickedlizerd systemd[1]: Started strongSwan IPsec services.
May 30 10:56:38 wickedlizerd charon[433]: 00[DMN] Starting IKE charon daemon (strongSwan 5.3.5, Linux 2.6.32-042stab127.2, x86_64)
May 30 10:56:38 wickedlizerd charon[433]: 00[LIB] plugin 'load-tester': failed to load - load_tester_plugin_create returned NULL
May 30 10:56:38 wickedlizerd charon[433]: 00[KNL] unable to set IPSEC_POLICY on socket: Operation not permitted
May 30 10:56:38 wickedlizerd charon[433]: 00[NET] installing IKE bypass policy failed
May 30 10:56:38 wickedlizerd charon[433]: 00[KNL] unable to set IPSEC_POLICY on socket: Operation not permitted
May 30 10:56:38 wickedlizerd charon[433]: 00[NET] installing IKE bypass policy failed
May 30 10:56:39 wickedlizerd charon[433]: 00[LIB] loaded plugins: charon test-vectors unbound ldap pkcs11 aes rc2 sha1 sha2 md4 md5 rdrand random nonce x509
May 30 10:56:39 wickedlizerd charon[433]: 00[LIB] dropped capabilities, running as uid 0, gid 0
May 30 10:56:39 wickedlizerd charon[433]: 00[JOB] spawning 16 worker threads
May 30 10:56:39 wickedlizerd ipsec_starter[429]: charon (433) started after 940 ms

/var/log/syslog after running ipsec restart and trying to connect

May 30 11:32:50 wickedlizerd charon: 00[DMN] signal of type SIGINT received. Shutting down
May 30 11:32:50 wickedlizerd ipsec[2165]: Stopping strongSwan IPsec failed: starter is not running
May 30 11:32:52 wickedlizerd charon: 00[DMN] Starting IKE charon daemon (strongSwan 5.3.5, Linux 2.6.32-042stab127.2, x86_64)
May 30 11:32:52 wickedlizerd charon: 00[LIB] plugin 'load-tester': failed to load - load_tester_plugin_create returned NULL
May 30 11:32:52 wickedlizerd charon: 00[KNL] unable to set IPSEC_POLICY on socket: Operation not permitted
May 30 11:32:52 wickedlizerd charon: 00[NET] installing IKE bypass policy failed
May 30 11:32:52 wickedlizerd charon: 00[KNL] unable to set IPSEC_POLICY on socket: Operation not permitted
May 30 11:32:52 wickedlizerd charon: 00[NET] installing IKE bypass policy failed
May 30 11:32:52 wickedlizerd charon: 00[LIB] loaded plugins: charon test-vectors unbound ldap pkcs11 aes rc2 sha1 sha2 md4 md5 rdrand random nonce x509 revocation acert pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey dnscert ipseckey pem openssl gcrypt fips-prf gmp agent chapoly xcbc cmac hmac ctr ccm gcm ntru bliss curl soup mysql sqlite attr kernel-netlink resolve socket-default connmark farp stroke updown eap-identity eap-sim eap-sim-pcsc eap-aka eap-aka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc xauth-generic xauth-eap xauth-pam xauth-noauth tnc-tnccs tnccs-20 tnccs-11 tnccs-dynamic dhcp whitelist lookip error-notify certexpire led radattr addrblock unity
May 30 11:32:52 wickedlizerd charon: 00[LIB] dropped capabilities, running as uid 0, gid 0
May 30 11:32:52 wickedlizerd charon: 00[JOB] spawning 16 worker threads
May 30 11:33:08 wickedlizerd python[264]: 2018-05-30 11:33:08,071 | ERROR | sd.collector | checks.collector(unix.py:220) | Cannot extract IO statistics
May 30 11:33:08 wickedlizerd python[264]: Traceback (most recent call last):
May 30 11:33:08 wickedlizerd python[264]:   File "/usr/share/python/sd-agent/checks/system/unix.py", line 122, in check
May 30 11:33:08 wickedlizerd python[264]:     stdout, _, _ = get_subprocess_output(['iostat', '-d', '1', '2', '-x', '-k'], self.logger)
May 30 11:33:08 wickedlizerd python[264]:   File "/usr/share/python/sd-agent/utils/subprocess_output.py", line 39, in get_subprocess_output
May 30 11:33:08 wickedlizerd python[264]:     raise SubprocessOutputEmptyError("get_subprocess_output expected output but had none.")
May 30 11:33:08 wickedlizerd python[264]: SubprocessOutputEmptyError: get_subprocess_output expected output but had none.
May 30 11:33:08 wickedlizerd sd.collector[264]: ERROR (unix.py:220): Cannot extract IO statistics#012Traceback (most recent call last):#012  File "/usr/share/python/sd-agent/checks/system/unix.py", line 122, in check#012    stdout, _, _ = get_subprocess_output(['iostat', '-d', '1', '2', '-x', '-k'], self.logger)#012  File "/usr/share/python/sd-agent/utils/subprocess_output.py", line 39, in get_subprocess_output#012    raise SubprocessOutputEmptyError("get_subprocess_output expected output but had none.")#012SubprocessOutputEmptyError: get_subprocess_output expected output but had none.
May 30 11:33:08 wickedlizerd python[264]: 2018-05-30 11:33:08,101 | INFO | sd.collector | checks.collector(collector.py:811) | gohai file not found
May 30 11:33:08 wickedlizerd sd.collector[264]: INFO (collector.py:811): gohai file not found

journalctl -u strongswan output
[...]
This doesn't look too right..

Yes, that's not good. The daemon requires these policies to prevent IKE packets from getting tunneled, however, it should only have an effect after a tunnel has been established. So it shouldn't prevent clients from connecting (that might be cause by some firewall rules). But it indicates that there might be a problem with IPsec on your host, which isn't really surprising considering that it's OpenVZ (see e.g. this wiki entry on openvz.org).

Tobias Brunner wrote:

journalctl -u strongswan output
[...]
This doesn't look too right..

Yes, that's not good. The daemon requires these policies to prevent IKE packets from getting tunneled, however, it should only have an effect after a tunnel has been established. So it shouldn't prevent clients from connecting (that might be cause by some firewall rules). But it indicates that there might be a problem with IPsec on your host, which isn't really surprising considering that it's OpenVZ (see e.g. this wiki entry on openvz.org).

Sorry, but I'm still a little lost. What should I be doing now?
I'm still learning my ways with Linux, so I'm not sure what I should be doing now. Sorry!

Tobias Brunner wrote:

journalctl -u strongswan output
[...]
This doesn't look too right..

Yes, that's not good. The daemon requires these policies to prevent IKE packets from getting tunneled, however, it should only have an effect after a tunnel has been established. So it shouldn't prevent clients from connecting (that might be cause by some firewall rules). But it indicates that there might be a problem with IPsec on your host, which isn't really surprising considering that it's OpenVZ (see e.g. this wiki entry on openvz.org).

Disregard what I said before. I got the issue fixed. A line in my script was totally wrong and didn't allow clients to connect. We're now back to the original issue, being able to connect, but with no internet.

Edit: Connected via my laptop running Windows 10. I can connect to the VPN with both devices. My phone makes it clear that there is no connection right away, not being able to load anything.
My laptop was still able to access the web after connecting, which was strange but it turned out it was just skipping the VPN all together when IPv4 and IPv6 had no network access. Only other odd thing I've seen is that on my laptop, it's sent 10,000 bytes (It keeps sending about 15 bytes a second) but it has received 0 in return.

Disregard what I said before. I got the issue fixed. A line in my script was totally wrong and didn't allow clients to connect. We're now back to the original issue, being able to connect, but with no internet.

As I mentioned above, this is probably due to a limitation of your OpenVZ setup. Check the server log for errors when the CHILD_SA is attempted to be installed in the kernel to confirm this. If possible, fix your host (see the link above, you might have to discuss this with your VPS provider), or try using kernel-libipsec to run IPsec in userland (but note its limitations, and it still requires the ability to create TUN devices).

Tobias Brunner wrote:

Disregard what I said before. I got the issue fixed. A line in my script was totally wrong and didn't allow clients to connect. We're now back to the original issue, being able to connect, but with no internet.

As I mentioned above, this is probably due to a limitation of your OpenVZ setup. Check the server log for errors when the CHILD_SA is attempted to be installed in the kernel to confirm this. If possible, fix your host (see the link above, you might have to discuss this with your VPS provider), or try using kernel-libipsec to run IPsec in userland (but note its limitations, and it still requires the ability to create TUN devices).

I have TUN/TAP enabled. I was able to enable it last night from my control panel.