Wireguard Server behind different router / gateway

phdoerfler · Sun Sep 26, 2021 10:44 am

I'm trying to set up a Wireguard server on an Audience. I set up port forwarding on the (different) router connected to the internet and I can connect from my Wireguard client to the server. However, from there I can't get anywhere else. My traffic seems to be stuck on the Audience router. DNS is not working either. I haven't investigated with wireshark yet so this is just an educated guess.

I've read that enabling the Wireguard server adds a new default route and I have also added NAT (srcnat with masquerade) on the Audience, but no luck.
It's probably something very simple that's missing and I hope that someone here was in this situation before and can point me in the right direction.
Do I need to set up anything else in the ISP / internet router besides the port forwarding of UDP 13231?
The Wireguard client itself connects just fine and everything is green.

I'm not currently near those routers, I'm writing this of memory so I might have gotten one or two things wrong, I'll update this once I got access again.

anav · Sun Sep 26, 2021 2:51 pm

Yeah the explanation is more confusing then helpful.
Suggest you provided a network diagram to show what you mean
Between devices within the same network on both sides of the tunnel.

phdoerfler · Mon Sep 27, 2021 2:02 pm

Right, here's the network layout:

IMG_0611.jpeg

anav · Mon Sep 27, 2021 2:14 pm

Im assuming gateway A and gateway B are standard consumer routers?
Do you have any dyndns domain names for either of the two gateways (and especially for network B router)?
Are both public IPs pingable (from a pc on the other network - in other words, ISP does not block ICMP pings?)

phdoerfler · Mon Sep 27, 2021 3:40 pm

tl;dr: yes, yes, yes.

Im assuming gateway A and gateway B are standard consumer routers?

Yes, both are AVM Fritz!Box devices. A brand of routers particularly common in Germany. They aren't the worst but I'm ready to move on. They have a few tricks up their sleeve but nothing like MikroTik routers.

Do you have any dyndns domain names for either of the two gateways (and especially for network B router)?

Yes, for gateway A I do. Why would I need one for gateway B, the client side? This being said, I can add one for the network B router as well if necessary.

Are both public IPs pingable (from a pc on the other network - in other words, ISP does not block ICMP pings?)

I want to say yes, gateway A is definitely pingable, I just checked. Pretty sure that gateway B is pingable as well.

sindy · Mon Sep 27, 2021 6:55 pm

Since you can reach at least something on the remote side via the wireguard tunnel, you don't need to bother about the Fritzboxes and the Internet any more - all the remaining issues are related to the wireguard configuration and the firewall. So you'll have to post the exports from both Mikrotik devices (or whatever the wireguard client is) to get an advice on that part. See the mini-howto in my automatic signature below.

anav · Mon Sep 27, 2021 9:35 pm

In a nutshell.
You can choose any port for wireguard as long as its UDP.
-Port forward on fritz (to audience lanip = audience wanip)
-input chain rule on audience accepting same traffic from WAN interface
-ip route for wg interface traffic with destination of IP of device or subnet (local to network b)
(thus any traffic client sends through server to the internet comes back from the internet hits the fritz box, goes to the audience lanip, hits the audience and the audience sends the return traffic out the wg interface back to the client).

As sindy noted, we really need to see the WG settings on the audience and client but seeing the whole config will reveal the associated settings as well........
/export hide-sensitive file=anynameyouwish

phdoerfler · Mon Sep 27, 2021 11:40 pm

Here's a compact export without sensitive details. I also removed all of the CAPsMAN stuff. Most of the config is firewall, it's mostly the default firewall and thinking about it I could probably just drop the firewall completely since this router has no direct WAN connection.

Anyways, here goes:

# sep/27/2021 22:32:12 by RouterOS 7.1rc4
# software id = 2QED-STSN
#
# model = RBD25G-5HPacQD2HPnD
/interface bridge
add admin-mac=08:55:31:CC:11:BD auto-mac=no comment=defconf name=lan-bridge
/interface wireguard
add listen-port=13231 mtu=1420 name=wireguard1
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.254
/ip dhcp-server
add address-pool=default-dhcp disabled=yes interface=lan-bridge name=defconf
/user group
add name=prometheus policy="read,test,winbox,api,!local,!telnet,!ssh,!ftp,!reb\
    oot,!write,!policy,!password,!web,!sniff,!sensitive,!romon,!dude,!tikapp,!\
    rest-api"
