Trying to issue static IP#s outside of the "server block" via tun, without success.

rammstein

I'm mainly trying to compartmentalise VPN subnets into four tiers to make firewalling and routing policies much more easily maintained.

To that end, I'm putting Group 1 (lowest trust) into 192.168.255.0/24, with static IP# assignments defined ideally in the CCD directory.
The main "highest trust" group are in 172.16.1.0/24, served dynamically via the internal DHCP as normal.

The basics: Servers are 4.1.x-grsec, with fairly high security profile. Note: when I run a simple DHCP/non-statically-assigned pool, everything works flawlessly.

I am running a two instance OpenVPN server to handle otherwise identical configurations/setups via both tcp and udp.

On the server side, I see errors like:

May  2 13:45:20 bigmomma ovpn-server_tcp[14296]: user1/4.3.2.1:56465 MULTI ERROR: primary virtual IP for user1/4.3.2.1:56465 (192.168.255.3) violates tunnel network/netmask constraint (172.16.1.0/255.255.255.0)
May  2 13:45:20 bigmomma ovpn-server_tcp[14296]: user1/4.3.2.1:56465 MULTI: Learn: 192.168.255.3 -> user1/4.3.2.1:56465
May  2 13:45:20 bigmomma ovpn-server_tcp[14296]: user1/4.3.2.1:56465 MULTI: primary virtual IP for user1/4.3.2.1:56465: 192.168.255.3
May  2 13:45:21 bigmomma ovpn-server_tcp[14296]: user1/4.3.2.1:56465 SENT CONTROL [user1]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 10.1.0.1,dhcp-option DNS 10.2.0.1,route-gateway 172.16.1.1,topology subnet,ping 10,ping-restart 65,socket-flags TCP_NODELAY,ifconfig 192.168.255.3 255.255.255.0,peer-id 0,cipher AES-128-GCM' (status=1)

On the client side, I get this:
https://pastebin.com/ZYsv2y1K

Server is:

OpenVPN 2.5_git x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 13 2017
library versions: OpenSSL 1.1.0e  16 Feb 2017, LZO 2.06
Originally developed by James Yonan
Copyright (C) 2002-2017 OpenVPN Technologies, Inc. <sales@openvpn.net>
Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=yes enable_fragment=yes enable_iproute2=no enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_management=yes enable_multi=yes enable_multihome=yes enable_pam_dlopen=no enable_password_save=yes enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=no enable_werror=no enable_win32_dll=yes enable_x509_alt_username=yes with_crypto_library=openssl with_gnu_ld=yes with_ifconfig_path=/sbin/ifconfig with_mem_check=no with_sysroot=no

Clients are 2.4.1 (release) on both Windows (7 x64 Ultimate) and Linux (4.x). They're test VMs running behind VIrtualBox's own NAT on a host that is behind NAT as well, but otherwise unfirewalled. The main network router is a small Linux host (4.1.x-grsec based) with several NICs using the normal stateful rules (iptables). When I assign a static IP# from the 172.16.1.0/24 pool, it works flawlessly.

The documentation and HOWTO on the OpenVPN site are very misleading if not outright wrong, at least for 2.4+. The provided examples of three tiers of subnets using ccd doesn't work at all.

