Join Log in
Score:0
ihorc avatar Server

OpenVPN route to the server itself over the tunnel

cn flag
ihorc

I want to use an OpenVPN connection to access my local resources. I have iptables set to allow connection from 192.168.1.0/24 subnet. When I connect from my phone or Windows machine everything works perfectly fine. But when I try to connect from Ubuntu it does not.

After checking tcpdump and reading a lot of logs I see that packets from Ubuntu have SRC=real white ip while for phone or Windows SRC=local tunnel ip and it works as expected.

Then I inspected my routes when connected to the VPN, and found the following (assume 77.77.77.77 - OpenVPN server, 192.168.8.1 - my router):

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.255.5   0.0.0.0         UG    50     0        0 tun0
0.0.0.0         192.168.8.1     0.0.0.0         UG    600    0        0 wlp2s0
77.77.77.77     192.168.8.1     255.255.255.255 UGH   600    0        0 wlp2s0
192.168.8.0     0.0.0.0         255.255.255.0   U     600    0        0 wlp2s0
192.168.8.1     0.0.0.0         255.255.255.255 UH    600    0        0 wlp2s0
192.168.255.1   192.168.255.5   255.255.255.255 UGH   50     0        0 tun0
192.168.255.5   0.0.0.0         255.255.255.255 UH    50     0        0 tun0

I believe the root of my problem is:

77.77.77.77     192.168.8.1     255.255.255.255 UGH   600    0        0 wlp2s0

as it says to use my router as a gateway to access the VPN server itself. As a result, I see my real IP address instead of a tunnel IP address.

But I don't understand how to fix this. I already tried modifying the route manually to route traffic to the server over the tunnel, but it didn't help:

77.77.77.77     192.168.255.5   255.255.255.255 UGH   600    0        0 tun0

So, if all my investigation was understood correctly, to resolve the problem I need to route the traffic to vpn server itself over the tunnel instead of the default gateway. I supposed redirect-gateway def1 directive should redirect ALL traffic over VPN, including itself. But looks like it does not.

My server.conf:

server 192.168.255.0 255.255.255.0
verb 3
key /etc/openvpn/pki/private/vpn.example.com.key
ca /etc/openvpn/pki/ca.crt
cert /etc/openvpn/pki/issued/vpn.example.com.crt
dh /etc/openvpn/pki/dh.pem
tls-auth /etc/openvpn/pki/ta.key
key-direction 0
keepalive 10 60
persist-key
persist-tun
proto udp
port 1194
dev tun0
status /tmp/openvpn-status.log
user nobody
group nogroup
route 192.168.254.0 255.255.255.0
push "block-outside-dns"
push "dhcp-option DNS 192.168.1.1"
push "dhcp-option DOMAIN lan"

My client.ovpn:

client
nobind
dev tun
remote-cert-tls server
remote vpn.example.com 1194 udp
...certificates...
key-direction 1
redirect-gateway def1
59
0 + 0
Tom Yan avatar
in flag
Tom Yan
You seem to be talking about two separate unrelated problems. Accessing other services on your VPN server host or other hosts in the server's LAN has nothing to do with remote address route. Please clarify your goal (without making wild guesses) and setup (e.g. whether your VPN server host is behind NAT or have a public IP configure directly on it)
0
Reply
ihorc avatar
cn flag
ihorc
I want to acess the service which is hosted on my VPN server by domain name, e.g. https://mysite.example.com, which is pointed to 77.77.77.77. The VPN server host is behind the NAT, but all the firewall and port forwarding configuration done properly, as I can access it as expected from other devices with the same config. Also, evertyhing works just fine without the limitation to 192.168.1.0/24 from public. The only problem is that linux client shows his real IP instead of a tunnel IP, thus it can not pass throught corresponding iptables rule (-A INPUT -s 192.168.1.0/24 -j ACCEPT).
0
Reply
Nikita Kipriyanov avatar
za flag
Nikita Kipriyanov
This is impossible. Or, should I say, you have to set up rather curious SVCB DNS records for that, this is out of the scope of the question as if it was formulated. In general, you *either* have to use "internal" (encapsulated) IP address to access the website (so the traffic will go through the VPN) or the "public" IP address which is also used as VPN endpoint, but the traffic will not go through the VPN, because you need a direct route (not via VPN) to that IP address to establish the VPN channel itself. **WHY do you need that?**
0
Reply
ihorc avatar
cn flag
ihorc
Why it works on phone or Windows client then? >>> Why do you need that? - To access my websites as usual by domain. But make them accessible only with VPN.
0
Reply
Nikita Kipriyanov avatar
za flag
Nikita Kipriyanov
Are you sure it works that way? I strongly doubt that. Also, the encryption of OpenVPN is exactly the same as the encryption in HTTPS, and the security is alike; why use VPN at all for that?
0
Reply
ihorc avatar
cn flag
ihorc
Yes, I'm sure. >>> Why use VPN at all for that? - To restrict public access to my websites, obviously.
0
Reply
Tom Yan avatar
in flag
Tom Yan
Probably having the DNS server for the VPN clients resolve the domain to the VPN IP of the server is the cleanest way, although technically you can use policy routing to route only certain (e.g. based on dport) traffics to `77.77.77.77` via the Internet gateway of the client. Whether that will end well ultimately depends on other things though, as that's quite some nasty hairpinning we are talking about here, apparently.
0
Reply
Tom Yan avatar
in flag
Tom Yan
Btw, it would probably be less nasty if you also redirect (as in, dnat to itself) the traffics at the VPN server, so that they won't get to its router and then get hairpinned back, if you are determined to go down that way.
0
Reply
ihorc avatar
cn flag
ihorc
If you mean MASQUERADE rule, it is already there. I'm pretty sure it is something about the NAT Loopback differences on different client OS. That's not server-related issue, as otherwise it would not work on any device. So, basically my goal is very simple - to make a website accessible with VPN only, but it seems more tricky than at a first glance.
0
Reply
Tom Yan avatar
in flag
Tom Yan
No, I mean a REDIRECT rule for destinstion address 77.77.77.77. But that's not a suggestion for you current problem, just an extra tip if you want to stick with this quirky desire/approach. And you current problem isn't about NAT Loopback, but how route is set up for `77.77.77.77` on the different client platform. (It's expected *not* to work on Linux unless you customize the route setup as I mentioned; not sure about Windows but on Android, every app has its own route table so it might work out of the box.)
0
Reply
Tom Yan avatar
in flag
Tom Yan
TL;DR, research about policy routing a.k.a. ip rule. I don't think there's any ovpn config option can help you achieve what you want, other than the fact that you'll need to ditch / filter the default route pushing / setting ones like `redirect-gateway`)
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

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.