/interface bridge port
add bridge=lan-bridge comment=defconf ingress-filtering=no interface=ether2
add bridge=lan-bridge ingress-filtering=no interface=wlan3
/ipv6 settings
set accept-router-advertisements=yes
/interface list member
add comment=defconf interface=lan-bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/interface wireguard peers
add allowed-address=192.168.66.2/32 comment=Umbra interface=wireguard1 \
    public-key="DEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEFmWI="
/ip address
add address=192.168.1.6/24 comment=defconf disabled=yes interface=lan-bridge \
    network=192.168.1.0
add address=192.168.66.1/24 interface=wireguard1 network=192.168.66.0
/ip dhcp-client
add comment=defconf interface=lan-bridge
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf dns-server=192.168.88.1 gateway=\
    192.168.88.1 netmask=24
/ip dns
set allow-remote-requests=yes servers=192.168.1.1
/ip dns static
add address=192.168.1.6 comment=defconf name=router.lan
/ip firewall filter
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related hw-offload=yes
add action=accept chain=forward comment=\
    "defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=accept chain=input comment=\
    "Allow Wireguard, doesn't seem to be necessary\?" dst-port=13231 \
    log-prefix=asdf protocol=udp
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WAN
/ip firewall nat
add action=src-nat chain=srcnat comment="defconf: masquerade" ipsec-policy=\
    out,none out-interface=lan-bridge protocol=udp to-addresses=192.168.1.65 \
    to-ports=13231
/ipv6 firewall address-list
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
add address=::1/128 comment="defconf: lo" list=bad_ipv6
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6
/ipv6 firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=input comment="defconf: accept UDP traceroute" port=\
    33434-33534 protocol=udp
add action=accept chain=input comment=\
    "defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=\
    udp src-address=fe80::/10
add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 \
    protocol=udp
add action=accept chain=input comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=input comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=input comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
add action=accept chain=forward comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop packets with bad src ipv6" src-address-list=bad_ipv6
add action=drop chain=forward comment=\
    "defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" \
    hop-limit=equal:1 protocol=icmpv6
add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=forward comment="defconf: accept HIP" protocol=139
add action=accept chain=forward comment="defconf: accept IKE" dst-port=\
    500,4500 protocol=udp
add action=accept chain=forward comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=forward comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=forward comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=forward comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
/system clock
set time-zone-name=Europe/Berlin
/system identity
set name=Audience
/system package update
set channel=development

sindy · Tue Sep 28, 2021 12:12 am

What I can see is that the Audience is a DHCP client, so the Fritzbox is most likely the default gateway on the LAN. So unless the Fritzbox tells its other DHCP clients that the gateway of the route to 192.168.66.0/24 is the IP address of the Audience, they send responses to requests coming from Umbra to the Fritzbox, and Fritzbox sends these responses to its WAN gateway because it doesn't know that it should send them to the Mikrotik either.

To overcome this, you have to add another masquerade rule:
chain=srcnat src-address=192.168.66.0/24 out-interface=lan-bridge action=masquerade

That way, the Audience will change the source address of all requests coming from Umbra to its own one in the LAN subnet, so it will get the responses from other devices in that subnet.

phdoerfler · Tue Sep 28, 2021 6:31 am

Unfortunately that didn't fix it

Your explanation makes a ton of sense in my head and is exactly along the lines of what I was suspecting. The fritzbox at 192.168.1.1 is the default gateway, indeed, alas the NAT rule doesn't seem to fix the problem. Bummer! For completeness sake, here's the NAT rules:

[admin@Audience] > /ip firewall nat print
Flags: X - disabled, I - invalid; D - dynamic
 0    ;;; defconf: masquerade
      chain=srcnat action=src-nat to-addresses=192.168.1.65 to-ports=13231 protocol=udp out-interface=lan-bridge
      log=no log-prefix="" ipsec-policy=out,none

 1    chain=srcnat action=masquerade src-address=192.168.66.0/24 out-interface=lan-bridge

I have since removed rule #0. It's a leftover from earlier experiments. Not that it changed anything.
I still can not ping 192.168.1.1 for instance, or 8.8.8.8. Nor can I surf the web.
Something is still amiss.

phdoerfler · Tue Sep 28, 2021 2:06 pm