Configuration files + helper scripts follow:
local 1.2.3.4
cd /etc/openvpn2
port 80
proto tcp
dev tunvpn0
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
dh dh2560.pem
topology subnet
server 172.16.1.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir ccd
route 192.168.255.0 255.255.255.0 172.16.1.1
learn-address /etc/openvpn2/learn-address.sh
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 10.1.0.1"
push "dhcp-option DNS 10.2.0.1"
keepalive 10 65
tls-auth ta.key 0
cipher AES-128-GCM
auth sha256
comp-lzo
max-clients 32
user vpn
group vpn
up '/etc/openvpn2/up.tun'
persist-key
persist-tun
remote-cert-eku "TLS Web Client Authentication"
status openvpn.server_tcp.status
verb 3
mute 15
ncp-ciphers "AES-128-GCM:AES-256-GCM:AES-128-CBC"
tls-version-min 1.2
tcp-nodelay
tcp-queue-limit 128 UDP Configuration:local 1.2.3.4
cd /etc/openvpn2
up '/etc/openvpn2/up.tun'
port 80
proto udp
dev tunvpn1
ca ca.crt
cert server.crt
key server.key
dh dh2560.pem
topology subnet
server 172.16.1.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir ccd
route 192.168.255.0 255.255.255.0 172.16.1.1
learn-address /etc/openvpn2/learn-address.sh
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 10.1.0.1"
push "dhcp-option DNS 10.2.0.1"
keepalive 10 65
tls-auth ta.key 0 # This file is secret
cipher AES-128-GCM
auth sha256
comp-lzo
max-clients 32
user vpn
group vpn
persist-key
persist-tun
remote-cert-eku "TLS Web Client Authentication"
status openvpn.server_udp.status
verb 3
mute 15
ncp-ciphers "AES-128-GCM:AES-256-GCM:AES-128-CBC"
tls-version-min 1.2 learn-address.sh:

if [ $# -lt 2 ]; then
  exit 0;
fi
action=$1;
addr=$2;
 
case ${action} in
        add|update)
                echo "[-] ${addr} logged in to ${dev}" >> vpn.log
                /usr/bin/sudo /bin/ip ro del ${addr}/32
                /usr/bin/sudo /bin/ip ro add ${addr}/32 dev ${dev};
        ;;
        delete)
                # Found out we'd better do nothing when delete is called.
               echo "[-] Deleting addr ${addr} -> ${dev}" >> vpn.log
               /usr/bin/sudo /bin/ip ro del ${addr}/32 &> /dev/null
        ;;
        *)
        ;;
esac
 
exit 0;

up.tun:

#!/bin/bash
/bin/echo 1 > /proc/sys/net/ipv4/conf/${1}/forwarding
exit 0

dev tun
proto tcp
remote my.vpn.com 80
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
remote-cert-tls server
cipher AES-128-GCM
auth sha256
comp-lzo adaptive
socket-flags TCP_NODELAY
verb 2
# Silence repeating messages
mute 30
key-direction 1
verify-x509-name 'CN=my.vpn.com' subject
remote-cert-eku "TLS Web Server Authentication"

### Windows specific options ###
block-outside-dns
dhcp-option NTP 10.2.0.1
dhcp-option DISABLE-NBT
dhcp-option DOMAIN vpn0.my.vpn.com
register-dns
### End of Windows specific options ###

<ca>
-----BEGIN CERTIFICATE-----
(snip)
-----END CERTIFICATE-----
</ca>
<cert>
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 6 (0x6)
Signature Algorithm: ecdsa-with-SHA256
(snip)
-----BEGIN CERTIFICATE-----
(snip)
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN ENCRYPTED PRIVATE KEY-----
(snip)
-----END ENCRYPTED PRIVATE KEY-----
</key>
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
(snip)
-----END OpenVPN Static key V1-----
</tls-auth>ifconfig-push 172.16.1.253 255.255.255.0

TinCanTech

rammstein wroteThe documentation and HOWTO on the OpenVPN site are very misleading if not outright wrong, at least for 2.4+. The provided examples of three tiers of subnets using ccd doesn't work at all.

Do you mean this ?
https://openvpn.net/index.php/open-source/documentation/howto.html#policy

rammstein

Yes. The second parametre of the ifconfig-push is a netmask when using tun for a start. I discovered this by scrutinising the client connection log and looking at the VPN host's routing table during connection attempts.

I am open to the possibility that what I'm attempting to do is "impossible" under tun mode, which is a shame, as I really do NOT need the VPNs to offer bridging support. It would mean more network policy tables to keep updated.

Is it possible to use more than one server block to indicate IP#s in the subnet I'm trying to use.

Essentially, I'm hoping to put each trust tier into its own /24 subnet and just create simple firewalling policies around that. I *REALLY* don't want to be doing eeny-meeny-miney-mo types of firewalling rulesets to segregate different users' access rights.

