Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Accessing a subnet that is behind a WireGuard client using a site-to-site setup

WireGuard Site-to-Site

Accessing a subnet that is behind a WireGuard client using a site-to-site setup

Problem Summary

We want to access a local subnet remotely, but it is behind a NAT firewall and we can't setup port forwarding. Outgoing connections work, but all incoming connections get DROPPED by the ISP's routing policy.

Solution Summary

We'll create a site-to-site connection with WireGuard allowing us to access the local subnet on a remote device (smartphone, in this example) by connecting through a cloud server in the middle.

Working Example

First let's define our three hosts. They all have WireGuard installed.

A the Linux machine on the local subnet, behind the NAT/firewall
B the Linux cloud server (VPS, like an Amazon EC2 instance)
C a third WireGuard client; a smartphone in this example

Host 'A'

The Host A's /etc/wireguard/wg0-client.conf:

[Interface]
Address = 10.200.200.5/24                  
PrivateKey = <HOST 'A' PRIVATE-KEY>
ListenPort = 27836                         # optional; will be randomly assigned otherwise
DNS = 1.1.1.1                              # or your own DNS server if you're running one    

[Peer]
PublicKey = <PUBLIC KEY OF HOST 'B'>
Endpoint = host-b-fqdn.tld:51820
AllowedIPs = 0.0.0.0/0, ::/0

PersistentKeepalive = 25                   # to keep connections alive across NAT

Here's what we need to add to Host A's iptables rules, expressed as the commands you would use to ADD them:

# iptables -A FORWARD -i wg0-client -j ACCEPT
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Finally, we need to make sure IP forwarding is enabled in Host A's kernel:

$ sysctl net.ipv4.ip_forward=1

Host 'B'

Host B's /etc/wireguard/wg0.conf:

[Interface]
Address = 10.200.200.1/24
PrivateKey = <HOST 'B' PRIVATE KEY>
ListenPort = 51820

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ens3 -j MASQUERADE


# This is the peer that is on the private subnet that we want to access.
#
# Notice the AllowedIPs... without this part, WireGuard will drop the 
# packets destined for the HOST 'A' subnet.  AllowedIPs is acting like
# a routing table and ACL here.

[Peer]
PublicKey = <HOST 'A' PUBLIC KEY>
AllowedIPs = 10.200.200.5/32, 100.10.202.0/24

# The smartphone
[Peer]
PublicKey = <HOST 'C' PUBLIC KEY>
AllowedIPs = 10.200.200.3/32

# An additional peer...
[Peer]
PublicKey = <Additional peer pubkey>
AllowedIPs = 10.200.200.4/32

Like we did with Host A, IP forwarding must also be enabled on Host B:

$ sysctl net.ipv4.ip_forward=1

Host C

Host C's configuration file:

[Interface]
PrivateKey = <HOST 'C' PRIVATE KEY>
Address = 10.200.200.3/24
DNS = 1.1.1.1


[Peer]
PublicKey = <HOST 'B' PUBLIC KEY>
AllowedIPs = 0.0.0.0/0
Endpoint = host-b-fqdn.tld:51820
PersistentKeepalive = 25

You're finished.
Make sure WireGuard is running on both HOSTS A and B, and then on the smartphone (HOST C), after connecting to HOST B with WireGuard you should be able to ping 10.200.200.5.

@modidep

This comment has been minimized.

Copy link

@modidep modidep commented Jan 20, 2019

Per your guidance I've added:

PostUp = echo nameserver 10.200.200.1 | resolvconf -a tun.%i -m 0 -x;  iptables -I FORWARD -i %i -j ACCEPT ;   iptables -t nat -I POSTROUTING -o enp3s8 -j MASQUERADE 
PostDown = resolvconf -d tun.%i; iptables -I FORWARD -i %i-j ACCEPT;  iptables -t nat -D POSTROUTING -o enp3s8 -j MASQUERADE 

Because I was using a docker server for Host A. Adding this here just in case somebody has the same problem.

@nordstrand

This comment has been minimized.

Copy link

@nordstrand nordstrand commented Aug 18, 2019

