Alright, I'm having a bit of difficulty in terms of parsing what you're getting at. The WG Server is meant to provide me access to LAN, but also serve for DNS (connected to router 192.168.1.1 port 53). So I guess it might go WG Server-LAN-Mullvad? Moreover, I'm unfamiliar with zone forwarding - is that just a difference in terminology? How does that pertain to the port on the Wireguard client endpoint? Thanks again.
Your source network zone is X, you want to send traffic to Y. Those are zones. You would normally allow traffic to flow from one to another.
Alternatively, you can only allow traffic to 192.168.1.1:53/udp. Your choice; but it appears you want to allow all traffic to move.
1 Like
OK, so I needn't worry about port-forwarding in any capacity so long as the interfaces are configured appropriately then? Disregarding DNS access, if I only wanted to connect to the LAN I should just connect this new WG Server interface to the LAN and otherwise configure it as I would on any other instance of Linux and not have to worry about forwarding a port? So in my client the endpoint would just be DDNSDOMAIN or WANIP without a port?
You usually do port forwarding when you want to access a service behind NAT. In the case of WG Server and LAN is not needed since you shouldn't be NATing traffic there.
Each zone has a policy for INPUT, OUTPUT and FORWARD. Input is for traffic incoming to the router, Output for traffic originating from the router, and Forward for traffic traversing from one interface to another in the same zone.
So if you assign the WG server interface in the LAN zone, you don't need to do much more, as LAN zone ACCEPTs all above mentioned traffic.
2 Likes
OK, so that all should work, and does when not connected to VPN (after having enabled the LAN-WAN connection in firewall again).The problem seems to lie in Wireguard's default routing method, it just seems to suppress everything else. I'm certain that's also why the VPN-Policy-Routing service refuses to start when Wireguard is enabled. Is there any way to resolve this? Thanks.
Post here the configuration to check what can be wrong:
uci export network; uci export firewall; uci export vpn-policy-routing
1 Like
Alright, update on this, managed to get VPN-Policy-Routing working by following the tutorial in the readme here. While it's nice to be able to do that, still hasn't quite yielded what I want. That having been said, there do seem to be packets traveling between the client and the wireguard server itself. I'm unsure as to what's blocking the free flow, though.
Network:
package network
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd2f:2f58:8537::/48'
config interface 'lan'
option type 'bridge'
option ifname 'eth0'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option delegate '0'
config interface 'wan'
option ifname 'eth1'
option proto 'pppoe'
option password 'x'
option ipv6 '0'
option delegate '0'
option force_link '1'
option username 'x'
config interface 'wgclient'
option proto 'wireguard'
option private_key 'x'
list addresses '10.65.58.106'
option delegate '0'
option force_link '1'
option listen_port '51820'
option mtu '1432'
config wireguard_wgclient
option public_key 'x'
option persistent_keepalive '25'
option endpoint_port '51820'
list allowed_ips '0.0.0.0/0'
option route_allowed_ips '1'
option endpoint_host 'x'
config wireguard_wgserver
option persistent_keepalive '25'
option route_allowed_ips '1'
list allowed_ips '10.200.200.2/32'
option public_key 'x'
config interface 'wgserver'
option proto 'wireguard'
option delegate '0'
option force_link '1'
option listen_port '61820'
list addresses '10.200.200.1/24'
option private_key 'x'
Firewall:
package firewall
config defaults
option syn_flood '1'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option flow_offloading '1'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option network 'lan'
config zone
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
option network 'wan wan6'
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 include
option path '/etc/firewall.user'
config zone
option network 'wgclient'
option name 'wgclient'
option masq '1'
option mtu_fix '1'
option input 'REJECT'
option forward 'ACCEPT'
option output 'ACCEPT'
config forwarding
option dest 'wgclient'
option src 'lan'
config forwarding
option dest 'lan'
option src 'wgserver'
config forwarding
option dest 'wan'
option src 'wgserver'
config forwarding
option dest 'wgclient'
option src 'wgserver'
config rule
option dest_port '61820'
option src '*'
option name 'Allow-WG-Inbound'
option target 'ACCEPT'
list proto 'tcp'
list proto 'udp'
config redirect
option dest_port '51825'
option src 'wan'
option name 'DietPi Server'
option src_dport '51825'
option target 'DNAT'
option dest 'lan'
option dest_ip '192.168.1.254'
config redirect
option dest_port '30659'
option src 'wgclient'
option name 'Torrent'
option src_dport '30659'
option target 'DNAT'
option dest_ip '192.168.1.223'
option dest 'lan'
config zone
option network 'wgserver'
option input 'ACCEPT'
option forward 'REJECT'
option name 'wgserver'
option output 'ACCEPT'
option masq '1'
VPN-Policy-Routing:
package vpn-policy-routing
config vpn-policy-routing 'config'
option verbosity '2'
option strict_enforcement '1'
option src_ipset '0'
option ipv6_enabled '0'
list supported_interface ''
option boot_timeout '30'
option iptables_rule_option 'append'
option iprule_enabled '0'
option webui_sorting '1'
list webui_supported_protocol 'tcp'
list webui_supported_protocol 'udp'
list webui_supported_protocol 'tcp udp'
list webui_supported_protocol 'icmp'
list webui_supported_protocol 'all'
option dest_ipset 'ipset'
option webui_enable_column '1'
option webui_protocol_column '1'
option webui_chain_column '1'
list ignored_interface 'wgserver'
option enabled '1'
config include
option path '/etc/vpn-policy-routing.netflix.user'
option enabled '0'
config include
option path '/etc/vpn-policy-routing.aws.user'
option enabled '0'
config policy
option interface 'wan'
option name 'Wireguard Server'
option src_port '61820'
option chain 'OUTPUT'
option proto 'tcp udp'
Honestly, if possible, I'd be tempted to just find a way to route an entire Virtual-Machine client to WAN and then use that client exclusively for a Wireguard server. I mean, as a secondary solution to running directly on the router. Definitely made progress, though. Thanks for your help.
Please edit your post and paste the output in preformatted text blocks (the </> button) here. Thanks!
2 Likes
You'll need to be a bit more specific as to what is not working.
From your config I don't see the reason for masquerade in wgserver zone. Actually the whole wgserver zone is kinda unnecessary, you could add the wgserver interface under lan zone.
One thing that might be wrong is having 2 default gateways (you can verify that with ip -4 ro)
1 Like
The Wireguard Server, in its entirety doesn't work while behind the VPN. The interface shows that the server is sending and receiving packets, the client only appears to be able to send packets. Either way, there doesn't seem to be a legitimate connection. I bound the WGserver interface to the LAN, but that yields the same outcome. I can't tell whether I've more than one default route through that command, but according to VPN-Routing-Policy the WGClient is the default route. VPN Policy Routing does work now, though. I'm able to route IPs through the WAN, rather than their default route of going through the wgclient.
Edit: Actually it doesn't even send those few packets if I bind the wgserver to the LAN interface - Rx and Tx stay at zero.
I can if you paste it here. 
default dev wgclient proto static scope link
10.200.200.0/24 dev wgserver proto kernel scope link src 10.200.200.1
10.200.200.2 dev wgserver proto static scope link
150.101.32.170 dev pppoe-wan proto kernel scope link src 124.171.109.177
192.168.1.0/24 dev br-lan proto kernel scope link src 192.168.1.1
217.138.204.146 via 150.101.32.170 dev pppoe-wan proto static
There isn't a secondary default gateway in the main routing table.
Check if the other tables have something.
ip -4 ru ; ip -4 ro list table all
1 Like
0: from all lookup local
32764: from all fwmark 0x20000 lookup 202
32765: from all fwmark 0x10000 lookup 201
32766: from all lookup main
32767: from all lookup default
default via 150.101.32.170 dev pppoe-wan table 201
10.200.200.0/24 dev wgserver table 201 proto kernel scope link src 10.200.200.1
10.200.200.2 dev wgserver table 201 proto static scope link
default via 10.65.58.106 dev wgclient table 202
10.200.200.0/24 dev wgserver table 202 proto kernel scope link src 10.200.200.1
10.200.200.2 dev wgserver table 202 proto static scope link
default dev wgclient proto static scope link
10.200.200.0/24 dev wgserver proto kernel scope link src 10.200.200.1
10.200.200.2 dev wgserver proto static scope link
150.101.32.170 dev pppoe-wan proto kernel scope link src 124.171.109.177
192.168.1.0/24 dev br-lan proto kernel scope link src 192.168.1.1
217.138.204.146 via 150.101.32.170 dev pppoe-wan proto static
local 10.65.58.106 dev wgclient table local proto kernel scope host src 10.65.58 .106
broadcast 10.200.200.0 dev wgserver table local proto kernel scope link src 10.2 00.200.1
local 10.200.200.1 dev wgserver table local proto kernel scope host src 10.200.2 00.1
broadcast 10.200.200.255 dev wgserver table local proto kernel scope link src 10 .200.200.1
local 124.171.109.177 dev pppoe-wan table local proto kernel scope host src 124. 171.109.177
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0 .1
broadcast 192.168.1.0 dev br-lan table local proto kernel scope link src 192.168 .1.1
local 192.168.1.1 dev br-lan table local proto kernel scope host src 192.168.1.1
broadcast 192.168.1.255 dev br-lan table local proto kernel scope link src 192.1 68.1.1
Alright, now do a iptables-save -c to verify the classification.
1 Like
I mean, they were all adequately committed as they survived through multiple reboots. Regardless, I appreciate your time and energy expenditure on this but I managed to get VPN-Routing-Policy to force an entire VM client to direct to WAN, then did the standard fare of port-forwarding and it works. Obviously not ideal as configuring on-router, but it's better than nothing. Thanks again for your help.
I believe there is some issue with PBR when the traffic originates from the router itself. I can recall a couple of more topics with the same problem. But if you managed it with off router WG server and it works fine for you, I am happy.
Feel free to mark the topic as solved.
Appreciate you keeping an eye on this, mate. Unfortunately, even with rp_filter=2 to allow VPN Policy Routing to successfully route Wireguard networking (I did a test run with them set to 0 as default, and despite VPR reporting 'success' it wouldn't work properly, whereas it worked with it set to 2). Moreover, that's why in the VPR readme.md doc guide it specifies setting an 'output' policy on port 61820 (as configured wgserver listen port) to push it through wan. That having been said I might try my hand at this again with a more hands-on approach to IP-tabling - see if adjusting output interface/destination or perhaps between forwarding/output/postrouting may yet yield a better outcome.
1 Like
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.