Yet more wireguard saga updates

Installing and Using OpenWrt
1

I've been struggling for a year or so with inconsistent / strange wireguard quirks mostly from not being fully versed in advanced networking (never finished my CCNA course long ago alas).

Weirdly I tonight I came across this thread and decided to compare firewall settings and wireguard client settings.

I changed the following and now seem to be able to access internal resources finally with my laptop wireguard setup (mobile setup always seemed to work for some reason).

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option masq '1'  <----- added this
	option forward 'ACCEPT' 
	list network 'lan'

config zone
	option name 'wg'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'   <--- changed this to accept from reject
	option family 'ipv4'
	list network 'wg0'
	option masq '1'           <------added this

Mostly I'm writing this to ask if I've done something horribly insecure by changing these firewall rules. I still struggle a bit to understand the implications for forwarding permissions through zones. So any feedback would be appreciated especially explanations that would help me to understand better what is happening behind the scenes with routing.

2

More context is necessary.

  1. Is this the main router on the network, or is it behind another router? If it is behind another router, please detail how it is connected to the main router.

  2. Let's look at your complete config to better understand your setup:

Please connect to your OpenWrt device using ssh and 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:

ubus call system board
cat /etc/config/network
cat /etc/config/firewall
3

Is this the main router on the network, or is it behind another router?
Main router, directly behind the Fiber modem from the ISP.

apologies yes.

ubus call system board

{
	"kernel": "5.15.134",
	"hostname": "OpenWrt_Fitlet",
	"system": "AMD A4 Micro-6400T APU + AMD Radeon R3 Graphics",
	"model": "CompuLab fitlet",
	"board_name": "compulab-fitlet",
	"rootfs_type": "ext4",
	"release": {
		"distribution": "OpenWrt",
		"version": "23.05.0",
		"revision": "r23497-6637af95aa",
		"target": "x86/64",
		"description": "OpenWrt 23.05.0 r23497-6637af95aa"
	}
}

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 'eth0'
	list ports 'eth1'
	list ports 'eth2'

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 interface 'wan'
	option proto 'dhcp'
	option device 'eth3'
	option peerdns '0'

config interface 'wg0'
	option proto 'wireguard'
	option listen_port '51820'
	list addresses '192.168.2.1/24'
	option private_key 'BLANK='
	option peerdns '0'
#	list dns '192.168.1.1'
config wireguard_wg0
	option description 'a20e'
	option public_key 'BLANK='
	option persistent_keepalive '25'
	list allowed_ips '192.168.2.2/32'
	option route_allowed_ips '1'

config wireguard_wg0
	option description 'X1'
	option public_key 'BLANK='
	option persistent_keepalive '25'
	option route_allowed_ips '1'
	list allowed_ips '192.168.2.3/32'

config wireguard_wg0
	option description 'Acer-5'
	option public_key 'BLANK='
	list allowed_ips '192.168.2.4/32'
	option route_allowed_ips '1'
	option persistent_keepalive '25'

config wireguard_wg0
	option description 'XA2'
	option public_key 'BLANK='
	list allowed_ips '192.168.2.5/32'
	option persistent_keepalive '25'
	option route_allowed_ips '1'

cat /etc/config/firewall

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

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

config zone
	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 src_ip 'fc00::/6'
	option dest_ip 'fc00::/6'
	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
	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
	option name 'allow-ssh-router'
	list proto 'tcp'
	option dest_port '22'
	option target 'ACCEPT'
	option src '*'
	option family 'ipv4'

config redirect
	option target 'DNAT'
	option name 'BLANK'
	list proto 'tcp'
	option src 'wan'
	option src_dport '80'
	option dest_ip '192.168.1.226'
	option dest_port '80'
	option dest 'lan'

config redirect
	option target 'DNAT'
	option name 'BLANK'
	list proto 'tcp'
	option src 'wan'
	option src_dport '8096'
	option dest_port '8096'
	option dest_ip '192.168.1.226'
	option dest 'lan'

config redirect
	option target 'DNAT'
	option name 'BLANK'
	list proto 'tcp'
	option src 'wan'
	option src_dport '8092'
	option dest_port '8092'
	option dest 'lan'
	option dest_ip '192.168.1.226'