Incidentally, I'm sure browsing the source would eventually give me the answer, but am I correct in assuming that if a given ccd configuration assigns a certain IP# to a client, there is NOTHING they can do (under tun, at least) to disregard it and attempt to use another IP#? Let's assume they forked the OpenVPN client code into something "nefarious" to help out.

TinCanTech

TinCanTech wrote
rammstein wroteThe documentation and HOWTO on the OpenVPN site are very misleading if not outright wrong, at least for 2.4+. The provided examples of three tiers of subnets using ccd doesn't work at all.
Do you mean this ?
https://openvpn.net/index.php/open-source/documentation/howto.html#policy

rammstein wroteYes. The second parametre of the ifconfig-push is a netmask when using tun for a start

Only if you use --topology subnet .. the guide above is written with --topology net30 in mind. :geek:

rammstein wroteIs it possible to use more than one server block to indicate IP#s in the subnet I'm trying to use.

No .. one network/mask per --server and one --server per config. You can run more than one server config though (on unique port numbers).

rammstein wroteEssentially, I'm hoping to put each trust tier into its own /24 subnet and just create simple firewalling policies around that

A simple approach would be --server 10.8.0.0 255.255.0.0 and assign all clients statically from which /24 you desire.

rammstein wroteIncidentally, I'm sure browsing the source would eventually give me the answer, but am I correct in assuming that if a given ccd configuration assigns a certain IP# to a client, there is NOTHING they can do (under tun, at least) to disregard it and attempt to use another IP#?

No .. the client can ignore your pushed parameters completely if they wish and try to hack into your network anyway they see fit. --pull-filter allows total control of what the client accepts. :o

rammstein wroteLet's assume they forked the OpenVPN client code into something "nefarious" to help out.

The code is open source so they can even try hacking the source .. Of course, their code would probably never be accepted into the true source tree. Also, if they publish their code then the real openvpn devs would be able to take mitigating action if such code posed a real threat.

The OpenVPN bottom line is this ..

See: https://github.com/OpenVPN/openvpn/blob/master/COPYRIGHT.GPL
OpenVPN provides a secure VPN which, until proven otherwise, is impervious to attack by an outsider/MITM.
(Attacks like Heartbleed and SWEET32 are outstanding examples of such)
SSL libraries provide the certificate/key chain of trust between peers which OpenVPN relies on.
(OpenSSL*, LibreSSL* and mbedtls(PolarSSL)* are the currently implemented Libraries. * work in progress)
All of this is Free Open Source Software (FOSS) and open to attack on all sides ..
From a genius hacking the source code to script kiddies playing around.

Therefore, if security is an overwhelming concern for you then you need to invest in your security model, consulting a security professional is always a good start. If you are working on a very tight budget then I would recommend following the openvpn developer mailing list for up to date information. However, you must be aware that the Devs are not going to teach you about internet security, that is still your own responsibility.

There are alternatives to OpenVPN but I cannot possibly recommend any of them 😉

TiTex

TinCanTech wroteNo .. the client can ignore your pushed parameters completely if they wish and try to hack into your network anyway they see fit. --pull-filter allows total control of what the client accepts. :o

If i remember correctly i tried this once , but the client cannot disregard the IP address the server is assigning to him ... what i mean is that you can't just configure manually the IP address on your client's TUN/TAP device and expect it to work. It won't. The client must use the IP address that was assigned to it by the server, at least that's what i'm getting from my tests.
Feel free to try it out.

TinCanTech

@ Titex .. agreed.

I was simply making the point that the client does have total control of what they accept from the server.
A client can ignore all the pushed parameters and apply their own but that does not mean it will work :mrgreen:

IMHO, the --pull-filter is a tool for extreme corner cases and it probably needs cooperation from the server admin for any client side changes to work .. but it is also open to abuse :twisted:

rammstein

UGH, ok.

If the server documentation mentioned anything that remotely translated to:

"This is the entirety of the netblock from which you can allocate IP#s from", I'd not even have been driven to register to yet-another-forum/support website and wasted your time.

It's a pity that that OpenVPN can't decouple port#s/ip# of listening sockets from "configurations" and instead bind configurations to whichever provided key produces a binding match to a signed cert on initial login. My selection of port#s/protocols stems more from mitigations of client-side connectivity issues than certificate-issuance-related concerns.

Put perhaps more simply: when I issue a given .ovpn/signed key, I would like to provide some flexibility in how the end-user connects to suit the environment they encounter in the wild, rather than bind implicit security policy to the selection of destination IP#/port/protocol. Or is that just being too much like a n00b?

The code is open source so they can even try hacking the source .. Of course, their code would probably never be accepted into the true source tree. Also, if they publish their code then the real openvpn devs would be able to take mitigating action if such code posed a real threat.

I highly doubt such people would ever:
1) submit their modifications to the master source tree, -or-
2) widely publish their changes in any way.

This defeats the point, that is, to use valid credentials for a "lower-class" account to obtain a "higher-class" IP# (thus IP-routing/firewalling policies) by subverting the protocol to escalate privileges beyond which the server would normally confer.

TiTex

TinCanTech wroteA simple approach would be --server 10.8.0.0 255.255.0.0 and assign all clients statically from which /24 you desire.

Yep, and using this approach would do what he wants , he just has to figure out what subnets carved from 10.8.0.0/16 wants to use and do the firewalling accordingly

TinCanTech

rammstein wrotePut perhaps more simply: when I issue a given .ovpn/signed key, I would like to provide some flexibility in how the end-user connects to suit the environment they encounter in the wild, rather than bind implicit security policy to the selection of destination IP#/port/protocol. Or is that just being too much like a n00b?

Again, seperate server instances and multiple client --remotes or even entire configs.

rammstein wroteIf the server documentation mentioned anything that remotely translated to:

"This is the entirety of the netblock from which you can allocate IP#s from", I'd not even have been driven to register to yet-another-forum/support website and wasted your time.

OpenVPN makes no constraints on what you can assign other than one range per server, which is totally acceptable for Free software. Perhaps you need to consider either a different approach (a standard approach not your current idea) or other software hardware to build/manage your environment. No time has been wasted 8-)

One final word with regard to your concerns of unacceptable client behaviour :

OpenVPN uses *SSL Certificate Authority (Just like the rest of the internet) to provide validated connections between server and client. However, the Trust that you impart to your clients is a matter for you to manage. As open source software there is little more OpenVPN can do .. and trust me, I have bought this up with the developers and the point has been clearly explained.

The example which I was curious about was locking the client.profile+machine by means of a "config file + machine specific hardware" HASH .. the answer is that OpenVPN does not provide this because the source is open and such a mechanism is not so hard to forge while it's implementation goes way beyond OpenVPN's goals.

However, one of the developers is working on something similar called http://www.eurephia.net/

Perhaps, my advice is not 100% accurate .. if a knowledgeable person would like to comment 8-)

dazo

TinCanTech wrote One final word with regard to your concerns of unacceptable client behaviour :
OpenVPN uses *SSL Certificate Authority (Just like the rest of the internet) to provide validated connections between server and client. However, the Trust that you impart to your clients is a matter for you to manage. As open source software there is little more OpenVPN can do .. and trust me, I have bought this up with the developers and the point has been clearly explained.

The example which I was curious about was locking the client.profile+machine by means of a "config file + machine specific hardware" HASH .. the answer is that OpenVPN does not provide this because the source is open and such a mechanism is not so hard to forge while it's implementation goes way beyond OpenVPN's goals.

However, one of the developers is working on something similar called http://www.eurephia.net/

So I'm behind the eurephia project. It's ageing and have not seen much development in a while. That said, it is deployed several places, where it works quite well. And I'm pondering on making LDAP user/password auth finally happen, possibly even with a SSSD integration (which can cache credentials if the auth-backend is unavailable) and FreeIPA support.

