Nginx sees OpenVPN linux client with its public IP address while android client is seen with private VPN IP address

tr flag

I've set up the following virtual server in my NGINX conf:

server {
   listen 80;
   listen [::]:80;   
   location / {
     default_type text/plain;
     return 200 "$remote_addr\n";

The idea is that I have some other virtual servers that I want to access only using the OpenVPN connection which is on the same machine. Using this test site, it should display the private IP address (or public if not connected to the VPN).

My Android phone works perfectly:

While connecting to the site without VPN connection it displays the following: (It has another address in reality, of course.)

When connecting to the site using the VPN connection, the following is displayed, this is the correct result as it is showing that the device is using the VPN connection and since the VPN service and Nginx server are on the same machine, Nginx sees the private IP of the VPN.

When doing this on my Linux machine, it displays the Linux machine's public IP address when connecting to the server without a VPN connection, and when connecting with a VPN connection it displays the server's public IP address, which is not what I expected.

I suspect there's something wrong with the way OpenVPN is configured on my Linux laptop, as the Android phone is working fine.

OpenVPN Server Config:

port 1194
proto udp6
dev tun
user nobody
group nogroup
keepalive 10 120
topology subnet
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS"
push "dhcp-option DNS"
push "redirect-gateway def1 bypass-dhcp"
server-ipv6 fd42:42:42:42::/112
push tun-ipv6
push "route-ipv6 2000::/3"
push "redirect-gateway ipv6"
dh none
ecdh-curve prime256v1
tls-crypt /etc/openvpn/tls-crypt.key
crl-verify /etc/openvpn/crl.pem
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server_key.crt
key /etc/openvpn/server_key.key
auth SHA256
cipher AES-128-GCM
ncp-ciphers AES-128-GCM
tls-version-min 1.2
client-config-dir /etc/openvpn/ccd
status /var/log/openvpn/status.log
verb 4

OpenVPN Client File (Without keys):

proto udp
remote 1194 # Changed this  for display.
dev tun
resolv-retry infinite
remote-cert-tls server
verify-x509-name server_key name # Changed this because not sure if private info
auth SHA256
cipher AES-128-GCM
tls-version-min 1.2
ignore-unknown-option block-outside-dns
setenv opt block-outside-dns # Prevent Windows 10 DNS leak
verb 3
Nikita Kipriyanov avatar
za flag
Actually, we don't need your Nginx config, but OpenVPN ones. Please, [attach]( them to the question. Also notice, that it if you mask public IP address, don't use any random ones, but choose one from [RFC5737](
tr flag
I would assume that my OpenVPN configs would be fine and the fault would be with my Linux laptop but I will post them for clarity sake. Please see amended description...
Nikita Kipriyanov avatar
za flag
I suspect different clients process *push*-ed dual `redirect-gateway` options differently. For instance, the second option may override the first or not. Wouldn't you try to combine them into single option? Also, if it is possible, attach `ip route` from connected Linux client just after the VPN was connected.
tr flag
How would I need to modify it to include everything in one push statement? I apologize for my lack of knowledge in this regard.
Nikita Kipriyanov avatar
za flag
I mean, instead of two `push "redirect-gateway ..."`, use just one `push "redirect-gateway def1 bypass-dhcp ipv6"`.
tr flag
Here's what IP ROUTE shows: ` via dev tun0 default via dev wlo1 proto dhcp src metric 600 dev tun0 proto kernel scope link src dev wlo1 proto kernel scope link src metric 600 via dev tun0 dev virbr0 proto kernel scope link src linkdown via wlo1 ` I swapped the IP address for privacy :)

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.