LinuxQuestions.org - [SOLVED] Share VPN with ethernet interface

- Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)

- - Share VPN with ethernet interface (https://www.linuxquestions.org/questions/linux-networking-3/share-vpn-with-ethernet-interface-4175655027/)

Hresna

06-02-2019 09:42 PM

Share VPN with ethernet interface

Running Ubuntu 18.04 LTS. Looking to share VPN connection (OpenVPN over wifi) with an ethernet interface, using gnome.

Use case is: a laptop connects to unsercure wifi, establishes VPN tunnel, the VPN is then shared with an Ethernet interface, upon which I connect a DD-WRT router (double-nat, obviously) that supplies secure wifi/ethernet to clients. The reason for using a laptop with a real OS for the gateway is to handle captive portals via browser (as many hotels do).

This setup makes it impossible for the clients' traffic to leak over the gateway wifi since only the VPN connection is shared (not the base wifi). If VPN drops, the clients have no connectivity at all. Easy enough to do under macos with l2tp.

Is there a reasonably simple way to do this from the gnome GUI?

It took me hours trying to get just the L2TP+IPsec tunnel to work and finally gave up. I am using OpenVPN now, but I can't find a way of sharing the OpenVPN connection specifically, just the wifi, which would fall to insecure if the tunnel ever dropped, exposing the client traffic.

I'm a new user, I'm sure there is a way to do this with CLI, but I much prefer a simple GUI method if it exist.s

baldur_1

06-03-2019 11:29 AM

i think you are looking at this wrong. i think you need to masquerade the connection not share it. you would do that via your firewall...ie create it into a router.

Hresna

06-03-2019 01:17 PM

Quote:

Originally Posted by baldur_1 (Post 6001625)

i think you are looking at this wrong. i think you need to masquerade the connection not share it. you would do that via your firewall...ie create it into a router.

I don't quite follow what you mean, by masquerading the connection.
I think that might be what this poster is doing? (Albeit with a lot more CLI-ninjary than I am comfortable with at the moment)
https://askubuntu.com/questions/9261...ther-lan-users

As a fall-back, if I can't get the OS to cut feed to the router when the VPN drops (should maybe have mentioned that the intent was for the laptop's ethernet to be connected to the WAN port of the router, feeding it the shared VPN connection established over wifi), then I'll try to build that functionality direct in the router. I think DD_WRT supports OpenVPN as a client and a simple firewall rule can set up an "internet kill switch" if it drops. I used to do this with a less capable router, hence using the laptop OS functionality for establishing/sharing the VPN and being the kill-switch.

baldur_1

06-04-2019 07:32 AM

masquerading is a term used in networking. it basically means sharing an internet connection. to do that, you set that up via your firewall. i searched on the duckduckgodotcom,

Code:

configure ufw masquerade vpn connection

and came up with this link...

ufw vpn masquerade

essentially you have 3 connections, the 2 physical ethernet devices and the vpn named something like tun0. you have tun0 set to use eth dev 1 which is part. now you need to masquerade tun0 (the vpn) and set up a ip server (dnfmasq or dhcp server). those are the elements you need to set this up. you need to just finish the last two parts. so the firewall will share the vpn connection allowing others to use it and the dhcp will serve ips to devices that want to connect.

squigley

06-05-2019 04:35 PM

I wouldn't do this with a laptop; I think you're better off doing it with whatever router/AP you're going to run dd-wrt on.

Have it run 2 SSIDs, eg one called "setup" or similar, which is bridged to a VLAN/subnet with NAT/passthrough (as "normal") which you can connect to in order to deal with the captive portal. Once that has been sorted, since the traffic from whatever device you used to authenticate with the portal was being masqueraded, the dd-wrt router will then be able to connect out itself, in order to bring up an OpenVPN client.

After that, bridge the secondary SSID eg "secure" with the OpenVPN client interface, and then connect your devices to that SSID. If the VPN goes down, traffic will stop, as that SSID/VLAN/subnet can only route through the VPN interface.

There is some info on setting up multiple SSIDs/VLANS/subnets with bridging here: https://wiki.dd-wrt.com/wiki/index.php/Multiple_WLANs

Hresna

06-05-2019 08:31 PM

Quote:

Originally Posted by squigley (Post 6002567)

