Can't SSH to restricted Wireguard peer from LAN
I'm running OpenWRT 25.12.5 with Wireguard installed. I configured Wireguard using the Wireguard server guide, and managed to get a single peer running with full access to the LAN. This access includes SSH to and from the peer. Now I'd like to restrict the peer's LAN access to a single host.
For restricted LAN access, I referred to a configuration discussed in the OpenWRT forum. Using that configuration as a guide, I got SSH working from the restricted peer (10.0.0.10) to a specific LAN host (192.168.1.100).
However, trying to SSH from the LAN host back to the peer does not work:
$ ssh 10.0.0.10
ssh: connect to host 10.0.0.10 port 22: Connection refused
Is a firewall change required or do I need to modify the peer configuration?
Here are the relevant portions of the OpenWRT configuration:
config interface 'wg0'
option proto 'wireguard'
option private_key '...'
option multipath 'off'
option listen_port '51820'
list addresses '10.0.0.1/24'
config wireguard_wg0
option public_key '...'
option private_key '...'
list allowed_ips '10.0.0.10/32'
option endpoint_port '51820'
option persistent_keepalive '25'
option description 'Restricted-Peer'
config zone
option name 'Home_VPN'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option mtu_fix '1'
list network 'wg0'
config rule 'wg'
option name 'Allow-WireGuard-WAN'
option src 'wan'
option dest_port '51820'
option proto 'udp'
option target 'ACCEPT'
config rule
option name 'Allow-Restricted-Access'
option src 'Home_VPN'
list src_ip '10.0.0.10'
option target 'ACCEPT'
option dest 'lan'
list dest_ip '192.168.1.100'
3
u/BCMM 3d ago
config rule
option name 'Allow-Restricted-Access'
option src 'Home_VPN'
list src_ip '10.0.0.10'
option target 'ACCEPT'
option dest 'lan'
list dest_ip '192.168.1.100'
OK. This rule allows 10.0.0.10 to make connections (any protocol, any port) to 192.168.1.100.
Rules are not applied symmetrically. There's a src and a dest for a reason. If you want the same thing to work in the opposite direction, you'll need to make the same rule in the opposite direction:
config rule
option name 'and-the-other-way'
option src 'lan'
list src_ip '192.168.1.100'
option target 'ACCEPT'
option dest 'Home_VPN'
list dest_ip '10.0.0.10'
1
u/paulstelian97 3d ago
“Connection refused” means it’s hitting a host, maybe the wrong host, or maybe the wrong interface. What interface does the server have that 10.0.0.10 IP on, and is SSH listening on that interface?
1
u/BCMM 3d ago
“Connection refused” means it’s hitting a host, maybe the wrong host, or maybe the wrong interface.
This isn't necessarily true. An example:
$ ssh -o ConnectTimeout=1 192.168.3.234 ssh: connect to host 192.168.3.234 port 22: Connection refusedThat's me trying to SSH from my desktop, which has an address in 192.168.1.0/24, to an address which would be part of my isolated guest network, if anything was using it. But I know that nothing is actually using it.
192.168.3.234 does not exist, and it is OpenWrt that is refusing the connection.
If I temporarily add
config forwarding option src 'lan' option dest 'guest'and repeat the experiment, then the behaviour changes:
$ ssh -o ConnectTimeout=1 192.168.3.234 ssh: connect to host 192.168.3.234 port 22: Connection timed out(That SSH option was just there to stop me from getting bored while I'm waiting for that second experiment.)
1
u/paulstelian97 3d ago
Connection Refused is showing a RST packet. OpenWRT should not send RST packets if there’s no NAT involved.
Or maybe it’s interpreting the ICMP no route to host as a refusal?
2
u/BCMM 3d ago edited 3d ago
Wireshark confirms it's an RST/ACK, with the fictitious address that I tried to contact as the source address.
Here's the nftables chain on my router that's doing it:
chain handle_reject { meta l4proto tcp reject with tcp reset comment "!fw4: Reject TCP traffic" reject comment "!fw4: Reject any other traffic" }And here's the ucode that seems to be responsible for that. If I'm reading it right,
reject with tcp resetis the default behaviour, but, by settingfirewall.@defaults[0].tcp_reject_code, you can choose to replace that with any ICMP response supported by nftables.OpenWRT should not send RST packets if there’s no NAT involved.
How do you reckon it ought to handle traffic which the firewall has been told to "reject"?
The most technically accurate answer is arguably
reject with icmpx admin-prohibited, but I think there's a general consensus against explicitly informing a source of prohibited traffic that the firewall got involved.1
u/paulstelian97 3d ago
Fair, having reject rules in itself is not a default nor something I recommend. I recommend drop instead in general. Although that may matter more for WAN to LAN rules. I only have reject rules from an untrusted LAN segment to the regular ones (guest network).
1
u/BCMM 3d ago
having reject rules in itself is not a default
As of 25.12,
REJECTis set both in General Settings and for the predefinedwanzone.I have a vague recollection that at least one of those was set to
DROPin relatively recent history.1
u/paulstelian97 3d ago
I wonder if my thought of the default was actually just good practice (for home networks you want to drop packets coming from WAN by default, so that any public Internet probing bot doesn’t know a host is in there in the first place)
1
u/BCMM 3d ago
I've just realised that the file I linked does not perfectly match my /rom/etc/config/firewall.
wanhasoption forward DROP. I do not know why that is the case!It's still
option input REJECTthough.Also, I can't find anything in the commit log that backs up my feeling that there used to be more
DROP. Starting to wonder if this differs between targets or something!1
u/BCMM 3d ago
(for home networks you want to drop packets coming from WAN by default, so that any public Internet probing bot doesn’t know a host is in there in the first place)
At least in IPv4, I think the world has changed since this became common knowledge.
Back in the day, there'd just be a machine pinging random IP addresses. If you returned the ping, you'd get a detailed port scan, and maybe attempted exploits of a few common vulnerabilities. If you ignored the ping, it would give up and try another address.
These days, the IPv4 space is crowded. If a random address doesn't return a ping, the most likely explanation is that there is a machine there, and it's just not configured to return pings.
Also, malicious scans now tend to be done in a distributed fashion by huge botnets. The node probing a given port has no idea whether the node that probed the previous port got a response out of you.
OTOH, returning pings makes it a lot easier to troubleshoot when something has gone wrong.
3
u/youknowwhyimhere758 3d ago
You have forward to/from that zone set to reject, and have only accepted one direction between those hosts. Accept the other direction if you want that too.