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 IP10.8.1.3
instead of10.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)?
Best Answer
The quote from Neil Brown in the old thread, that you posted, is followed by a reference to the source code:
I think he was referring to the comment that is now at line 2569:
Later on, at lines 2580 and 2690, you can see that this can result in the following log message:
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:
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 thetun
interface (from the perspective of theopenvpn
process) andW
is that packet encapsulated and sent to the server. (Normally I would also getRw
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):
And everything was working again, the counter was incrementing and existing hosts were replying.