Have it run 2 SSIDs, eg one called "setup" or similar, which is bridged to a VLAN/subnet with NAT/passthrough (as "normal") which you can connect to in order to deal with the captive portal. Once that has been sorted, since the traffic from whatever device you used to authenticate with the portal was being masqueraded, the dd-wrt router will then be able to connect out itself, in order to bring up an OpenVPN client.

After that, bridge the secondary SSID eg "secure" with the OpenVPN client interface, and then connect your devices to that SSID. If the VPN goes down, traffic will stop, as that SSID/VLAN/subnet can only route through the VPN interface.

Your suggestion is intriguing. If I follow, the router would be connecting to the hotel wifi for its WAN, bridged to an 'unsecure' SSID that I would use to handle the captive portal. I hadn't considered the portal could be dealt with through two bridged wifis like that but it seems reasonable.

I like it.

It would reduce how much dedicated hardware is needed, provided my DDWRT router has enough radios to manage it all, and the processor can keep up with the VPN (something I'm not convinced it can do after some fiddling with it today). I still need a "burner" device that I don't mind exposing to the hotel network, if only briefly, but if I go all-in I could probably do it with VM.

After messing with the DD a bit today, I don't wonder if it might be a bit fussier to get working and/or troubleshoot on the road though when it hiccups. When I do this in MacOS, it is pretty dead simple. The setup in Linux is proving more complicated, but at least when things are glitching it's easy enough to investigate whats going on and reset things. The router is a bit more opaque in that regard.

JamesAM

06-06-2019 07:18 AM

Have you thought of bridging the ethernet and vpn connections? If you want to go that route, here is my client config:

client.conf

Code:

### Client configuration file for OpenVPN



# Specify that this is a client

client



# Bridge device setting

dev tap0



# Host name and port for the server (default port is 1194)

# note: replace with the correct values your server set up

remote <your vpn server> 1194



# Client does not need to bind to a specific local port

nobind



# Keep trying to resolve the host name of OpenVPN server.

## The windows GUI seems to dislike the following rule.

##You may need to comment it out.

;resolv-retry infinite



# Preserve state across restarts

;persist-key

;persist-tun



# Up and down scripts

script-security 2

up "/etc/openvpn/up br0 eth0"

down "/etc/openvpn/down br0 eth0"



# SSL/TLS parameters - files created previously

ca /etc/openvpn/ca.crt

cert /etc/openvpn/pi.crt

key /etc/openvpn/pi.key



# Since we specified the tls-auth for server, we need it for the client

# note: 0 = server, 1 = client

tls-auth /etc/openvpn/ta.key 1



# Specify same cipher as server

cipher BF-CBC



# Use compression

comp-lzo



# Log verbosity (to help if there are problems)

verb 3

This config also uses two supporting scripts.

up

Code:

#!/bin/bash

br=$1

eth=$2

dev=$3

mtu=$4

cd /usr/bin/



# only if you start dhcpcd and leave it

#  running for eth

#/etc/init.d/isc-dhcp-server stop



# needed if script is run independently

# but when run through openvpn

# openvpn will do this automatically

#  could also use 'ip tuntap ..'

#openvpn --mktun --dev $dev



#brctl addbr $br

# set forwarding delay to 0

#  otherwise dhcp called below would timeout

#brctl setfd $br 0

#brctl addif $br $eth

# order matters here.. right now there is only

#  one mac in the bridge's table

# if there were two.. there is no guarantee

#  which would be passed to the dhcp server

#dhcpd $br

brctl addif $br $dev



#ip link set $eth up promisc on mtu $mtu

ip link set $dev up promisc on mtu $mtu

down

Code:

#!/bin/bash

br=$1

eth=$2

cd /usr/bin/



#/etc/init.d/isc-dhcp-server stop



#ip link set $br down

brctl delif $br $dev



# needed if script is run independently

# but when run through openvpn

# openvpn will do this automatically

#  could also use 'ip tuntap ..'

#openvpn --rmtun --dev $dev



# only if you start dhcpcd and leave it

#  running for eth

#dhcpcd $eth

Keep in mind that your configuration may differ from mine, and you will probably need to make minor changes to these files before you can use them.

Hresna

06-06-2019 11:51 AM

Quote:

Originally Posted by JamesAM (Post 6002735)

Have you thought of bridging the ethernet and vpn connections? If you want to go that route, here is my client config:
Keep in mind that your configuration may differ from mine, and you will probably need to make minor changes to these files before you can use them.

Wow thanks! I have to say, I'm very encouraged by the helpfulness and breadth of the suggestions... and at the same time a bit uneasy at how all if it is a fair bit more involved than just some settings in GNOME. But then, I'm fast learning that that's linux... extremely powerful and versatile under the hood... not so much so in the shell (at least not for this sort of more advanced stuff).

Bridging is where I thought I might go with this, since that's the one option that seems to get some treatment in the GUI, but I'll have to think through my options a bit, and pick something that I'm confident I will know how to reverse, in case it all gets bungled up. It's clear now that it won't be a quick 20 minute jobby for me, I'll have to dedicate some serious time to figuring it out, since I'm also learning my way around linux as I go.

When I do finally get something working, I'll make a point to come back here with my notes!

Hresna

06-08-2019 01:22 PM

EDITED

Quote:

Originally Posted by baldur_1 (Post 6002004)

masquerading is a term used in networking. it basically means sharing an internet connection. to do that, you set that up via your firewall.
ufw vpn masquerade

Ok, I tried the method at that link and figured out a handful of mods I had to make for my use case (namely that I'm using the laptop wifi and not eth0 for establishing the wan connection). At one point my ufw/before.rules file was coming up completely blank for reasons that mystify me, but it eventually came back on its own.

I think I have it working, but one thing has me stumped in this code:

Code:

# START OPENVPN RULES

    # NAT table rules

    *nat

    :POSTROUTING ACCEPT [0:0]

    # Allow traffic from OpenVPN client to eth0 and Wlan0

    -A POSTROUTING -s 10.8.0.0/8 -o eth0 -j MASQUERADE

    -A POSTROUTING -s 10.8.0.0/8 -o wlan0 -j MASQUERADE

    -A POSTROUTING -s 10.8.0.0/8 -o wlp2s0 -j MASQUERADE  ##I added this for my setup 

    COMMIT

    # END OPENVPN RULES

Where does that 10.8.0.0/8 IP range come from?
If I do an ifconfig on my device, I don't actually see that IP address/range come up anywhere. What does this part of the setup actually do?

Hresna

06-08-2019 06:36 PM

Quote:

Originally Posted by baldur_1 (Post 6002004)

Code:

configure ufw masquerade vpn connection

and came up with this link...

ufw vpn masquerade

I am so close.
The gateway computer kill switch is working fine, using the method at the link you provided. When the VPN is open, the client traffic passes through the VPN no problem. The issue is, when the VPN tunnel drops, even though the gateway loses access, somehow the client still reaches out to the internet (and leaks the IP address).

So, the connection sharing that I set up with nm-connection-editor is bypassing the gateway's ufw rules (or, at least, the kill-switch functionality I put in for the VPN).

I'm sure there is a simple addition to either iptables or ufw I would need to do to get the kill to propagate to the client, but I'm weary of trying random things for fear of totally breaking it everything.

tun0 is my VPN, wlp2s0 is the wifi adapter that connects to the wan, and ens9 is the ethernet adpater that shares with the client (it's a tunderbolt ethernet adapater). I haven't created any rules yet for ens9, but assumed that this set of defaults would be blocking it from doing anything:

Code:

sudo ufw default deny incoming

sudo ufw default deny outgoing

sudo ufw allow out on tun0

sudo ufw allow out on wlp2s0 to 192.168.0.0/22

I think maybe the "ACCEPT" packet forwarding policy might be trumping the denial or something? Or I'm not making sense because I've been staring at terminal too long...

Thanks to anybody that can tell me what I'm missing!

squigley

06-10-2019 03:50 PM

Quote:

Originally Posted by Hresna (Post 6003385)

EDITED

Where does that 10.8.0.0/8 IP range come from?
If I do an ifconfig on my device, I don't actually see that IP address/range come up anywhere. What does this part of the setup actually do?

This is the OpenVPN range. You need to change this to match whatever IP range you are using in your OpenVPN bridge network.

Hresna

06-12-2019 08:07 AM

Solved

Update: I have it working now.

I will post my full solution with code once I have it streamlined a bit more, but I’ll include a synopsis for now.

I followed the steps from the link : https://ubuntu-mate.community/t/vpn-...ate-15-04/1452

Those steps amount to:
-disabling IPv6 (because of various forms of vpn leakage)
-enabling packet forwarding at kernel level
-using ufw to build firewall rules that activate a “VPN kill switch” (by making the defaults deny, adding a few allow rules, and adding *nat rules to the before.rules for some local masquerades)

That much got a working vpn kill switch functioning on the Gateway computer, but it wasn’t addressing the sharing/masquerade with the client network (which in my case is a DDWRT router wanting its WAN access through the tunnel).

A few things were missing for my use case. For starters, I had Network Manager from the start, so both the VPN and the client network (interfaces/devices) had to be set up there. More on this in a second.

I also had used nm-connection-editor to build the connection sharing in the first place (this was before wanting to do a vpn kill switch). That ended up being a confusing mistake, since the GUI method evidently built the masquerade directly in iptables rules, and it did it in a way that was bypassing/defeating the *nat before.rules in ufw. I had to reverse all that and go back to the before.rules to add an additional masquerade line in the *nat to actually enable sharing the vpn with the client network (simple enough, but took me forever to figure out, since the instructions at link didn’t address it). That line looks like this:

Code:

-A POSTROUTING 192.168.10.0/24 –o tun0 –j MASQUERADE

#the IP above is the one that defines my statically-defined client network between the gateway and the DDWRT router *note below

*Another thing that the connection editor had done was set up some form of DHCP to enable the sharing over the ethernet. When I reversed this, I had to configure the wired Ethernet for static IP on a local subnet, and configure the DD-WRT to use a static IP on the same subnet, with the IP of the gateway’s interface as its gateway. (Duh, right?) I likely could have used CLI methods to do the dhcp, but as far as I could tell, they all required to install new packages, and this seemed a leaner and simpler solution, particularly since this part of it was done all in GUI.

And that’s it in nutshell. (A big-ish nutshell. I am verbose…). I’ll post the full code and ufw rules once I whittle it down to what was necessary. Ther may be one or two ufw rules that were missing from the link to make this work, but I wan’t to try removing a few of the one I added while troubleshooting before I’m sure.

As a side note, I opted not to create the VPN and kill switch in the DD-WRT for a few reasons: First, this gateway-VPN method allows secure browsing on the gateway computer, which wasn’t necessary but is a nice perk. The main reason is: the router I’m using for DDWRT is an older Broadcom-based single core dealy. Its maximum throughput with the VPN enabled was about 5 Mbit, which is likely sufficient for most hotel connections, but still a bit of a bummer. And dialing into the router’s web-based GUI to try and troubleshoot things when it goes down is a bit fussier than just doing the Ubuntu stuff on the gateway.

Hresna

06-13-2019 11:43 AM

Solution

Quote:

Originally Posted by Hresna (Post 6004455)

Update: I have it working now.

The procedure for the VPN kill-switch in the Gateway device was:

Made these changes in /etc/sysctl.conf

Code:

#disable ipv6

net.ipv6.conf.all.disable_ipv6 = 1

net.ipv6.conf.default.disable_ipv6 = 1

net.ipv6.conf.lo.disable_ipv6 = 1

#enable packet forwarding (note, the line below shows up elsewhere in the file)

net.ipv4.ip_forward=1

In UFW’s default config file (/etc/default/ufw), made this change:

Code:

DEFAULT_FORWARD_POLICY=“ACCEPT”

Created these ufw rules using command line:

Code:

sudo ufw default deny incoming

sudo ufw default deny outgoing

sudo ufw allow out on tun0

sudo ufw allow out on wlp2s0 to XXX.YYY.ZZZ.AAA port 1194 proto udp

(note, wlp2s0 is the wifi adapater I’m using for the external wan connection; the IP address is of my openVPN provider)

This much got me a working VPN kill-switch on the gateway device.
The last step was masquerading the VPN connection on the secondary interface (in my case, the Ethernet device called ens9). This is where the isntructions at link were leading me astray. Using the IP-space of the VPN client wasn’t actually doing anything for me, and masquerading on the physical interfaces neither. What I ended up doing was masquerading the virtual tun0 interface onto the subnet for my client devices connected by ens9. Like this:

Code:

 ### Start OpenVPN Share rules

### NAT table rules

*nat

:POSTROUTING ACCEPT [0:0]

-A POSTROUTING -s 192.168.10.0/24 -o tun0 -j MASQUERADE  

COMMIT

And that was pretty much it.

I expected to need a ufw rule like this:

Code:

sudo ufw allow out on ens9 to 192.168.10.0/24

But it works just fine without it.

All times are GMT -5. The time now is 02:25 PM.