In addition I did need to enable ip forwarding on both A and B to make the setup work:

$ sysctl net.ipv4.ip_forward=1

@maulwurf87

This comment has been minimized.

Copy link

@maulwurf87 maulwurf87 commented Oct 15, 2019

In addition I did need to enable ip forwarding on both A and B to make the setup work:

$ sysctl net.ipv4.ip_forward=1

Had to do the same. Using elementary os (ubuntu 18.04 base). Great guide, thanks a lot.

@nizmow

This comment has been minimized.

Copy link

@nizmow nizmow commented Oct 24, 2019

This is fantastic and well written! I have a question though, do we really need to masquerade to do this? If IP forwarding is enabled on Host A (Linux box behind NAT) and devices on the LAN with it are using it as the default gateway, wouldn't regular routing just work?

Sorry if this is an ignorant comment, I'm no expert on networking -- just making a query!

@insdavm

This comment has been minimized.

Copy link
Owner Author

@insdavm insdavm commented Oct 24, 2019

This is fantastic and well written! I have a question though, do we really need to masquerade to do this? If IP forwarding is enabled on Host A (Linux box behind NAT) and devices on the LAN with it are using it as the default gateway, wouldn't regular routing just work?

Sorry if this is an ignorant comment, I'm no expert on networking -- just making a query!

Unfortunately it won't usually just work--both host A and B need some instruction on what to do with packets coming in on the wg interface. We need to use iptables and network address translation with the masquerade target to tell the system how to rewrite the destination IP address so those packets get to the right place (an IP on Host A's local subnet). You could also do this with the DNAT target, but MASQUERADE allows for flexibility with changing IP addresses. I don't think this can be accomplished with route(8) because we need to be able to rewrite the destination IP on each packet (NAT), but I've been wrong before ;)

@keviiin38

This comment has been minimized.

Copy link

@keviiin38 keviiin38 commented Apr 18, 2020

Thanks, very useful and clear enough! Is it possible for Host A to be a virtual router (like OPNsense or VyOS) ?
Allowing me to access a whole virtual LAN ?

@euterklaas

This comment has been minimized.

Copy link

@euterklaas euterklaas commented Apr 20, 2020

Just wanted to say thank you! I've been struggling for days to get this exact setup going. Your gist helped a lot and in the end it took me only a few minutes to get a working config.

@euterklaas

This comment has been minimized.

Copy link

@euterklaas euterklaas commented Apr 20, 2020

Thanks, very useful and clear enough! Is it possible for Host A to be a virtual router (like OPNsense or VyOS) ?
Allowing me to access a whole virtual LAN ?

Absolutely. My 'host A' is an OPNsense box and this config works like a charm. Make sure that you have the correct firewall rules on your OPNsense box

@keviiin38

This comment has been minimized.

Copy link

@keviiin38 keviiin38 commented Apr 20, 2020

Thanks, very useful and clear enough! Is it possible for Host A to be a virtual router (like OPNsense or VyOS) ?
Allowing me to access a whole virtual LAN ?

Absolutely. My 'host A' is an OPNsense box and this config works like a charm. Make sure that you have the correct firewall rules on your OPNsense box

Really?! I'm stuck trying to setup this using OPNsense... Could you share me your config or steps please ? (Maybe privately if you prefer)
Thanks very much in advance

@euterklaas

This comment has been minimized.

Copy link

@euterklaas euterklaas commented Apr 21, 2020

Really?! I'm stuck trying to setup this using OPNsense... Could you share me your config or steps please ? (Maybe privately if you prefer)
Thanks very much in advance

I used this guide, mainly for the basic setup (setting up the forwarding and the wireguard interface). For setting up the site2site connection and clients I used this gist. That's all I needed.

I discovered one caveat though. When wireguard is up, all outgoing lan traffic is routed through the tunnel, which is nice. But it seems, that I cannot access google services anymore. I am unable to establish tls connections from within the lan. However, issuing curl https://google.com directly on the opnsense box will work. And as far as I can tell, only Google services are impacted by this.

UPDATE: Fixed the tls problem by activating MSS-Clamping on the lan interface of the opnsense box. Currently using 1300 bytes and everything works. Might tweak that value later.

