Wireguard – access devices behind router

Hi!

I've read countless forum posts and documentation and I am now really confused after having spent many hours with this problem.

I have set up Wireguard on my router using the script I found in the documentation. I would like to connect to Wireguard from my Android phone vie LTE and remotely access my Raspberry Pi connected to the router. The issue is that I can SSH into the router, but I cannot access the Raspberry Pi. The SSH request just keeps hanging.

What has worked, however, is enabling masquerading on the LAN zone. That works wonderfully and I can connect to the Raspberry Pi without an issue. However, I have read many times that enabling masquerading in the LAN zone isn't needed (as opposed to the WAN zone where it's enabled) and I wondered if there is another option available? I wouldn't want problems to unexpectedly start appearing elsewhere because of masquerading being switched on in the LAN zone.

Here are some technical details:

/etc/config/firewall
/etc/config/network

Thanks a lot!

Your Raspberry Pi might have its own firewall which does not allow traffic from WireGuard (10.0.5.0/24).

Try with allowing incoming traffic from 10.0.5.0/24 on the Raspberry Pi's firewall?

2 Likes

I have created these ufw rules on the Raspberry Pi and I still can't access it. :frowning:

Status: active

     To                         Action      From
     --                         ------      ----
[ 1] Anywhere                   ALLOW IN    10.0.5.0/24
[ 2] 22                         ALLOW IN    Anywhere                   # ssh
[ 3] 22 (v6)                    ALLOW IN    Anywhere (v6)              # ssh

Is this correct?

I've compared my config and yours. One thing that stands out is my firewall config has the LAN zone defined differently

Yours

config zone 'lan'
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option network 'lan wg_lan'

Mine

config zone 'lan'
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option network 'lan'
        option network 'wg_lan'

Could you make this change and restart your firewall?

Maybe you can put wireguard interface into a new firewall zone like "vpn" which allow input,output,redirect data,and allow data redirect from and to zone "lan"。then you can enable masquerading in zone "vpn" only.

Is the router running OpenWrt and Wireguard server also the main router in the home network?

If it is not, there will be a problem routing back to the 10.0.5.0 tunnel, unless the tunnel is masqueraded into the LAN. That causes packets from the phone to be modified to appear to have come from the wireguard server's LAN address instead of a 10.0.5 IP which the LAN is not aware of.

This is wrong. For an option like network that can be set more than once, use list instead of option.

    list network 'lan'
    list network 'wg_lan'

Below is the deprecated old syntax which may or may not still work:

    option network 'lan wg_lan'

Replace this with list network on two lines.

Masquerading requires the traffic to be between two different zones (having both in the lan zone as above will not work) and the option masq is set on the destination zone.

Log into the Pi from the LAN, and with the phone connected to the VPN via LTE, see if you can ping the phone's tunnel IP.

3 Likes

Okay, I have now set up the 'lan' firewall like so:

config zone 'lan'
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'lan'
        list network 'wg_lan'

I have restarted the router and the SSH connection from my phone to the Pi still keeps hanging, it doesn't connect.

Pinging the phone (10.0.5.2) from the Pi doesn't work either. Pinging the phone from the OpenWRT router works as expected.

Yes, it's the main and only router in the home network.

Just an idea: shouldn't I set up a static IPv4 route? I haven't got one yet, could that be the problem? If so, how would you recommend I set it up?

Are you getting a handshake? What is the output from:

wg show

No, the WG "route allowed IPs" option does that for you.

This is the output of wg show from the OpenWRT router.

interface: wg_lan
  public key: <redacted>
  private key: (hidden)
  listening port: 989

peer: <redacted>
  preshared key: (hidden)
  endpoint: <redacted>:22656
  allowed ips: 10.0.5.2/32
  latest handshake: 1 minute, 51 seconds ago
  transfer: 204.52 KiB received, 597.09 KiB sent
  persistent keepalive: every 25 seconds

ok... so handshake is okay.

Let's see the latest config files:

Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

cat /etc/config/network
cat /etc/config/firewall

/etc/config/network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix '<redacted>::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth0'
	list ports 'eth1'
	list ports 'eth2'
	list ports 'eth3'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config device
	option name 'pppoe-WAN2'
	option type 'tunnel'

config interface 'WAN'
	option proto 'pppoe'
	option device 'eth4'
	option username '<redacted>'
	option password '<redacted>'
	option ipv6 'auto'

config interface 'wg_lan'
	option proto 'wireguard'
	option private_key '<redacted>'
	option listen_port '989'
	list addresses '10.0.5.1/24'
	option mtu '1420'

config wireguard_wg_lan
	option public_key '<redacted>'
	option preshared_key '<redacted>'
	option description '<redacted>'
	list allowed_ips '10.0.5.2/32'
	option route_allowed_ips '1'
	option persistent_keepalive '25'

/etc/config/firewall


config defaults
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'

config zone 'lan'
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	list network 'lan'
	list network 'wg_lan'

config zone 'wan'
	option name 'wan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	list network 'WAN'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config rule 'wg'
	option name 'Allow-WireGuard-lan'
	option src 'wan'
	option dest_port '989'
	option proto 'udp'
	option target 'ACCEPT'

I'm not seeing any issues.

Are you testing from a remote network (i.e. cellular or a different wifi network)? If so, what is the result of these ping tests (from your mobile phone):

  • 192.168.5.1
  • 192.168.1.1
  • 8.8.8.8
  • google.com
  • <your.rpi.ip.address>

100% packet loss

0% packet loss

0% packet loss

0% packet loss

0% packet loss

Strangely, I can ping the RPi, but not SSH into it. I should be able to though, because everything works fine when I am connected to the home WiFi.

Do you have other devices on your network that you can try to connect to? Ideally not windows based machines... a mac or linux system should be the best.

I suspect that there is something on your RPi that is blocking the inbound ssh from a different subnet. You actually shouldn't need the explicit ufw rules on your pi.... normally these things work without any additional rules.

1 Like

Oh no, I've tried to SSH into a different Linux machine and it worked fine from my phone over LTE! So something must be messed up with the RPi. I wouldn't have suspected that! Thank you so much for your patience, now I'll go and try to debug the RPi...

no problem. Glad we were able to confirm that the tunnel was working properly!

2 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.