Routing from one network to another

[TheEngineer2019]

Hello,

i would like some assistance setting up a scenario as follows:

i have a raspberry pi zero where it acts as a wireguard vpn client installed on it.
i added an external wireless usb dongle to the usb interface of the pi.

so the set up is as follows:

- wlan0 is the built in wireless
- wlan1 is the usb wireless dongle.
- wg0 is the interface for the wireguard client which has an ip address of 10.0.0.1
- lo is the loopback interface.

i configured the wireguard client to connect to my vpn network remotely using the wireguard server.
This is working properly and i am able to ping and reach my vpn network with no problem.

on my vpn network i have a dhcp server that can provide ip address to my local network with the subnet of: 192.168.1.0.

wlan1 on the pi connects to the internet using dhcp to provide internet to the pi.

which i would like to set up as follows.

i need wlan0 to act like an access point to provide ip address to clients that are connected to it wireless, but i need wlan0 to provide ip address from the dhcp server (192.168.1.1) sitting on my local network, which can be reached easily from the pi.

so if a client connected to the wlan0, the interface will provide an ip address for example 192.168.1.5.
the interface should provide something like this from the dhcp server on the lan.

ip address: 192.168.1.5
gateway: 192.168.1.1
dns-server: 192.168.1.15, 192.168.1.25

and if also possible to add an option let's say the pi cannot reach the dhcp server can then provide it's own dhcp ip address using a 2nd local dhcp server.

The reason why i need this, is that i do not want to create any routing on my local pc to forward traffic to my network 192.168.1.0
and i should be able to reach any node on my local network without the need for any additional routing.

So i am sitting remotely and i already picked up an ip address from my local network, where the vpn is already active, i should be able to reach any node on my lan without any routing.

is that possible to achieve? if yes, can you please provide steps to get this working?

Thank you,

TheEngineer2019

[epoch1970]

So you're trying to setup a tunnel that bridges two sites.
It is relatively easy to do with openvpn, because it supports bridging. A convoluted example here, there are certainly simpler cases.

WG does not support bridging at all, and not even multicast I think.
But assuming you have at least one static IP address available on each side of the LAN, I suppose you could setup additional tunnel interfaces "downstream" from the WG endpoints. So WG would in effect route tunnel packets containing ethernet frames (MAC addresses, broadcasts and all that). I've found this looking for "wg vxlan", that's far from the step-by-step you're asking for I'm afraid.

(With vxlan and tunnels in general, pay attention to the resulting reduced MTU size. If you see things like DHCP offers never acknowledged by the client, or ping working but http not, check the MTU size of all participating interfaces.)

[TheEngineer2019]

Thank you epoch1970 for your response,
yes this is what i figured out bridging is what i want to do in my case,
i will try to play around with the setting to see if i can get something,
i saw this article:
https://serverfault.com/questions/91741 ... nd-inbound

not sure if it will help, but i'll give it a try, if not, then i would probably move on to implement openvpn instead.

Thanks,
TheEngineer2019

[TheEngineer2019]

hi again,

i found an interesting article this morning on:

https://thepi.io/how-to-use-your-raspbe ... ess-point/

based on the article it allows you to bridge 2 interfaces together on raspberry pi, so i was wondering if i set it up as a bridge between the 2 interfaces the wireguard interface & the wlan0 which is the wifi connection, then my problem would be solved, and this article doesn't actually need a lot of configurations.

I am going to test it on a sample pi to see if it does what i need.

Best ,
TheEngineer2019

[epoch1970]

I don't think that works because a wireguard endpoint needs to have an IP address, and a bridge member cannot have one.
I could be wrong.

[TheEngineer2019]

i think it does have an ip,

here is what i can see if i use ifconfig:

wg0: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 1420
inet 10.0.0.3 netmask 255.255.255.255 destination 10.0.0.3


so i guess it can work. But won't hurt to give it a try.

[epoch1970]

so I guess you cannot bridge the wg interface: bridge members shall not have an IP address. Only the bridge itself can.

[TheEngineer2019]

yes you were right, unfortunately this utility does not allow you to add a virtual interface, it should only be for physical interfaces. So that won;t work. Need to think about a different easy way to implement it.

[epoch1970]

As before: you can probably bridge wlanX (AP mode) with the tap device from an OpenVPN bridge tunnel, or with a vxlan or other tunnel endpoint device plugged upon a wg0 interface.

