1

I have set up static IP configuration for clients connecting to OpenVPN server running on AWS EC2 (CentOS) instance. Purpose of assigning static IP is to allot QUOTA using iptables to every client so that bandwidth usage is under control.

Following are my configurations:

server.conf:

mode server
tls-server
dev tun

topology subnet
push "topology subnet"

ifconfig 10.8.1.1 255.255.255.0
push "route-gateway 10.8.1.1"

port 443
proto tcp-server

push "redirect-gateway def1 bypass-dhcp"

ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
tls-crypt tc.key
cipher AES-256-CBC

user nobody
group nobody
persist-key
persist-tun

client-config-dir /etc/openvpn/ccd/

management localhost 7505

/etc/openvpn/ccd/client:

ifconfig-push 10.8.1.2 255.255.255.0

iptables rules:

-P FORWARD DROP
-A FORWARD -d 10.8.1.2/32 -g client
-A FORWARD -s 10.8.1.2/32 -g client
-A client -m quota --quota 10000000000 -j ACCEPT

client.ovpn:

client
dev tun

remote-cert-tls server
cipher AES-256-CBC

pull
resolv-retry infinite

remote xyz.dynu.net 443 tcp-client
nobind

<ca> ... </ca>
<cert> ... </cert>
<key> ... </key>
<tls-crypt> ... </tls-crypt>

Clients include Windows, Linux and Android users.

My questions are:

  • Is it possible for client (by manually configuring IP addresses and routes) to use IP 10.8.1.3 instead of 10.8.1.2 which was pushed from server?
  • If yes, how can we prevent this?

I don't prefer topology net30 because that's getting obsolete and leaves with smaller IP pool for clients.

A similar question is asked here: Prevent openvpn client from changing ip of tap device but that's not for tun devices.

An old thread missing link Forcing the client to accept ifconfig-push states:

When it (OpenVPN server) receives a packet from a particular client, it does a reverse-path check to confirm that if it were sending to the source IP address, it would send to that client. If not, it drops the packets.

So if the client chooses a different IP address, the packets won't get through.

Is this behavior documented somewhere and does this hold true for latest OpenVPN releases (2.4.6)?

Irfan Latif
  • 121
  • 1
  • 2
  • 6

1 Answers1

5

The quote from Neil Brown in the old thread, that you posted, is followed by a reference to the source code:

See the comment at line 1605 of multi.c and the surrounding code.

I think he was referring to the comment that is now at line 2569:

/* make sure that source address is associated with this client */

Later on, at lines 2580 and 2690, you can see that this can result in the following log message:

"MULTI: bad source address from client [%s], packet dropped"

So my guess would be that it still holds true today.

For future reference, "today" refers to version 2.4.7.

Edit:

I set up a test OpenVPN server today. I also set up a rule in the machine's firewall to count all incoming packets from the virtual interface. After connecting from a client, I was able to ping another address reachable through the server and the counter was incrementing (even for non-existent hosts). I then changed the address on the client interface:

ip a add 192.168.1.3/24 dev tun0
ip a del 192.168.1.2/24 dev tun0

I was not able to ping anything through that interface anymore and the counter was not incrementing. It looks like the client was still sending the packets through the tunnel because when I set verbosity to 5 on the client, I would get a rW for each ping packet sent. r represents a packet received from the tun interface (from the perspective of the openvpn process) and W is that packet encapsulated and sent to the server. (Normally I would also get Rw if there were a reply.) This suggests that the packets were being dropped server-side, which is good.

I did not see the packets being dropped in the server openvpn's log, but that is probably because my verbosity was set to 3 and according to this, D_MULTI_DROPPED shows up only at 4 and above.

I then changed the address back to the originally assigned one (without restarting the connection):

ip a add 192.168.1.2/24 dev tun0
ip a del 192.168.1.3/24 dev tun0

And everything was working again, the counter was incrementing and existing hosts were replying.

Karel Vlk
  • 151
  • 1
  • 3