@ssalonen

This comment has been minimized.

Copy link

@ssalonen ssalonen commented May 7, 2020

If host A is OpenWRT router, you can follow these steps (adapted from https://openwrt.org/docs/guide-user/services/vpn/wireguard/client)

opkg update
opkg install wireguard

# Configuration parameters
WG_IF="wg0"
# Server IP HOST B
WG_SERV="HOST B"
# Server port
WG_PORT="51820"
# OpenWRT ip in vpn
WG_ADDR="10.200.200.5/24"
# server public key
WG_PUB="<PUBLIC KEY OF HOST 'B'>"

# generate keys
#
umask u=rw,g=,o=
wg genkey | tee wgclient.key
cat wgclient.key | wg pubkey > wgclient.pub


WG_KEY="$(cat wgclient.key)"


# Configure wireguard network interface
# analogous to wireguard conf [Interface]
uci -q delete network.${WG_IF}
uci set network.${WG_IF}="interface"
uci set network.${WG_IF}.proto="wireguard"
uci set network.${WG_IF}.private_key="${WG_KEY}"
uci add_list network.${WG_IF}.addresses="${WG_ADDR}"
 
# Add VPN peers (wireguard server)
# analogous to wireguard conf [Peer]
uci -q delete network.wgserver
uci set network.wgserver="wireguard_${WG_IF}"
uci set network.wgserver.public_key="${WG_PUB}"
uci delete network.wgserver.preshared_key
uci set network.wgserver.endpoint_host="${WG_SERV}"
uci set network.wgserver.endpoint_port="${WG_PORT}"
uci set network.wgserver.route_allowed_ips="1"
uci set network.wgserver.persistent_keepalive="25"
# Allow traffic from OpenWRT client to VPN lan
uci set network.wgserver.route_allowed_ips="1"
uci -q delete network.wgserver.allowed_ips
# Change below accordingly if you want everything to go through the tunnel
uci add_list network.wgserver.allowed_ips="10.200.200.0/24"

uci commit network
/etc/init.d/network restart

# one more step using Web UI:

# Go to http://192.168.1.11/cgi-bin/luci/admin/network/firewall/zones/lan
# make sure lan zone has wg0 and lan interfaces attached 
@rvhaasen

This comment has been minimized.

Copy link

@rvhaasen rvhaasen commented May 11, 2020

Great desription!
i followed the instructions, and it seems to work, however i cannot get ssh working :
I have following setup: 3 nodes, 2 Raspberry Pies in local network, 1 Amazon EC2 node. Wireguard has been setup as described.
what does works:

  • ping from each of the 3 nodes to the other 2
  • ssh from the EC2 node to RPi's
  • starting a simple http server on RPi1 ("python3 -m http.server") and connecting to it from RP2 ("telnet ip-of-RPi1 8000") shows expected response

However, ssh from one RPi to the other does not works, no error, just hangs...
The succesfull telnet and ping proves that the nodes can contact eachother

What am i missing in order to get ssh between the peers working?

@insdavm

This comment has been minimized.

Copy link
Owner Author

@insdavm insdavm commented May 12, 2020

What am i missing in order to get ssh between the peers working?

Good question!

  1. Are the two RPi's on the same local subnet?
  2. What IP are you trying to connect to (i.e., tunnel IP, local subnet IP)?
  3. Can you confirm SSH is listening on 0.0.0.0:22 on both RPi's? (sudo ss -tunlp)
@rvhaasen

This comment has been minimized.

Copy link

@rvhaasen rvhaasen commented May 12, 2020

Hi insdavm,
First of al thanks for your help! i have the feeling that i'm very close to get this working but I can't figure out what i'm missing...

1. Are the two RPi's on the same local subnet?
Yes they are. Although the final goal is to have the RPi's in different local subnets, for practical reasons the testing is now in the same subnet. I assume this does not make a difference, or does it? Both RPi's reach out independent to the EC2 node, so I would think it does not matter if they are in the same or different local subnet. Or is there something I overlook?

2. What IP are you trying to connect to (i.e., tunnel IP, local subnet IP)?
I try to connect via the tunnel IP's. The local IP's are 192.168.68 and 192.168.109. When using the local addresses, ping and ssh does work in both direcions.
The tunnel IP's are 100.64.0.101 and 100.64.0.102 (the EC2 node acts as wg server and has IP address 100.64.0.1)
Ping works between all 3 nodes.
ssh only from 100.64.0.1 to both 100.64.0.101 and 100.64.0.102
ssh does not work from 100.64.0.101 to 100.64.0.102
As mentioned in my first message, running an http server on 100.64.0.101 and chatting to it with telnet on 100.64.0.102 (and the other way around) does work...

3. Can you confirm SSH is listening on 0.0.0.0:22 on both RPi's? (sudo ss -tunlp)
this is confirmed:
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=564,fd=3))

