Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I'm having a bit of trouble with openvpn routing. I got openvpn installed and can connect to it from a remote machine. Once I connect however, there is no access to the internet or to machines on my LAN.
Here's my set up. I have a home router than runs on the 192.168.5.x address space. My router is 192.168.5.1. The router is a simple TP-Link consumer device. My OpenVPN server (a small machine that sits in the corner of my house) is 192.168.5.12 from the LAN. Server runs Ubuntu server edition. OpenVPN runs on port 2300 TCP.
I am trying to get my server to give remote clients IPs in the same subnet, in the 192.168.5.245-250 range. I want all devices to be on the same subnet, openVPN connections should see everything on the LAN as if they were inside my home and connected to my router.
I think something is messed up with the firewall and I can't figure out what. Here are some outputs:
ip addr:
Code:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:26:2d:18:86:f8 brd ff:ff:ff:ff:ff:ff
inet 192.168.5.12/24 brd 192.168.5.255 scope global enp2s0
valid_lft forever preferred_lft forever
inet6 fe80::226:2dff:fe18:86f8/64 scope link
valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 192.168.5.254 peer 192.168.5.253/32 scope global tun0
valid_lft forever preferred_lft forever
ufw status verbose
Code:
vitali@vitali-server:/etc/openvpn$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), allow (routed)
New profiles: skip
To Action From
-- ------ ----
2300/tcp ALLOW IN Anywhere
22/tcp (OpenSSH) ALLOW IN Anywhere
137,138/udp (Samba) ALLOW IN Anywhere
139,445/tcp (Samba) ALLOW IN Anywhere
2300/tcp (v6) ALLOW IN Anywhere (v6)
22/tcp (OpenSSH (v6)) ALLOW IN Anywhere (v6)
137,138/udp (Samba (v6)) ALLOW IN Anywhere (v6)
139,445/tcp (Samba (v6)) ALLOW IN Anywhere (v6)
port 2300
proto tcp-server
dev tun
mode server
tls-server
ifconfig 192.168.5.254 192.168.5.253
ifconfig-pool 192.168.5.245 192.168.5.250
route 192.168.5.0 255.255.255.0
push "route 192.168.5.254"
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
user nobody
group nobody
Excerpt of /etc/ufw/before.rules
Code:
# START OPENVPN RULES
# NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]
# Allow traffic from OpenVPN client to enp2s0
-A POSTROUTING -s 192.168.5.0/24 -o enp2s0 -j MASQUERADE
COMMIT
# END OPENVPN RULES
Happy to post anything else that would be helpful. Any help is appreciated. Thanks.
Last edited by evilmonkey1987; 11-20-2016 at 01:20 PM.
Let's ignore the above reply (it is entirely untrue and it's trollbait).
So, on the topic:
- Do not use the same subnet for 2 different connections. Why? Because you will confuse things on networking level. You will have 2 connections on the openvpn server within the same network mask which leads to confusion in routing decisions. Also you wanto to NAT the same class on both ends (masquarade). Routing is done strictly, everything has to be exacty defined. Using 192.168.5.x for both is probably doable but it is harder and more error prone and require more configuration (VLSM is not fun when not needed).
Best use something different, like 192.168.6.0/24 for the vpn. Also you have to enable net.ipv4.ip_forward on the vpn server to actually forward incoming packets to the rest of the lan.
-Reaching stuff fron vpn->lan will work since you NAT your way out of the server, but initiating connections lan->vpn will need some additional route, best placed on the router (something like 192.168.6.0/24 is reachable through 192.168.5.12).
- If you use OpenVPN, unless you have a real pressing reason, use UDP. It is designed for best performance that way. Using TCP is a fallback measure, it is not that efficient since you will likely route TCP over TCP which has performance issues if packets get lost (you have 2 layers of TCP packet retransmits etc). OpenVPN has his built in packet resend mechanism in its UDP implementation, don't worry (but anyway who cares if UDP is lost in the tunnel and TCP will be retransmitted anyway by the tunneled TCP layer).
Thanks gradinaruvasile. I had to format the machine that will act as the openvpn server for unrelated reasons, so I now have a clean slate. I'm happy to have openvpn run on a different subnet (either 192.168.6.x or even something like 10.0.1.x). I will need some help however setting up the nat/masquerading.
I don't care about lan to vpn, I only care about vpn to lan. I should not need to make any router configuration in this case, it will be sufficient to simply push the right route to the machine connecting to openvpn and have the openvpn server route the data.
Assuming I can set up openvpn, can you point me to a tutorial on how to set up access from an openvpn client to a machine on my lan?
Thanks gradinaruvasile. I had to format the machine that will act as the openvpn server for unrelated reasons, so I now have a clean slate. I'm happy to have openvpn run on a different subnet (either 192.168.6.x or even something like 10.0.1.x). I will need some help however setting up the nat/masquerading.
I don't care about lan to vpn, I only care about vpn to lan. I should not need to make any router configuration in this case, it will be sufficient to simply push the right route to the machine connecting to openvpn and have the openvpn server route the data.
Assuming I can set up openvpn, can you point me to a tutorial on how to set up access from an openvpn client to a machine on my lan?
Thanks!
Basically you need the following:
Set up openvpn -> you will have something like 192.168.6.1 on the vpn interface.
- Unless you connect Android/Iwhatever phone/tablet, i recommend using tap interface - this will act as a "normal" ethernet device as opposed to tun which is point to point (mobile devices do not have support for tap). ("dev-type tap" in the conf).
- I suggest naming it manually - using the "dev $DEVICENAME" line in the .conf where DEVICENAME is anything you want your network device to be called).
- Other best practices:
-- If possible Use udp for openvpn data transfer (as to why, google "openvpn udp vs tcp")
-- use per-user certificates
-- make use of the ccd options - this will permit per-user options (such as routes /specific ip addresses to be pushed for each connection name determined by the certificate name), also it can be used as a brute connection permission mechanism if you set "ccd-exclusive" in the conf.
-- use good encryption - explicitly set a good encryption type (such as "cipher AES-256-CBC" in the conf) - this will prevent clients from auto-selecting ciphers which usually default to weaker encryption types. As an added bonus, most newer CPUs support AES hardware acceleration, a feature natively supported by openssl which is used by openvpn (it is debated as to how much exactly helps with openvpn, but probably better than not having it).
-- Use tls-auth - this is a low-cost method of securing your openvpn instance by creating a per-server static certificate that is used for signing each packet - before the packets are interpreted, this signature is checked - if this check fails the package is dropped. This prevents dos attacks and may protect from yet-unknown bugs (actually there are no known bugs asof yet) that potentially could be exploited by 3rd parties upper in the processing chain.
The essentials to permit data flow from vpn to lan are the following:
- You have to permit the server machine to relay data through it by enabling IP forwarding:
-You have to set up NAT on the main network device to set up data flow from vpn->lan (actually it's a any other interface->lan NAT rule):
Code:
iptables -t nat -A POSTROUTING -o enp2s0 -j MASQUERADE
As for tutorials, the official openvvpn site is the best source. What you could find useful on other sites are mainly the debian/ubuntu specifics of the openvpn setup.
BTW here is a tip that probably will prevent headaches for some:
-On Debian/Ubuntu the easy-rsa package will not put stuff into /etc/openvpn folder so the commands used to set up keys (./build key etc) will not work by default - you have to actually copy everything from /usr/share/easy-rsa/ to /etc/openvpn:
Code:
sudo cp /usr/share/easy-rsa/* /etc/openvpn/
-when you start the openvpn service it will parse /etc/openvpn and it will create processes for every .conf file from there. If you have systemd (most recent distros do) you will have to be able to restart/stop/etc every individual openvpn connection by using the "openvpn@conffilename.service" service name.
If the remote user connects to OpenVPN using a client running on his or her own machine, that user will acquire an address in the range specified on the server statement, most-commonly 10.8.0.xx. You do not have a choice in this matter. The traffic will be snagged by a route on his/her machine, and stuffed right into the utunX virtual device. On the other side, it will bear that return address, which uniquely identifies the client although it is unpredictable. Your home router must have a static route that will direct all traffic bearing such addresses back to your OpenVPN server machine on your home network, so that it can be encrypted and delivered.
Your home router must also have port-forwarding, in this case on 2300 TCP, to forward that connection to your local OpenVPN server. (Note that OpenVPN ordinarily uses UDP ... If you use TCP, you will have a detectable "open port.") This is needed so that inbound encrypted OpenVPN traffic will be delivered properly.
If the remote user is, instead, on a subnet with a setup similar to that of your home, and is accessing the remote side indirectly through a server machine, then their traffic will bear the IP-addresses of their local network, and these must not overlap with yours. Once again, your router will also have to have a static route which forwards traffic bearing those IP-addresses to your local OpenVPN server ... and the local network on the other side must do the same with your addresses, sending them to their OpenVPN server.
I do not believe that you will actually need to fool around with iptables in order to accomplish any of this. (I've set up a lot of OpenVPN's on Linux and have never needed to use this command.)
traceroute is your best friend. You should be able to trace a route from one side to the other and see the entire sequence of hops. The entire route should be successfully traversed. If, instead, you see the route "stall" (as I did, in the second post of the above thread ...), it means that you have a routing issue: either the packets did not know how to get there, or they did not know how to get back home, or both.
If you are diagnosing a connection problem, tcpdump, or better yet a tool like WireShark, is your best friend. Although you of course cannot read the content of the encrypted traffic, you can see it coming back and forth ... or, not. There are two levels of routing here: first, the various OpenVPN servers must be able to communicate with one another. Then, once the tunnel is established, traffic must at all "hops" be able to find its way to and through the tunnel, and back again.
Last edited by sundialsvcs; 11-29-2016 at 11:50 AM.
Thanks, all. I am making great progress. Here is what I did:
Code:
-My home subnet is 192.168.5.x. Home router is 192.168.5.1, internal address of the vpn server is 192.168.5.12
-opened the port on the router on which I intended to connect, and forwarded it to 192.168.5.12
-installed openvpn, set up security, got it to connect. It gives addresses in the 10.8.0.x subnet.
-made sure that "net.ipv4.ip_forward = 1" is not commented out in sysctl.conf
-added "push route 192.168.5.0 255.255.255.0" to server.conf
-added a static route to my home router --> 10.8.0.0 (destination network) 255.255.255.0 (subnet mask) 192.168.5.12 (default gateway)
Here are the results:
Code:
-if I connect to VPN, I have full access to everything on 192.168.5.12 (the openvpn server also acts as a file server, and I have access to those files)
-If I connect to VPN, I can access my router (192.168.5.1)
-An openVPN client cannot access anything else in the 192.168.5.x LAN
-I cannot ping a VPN client for any computer in my 192.168.5.x LAN, other than from 192.168.5.12 (the vpn server, which makes sense)
Something is still missing. Thoughts?
Last edited by evilmonkey1987; 12-03-2016 at 12:41 PM.
That's what you decided to do when you used the directive push "redirect-gateway def1 bypass-dhcp", and that's why you had to use the iptables command. As the documentation cited says:
Quote:
Pushing the redirect-gateway option to clients will cause all IP network traffic originating on client machines to pass through the OpenVPN server. The server will need to be configured to deal with this traffic somehow, such as by NATing it to the internet, or routing it through the server site's HTTP proxy.
(The documentation then cites the same iptables command that you were given, as its necessary solution.)
It is up to you, however, whether you want "all traffic from the client machines" to pass through your server. Perhaps this is exactly what you want: lots of people have learned the hard way to distrust the non-security of their local coffee shop.
Since I do not use this directive on any of my OpenVPN connections, I cannot speak to as to why such a directive might possibly be needed to allow communication to "any other computer within the local network." I've never had to use it.
Edit: I can see where this directive would be required if you were sending "everything from your box" through "another box" to the outside world (by way of that machine's network's router). But it should not be required if you are simply trying to reach another local machine on that machine's network . . . unless, as I now suspect, redirect-gateway-def1 changes the routing very considerably. (As indeed it would have to do, in order to distribute "everything from your box" on your side ...)
Last edited by sundialsvcs; 12-05-2016 at 08:14 AM.
Actually unless you set up static routes (toward the vpn) on all your computers on the LAN (or router) you will need the iptables command to access VPN->LAN.
You can access the LAN only via the net forwarding, but the computers on the LAN do not have routes back to your VPN so the connections (which need bi-directional communication) will not work.
The LAN computers will send the response packets to the default gateway (because they do not have information about the originating subnet) which will discard them (because does not know where to send them).
So you have the following options:
- Static routes on all LAN computers (and if you have other devices can be tricky if possible at all) - set the VPN server's IP address as gateway to your VPN subnet
- Static route on router (more elegant, but it might not work if the router refuses to forward stuff back to LAN, it happens sometimes) - same as above
- NAT (PAT) your way out of the VPN server - this might not look elegant but it's the easiest to set up (actually you need only the LAN-faced network interface name) and should work in pretty much all cases. LAN devices see packages as coming from the VPN server and only the VPN server knows that they are actually forwarded to/from the VPN subnet. This has the advantage of single point of configuration (is doable even you don't have access to the router).
Thank you for your clarifications, gradinaruvasile. I can now see in each case how the routing would go, particularly in your third case, and I agree with you on all points. (I'll definitely keep that case in my "bag of tricks" if I ever find myself in that situation! Thanks for sharing ... and clarifying!)
- - -
Echoing, then, my previous comment that traceroute (and tcpdump or WireShark) are always "your best friends."
There are always several ways to make a multi-hop TCP/IP networking situation like this one work, and it's crucial not only that you know which provision (of several possible provisions) has been made for each "hop," but why it has been made, and exactly what it does.
And this appliesmust(!)apply: "both going and coming and(!) returning!"
Traffic originating from either side must not only successfully reach the other side (and beyond??), but then, safely make it all the way back home. And, your job is done only when both sides can do that. (Uhhh, if you actually want 'both sides' to be able to do that ... or, not. Sometimes you most-definitely don't.)
You will quickly find that you really can't guess about such things: you need to perfect the means to s-e-e it. (And then, at least for poor ol' me, "grab a blank sheet of paper and a number-two pencil and draw it!")
- - -
"I hate networking ... ..."
Last edited by sundialsvcs; 12-05-2016 at 01:04 PM.
Thanks all. As I mentioned above, I set up a static route on the router for the information to find its way back across the VPN tunnel. I did intend for all traffic to go through the VPN as I have certain IP-restricted applications for which I need a predictable outside IP.
It seems that something in my machinery got mixed up again. An openvpn client (10.8.0.x) can see only the openvpn server (192.168.5.12) and the router (192.168.5.1). They cannot see any other machines behind the router. However, machines behind the router (say, 192.168.5.101) can ping the openvpn client at 10.8.0.x. It looks like 192.168.5.x traffic is not hitting my router. I ran "route" got this:
Code:
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.5.1 0.0.0.0 UG 0 0 0 enp2s0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
10.8.0.2 * 255.255.255.255 UH 0 0 0 tun0
192.168.5.0 * 255.255.255.0 U 0 0 0 enp2s0
It appears that the last line is problematic because it's not pointing to a gateway. It should point to 192.168.5.1, right? Any suggestions on a fix?
default via 192.168.5.1 dev enp2s0
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
192.168.5.0/24 dev enp2s0 proto kernel scope link src 192.168.5.12
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
..."