Taking a mental step back, I'm not sure how much the active connection status of my wireguard client really says. If I omit specifying the endpoint I can still activate the tunnel and the client will say it's active. I guess I'm not yet familiar enough with how WireGuard works. Apparently it doesn't take much to get the green "active" status.
Moreover, if I do enter an endpoint but use a wrong port number it also says it's active and that a few bytes (like 444 bytes or 1.01 KiB) are sent. Seems to be the same low amount of bytes as when I use the "correct" port number. So it's probably best to look for the (remaining) problem there.

Here's my client config: ²

[Interface]
PrivateKey = asdfasdfasdfasdfasdfasdf=
Address = 192.168.66.2/24
DNS = 192.168.66.1

[Peer]
PublicKey = QshdhpmPjzYhKtajMjkhRK02nPTqj45Kbo0RQTT1Mic=
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = somethingsomething.myfritz.net:13232

Here the current config of the wireguard server: ¹

# sep/28/2021 12:50:42 by RouterOS 7.1rc4
# software id = 2QED-STSN
#
# model = RBD25G-5HPacQD2HPnD
/interface bridge
add admin-mac=08:55:31:CC:11:BD auto-mac=no comment=defconf name=lan-bridge
/interface wireguard
add listen-port=13231 mtu=1420 name=wireguard1
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.254
/ip dhcp-server
add address-pool=default-dhcp disabled=yes interface=lan-bridge name=defconf
/user group
add name=prometheus policy="read,test,winbox,api,!local,!telnet,!ssh,!ftp,!reb\
    oot,!write,!policy,!password,!web,!sniff,!sensitive,!romon,!dude,!tikapp,!\
    rest-api"
/interface bridge port
add bridge=lan-bridge comment=defconf ingress-filtering=no interface=ether2
add bridge=lan-bridge ingress-filtering=no interface=wlan3
/ipv6 settings
set accept-router-advertisements=yes
/interface list member
add comment=defconf interface=lan-bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/interface wireguard peers
add allowed-address=192.168.66.2/32 comment=Umbra interface=wireguard1 \
    public-key="eRQk9vsJKT7mY2rdH8g7OaX5FhWt/Haqy4ZAl9qBmWI="
/ip address
add address=192.168.1.6/24 comment=defconf disabled=yes interface=lan-bridge \
    network=192.168.1.0
add address=192.168.66.1/24 interface=wireguard1 network=192.168.66.0
/ip dhcp-client
add comment=defconf interface=lan-bridge
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf dns-server=192.168.88.1 gateway=\
    192.168.88.1 netmask=24
/ip dns
set allow-remote-requests=yes
/ip firewall nat
add action=masquerade chain=srcnat out-interface=lan-bridge src-address=\
    192.168.66.0/24
/ipv6 firewall address-list
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
add address=::1/128 comment="defconf: lo" list=bad_ipv6
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6
/snmp
set enabled=yes
/system clock
set time-zone-name=Europe/Berlin
/system identity
set name=Audience
/system ntp client
set enabled=yes
/system ntp client servers
add address=192.168.1.1
/system package update
set channel=development
/system routerboard settings
set cpu-frequency=auto
/system scheduler
add interval=1d name="auto upgrade" on-event="/system package update\r\
    \ncheck-for-updates once\r\
    \n:delay 3s;\r\
    \n:if ( [get status] = \"New version is available\") do={ install }" \
    policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
    start-date=sep/21/2021 start-time=03:00:00
/tool graphing interface
add store-on-disk=no

Screenshot of what it looks like in action: ²

Untitled 14.png

¹ Again with CAPsMAN and maybe some more unrelated things removed
² + changes to remove publicly identifiable information

sindy · Tue Sep 28, 2021 2:59 pm

Maybe I just didn't get your OP right when you wrote that the traffic is trapped in the Audience? My feeling was that Umbra can ping 192.168.66.1, which would prove the tunnel itself to be working allright (which the configurations suggest), but it cannot get anywhere else.

If that's the case, make your command line window for the Audience as wide as your screen allows, run /tool sniffer quick ip-address=1.1.1.1 ip-protocol=icmp in it, and start pinging 1.1.1.1 from Umbra, to see whether the ping request makes it to the Audience, whether the Audience forwards it to Fritzbox and properly does the masquerade, whether 1.1.1.1 responds, and whether the Audience forwards the response via the wireguard tunnel interface to Umbra.

If not sure what it shows, post the output here.

