[Solved] Wireguard zone/firewall: I dont understand

I am currently on OpenVPN because I have it working. I configured it with firewall rules that denies any connection from LAN to WAN. Only traffic via VPN is allowed.

I setup Wireguard using this: (which works)

Then tried to configure Wireguard the same way as I have OpenVPN, with a separate "vpnfirewall" zone and its not working any more.

I need assistance :blush: because my potato brain can't handle it.

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
1 Like

/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 'fd27:da56:551d::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth1.1'

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

config interface 'wan'
	option device 'eth0.2'
	option proto 'dhcp'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '2 3 4 5 0t'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '1 6t'

config interface 'wg0'
	option proto 'wireguard'
	option private_key ''
	list addresses '10.xx.xx.xx/32'

config wireguard_wg0
	option public_key ''
	option route_allowed_ips '1'
	list allowed_ips '0.0.0.0/0'
	option persistent_keepalive '25'
	option description 'WG'
	option endpoint_host 'xx.xx.xx.xx'
	option endpoint_port '51820'

/etc/config/firewall

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

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	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 rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config zone
	option name 'vpnfirewall'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	list network 'wg0'
	option mtu_fix '1'

config forwarding
	option src 'lan'
	option dest 'vpnfirewall'

config rule
	option name 'Deny-LAN-toWAN'
	list proto 'all'
	option src 'lan'
	option dest 'wan'
	option target 'REJECT'

Everything looks fine from what I can tell. I suspect your WireGuard connection is not actually working.
Let's see the output of wg show

Meanwhile, although not related to your issue, the following is unnecessary:

This isn't needed because you do not allow wan > lan forwarding (you've removed the config forwarding stanza). You can safely remove it.

@bigsmile ... just ignore @ulmwind's comment. It is not clear why they have such an aversion to WireGuard (there has never been a good justification from this user as to why WireGuard is problematic, therefore we can consider it noise and trolling). The vast majority of users on this forum who have moved to WireGuard have been happy with the results.

1 Like

Check that the wg tunnel is working by using just the command wg and confirm that the send and receive counts are not zero and there has been a recent handshake. Try to ping the server's tunnel IP if you know it. This appears to be a point to point configuration though so there may not be any IPs on the tunnel.

Check the routing table to confirm that proper routes have been set up. There should be a split route of the whole Internet via wg0 (0.0.0.0/1 and 128.0.0.0/1) and single /32 route to the peer via the regular WAN. Encrypted packets have to be sent by regular WAN instead of placed in the tunnel.

The routing table determines where the kernel tries to send a packet, and the firewall rules determine if it will be allowed to be sent. So you need to consider both.

1 Like

I removed the obsolete rule, still nothing. (no surprise there)
Then reset all cables and decided to reboot the router and the client behind it.

When they were up it seems to be working :smiley:

interface: wg0
  public key: <key>
  private key: (hidden)
  listening port: <port>

peer: <peer>
  endpoint: x.x.x.x:51820
  allowed ips: 0.0.0.0/0
  latest handshake: 30 seconds ago
  transfer: 51.94 MiB received, 2.49 MiB sent
  persistent keepalive: every 25 seconds

However I still have to figure out where the traffic goes

Active IPv4 Routes

wg0	0.0.0.0/0		-				0	main
wan	<endpoint ip>	<gateway_ip>	0	main
lan	192.168.1.0/24	-				0	main
wan	<ip_range/32>	-				0	main

Both the wan and wg0 counters go up when running a speedtest.
DNSleaktest.com saw only 1 DNS server from the VPN which is good.

I think its working :smiley:

Thanks everyone

Glad it appears to be working now!

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.

3 Likes

OK, and what about killswitch, does it work?

I can repeat, no problem. OpenVPN is very nice solution with predictable behavior. It can be easily configured to run OpenVPN-client, and OpenVPN-server on the same device. In case of WireGuard it is very difficult task due to limitation of UDP-protocol.

Then why even comment here?

Sure. But it is much harder to configure and it is significantly less performant than Wireguard when running on the same hardware. There are many reasons that a user might want to run a given VPN protocol -- if you prefer OpenVPN, fine... but your comments don't add any value when the user wants to run something else.

Sure, but there are other VPN protocols that can do the same (I'm pretty sure it is possible to do this with Wireguard, too). But this is irrelevant here and in most of the threads in which you have commented where the user is only trying to run in a server or a client context, not both. In this one, the OP was clearly running in a client mode,

OpenVPN can be run on TCP or UDP. But it is actually recommended to be run on UDP because of the "TCP meltdown" scenario. So, while there is an option for TCP, making blanket statements about why OpenVPN is better based on a "limitation of UDP-protocol" is non-sensical.

If I'm being honest here (and I do say this with good intentions), many of the users here simply find your comments on the topic to be useless at best, annoying/trolling at worst. There is no reason or value for you to comment on WG based threads if all you're going to do is tell people to use another protocol. Instead, since you seem to be a fan of OpenVPN, you can a more positive impact here by helping OpenWrt + OpenVPN users debug their OpenVPN related issues -- these do happen with enough regularity to benefit from additional OpenVPN fans/experts.

2 Likes

Yes, sure. But in this tread OP has announced, that he has configured OpenVPN successfully.

The OP clearly wanted to use Wireguard. Yes, it was working on OpenVPN, but they wanted to move to (or add as an option) WG. So there's no value in telling them not to use Wireguard.

That said, if you want to continue this conversation, please send me a personal message... I fear that we are cluttering this thread.

2 Likes

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