Here how the configuration of the nodes look:
pi@rp1: ~ sudo wg show
interface: wg0
public key: vL2byDvX281fra3Xe9JSTu3CjHypL1UzHNfLPDCkI2A=
private key: (hidden)
listening port: 51505
fwmark: 0xca6c

peer: NuHDg0RykQ6hdevLxBaSlCuTuSD1QlxKiG2qmzUZywM=
endpoint: "external-ip-address-of-EC2-node":42840
allowed ips: 0.0.0.0/0, ::/0
latest handshake: 18 seconds ago
transfer: 3.20 KiB received, 6.59 KiB sent
persistent keepalive: every 25 seconds

pi@rp2:~ $ sudo wg show
interface: wg0
public key: N//AIetJgc6W6AmU24sJeuewB2ZKuJbFX8VqzcbkYjA=
private key: (hidden)
listening port: 40374
fwmark: 0xca6c

peer: NuHDg0RykQ6hdevLxBaSlCuTuSD1QlxKiG2qmzUZywM=
endpoint:"external-ip-address-of-EC2-node":42840
allowed ips: 0.0.0.0/0, ::/0
latest handshake: 35 seconds ago
transfer: 34.13 MiB received, 66.13 MiB sent
persistent keepalive: every 25 seconds

ubuntu@my_ec2:~$ sudo wg show
interface: wg0
public key: NuHDg0RykQ6hdevLxBaSlCuTuSD1QlxKiG2qmzUZywM=
private key: (hidden)
listening port: 42840

peer: qd+nyR96UNNQXuWqoYhMJ3QBSwhwyBAnaKLOzzNj2xM=
endpoint: "my-external-ISP-ip-address":48311
allowed ips: 100.64.0.102/32
latest handshake: 1 minute, 21 seconds ago
transfer: 360.70 KiB received, 103.08 KiB sent
persistent keepalive: every 25 seconds

peer: vL2byDvX281fra3Xe9JSTu3CjHypL1UzHNfLPDCkI2A=
endpoint: "my-external-ISP-ip-address":48221
allowed ips: 100.64.0.101/32
latest handshake: 1 minute, 22 seconds ago
transfer: 313.04 KiB received, 128.68 KiB sent
persistent keepalive: every 25 seconds

@rvhaasen

This comment has been minimized.

Copy link

@rvhaasen rvhaasen commented May 13, 2020

Problem solved!
because the connection seemed to be ok (ping and simple wevbserver did work) somehow i had the feeling that it had to do something with the MTU size. So I started with using ping with specific sizes and noticed that the default MTU size that wireguard uses (1500) could not be pinged:
ping 100.64.0.102 -s 1500 did not work.
Trying something smaller did work:
ping 100.64.0.102 -s 1400
So next i set "MTU = 1400" in the interface section of the wg config:

[Interface]
PrivateKey = xxxxxxx
MTU = 1400

And now ssh works :-)

It also appears that it is sufficient to have the MTU setting on the "initiating" side. But because all nodes can be initating an ssh session,
So I set the value to all client nodes.

It would be good to know how to handle this issue properly. For example, ssh between the EC2 node and the RPi's did already work without the MTU setting. When is a specific MTU setting required? Is this dependent on the kind of peers nodes?
Anyway I am happy to have a solution for my vpn with RPi's :-)