If it shows nothing at all, it means that even the request doesn't make it to the Audience, which to me means that whilst the Wireguard configuration at Umbra is correct, OS-level routing may not be. There are two stages of routing when it comes to Wireguard - the first stage at operating system level says that the gateway to a given destination is the Wireguard interface, and the second stage is a Wireguard-internal one, indicating which destination is accessible via which Wireguard peer linked to the same Wireguard interface. Your configuration from Umbra only contains the second stage.

Tue Sep 28, 2021 3:56 pm

Taking a mental step back, I'm not sure how much the active connection status of my wireguard client really says. If I omit specifying the endpoint I can still activate the tunnel and the client will say it's active. I guess I'm not yet familiar enough with how WireGuard works. Apparently it doesn't take much to get the green "active" status.
Moreover, if I do enter an endpoint but use a wrong port number it also says it's active and that a few bytes (like 444 bytes or 1.01 KiB) are sent. Seems to be the same low amount of bytes as when I use the "correct" port number. So it's probably best to look for the (remaining) problem there.

Don't know anymore where I saw it but I understood Wireguard is to be considered a stateless interface.
There is no activity indicator except for checking traffic is flowing BOTH ways or the ability to reach the endpoint ip address.
Took me also some time to get that one.

Once you set up an interface, successful or not, it WILL send out packets. That's what you see happening. But if nothing comes back, it's not working.
Apart from routing issues blocking you to access the other site LAN, the setup of the interface itself should be pretty easy.
- make sure the "server"-port is THE SAME for peers on both server and client side. From your config above it seems this was not the case.
- make sure this port is accessible on the server device (UDP only and do check other firewalls in between as well !)
- for ease of config/troubleshooting, use a separate IP subnet for the wireguard endpoints on both ends.
- for the client peer, use the public IP or DDNS or whatever of the server device with the correct port. Make sure you can at least ping that IP address from the client. If you can not, the interface will not be set up either.
- for the server peer, use the IP address of the server endpoint, same port.

Routing as in getting proper access to both LAN-sides is another thing. Still struggling with it myself

phdoerfler · Tue Sep 28, 2021 4:06 pm

Maybe I just didn't get your OP right when you wrote that the traffic is trapped in the Audience? My feeling was that Umbra can ping 192.168.66.1, which would prove the tunnel itself to be working allright (which the configurations suggest), but it cannot get anywhere else.

Oh no, you definitely got it right! That's exactly what I thought was going on at that time. I think this is how it happened:

1. I first tried to set this up while I was in network A and IIRC I did get to the point where I could establish a wireguard connection from Umbra to the Audience while I was on the LAN, so no Fritzbox gateway in between. If I remember right I was indeed able to ping 192.168.66.1 from Umbra. Great! In this situation I used the LAN IP (192.168.1.65) of Audience to connect.
2. Then I tried to connect to it from outside that network having set up port forwarding and using the external IP. And there I still got a green "active" wireguard connection and my monkey brain read that as "great, wireguard works". Looking at it now I didn't even get a handshake. Yet it turned green. I could enter a wrong port number for the endpoint and it still went green and read "active". Contrary to my earlier experiments where I was within network A, from outside the network I was not able to ping 192.168.66.1.

So, my bad, I might have mixed up results of my experiments from 1. and 2..

This being said:

It's working now. And I do not know what changed, which is very frustrating. I re-did the port forwarding rule in the fritzbox on network A multiple times. Eventually I got so desperate I temporarily set up port forwarding to Audience's port 80 and that did work. I then quickly removed that forwarding rule and let the fritzbox router apply those changes. Then, just now, I spotted that from earlier "look, I can enter whatever port, it still goes green" experiments I still had the wrong port number on Umbra, so I changed that. Great catch of you to notice that as well.
After which I have been able to connect with Wireguard and get a handshake! DNS is working, too. In fact, I am writing this post through this exact tunnel.
I am fairly confident, though, that I have tried with this port forwarding rule and the correct port multiple times and never got a single handshake. But who knows at this point. In my experience, after messing around with things for a while stupid mistakes tend to creep in.

Anyways. Case closed? Not quite:
I tried to set up my phone as another Wireguard client and added it as a new peer in the Audience. On my phone I can also get a handshake, but only if I add persistent keepalive and besides the handshake nothing much happens. I can't browse the web.
If I torch the wireguard1 interface on Audience I can see the activity of Umbra, but I see no trace of my phone. I do see it sending and receiving small bits of data. The handshakes and keep alive packets presumably. But no actual traffic is happening.

I did not have to add keepalive on Umbra.