config redirect
	option target 'DNAT'
	option src 'wan'
	option src_dport '25565'
	option dest_port '25565'
	option dest 'lan'
	option dest_ip '192.168.1.226'
	option src_ip 'BLANK'
	list proto 'tcp'
	list proto 'udp'
	option name 'BLANK'
	option enabled '0'



config redirect
	option target 'DNAT'
	list proto 'tcp'
	option src 'wan'
	option src_dport '143'
	option dest 'lan'
	option dest_ip '192.168.1.226'
	option name 'BLANK'
	option dest_port '143'

config redirect
	option target 'DNAT'
	list proto 'tcp'
	option src 'wan'
	option src_dport '993'
	option dest 'lan'
	option dest_ip '192.168.1.226'
	option name 'BLANK'
	option dest_port '993'

config redirect
	option target 'DNAT'
	option name 'BLANK'
	list proto 'tcp'
	option src 'wan'
	option src_dport '465'
	option dest 'lan'
	option dest_ip '192.168.1.226'

config redirect
	option target 'DNAT'
	option name 'BLANK'
	list proto 'tcp'
	option src 'wan'
	option src_dport '587'
	option dest 'lan'
	option dest_ip '192.168.1.226'

config redirect
	option target 'DNAT'
	option name 'BLANK'
	list proto 'tcp'
	option src 'wan'
	option src_dport '25'
	option dest 'lan'
	option dest_ip '192.168.1.226'

config rule
	option name 'BLANK'
	option family 'ipv4'
	list proto 'tcp'
	option src '*'
	option dest 'lan'
	list dest_ip '192.168.1.226'
	option dest_port '25'
	option target 'ACCEPT'
	option enabled '0'

config rule
	option name 'BLANK'
	list proto 'tcp'
	option src 'lan'
	list src_ip '192.168.1.226'
	option dest '*'
	option dest_port '25'
	option target 'ACCEPT'
	option enabled '0'

config rule
	option name 'Block all other SMTP'
	list proto 'tcp'
	option src '*'
	option dest '*'
	option dest_port '25'
	option target 'REJECT'
	option enabled '0'

config zone
	option name 'wg'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option family 'ipv4'
	list network 'wg0'
	option masq '1'

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

config forwarding
	option src 'wg'
	option dest 'wan'

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

config forwarding
	option src 'wan'
	option dest 'wg'

config rule
	option name 'wan-local-wireguard'
	list proto 'udp'
	option src 'wan'
	option target 'ACCEPT'
	option dest_port '51820'

config redirect
	option target 'DNAT'
	option name 'BLANK'
	list proto 'tcp'
	option src 'wan'
	option src_dport '443'
	option dest 'lan'
	option dest_ip '192.168.1.226'
	option dest_port '443'

config redirect
	option target 'DNAT'
	option name 'BLANK'
	option src 'wan'
	option dest 'lan'
	option dest_ip '192.168.1.226'
	option src_dport '50881'
	option dest_port '50881'

config redirect
	option target 'DNAT'
	option name 'BLANK'
	option src 'wan'
	option dest 'lan'
	option dest_ip '192.168.1.226'
	option src_dport '51413'
	option dest_port '51413'

I took the liberty of removing any firewall entries / port forwards that had disabled rules (option enabled '0'). I also blanked a few service names just for privacy reasons, it's obvious from the ports what they are but it might help a little.

4

The masquerading you're showing should not be needed... I'll get to that in a moment. Beyond that, though, I don't see anything glaring, but a few things to optimize...

Typically, if you set peerdns to 0, on the wan, you should specify a public DNS of your choosing:

The DNS lines below don't do anything -- just remove them.

Masquerading should not be needed, nor should it be enabled on the lan zone:

This is generally not recommended, especially since you have a WG config... don't expose ssh to the internet:

And same here (you can also remove the family option):

Remove this:

Check your port forwards to make sure that you don't have duplicates (the stuff going to 192.168.1.226)... I didn't look at them in detail, but you have a bunch of disabled ones and a bunch of enabled ones... just go through and make sure you have only one forward per port, and that you've got only the ones you need/want.

