2

The sample OpenVPN configuration in Debian documentation https://wiki.debian.org/OpenVPN gives the following code.

Server /etc/openvpn/tun0.conf:

dev tun0 
ifconfig 10.9.8.1 10.9.8.2 
secret /etc/openvpn/static.key

Client /etc/openvpn/tun0.conf:

remote your-server.org
dev tun0
ifconfig 10.9.8.2 10.9.8.1
secret /etc/openvpn/static.key

My question: how to adapt this to handle more than one client? Without hard coding IPs on the clients?

AsTeR
  • 257
  • 4
  • 13

2 Answers2

1

I am another such lazy and inexperienced person. I can't use wireguard or vxlan tunnels because I don't know up front all my VPN clients (to predeclare point-to-point tunnels) and my clients don't share an l2 segment with the VPN server (that would allow for multicast vxlan). Moreover, I can't easily tunnel through NAT with vxlan. Finally, I might want to connect from a macOS computer. So, OpenVPN it is.

Server config

Create the certificates. Public certificate for the server is sufficient. You can either use easy-rsa, or you can do it on your own with openssl. I prefer openssl.

On RHEL 9, do this

dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
dnf install -y openvpn easy-rsa openssl

When using easy-rsa, that got installed into

/usr/share/easy-rsa/3.0.8/easyrsa

When using openssl, create certificate authority and server certificate. Use the -nodes parameter for openssl to avoid having to specify password for the generated certificates.

openssl req -nodes -x509 -newkey rsa:4096 -sha256 -days 3650 -keyout ca-key.pem -out ca-cert.pem -subj "/CN=TestCA"

openssl req -nodes -newkey rsa:4096 -keyout server-key.pem -out server-csr.pem -subj "/CN=localhost"
openssl x509 -req -in server-csr.pem -CA ca-cert.pem -CAkey ca-key.pem -out server-cert.pem -days 365

openssl dhparam -out dh.pem 2048

Create config following the sample in https://github.com/OpenVPN/openvpn/blob/master/sample/sample-config-files/server.conf

proto udp
dev tun
ca ca-cert.pem
cert /root/server-cert.pem
key /root/server-key.pem
dh /root/dh.pem
verify-client-cert none
auth-user-pass-verify /bin/true via-env
script-security 3
server 11.8.0.0 255.255.255.0
push "route 11.0.0.0 255.0.0.0" 
push "redirect-gateway local"
topology subnet
explicit-exit-notify 1

Now run server with

# openvpn --config openvpn.config 
2023-07-20 23:32:55 WARNING: Compression for sending and receiving enabled. Compression has been used in the past to break encryption. Allowing compression allows attacks that break encryption. Using "--allow-compression yes" is strongly discouraged for common usage. See --compress in the manual page for more information 
2023-07-20 23:32:55 --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
2023-07-20 23:32:55 WARNING: POTENTIALLY DANGEROUS OPTION --verify-client-cert none|optional may accept clients which do not present a certificate
2023-07-20 23:32:55 OpenVPN 2.5.9 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 16 2023
2023-07-20 23:32:55 library versions: OpenSSL 3.0.7 1 Nov 2022, LZO 2.10
2023-07-20 23:32:55 WARNING: --keepalive option is missing from server config
2023-07-20 23:32:55 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2023-07-20 23:32:55 TUN/TAP device tun0 opened
2023-07-20 23:32:55 net_iface_mtu_set: mtu 1500 for tun0
2023-07-20 23:32:55 net_iface_up: set tun0 up
2023-07-20 23:32:55 net_addr_v4_add: 11.8.0.1/24 dev tun0
2023-07-20 23:32:55 Could not determine IPv4/IPv6 protocol. Using AF_INET
2023-07-20 23:32:55 UDPv4 link local (bound): [AF_INET][undef]:1194
2023-07-20 23:32:55 UDPv4 link remote: [AF_UNSPEC]
2023-07-20 23:32:55 Initialization Sequence Completed

Client config

Copy ca-cert.pem to all clients. Then configure clients in the NetworkManager GUI for KDE.

enter image description here

Don't forget to enable "Use only for resources on this connection", from https://serverfault.com/a/469131/116739, otherwise all your traffic will go through the VPN by default, which you may not want.

enter image description here

user7610
  • 214
  • 1
  • 9
0

Try

server 10.9.8.0 255.255.255.0

on the server, and

client

on the clients. The server should take the first address in the range (10.9.8.1) for itself, then hand out the others to the clients; the clients should accept those assignations.

MadHatter
  • 79,770
  • 20
  • 184
  • 232
  • 1
    Thanks for the advice, unfortunately `Options error: --server and --secret cannot be used together (you must use SSL/TLS keys)` – AsTeR Aug 08 '14 at 15:10
  • Then it's clear that, by design, you can't use a single-shared-secret to connect more than two endpoints; if you want more than a simple ad-hoc network, a proper key infrastructure is unavoidably imposed upon you. Are there good business reasons not to like such a prospect? – MadHatter Aug 08 '14 at 15:27
  • 1
    It's mostly laziness and inexperience, I'm trying to pick the simplest way. In my case, this VPN will be setup between VM instances to connect to another network, if one VM is compromised, the whole image should be trashed. The static key could have been enough in terms of security. – AsTeR Aug 08 '14 at 15:34
  • The simplest way is probably public-key - it's so well-documented that it's really quite painless to set up. – MadHatter Aug 08 '14 at 15:42