Cannot ssh to clients on lan when accessing router via wireguard client

I have configured a wireguard server on my openwrt router using "/root/auto_wg_username-id.sh", from this page. The ip address of my openwrt router when accessed from the lan and not the vpn client, is 192.168.1.1. The vpn client dns address is 10.0.5.1. The Wireguard vpn client connects successfully, and when I type in 192.168.1.1 to access luci interface, it works, and I can access luci just fine. However, I also have an ssh server running on my lan located at 192.168.1.2. I can ssh into this server when connected directly to my lan, however, I cannot ssh to this server when connected via the Wireguard VPN as a client. I suspect this has something to do with the vpn client not sharing the same dns as the LAN. But I am not for certain. What I want to do, is (securely) force my wireguard vpn client to use the same dns as my lan, or at least be able to access other systems on my lan via ssh, when connecting as a wireguard client. I cannot seem to figure out how to do this and could use some help and advice.

Thank you so much!

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

cat /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'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option netmask '255.255.255.0'
	option ip6assign '60'
	list dns '1.1.1.1'
	list dns '1.0.0.1'
	list dns '8.8.8.8'
	option ipv6 '0'
	option delegate '0'
	option ipaddr '192.168.1.1'

config device
	option name 'wan'
	option macaddr '************'

config interface 'wan'
	option device 'wan'
	option proto 'dhcp'
	option ipv6 '0'

config interface 'wan6'
	option device 'wan'
	option proto 'dhcpv6'

config interface 'wg_lan'
	option proto 'wireguard'
	option private_key '*************************************='
	option listen_port '51820'
	list addresses '10.0.5.1/24'
	option mtu '1420'

config wireguard_wg_lan
	option public_key '*************************************='
	option preshared_key '*************************************='
	option description '1_lan_MBPClient'
	list allowed_ips '10.0.5.2/32'
	option route_allowed_ips '1'
	option persistent_keepalive '25'

config wireguard_wg_lan
	option public_key '*************************************='
	option preshared_key '*************************************='
	option description '2_lan_iPhoneClient'
	list allowed_ips '10.0.5.3/32'
	option route_allowed_ips '1'
	option persistent_keepalive '25'

cat /etc/config/firewall

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

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

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

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'
	option enabled '0'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option src_ip 'fc00::/6'
	option dest_ip 'fc00::/6'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'
	option enabled '0'

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'
	option enabled '0'

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'
	option enabled '0'

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'
	option enabled '0'

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

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

config rule
	option name 'Support-UDP-Traceroute'
	option src 'wan'
	option dest_port '33434:33689'
	option proto 'udp'
	option family 'ipv4'
	option target 'REJECT'
	option enabled '0'

config include
	option path '/etc/firewall.user'

config rule 'ovpn'
	option name 'Allow-OpenVPN'
	option src 'wan'
	option dest_port '1194'
	option proto 'udp'
	option target 'ACCEPT'

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

nothing jumps out as problematic.

What OS(s) do the host(s) use on your 192.168.1.0/24 network (that you are having trouble reaching)? If they are Windows based systems, you probably need to adjust the firewall on those hosts -- by default, Windows will block any connection attempts initiated from a different subnet.

My host os's on the Lan (192.168.1.0/24) are ubuntu server 20.04. I can ssh into it easily if I connect directly to my router, of which the ubuntu server is also connected to. I'm ssh'ing from Mac OS.
Also, on a side note (which I didn't document in my ORIGINAL POST), I DID change my routers LAN address from 192.168.1.1 to a different address and subnet like 192.168.2.1. I'm not sure if I have to change something in the firewall as well after changing the router's LAN ip address. Could that be an issue?

do you have any host-level firewall rules that could restrict inter-VLAN connections?

You could try the following options (either/or, not both)

Option 1: Change the networks in your lan zone to be defined as "list network" lines.

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

-- or --
Option 2:

remove wg_lan from the lan zone and then create a new zone for it and allow forwarding

config zone 'lan'
    option name 'lan'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'ACCEPT'
    list device 'tun+'
    list network 'lan'

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

config forwarding
    option src 'wg'
    option dest 'lan'

Oh… and another thought - let’s see the wg config on your peer (Mac) that is trying to connect back to your Ubuntu servers

I have a stupid question:
Does it matter that the list network are ordered ahead of the

  • option input
  • option output
  • option forward
    entries?

No. Within a stanza, order doesn’t matter.

2 Likes

I don't have any host level firewall rules that could restrict interVLAN connections. At least I don't think I do. All of my firewall rules are untouched from defaults aside from anything the wireguard auto-installation script installed. On my lan network all peers are open as well.

I tried both of the above listed options to no avail.
Here is my wg config for my mac peer:

[Interface]
Address = 192.168.9.3/24, fdf1:e8a1:8d3f:9::3/64
PrivateKey = =
DNS = 192.168.9.1, fdf1:e8a1:8d3f:9::1
[Peer]
PublicKey = =
PresharedKey = =
PersistentKeepalive = 25
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = MYPUBLICIP:51820

I also tried changing the DNS to 192.168.2.1 on this configuration. 192.168.2.1 is the dns and ip address of my router. I successfully connected, but did not see other local hosts on the lan.

By host level firewall rules, I mean the windows firewall (or whatever os you are running). Windows will block connections from a different subnet unless you change the firewall settings on the pc itself.

Gotcha. I am using a mac, and no, I don't have any host level firewall restrictions on.

What is the output of wg show

interface: vpn
  public key: ****=
  private key: (hidden)
  listening port: 51820

peer: *****=
  preshared key: (hidden)
  allowed ips: 192.168.9.2/32

peer: *****=
  preshared key: (hidden)
  allowed ips: 192.168.9.3/32

peer: *****=
  preshared key: (hidden)
  allowed ips: 192.168.9.4/32

It looks like you're not actually getting a handshake.

EDIT: to elaborate.. if you're getting a valid handshake, you will see something like this:

interface: wireguard
  public key: <REDACTED>
  private key: (hidden)
  listening port: 8444

peer: <REDACTED>
  preshared key: (hidden)
  endpoint: <REDACTED>
  allowed ips: 10.0.21.2/32
  latest handshake: 12 seconds ago
  transfer: 10.88 KiB received, 34.80 MiB sent
  persistent keepalive: every 25 seconds

Wireguard can appear to be connected even if there is no handshake. But if there is no handshake, it isn't actually able to transfer any data. And that would account for the fact that you cannot reach your devices on the LAN from the remote WG peer.

Some things to check:

  1. Do you have a public IPv4 address (if in doubt, post the first two octets, in bold, of your WAN IP as seen on your OpenWrt device: aaa.bbb.ccc.ddd)
  2. Does the address from above match what you see when you google "what's my IP"
  3. Are your keys exchanged properly.
    3a) Try removing the preshared key to reduce the number of variables (you can add it in later).
    3b) The interfaces each need their own private key (not to be exchanged).
    3c) The public keys must be exchanged between the to peers that will directly connect to each other.

If your keys might be messed up, you can try to fix them, but sometimes it's easier to simply generate new keys.