That said... going back to the masquerading:

  1. How are you testing your laptop? Is that from inside or outside your network?
  2. If you were on a remote network, what was the subnet of that network? The reason this may be critical is that if the local-to-you-at-that-moment network uses the same 192.168.1.0/24 network, the traffic that is destined for your own network won't go through the tunnel as you expect.
  3. What tests did you run to attempt to reach your network, and what were the results? What is the host OS of the devices you are trying to reach remotely?
  4. Let's see your laptop's WG config.
5

Typically, if you set peerdns to 0, on the wan, you should specify a public DNS of your choosing:

This one is a bit strange actually, I'd definitely set a public DNS previous to this, but I just had a wipe last month and reflash. It should have been set already.
I updated it now and got a msg about uci del dhcp.wan.ra_flags which I assume is the upstream ISP managed DNS.

don't expose ssh to the internet:

It's pubkey only auth with denyhosts, I'm fine with that.

Check your port forwards to make sure that you don't have duplicates (the stuff going to 192.168.1.226). I didn't look at them in detail, but you have a bunch of disabled ones and a bunch of enabled ones

it's a docker server, so it just hosts a variety of services that themselves are internet accessible. the host itself runs a fw as well as how docker does things.

How are you testing your laptop? Is that from inside or outside your network?

Just a combination of using my phone as a mobile hotspot, or an open wifi I can jump on near my home (I believe it blocks VPN protocol) and the spare wired fiber modem port ethernet (gives a seperate public ip).

If you were on a remote network, what was the subnet of that network?
The reason this may be critical is that if the local-to-you-at-that-moment network uses the same 192.168.1.0/24 network, the traffic that is destined for your own network won't go through the tunnel as you expect.

Yes, I recall our earlier threads about this maybe being the problem, and I've tried to keep it in mind when testing. What's the best way to check the subnet, just connect and then check the output of ip a and look at the netmask?

What tests did you run to attempt to reach your network, and what were the results? What is the host OS of the devices you are trying to reach remotely?

  1. Switch wifi or wired to test network
  2. check IP from a public ip checking webpage
  3. switch on vpn, confirm via same ip checking page IP has changed
  4. test some of the local lan machines for access

Let's see your laptop's WG config.

[Interface]
Address = 192.168.2.4/32
DNS = 192.168.1.1
ListenPort = 51820
PrivateKey = BLANK=

[Peer]
AllowedIPs = 0.0.0.0/0, 192.168.1.1/24
Endpoint = BLANK:51820
PersistentKeepalive = 15
PublicKey = BLANK=
6

I don't think so... AFAIK, that ra_flags line is related to IPv6 stuff, not DNS.

Ok... sounds good.

K... no worries. More than the server itself was just the idea of making sure your OpenWrt firewall is not bloated with duplicate entries (even if the dups are disabled).

All of these seem fine except for the open wifi that might block VPN... obviously that's not a good test.

Yes, but don't forget about the IP address itself.

Remove the listen port from the laptop's config.

I see a problem here...
first, in theory you should not need to specify anything more than 0.0.0.0/0, (which is the equivalent of all IPs), but I think Windows has a quirk that requires the additional specificity for RFC1918 addresses.

However, the problem for your local network is that you've specified only one host (the router itself), and not the entire subnet. Change it to:

192.168.1.0/24

(note the last octet is 0 instead of 1).

Beyond that, we need to see the output of wg show form your router, and ideally also the laptop (not sure if the same command is available on Windows or how you get the equivalent output).

7

The Masquerading of the LAN will let your LAN clients, you are trying to reach from your WG client see the routers address and not the address of the WG client (192.168.2.x).
Most LAN clients have their own firewall and will not allow connections from different subnets, so your LAN clients by default will only allow connections from their own 192.168.1.0/24 subnet and not from your WG clients which are on 192.168.2.0/24.

The proper solution is to tweak the firewall of your local LAN clients to also allow traffic from the WG subnet (192.168.2.0/24).

If that is impossible or not practical you can enable the Masquerading on the LAN, I am not a big fan of it as you loose access control and logging but in a typical soho setup were you trust your WG clients is is not a big deal.

1 Like
8

okay bit of a basic question then, but should I be setting which public DNS to use under:

LuCI -> Network -> Interfaces -> wan -> Advanced Setting -> Use custom DNS servers

OR

LuCI->Network->DHCP and DNS->DNS forwardings

I guess I really don't fully understand the difference and I'd like to.

