OVPN clients appear from public IP

philibuster

Hi,

We've restricted our web apps (using nginx) so they're only accessible from internal IPs which includes the subnet assigned to OVPN clients. All other IP ranges are denied. However OVPN clients appear (to nginx) as from the public IP of their internet connection rather than their OVPN (10.8.0.0/24) range.

Any idea how we can fix this so clients appear from their OVPN range?

Many thanks

maikcat

post configs used and tell us more about your setup.

Michael.

philibuster

Yes sorry, wanted to edit to add detail, but couldn't as was my first post so had to be moderated.

Our web apps are also published externally through nginx, but ping and tracert both show traffic is taking the OVPN route to them.

client config:

dev tun
proto tcp
remote remote.DOMAIN_NAME.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca "C:\\PATH_TO_CA_CERT"
cert "C:\\PATH TO CLIENT CERT"
key "C:\\PATH TO CLIENT KEY"
comp-lzo
verb 3
auth-user-pass
reneg-sec 0
auth-retry interact

And server:

port 1194
proto tcp
dev tun
ca /PATH TO CA CERT
cert / PATH TO HOST CERT
key /PATH TO KEY FILE  
dh /etc/ssl/dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 10.1.0.0 255.255.255.0"
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3
push "dhcp-option DNS 10.1.0.1"
plugin /opt/duo/duo_openvpn.so DUO_CREDENTIALS
reneg-sec 0

Our OVPN server also runs various web apps, so we run SSLH to allow port 443 sharing between SSL and OVPN, and this re-routes incoming traffic (to TCP 1194 in the case of OVPN). Any ideas why nginx sees OVPN clients as from their public ip (and hence is blocking them)? Many thanks.

maikcat

so we run SSLH to allow port 443 sharing between SSL and OVPN, and this re-routes incoming traffic (to TCP 1194 in the case of OVPN).

if i understood correctly you are perfoming ssh forwarding via openvpn server,

meaning,

you connect to openvpn then open an ssh session with port forwarding enabled,right?

if you do that ALL traffic passing the ssh tunnel is indeed seems to come from openvpn server itself.

Michael.

philibuster

We are doing no ssh forwarding, are you suggesting we do so? SSLH is a program that listens on port 443, and detects whether it's SSL, OVPN traffic or something else. If it's OVPN, it redirects it to TCP 1194 which is what the OVPN server listens on.

maikcat

We are doing no ssh forwarding, are you suggesting we do so?

no, i understood wrong.

can you post the output of:

iptables -t nat -L
on your openvpn server?

Michael.

philibuster

Here you go:

:~$ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

maikcat

which ip is your nginx server?is this the same as openvpn servers public ip?

can you tell me how exactly do you access nginx server?

Michael.

philibuster

Yes it's the same server, same public and private IP. We access from OVPN Client via SSHL to OVPN Server, the latter two reside on the same server along with nginx, which acts as reverse proxy to various websites. The nginx logs show OVPN clients are blocked because nginx thinks they're public IP addresses. On what IP do others generally see their OVPN Clients? Is it their public or private IP? I'd have thought it should be the latter.

maikcat

Yes it's the same server, same public and private IP.

your problem really troubles me, here is why:

in your configs you are pushing only a route to 10.1.0.0/24 network to your clients,
if you try to access your nginx server via its private ip then you should see your openvpn clients vpn ip
while you are not perfoming any type of NAT anywhere there is no possible for your
clients to access a private ip range via their public interface.

a tcpdump on openvpn server may enlighten this situation...

Michael.

philibuster

Apologies, I should have pointed out there is also an edge router that does indeed NAT from public IP of the router to the private IP of the OVPN server.

Yes our internal network is 10.1.0.0/24 so this is the only route we push. If in this scenario nginx should see OVPN Clients' internal (OVPN) IP, but this is not happening, then I think this is down to the SSLH proxying rather than any issue with OVPN. I'll be able to validate this by temporarily disabling SSLH and make OVPN listen on TCP 443. If this fixes (and pinpoints the cause as SSLH) we'll have to find another way, such as buying a second public IP address only for OVPN so SSLH does not have to be used.

philibuster

I've worked around without having to buy a second IP. Instead of using SSLH, I've changed the OVPN server from TCP 443 to TCP 21. Nginx now listens on 443 rather than SSLH and see's OVPN Clients from their internal IP (10.8.0.0/24).

Downside of this approach is TCP 21 isn't as widely open in firewalls as 443. We already use TCP 80 for something else. I tried UDP 53, as I expect this is open everywhere (?), but couldn't get OVPN to work. Can anyone think of a more widely port (TCP or UDP) than TCP 21?