[TheEngineer2019]

yes, that can work, but the problem is that wireguard is easy to implement, and is more secure and faster. That would be my last option to use openVPN if none of the solutions work.

[swampdog]

I don't know if this contributes or not as I've only yesterday got my rpi4 working as an access point and is very much a work in progress. In my case it will be a "laptop" so ordinarily will use dhcp on eth0 & wlan0 but when at home may as well serve as an AP. I nearly pulled my hair out with dhcpcd. I got on much better with it disabled. The following script toggles between the two modes. 'svr-ap 1' turns it into an AP, 'svr-ap 0' reverts to normal. I run my own DNS/DHCP server btw.

Code: Select all

#!/bin/bash

NAM=`basename "$0"`

S="sudo"
HOSTAPD="hostapd"
WLAN="wlan0"
ENI="/etc/network/interfaces"

fcp_usage ()
{
cat<<EOF
${NAM}: [ --help | -h ]
EOF
}

fcp_q ()
{
 $S systemctl show "$HOSTAPD" --property ActiveState
 brctl show
}

fcp_1 ()
{
 $S -i ifdown "$WLAN"
 $S ln -sf /usr/local/sd/etc/interfaces.ap "$ENI"
 $S systemctl enable "$HOSTAPD"
 $S systemctl start "$HOSTAPD"
 $S -i ifup "$WLAN"
}

fcp_0 ()
{
 $S -i ifdown "$WLAN"
 $S ln -sf /usr/local/sd/etc/interfaces.lt "$ENI"
 $S systemctl stop "$HOSTAPD"
 $S systemctl disable "$HOSTAPD"
 $S -i ifup "$WLAN"
}

case "$1" in
	--help | -h)
	fcp_usage
	exit 0
	;;

	--query | -q)
	fcp_q
	;;

	start | 1)
	fcp_1
	;;

	stop | 0)
	fcp_0
	;;

	*)
	fcp_usage
	exit 1
	;;
esac

..hmm, yes, I turned /etc/network/interfaces into a symlink and toggle between a pair of files.

AP mode..

Code: Select all

[email protected]:/usr/local $ cat /usr/local/sd/etc/interfaces.ap | egrep -v "^(#|$)"

source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
iface wlan0 inet manual
auto br0
iface br0 inet dhcp
bridge_ports eth0 wlan0

LapTop mode..

Code: Select all

[email protected]:/usr/local $ cat /usr/local/sd/etc/interfaces.lt | egrep -v "^(#|$)"

source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
auto wlan0
iface wlan0 inet dhcp
	wpa-conf	/etc/wpa_supplicant/wpa_supplicant.conf
auto br0
iface br0 inet dhcp
bridge_ports eth0

With it in AP mode..

Code: Select all

[email protected]:/usr/local $ brctl show && netstat -anr
bridge name	bridge id		STP enabled	interfaces
br0		8000.dca63207642a	no		eth0
							wlan0
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 br0
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 eth0
192.168.1.0     0.0.0.0         255.255.255.192 U         0 0          0 br0
192.168.1.0     0.0.0.0         255.255.255.192 U         0 0          0 eth0

Code: Select all

[email protected]:/usr/local $ cat /usr/local/sd/etc/svr-fw.dat

# Generated by iptables-save v1.6.0 on Wed Mar 21 22:57:43 2018
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [88:11004]
:FWF - [0:0]
:FWI - [0:0]
:FWO - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -i br0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4000 -m state --state NEW,ESTABLISHED -j ACCEPT
-A INPUT -i br0 -p icmp -m icmp --icmp-type 8 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p icmp -m icmp --icmp-type 8 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i wlan0 -p icmp -m icmp --icmp-type 8 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wlan0 -o eth0 -j ACCEPT
COMMIT
# Completed on Wed Mar 21 22:57:43 2018
# Generated by iptables-save v1.6.0 on Wed Mar 21 22:57:43 2018
*mangle
:PREROUTING ACCEPT [1603:319675]
:INPUT ACCEPT [1357:227372]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1053:87636]
:POSTROUTING ACCEPT [1053:87636]
COMMIT
# Completed on Wed Mar 21 22:57:43 2018
# Generated by iptables-save v1.6.0 on Wed Mar 21 22:57:43 2018
*nat
:PREROUTING ACCEPT [517:142771]
:INPUT ACCEPT [1:60]
:OUTPUT ACCEPT [234:15931]
:POSTROUTING ACCEPT [8:527]
-A POSTROUTING -o eth0 -j MASQUERADE
-A POSTROUTING -o br0 -j MASQUERADE
COMMIT
# Completed on Wed Mar 21 22:57:43 2018