Hah, that's even AFTER removing all the disabled entries.

okay what should I be looking for specifically?

okay done so.

9

That's a good thing right though?
Since I don't have anything on my network that resides on the 192.168.2.x network.

I feel like I perhaps set that up when I was doing the wireguard configuration tutorials but I should certainly double check.
Is that not the /etc/config/firewall settings like:

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

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

?

I do for the most part (trust my client devices) but I'd be interested in hearing how it affects ACL and logging specifically if you'd be willing to explain.

10

Generally, the wan DNS is considered most important, but you can of course use both. The DNS entry on an interface is the DNS that should be used for traffic that will exit via that interface (this is really only useful for upstream facing interfaces). The dnsmasq system resolver, when specified, will be used for all system level queries -- internally as well as for the DNS services that the router provides to your downstream networks. I don't actually have a better explanation for how the DNS on the wan differs from the dnsmasq entry, but it is generally recommended to ensure that the wan always has one.

When you look at your IP address information, you'll likely see an RFC1918 address (192.168.x.y. or 17.16.x.y - 17.31.x.y, or 10.x.y.z), as well as a subnet mask (eg. 255.255.255.0) or subnet size (eg /24). Both the IP and the subnet size/mask are important to know in this case.

11

hey @psherman some really strange behaviour has just arisen and I'm a bit desperate now. For some strange reason my mail server (docker-mailserver) has become completely uncontactable by all client devices in the last 24 hours. Been struggling to figure out why since the only things I've changed have been the things we've discussed above.

Could any of these recent changes above have resulted in my mail domain becoming unresolvable / routable for my mailserver?

12

The changes we discussed should not have affected your mail server, but it's possible that your cleanup of the firewall rules ended up affecting something. Review your firewall file for missing or malformed rules.

13

it was merely a cleanup of the firewall rules that I copied and pasted here. I didn't delete anything from the router config.

14

Is the mail server not being resolved to the correct IP address, or is the server not reachable despite proper IP/DNS resolution?

15

the latter. At first I could not connect to the mailserver from clients on the Lan (but external worked) now I cannot connect at all and clients claim connection refused. The logs on the server itself show mail is being sent and received fine however. super strange.

16

what changes did you make, specifically?

17

I've only ever made the changes that have appeared in this thread so far.

I'm currently comparing the files discussed in this thread with an openwrt backup file from Aug to see if I can find any discrepencies.

18

Can you please tell us the details of what you changed. For example, sometimes people will not implement all of the suggestions. Other times, people may change (intentionally or accidentally) some of the suggestions as they go to implement them. And since there were a bunch of posts talking about potential changes to the config, it's important to have a summary of the current state... or... post the complete set of configs as they stand now.

19

Not really I was talking about the firewall of your individual LAN clients e.g. your PC/NAS/Server on your LAN, they have their own firewall which by default only allows traffic from their own subnet and thus not from e.g. your WG clients which have the WG subnet (192.168.2.0/24).
By NATing everything going out via the LAN your WG clients will have the routers address so you will never now from whom the traffic is coming so you cannot log or use access control, as said in a typical soho environment where you are the only one using WireGuard it is not a big deal.
But if you give other users access via WG e.g. family members/friends you might want to restrict access to some parts of your network which is impossible if you NAT all traffic.

If you decide to go the NAT route, you can consider only NATting the WG traffic and not all traffic:
/etc/config/firewall:

config nat
	option name 'SNAT-WGserver'
	option src 'lan'
	option src_ip '192.168.2.0/24'
	option target 'MASQUERADE'
	list proto 'all'
	option enabled '1'
20

/etc/config/firewall

	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option masq '1'  <----- added this
	option forward 'ACCEPT' 
	list network 'lan'

config zone
	option name 'wg'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'   <--- changed this to accept from reject
	option family 'ipv4'
	list network 'wg0'
	option masq '1'           <------added this

/etc/config/network

config interface 'wg0'
	option proto 'wireguard'
	option listen_port '51820'
	list addresses '192.168.2.1/24'
	option private_key 'BLANK='
	option peerdns '0'
#	list dns '192.168.1.1' <----removed this

config forwarding                <------removed this entire stanza
	option src 'wan'
	option dest 'wg'

I reverted back to peerhosts = 0 and and DNS forwarders just under forwarders