Both Umbra and my phone are on the same Wifi. Fwiw if I switch my phone to cellular it still won't work.

At this point I am a bit afraid to disconnect my wireguard session on Umbra for fear I won't be able to get it running again but science demands sacrifices I guess…

Edit: It span up again after disconnecting like there was never any trouble to begin with. Also: Amazing how I did not notice the wrong port when I edited the screenshot to mask the IP. It was right next to it and I zoomed in on the IP. Oh well.

sindy · Tue Sep 28, 2021 4:27 pm

- make sure the "server"-port is THE SAME for peers on both server and client side. From your config above it seems this was not the case.

To be precise - packets sent by router A to a configured "endpoint IP and port" must reach router B's "listen port", or packets sent by router B to a configured "endpoint IP and port" must reach router A's "listen port". Both peers keep sending the initial packet until they get a response or the peer's initial packet. If the recipient can map a received initial packet to one of the configured peers by the key, it updates the "endpoint IP and port" of that peer, and sends a response to the updated destination. This means that a public address or static port forwarding is only necessary at one end, the other one may be behind a NAT with no static port forwarding.

Whether it is correct or a typo that the Audience listens at 13231 whilst the Umbra's configuration says 13232 depends on how the port forwarding on the Fritzbox between the Audience and the internet is configured.

Tue Sep 28, 2021 4:34 pm

Anyways. Case closed? Not quite:
I tried to set up my phone as another Wireguard client and added it as a new peer in the Audience. On my phone I can also get a handshake, but only if I add persistent keepalive and besides the handshake nothing much happens. I can't browse the web.
If I torch the wireguard1 interface on Audience I can see the activity of Umbra, but I see no trace of my phone. I do see it sending and receiving small bits of data. The handshakes and keep alive packets presumably. But no actual traffic is happening.

Do your wireguard peers all have unique IP addresses within the same subnet ?
On server side, best to use the exact end-address for the peer (a.b.c.d/32). Otherwise the server side does not know what to send where if you got multiple peers active. That's how I understood it should be setup (and that's how it works for me).

phdoerfler · Thu Sep 30, 2021 11:45 pm

Edit: Scroll down to below the screenshot for the solution.

Yeah I have set it up exactly like you describe. It’s really odd.

Server:

/interface/wireguard export hide-sensitive 
# sep/30/2021 22:52:51 by RouterOS 7.1rc4
# software id = 2QED-STSN
#
# model = RBD25G-5HPacQD2HPnD
/interface wireguard
add listen-port=13231 mtu=1420 name=wireguard1
/interface wireguard peers
add allowed-address=192.168.66.2/32 comment=Umbra interface=wireguard1 public-key="eRQk9vsJKT7mY2rdH8g7OaX5FhWt/Haqy4ZAl9qBmWI="
add allowed-address=192.168.66.3/32 comment=Chinchilla interface=wireguard1 public-key="KkylEUn5MynCYjAMxYiYxdudTznhU4XYk4oEYax3plk="

/ip address/ print
Flags: X, D - DYNAMIC
Columns: ADDRESS, NETWORK, INTERFACE
#   ADDRESS          NETWORK       INTERFACE 
;;; defconf
0 X 192.168.1.6/24   192.168.1.0   lan-bridge
1   192.168.66.1/24  192.168.66.0  wireguard1
2 D 192.168.1.65/24  192.168.1.0   lan-bridge

Client:

IMG_3684.jpg

Edit: Ha! Figured it out!

AllowedIPs = 0.0.0.0/0, ::/0

was missing on Chinchilla. I had that in the client config for Umbra.

Wireguard Server behind different router / gateway

Wireguard Server behind different router / gateway

Re: Wireguard Server behind different router / gateway

Re: Wireguard Server behind different router / gateway

Re: Wireguard Server behind different router / gateway

Re: Wireguard Server behind different router / gateway

Re: Wireguard Server behind different router / gateway

Re: Wireguard Server behind different router / gateway

Re: Wireguard Server behind different router / gateway

Re: Wireguard Server behind different router / gateway

Re: Wireguard Server behind different router / gateway

Re: Wireguard Server behind different router / gateway

Re: Wireguard Server behind different router / gateway

Re: Wireguard Server behind different router / gateway

Re: Wireguard Server behind different router / gateway

Re: Wireguard Server behind different router / gateway

Re: Wireguard Server behind different router / gateway

Re: Wireguard Server behind different router / gateway

Who is online