..yeah other junk in there!

Code: Select all

[email protected]:/usr/local $ ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.13  netmask 255.255.255.192  broadcast 192.168.1.63
        inet6 fe80::dea6:32ff:fe07:642a  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:07:64:2a  txqueuelen 1000  (Ethernet)
        RX packets 4927  bytes 676835 (660.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3496  bytes 534988 (522.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.13  netmask 255.255.255.192  broadcast 192.168.1.63
        ether dc:a6:32:07:64:2a  txqueuelen 1000  (Ethernet)
        RX packets 5075  bytes 776363 (758.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3933  bytes 630014 (615.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 287  bytes 24169 (23.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 287  bytes 24169 (23.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether dc:a6:32:07:64:2b  txqueuelen 1000  (Ethernet)
        RX packets 121  bytes 12122 (11.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2392  bytes 592942 (579.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

With some luck the above might help you figure out how to make things work together. I've been through a few tutorials myself this week with varying degrees of success. I really don't want to see "wlan0: carrier lost" and "wlan0: carrier acquired" in /var/log/syslog for a while!

[TheEngineer2019]

hey swampdog,

thanks for your reply,

your instructions seems a bit confusing in regards to applying it to my local instance,

i already set up my wlan0 interface to act as an access point and that is working fine.

Let me explain better what is the current scenario,

i have 2 wireless ethernet on my raspberry pi Zero, one the built in, and one a usb dongle,

wlan0 is the AP where i set it to be able to transmit wireless and clients connect to it,
wlan1 is configured as a wireless client to connect to my phone's hotspot.
wireguard software is installed to connect to the internet from wlan1 all the way to reach my wireguard server sitting somewhere else.

i also applied all the crazy iprouting rules between the wireguard and wlan0 (2 way communication), which works fine.
when connecting my laptop to wlan0, i am able to ping and reach only the wlan0 ip addresses, but not the remote internal LAN subnet where the wireguard server is.
the way that i am doing it now is creating an ip route rule on my laptop to redirect all my internal subnet to the wlan0 interface.
This works fine, but as i said i don't want other client have to add a rule on their laptop, just connect to the AP and be able to connect to my internal lan subnet, as easy as that. This is why i was thinking of the tool bridge-utils so i can bridge the wg0 with wlan0 because that is the only way you can reach your internet network, but it doesnt seem the tools like a virtual interface.

If you can think of a way on how to bridge the wlan0 with wg0 so makes it easier, help would be really appreciated.

Thanks,

[ejolson]

hey swampdog,

thanks for your reply,

your instructions seems a bit confusing in regards to applying it to my local instance,

i already set up my wlan0 interface to act as an access point and that is working fine.

Let me explain better what is the current scenario,

i have 2 wireless ethernet on my raspberry pi Zero, one the built in, and one a usb dongle,

wlan0 is the AP where i set it to be able to transmit wireless and clients connect to it,
wlan1 is configured as a wireless client to connect to my phone's hotspot.
wireguard software is installed to connect to the internet from wlan1 all the way to reach my wireguard server sitting somewhere else.

i also applied all the crazy iprouting rules between the wireguard and wlan0 (2 way communication), which works fine.
when connecting my laptop to wlan0, i am able to ping and reach only the wlan0 ip addresses, but not the remote internal LAN subnet where the wireguard server is.
the way that i am doing it now is creating an ip route rule on my laptop to redirect all my internal subnet to the wlan0 interface.
This works fine, but as i said i don't want other client have to add a rule on their laptop, just connect to the AP and be able to connect to my internal lan subnet, as easy as that. This is why i was thinking of the tool bridge-utils so i can bridge the wg0 with wlan0 because that is the only way you can reach your internet network, but it doesnt seem the tools like a virtual interface.

If you can think of a way on how to bridge the wlan0 with wg0 so makes it easier, help would be really appreciated.

Thanks,

As far as I know It is not possible to bridge a WireGuard interface.

Since the Zero is acting as both the access point and the WireGuard VPN endpoint, all machines connected to the access point need only set the Zero as the default route provided you then add firewall, forwarding and routing rules on the Zero to sort out which packets go to the VPN and which go to the rest of the Internet via NAT on wlan1.

Use a separate subnet for wlan0 and configure the WireGuard devices on the upstream VPN to accept forwarded packets from that subnet. Packets going out over wlan1 to the Internet should be translated using IP masquerade so they appear to come from the Zero.

[TheEngineer2019]

hi ejolson,

yes, this was the original conversation that it is not possible to achieve with wireguard,
but i am still doing my search hopefully i can come up with something someone else might have tried a similar situation and worked.

But anyone feel free to share their thoughts about it, maybe we can come up with a solution, which might be helpful for everyone who thinks this is helpful for them.

[ejolson]

hi ejolson,

yes, this was the original conversation that it is not possible to achieve with wireguard,
but i am still doing my search hopefully i can come up with something someone else might have tried a similar situation and worked.

But anyone feel free to share their thoughts about it, maybe we can come up with a solution, which might be helpful for everyone who thinks this is helpful for them.

Why doesn't packet forwarding from one subnet to the other work?

From the user point of view, they connect to the access point, receive the DHCP lease with default route from the Pi Zero and they are done. Then the Zero checks which packets goes where and forwards them accordingly.

In my opinion, bridging only makes sense when you want to turn a computer with multiple networking ports into a switch--hopefully a rare event, but see this description of setting up a super-cheap cluster without a switch.

For connecting two subnets through a VPN, simply set the VPN endpoints as the default route and then use suitable routing tables on the endpoints to sort everything out.

[TheEngineer2019]

hi ejolson,

this is what i did already by routing traffic between them.

i tried all these below:

sudo iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
sudo iptables -A FORWARD -i wg0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i wlan0 -o wg0 -j ACCEPT

all works only if you create a static route on your pc, but if not, then it won't

and yes, to answer your question, the pc or laptop does have dual interface (ethernets), each one is connected to a different network, but when you try to reach an ip address that is not picked up by the dhcp then the pc won't know how to route those packets, which interface. So you need to tell the static route on pc if it tries to reach that destination where to find that network.

I was thinking of having the dhcp provide an ip from the local network this way no routing is required, but i don't think that works too.

[ejolson]

hi ejolson,

this is what i did already by routing traffic between them.

i tried all these below:

sudo iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
sudo iptables -A FORWARD -i wg0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i wlan0 -o wg0 -j ACCEPT

all works only if you create a static route on your pc, but if not, then it won't

and yes, to answer your question, the pc or laptop does have dual interface (ethernets), each one is connected to a different network, but when you try to reach an ip address that is not picked up by the dhcp then the pc won't know how to route those packets, which interface. So you need to tell the static route on pc if it tries to reach that destination where to find that network.

I was thinking of having the dhcp provide an ip from the local network this way no routing is required, but i don't think that works too.

The routing will only work if the wlan0, wg0 and the remote network are each on different subnets.

For example, let

Local WiFi be 192.168.7.0/24
WireGuard be 192.168.8.0/24

Also, you don't want any NAT for the WireGuard interface, but simply let the upstream endpoint accept forwarded packets from the local WiFi.

Networking is tricky, because if there is more than one thing wrong with the configuration, it is very difficult to debug.

[swampdog]

You don't need the bridge for forwarding. Here's the essential part of my rpi filewall, eth0 is my ISP, eth1 is my internal network.

Code: Select all

[email protected] ~ $ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

[email protected] ~ $ cat /usr/local/sd/etc/svr-fw.dat | grep eth
-A POSTROUTING -o eth0 -j MASQUERADE
-A INPUT -i eth1 -j ACCEPT
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1 -o eth0 -j ACCEPT

[email protected] ~ $ netstat -anr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         81.109.74.1     0.0.0.0         UG        0 0          0 eth0
81.109.74.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
192.168.1.0     0.0.0.0         255.255.255.192 U         0 0          0 eth1

In your scenario wlan1 is your "ISP", wlan0 is your internal network, so methinks it should look like this..

Code: Select all

[email protected] ~ $ cat /usr/local/sd/etc/svr-fw.dat | grep eth | sed -e 's/eth0/wlan1/' -e 's/eth1/wlan0/'
-A POSTROUTING -o wlan1 -j MASQUERADE
-A INPUT -i wlan0 -j ACCEPT
-A INPUT -i wlan1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wlan1 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wlan0 -o wlan1 -j ACCEPT

..so that any traffic on wlan0 should get pushed out to wlan1 and any known traffic coming back from wlan1 finds its way back into wlan0.

You've mentioned wg0 is on 10.0.0.3. Your internal network is on 192.168.1.0 which means wg0 has nowhere to go. I'm assuming wlan0 is bridged to wg0 ('brctl show')? so sidestep that problem by assigning a 192.168.1.x address to wg0 instead of 10.0.0.3 (if they're on the same subnet no routing required).

Lots of guesses there!

[ejolson]

You've mentioned wg0 is on 10.0.0.3. Your internal network is on 192.168.1.0 which means wg0 has nowhere to go. I'm assuming wlan0 is bridged to wg0 ('brctl show')? so sidestep that problem by assigning a 192.168.1.x address to wg0 instead of 10.0.0.3 (if they're on the same subnet no routing required).

No, you can not bridge a WireGuard network with a physical one. First they are at different levels in the Linux network stack; second bridging could have security implications regarding the cryptographic authentication of packets. Since the Zero is acting as the access point, then it is already the default route for all the computers on wireless. All you need is the correct routing and forwarding rules on the Pi Zero.

I'll be setting up a Zero as an access point this weekend to deal with some some smart switches. Upstream will be through a wired dongle but otherwise much the same. I'll try to post a working configuration soon.

[swampdog]

You've mentioned wg0 is on 10.0.0.3. Your internal network is on 192.168.1.0 which means wg0 has nowhere to go. I'm assuming wlan0 is bridged to wg0 ('brctl show')? so sidestep that problem by assigning a 192.168.1.x address to wg0 instead of 10.0.0.3 (if they're on the same subnet no routing required).

No, you can not bridge a WireGuard network with a physical one. First they are at different levels in the Linux network stack; second bridging could have security implications regarding the cryptographic authentication of packets. Since the Zero is acting as the access point, then it is already the default route for all the computers on wireless. All you need is the correct routing and forwarding rules on the Pi Zero.

I'll be setting up a Zero as an access point this weekend to deal with some some smart switches. Upstream will be through a wired dongle but otherwise much the same. I'll try to post a working configuration soon.

Ah. Thanks for mentioning that about WireGuard. I guess it was inevitable it couldn't be "ignored". C'est la vie!

[ejolson]

I'll try to post a working configuration soon.

This is a quick description of how to setup a WireGuard VPN tunnel using two Raspberry Pi Computers to securely route traffic between two private subnets. We assume each of the Raspberry Pi computers have two network interfaces: one should be connected to the private subnet and the other should be connected to the Internet and have a public IP addresses.

Denote the public IP addresses of the two Raspberry Pi computers by upstream.public.ip and downstream.public.ip for simplicity. Further suppose, for definiteness, that the local IP number of the downstream Pi is 192.168.15.1 and the local IP number upstream Pi is 192.168.17.1. Note that which Pi is called upstream and which one is called downstream is not important as the configuration will be symmetric.

For this to work, it is important that all the other computers on the 192.168.15.0/24 subnet set their default route to 192.168.15.1 and all the computers on the 192.168.17.0/24 subnet set their default route to 192.168.17.1. One way way to do this is for each Pi to function as the DHCP server for the respective subnet. The extension to the case where additional routers and subnets are involved is straight forward but beyond the scope of this simple example.

Begin by compiling and installing WireGuard on both of the Pi computers. The WireGuard configuration files should read

Code: Select all

# Downstream wireguard.conf
[Interface]
ListenPort = 50176
PrivateKey = ???????????????????????????????????????????=

[Peer]
PrivateKey = ???????????????????????????????????????????=
Endpoint = upstream.public.ip:50176
AllowedIPs = 192.168.0.0/16

and

Code: Select all

# Upstream wireguard.conf
[Interface]
ListenPort = 50176
PrivateKey = ???????????????????????????????????????????=

[Peer]
PrivateKey = ???????????????????????????????????????????=
Endpoint = downstream.public.ip:50176
AllowedIPs = 192.168.0.0/16

where the question marks are replaced by suitable public keys generated using the wg program. Please refer to the instructions on the WireGuard web site for more information.

Use one more subnet for the WireGuard devices. Specifically, choose the IP number of wg0 on downstream Pi to be 192.168.16.1 and 192.168.16.2 to be the the IP number on the upstream Pi. To do this initialize the wireguard interfaces using the following scripts.

Code: Select all

#!/bin/bash
# Downstream wireguard initialization
case $1 in
down)
    ip route del to 192.168.17.0/24 via 192.168.16.2
    ip link set down dev wg0
    ip address del dev wg0 192.168.16.1/24
    ip link del dev wg0 type wireguard
;;
*)
    ip link add dev wg0 type wireguard
    ip address add dev wg0 192.168.16.1/24
    wg setconf wg0 wireguard.conf
    ip link set up dev wg0
    ip route add to 192.168.17.0/24 via 192.168.16.2
esac

and

Code: Select all

#!/bin/bash
# Upstream wireguard initialization
case $1 in
down)
    ip route del to 192.168.15.0/24 via 192.168.16.1
    ip link set down dev wg0
    ip address del dev wg0 192.168.16.2/24
    ip link del dev wg0 type wireguard
;;
*)
    ip link add dev wg0 type wireguard
    ip address add dev wg0 192.168.16.2/24
    wg setconf wg0 wireguard.conf
    ip link set up dev wg0
    ip route add to 192.168.15.0/24 via 192.168.16.1
esac

After running the above scripts, it should be possible to ping the upstream Pi from the downstream Pi through WireGuard. For example, on the downstream Pi the command ping 192.168.16.2 should work.

It remains to set up the routing on each Pi to send the packets destined to the remote subnet through the WireGuard interfaces and translate the packets intended for the public Internet using IP masquerade. Note that the routing information was actually contained in the WireGuard setup scripts above and only the firewall rules remain to be set.

To make things specific, let's assume the names of the network devices on the downstream Pi appear as

• wg0 -- the wireguard device (192.176.16.1)
• eth0 -- the public Internet (downstream.public.ip)
• wlan0 -- the private subnet (192.168.15.1)

and on the upstream Pi appear as

• wg0 -- the wireguard device (192.176.16.2)
• eth0 -- the public Internet (upstream.public.ip)
• wlan0 -- the private subnet (192.168.17.1)

In this case the firewall rules on both Pi computers should be set as

Code: Select all

#!/bin/bash

# Turn off forwarding
echo 0 > /proc/sys/net/ipv4/ip_forward
# Flush the rulesets
iptables -F
iptables -t nat -F
# Make reject the forwarding policy
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
# Forward from the LAN and tunnels
iptables -A FORWARD -i wlan0 -j ACCEPT
iptables -A FORWARD -i wg0 -j ACCEPT
# Forward established masquerade connections
iptables -A FORWARD -i eth0 -o wlan0 -m state \
    --state ESTABLISHED,RELATED -j ACCEPT
# IP Masquerade to upstream
iptables -t nat -A POSTROUTING ! -d 192.168.0.0/16 -o eth0 -j MASQUERADE
# Turn on forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

Hopefully, I've got all the details straight here. Please let me know if you run into difficulties.

[TheEngineer2019]

hi ejolson,

thank you for your suggestion,
i will give it a try when i get the chance, hopefully this week.

one more question to see if my logic is possible to work as well.

as you may know before openVPN & Wireguard was implemented, we used to have L2TP over IPSEC protocol to access the VPN, but with security breach possiblity, other companies did create a better and more secure way to encrypt data between the 2 nodes.

So speaking of that, this L2TP protocol setting have an option where when you connect to the server, the remote client provides you an ip address from your local LAN, this way the remote pc acts as if it is part of the internal LAN where you can reach out all nodes on your network with no problem. And as OpenVPN & Wireguard were implemented, i haven't seen any article that mentions if this implementation is possible from any of these 2 modern solutions. I hope you understood my point.

Basiscally when you configure L2TP on your server, you set the option to provide the remote pc with ip address from it;s dhcp pool.

so if your network is like
192.168.8.0, the dhcp provides the remote pc an ip address from that pool, without having to have a separate network and do all the routing between them. Have you heard of that? or it is not possible with them?

Thanks,

TheEngineer2019