@xmattx

This comment has been minimized.

Copy link

@xmattx xmattx commented Aug 30, 2020

Great one! In my particular case i had to manually add a route on the host outside of the network pointing to the internal lan via the router connected to the wg server internal ip. Also on the local pc a route to the wireguard network via the local ip of the router that acts as an access server. Else, it wouldn't work.
Thanks!

@vtronko

This comment has been minimized.

Copy link

@vtronko vtronko commented Nov 11, 2020

Can you explain why

# iptables -A FORWARD -i wg0-client -j ACCEPT
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

and

$ sysctl net.ipv4.ip_forward=1

on host A? It should work without these, all 3 devices are in the same subnet.

I am confused, at first I assumed this is a guide about routing between client subnets, but in fact all three devices here are in the same subnet (10.200.200.0/24).

Can anybody elaborate, please?

@insdavm

This comment has been minimized.

Copy link
Owner Author

@insdavm insdavm commented Nov 11, 2020

Can you explain why

# iptables -A FORWARD -i wg0-client -j ACCEPT
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

and

$ sysctl net.ipv4.ip_forward=1

on host A? It should work without these, all 3 devices are in the same subnet.

They're not on the same subnet. Host A is acting as a "server" so we can access the private subnet that's behind it, so we have to use IP forwarding and NAT to translate those packets from the tunnel to the local (to host A), private subnet.

I am confused, at first I assumed this is a guide about routing between client subnets, but in fact all three devices here are in the same subnet (10.200.200.0/24).

They're not; that's the tunnel subnet.

@vtronko

This comment has been minimized.

Copy link

@vtronko vtronko commented Nov 11, 2020

Can you explain why

# iptables -A FORWARD -i wg0-client -j ACCEPT
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

and

$ sysctl net.ipv4.ip_forward=1

on host A? It should work without these, all 3 devices are in the same subnet.

They're not on the same subnet. Host A is acting as a "server" so we can access the private subnet that's behind it, so we have to use IP forwarding and NAT to translate those packets from the tunnel to the local (to host A), private subnet.

I am confused, at first I assumed this is a guide about routing between client subnets, but in fact all three devices here are in the same subnet (10.200.200.0/24).

They're not; that's the tunnel subnet.