My motivation for writing eurephia is exactly what TinCanTech highlights. You can never trust the client. What you can trust is the environment you control, which in essence is the server. So eurephia can tie certificates to a usernames, which then results in an access profile. This access profile is used to do firewall updates on the fly.

If you choose to deploy different certificates per device, the access to services behind the VPN server can then be different. There are however not too hard for a (clever) user to circumvent this, by just copying over the certificate from one device to another one. This can of course be hardened further in eurephia to analyze the client details (there's a lot of IV_ peer-info details which provides some client details). But, as the source code to OpenVPN is fully open, there are no guarantee that the user won't have compiled its own OpenVPN build providing faked information. It will in the end be a cat-and-mouse game, where the winner is just the one who sustains this game the longest. So this isn't something I'm too keen on making too complicated.

These days I believe more in written policies, defining what a user is allowed to do and consequences what will happen the user breaks the policy. Then a breakage can become a legal affair instead, which might be easier to scare users with than trying to solve this from a technical point of view. The technical solutions to controll users will generally just be overly over-engineered which doesn't even fill all the possible gaps, and for a technical solution to really work you need to have tackled all those possible gaps. That doesn't mean eurephia doesn't play a reasonable role; it does enable some sane restrictions to your users. However it is possible to escape those restrictions by being technically clever, and at that point a user will have had to take deliberate steps which can be explicitly forbidden to do in a written policy. Then deploying some control mechanisms (by studying peer-info or other interesting details in logs on the server) you can to some degree detect what is happening and take the legal actions based on that.

rammstein

My concern is less about spoofed certificates or issues of the wrong device using a given certificate. You either trust the underlying security of your PKI or you don't. By their nature in many cases, you may use the same client profile on more than one device. I assume the client profile to be of low security sensitivity, as I require authentication to decrypt the client key. I wish OpenVPN provided for encrypting the entire profile, which would let me conceal the server's HMAC key from casual inspection, but oh well.

The issue is one of an "attacker" who notices another user's VPN profile gives them a "better" view of internal resources and who notes the provided IP# (easy to determine without elevated privileges), assuming that the VPN server is making routing + firewalling policy decisions based around the client's IP# - usually a correct assumption on most servers.

I agree that more than a technical approach is merited, but at the end of the day, for a BOFH's peace of mind, a defensive posture that at the very least closes off (or makes very difficult) the access to low-hanging "exploits" is what I'm after.

It may very well be that such a "spoofing" (trying to use another client's IP# as your own, whether or not they're currently connected at the same time) is impossible under tun mode with the code (and Linux) as they are. I would expect (hope?) that ARP requests for that IP# are completely generated and fielded by the server, and so both reads and writes from/to any given user's assigned IP# will be the only IP# involved in the transaction in question.

To use a local ethernet connectivity via a "dumb" switch as an example:

Many organisations use IP# based firewalling/routing policies, and use DHCP to assign various users' IP#s (and thus, their access "rights") via the connected MAC ids. But nothing stops anyone from disabling DHCP in their device, and statically assigning themselves an IP# of a "better" class of user, or even reprogramming their local ethernet adaptor's MAC address to match the "better" IP#''s user's device and continuing with DHCP.

"Smart" switches can filter MAC addresses based on physical port number, at least. You can probably define ebtables rules to filter "unauthorised" use of anything other than the assigned IP# to the user's device, assuming you're content with the risks that MAC addresses are not hard to forge.

TinCanTech

rammstein wroteThe issue is one of an "attacker" who notices another user's VPN profile gives them a "better" view of internal resources and who notes the provided IP#

dazo wroteThese days I believe more in written policies, defining what a user is allowed to do and consequences what will happen the user breaks the policy. Then a breakage can become a legal affair instead, which might be easier to scare users with than trying to solve this from a technical point of view.

OpenVPN provides the VPN and *SSL provides the verification of peers. And all this is for free. As for the rest of your security concerns, you will have to consider other solutions ..

The simplest solution I can think of is to issue your users with a username+password to verify who they are.