Sorry, I was indeed confused. You are right, thanks!
Although, for even more representative demo you could rather ping something in 100.10.202.0/24 (A's local network) rather than A's IP on tunnel interface.
Cheers

@thatsthat

This comment has been minimized.

Copy link

@thatsthat thatsthat commented Jan 1, 2021

Does all the WireGuard traffic go through host B or is it direct A-C after establishing the connection? I would like to achieve a direct A-C connection (something like ZeroTier) in order to avoid VPS extra traffic fees.

@thatsthat

This comment has been minimized.

Copy link

@thatsthat thatsthat commented Jan 6, 2021

Does all the WireGuard traffic go through host B or is it direct A-C after establishing the connection? I would like to achieve a direct A-C connection (something like ZeroTier) in order to avoid VPS extra traffic fees.

I ended up using https://tailscale.com

@posta246

This comment has been minimized.

Copy link

@posta246 posta246 commented Mar 15, 2021

Hi everybody,
I have a little problem with this config... please help me! Hope it may help others.
The question is that i want to have a site to site connection using different subnet for vpn tunnel (10.0.0.0/24) and for my home subnet (172.16.1.0/24).
With the following configs, my 'A' node does not allow me to access to other IPs behind it... is it normal? What should I check/add? Forward is done on both nodes.

this is my A node config:

[Interface]
Address = 10.0.0.186/32
PrivateKey = ...
DNS = 1.1.1.1

# as for the B node, I added here iptables route... is it ok?
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o enol -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o enol -j MASQUERADE

[Peer]
PublicKey = ...
# here, I specify only the wireguard lan IPs, because I dont want that my A node send all traffic out via wg0
AllowedIPs = 10.0.0.0/24
PersistentKeepalive = 10
Endpoint = B-node-public-IP:51820

this is the result of ip r on node A:

default via 172.16.1.1 dev eno1
10.0.0.0/24 dev wg0 scope link
172.16.1.0/24 dev eno1 proto kernel scope link src 172.16.1.186

this is my B node config:

[interface]
Address = 10.0.0.1/32
ListenPort = 51820
PrivateKey = ...

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = ...
AllowedIPs = 10.0.0.186/32, 172.16.1.0/24
#PersistentKeepalive = 25
@maulwurf87

This comment has been minimized.

Copy link

@maulwurf87 maulwurf87 commented Mar 15, 2021

this is my A node config:

[Interface]
Address = 10.0.0.186/32

# as for the B node, I added here iptables route... is it ok?

this is my B node config:

[interface]
Address = 10.0.0.1/32
ListenPort = 51820

At least your Address config is only a /32. That means both devices are NOT on the same subnet. I would change that to /24. If you look closely on the example config above, it is quite the same there.

@posta246

This comment has been minimized.

Copy link

@posta246 posta246 commented Mar 15, 2021

Thanks for the fast answer!
I will try but I dont understand why it should work... the problem is that I cannot reach the 172.16.1.0/24 subnet behind the node A. If I ping or access to server via 10.0.0.186 it works. Better, it works also if I access to the lan IP address of the node A server, 172.16.1.186, via tunnel, from host C: but if i traceroute another subnet ip 172.16.1.x, it stop after reaching the node A... There is something on node A misconfigured I think, dont know what :(

@posta246

This comment has been minimized.

Copy link

@posta246 posta246 commented Mar 15, 2021

it doesnt work...

@micktech

This comment has been minimized.

Copy link

@micktech micktech commented Mar 17, 2021

Thanks, very useful and clear enough! Is it possible for Host A to be a virtual router (like OPNsense or VyOS) ?
Allowing me to access a whole virtual LAN ?

Absolutely. My 'host A' is an OPNsense box and this config works like a charm. Make sure that you have the correct firewall rules on your OPNsense box

@euterklaas I have been trying to do this for a long time. My opnsense client connects and can be accessed on the wireguard network, but does not allow other wireguard clients opnsense lan access. Are you able to post some more info or contact me about your setup ?

@euterklaas

This comment has been minimized.

Copy link

@euterklaas euterklaas commented Mar 17, 2021

@micktech

Hey there! I'm happy to help.
I have a vserver which basically acts as my gateway to the internet. My opnsense firewall at home connects to the vserver via wireguard and the clients on my local network use this connection to reach the internet. Additionally, there are some external clients, like my mobile phone or my parent's notebook which use the vserver as their gateway. The external clients are also able to reach the clients on my home network.
The wireguard configs are the following:

Node A ("main" node, vserver)

Address = 10.0.0.2/24
PrivateKey = [...]
ListenPort = 51820

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE


# This is the peer that is on the private subnet that we want to access.
#
# Notice the AllowedIPs... without this part, WireGuard will drop the
# packets destined for the HOST 'A' subnet.  AllowedIPs is acting like
# a routing table and ACL here.
# Home
[Peer]
PublicKey = [...]
AllowedIPs = 10.0.0.1/32, 192.168.100.0/24, 192.168.99.0/24

[Peer]
PublicKey = [...]
AllowedIPs = 10.0.0.3/32

[Peer]
PublicKey = [...]
AllowedIPs = 10.0.0.4/32

[Peer]
PublicKey = [...]
AllowedIPs = 10.0.0.5/32

Node B (opnsense firewall @home)

Address = 10.0.0.1/24
DNS = 192.168.100.1,192.168.100.254
ListenPort = 51820
PrivateKey = [...]
[Peer]
PublicKey = [...]
AllowedIPs = 0.0.0.0/0
Endpoint = nodeA:51820
PersistentKeepalive = 25

Node C (external client aka mobile phone)

Address = 10.0.0.3/24
DNS = 192.168.100.1, 192.168.100.254
PrivateKey = [...]

[Peer]
AllowedIPs = 0.0.0.0/0
Endpoint = nodeA:51820
PersistentKeepalive = 25
PublicKey = [...]

I hope this helps...

@micktech

This comment has been minimized.

Copy link

@micktech micktech commented Mar 18, 2021

Thanks @euterklaas I appreciate your help,
I have exactly the same configuration except my opnsense wireguard client wont let 0.0.0.0/0 in the AllowedIPs of the endpoint section. If i add it, wireguard crashes and doesn't connect at all. I'm thinking it might be a bug. When I just leave AllowedIPs = (Wireguard network subnet) it connects and allows me to access just the wireguard IP from a mobile phone and not the internal network.

Sounds like I'll be doing some more debugging. Are you running the latest opnsense ? Thank you for getting back to me.

@euterklaas

This comment has been minimized.

Copy link

@euterklaas euterklaas commented Mar 18, 2021

You're welcome. I'm running the current version, OPNsense 21.1.2-amd64.
Did you use the GUI to configure the opnsense client? Because when I first configured it, I had some difficulties using the GUI. So I created the config file manually via SSH. Just put the file wg0.conf under /usr/local/etc/wireguard/.
For the basic setup beforehand (setting up the forwarding and the wireguard interface) I used this guide.

@jschwalbe

This comment has been minimized.

Copy link

@jschwalbe jschwalbe commented Apr 21, 2021

Can someone help me understand one thing..
My wg subnet is 10.0.25.0.
My home subnet is 192.168.25.0.
Host A is 192.168.25.81, and I'm giving it 10.0.25.81 on the wg net.
Host B is 10.0.25.1
Host C is 10.0.25.50.

Let's say Host D now connecting and should be able to ping Host C at 10.0.25.50 and Host A at 192.168.25.81, but should it also be able to ping 192.168.25.100 (not a client running wg)?

Second question, with the above configuration, all of Host A's outgoing data is hitting the VPS, which is unnecessary. I believe it's because of AllowedIPs = 0.0.0.0/0, ::/0, but I'm not sure what to change it to. Help?

@Bayliner4387

This comment has been minimized.

Copy link

@Bayliner4387 Bayliner4387 commented May 15, 2021

Hi everyone, I have a similar situation to all of the above but with some exceptions. Basically I'm trying to get to a web site hosted on a Arduino (MicroA) connected to a Rasperry Pi Access Point (RpiAP) which is WireGuard connected to a Rasberry Pi WireGuard VPN Server (RpiVPN) to my home network. The RpiAP is behind a Public WiFi router. All of this is working and I can VNC to the RpiVPN and then VNC to from there to the RpiAP and then browse the MicroA.

So understanding all this, I would like to setup a port on my home firewall (aaa.aaa.aaa.aaa:xxx) which if accessed (the easy part), will forward to the RpiVPN (192.168.1.22)(wireguard 10.6.0.1) which will then route to the RpiAP (10.6.0.2) subnet(10.10.10.1) which with then route to the MicroA (10.10.10.180).

Allowing me to get to the MicroA from anywhere Public.

This All seems doable but I lack the skill to setup all the tables (ipTables and Wireguard).

Can anyone offer some help.

Thanks.

@dominiquedutra

This comment has been minimized.

Copy link

@dominiquedutra dominiquedutra commented Oct 25, 2021

Lifesaver. Working as of this date.

@OvertCoffee

This comment has been minimized.

Copy link

@OvertCoffee OvertCoffee commented Nov 22, 2021

Thanks so much for the gist. I've been using this to connect to my local home automation setup for a while without issue via Phone > VPS > VM > LAN. I'm now looking to use this to connect to a different LAN, hoping to keep using the same VPS to save myself an extra $5/mo and I was hoping you could help me understand the iptables bit of the config on Host B.

My current wg network runs 10.200.200.0/24. I've managed to set up another instance listening on a different port in the 10.300.300.0/24 range, but I'm not sure what (if anything) needs to change about the forwarding rules for my public host to forward the traffic correctly.

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ens3 -j MASQUERADE

Will cloning the above work since anything that needs to be forwarded would already be on the 300 network, or will it break things because Host B also has an interface to the 200 network? I'm not sure how %i gets interpreted here. Normally I'd just try it and see but I don't want to bork the remote connection and lock myself out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment