nice... makes sense... and better than my cidr suggestion...
(i.e. traffic being forwarded carrying routing marks is ok, assuming that the marking happens earlier in the chains)
(the rules will likely be more efficient and cause less collateral damage if issues of you specify the source zone also)
is it possible to use ipv6 on the wan interface but not on the VPN interface?
So my wan network and clients can use ipv6 and my VPN clients are limited to ipv4 (because my VPN provider only uses ipv4)
If I set
type option ipv6_enabled '0'
Then there is off course no ipv6 on both wan and VPN and when I set it to '1' both have ipv6.
Or is there no leak at all because my vpn provider doesn't use ipv6?
define "use ipv6".
My VPN provider recommends not to use ipv6, so there is no (dns)leak when using th VPN.
Al my 'normal' users do not use the VPN so they can use ipv6. But when a client is using the VPN it must be over ipv4.
Maybe this is already the default, because my VPN provider doesn't support ipv6 over the VPN connection.
The way you described it, use of IPv6 will break the defined policies.
Originally posted here.
TL;DR: I would like this configuration with Wireguard client and server interfaces instead of OpenVPN.
Long Version:
Desired Behavior: WG client device (phone, laptop, tablet, etc.) > WG0 server interface > LAN > WG1 client interface > Commercial VPN provider > Internet
In the desired setup, the WG client device has access to all LAN devices AND internet traffic is also tunneled to Commercial VPN provider.
What currently works: WG client device > WG0 server interface > LAN > WAN (ISP modem) > Internet
In this instance, the clients can connect to WG0 and have full access to LAN devices and internet (over non-VPN ISP WAN). This configuration only works if WG1 client interface is stopped. Once WG1 client interface is started, this tunnel brakes.
What also works: LAN > WG1 client interface > Commercial VPN provider > Internet
In this instance, all devices on the LAN have their internet traffic tunneled to the Commercial VPN provider. This configuration works regardless of whether WG0 server interface is running or stopped.
Here is the desired config:
Configs:
/etc/config/network
config interface 'loopback'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
option device 'lo'
config interface 'lan'
option proto 'static'
option netmask '255.255.255.0'
option ipaddr '10.10.10.1'
option device 'eth0'
option ipv6 '0'
option delegate '0'
config interface 'wan'
option proto 'dhcp'
option device 'eth1'
option ipv6 '0'
option delegate '0'
option peerdns '0'
list dns '9.9.9.9'
config device
option name 'eth1'
config device
option name 'eth0'
config interface 'WireGuardClient1'
option proto 'wireguard'
option private_key 'PRIVATE-KEY'
list addresses '10.5.0.2'
option delegate '0'
option peerdns '0'
list dns '1.1.1.1'
option auto '0'
config wireguard_WireGuardClient1
option public_key 'PUBLIC-KEY'
option persistent_keepalive '25'
option route_allowed_ips '1'
option endpoint_host 'X.X.X.X' #commercial VPN provider endpoint
option endpoint_port '51820'
list allowed_ips '0.0.0.0/0'
list allowed_ips '::0'
config interface 'WireGuardServer0'
option proto 'wireguard'
option private_key 'PRIVATE-KEY'
option listen_port '51820'
list addresses '10.14.0.1/24'
config wireguard_WireGuardServer0
option description 'MyDevice'
option public_key 'PUBLIC-KEY'
list allowed_ips '10.14.0.3/32'
option route_allowed_ips '1'
option persistent_keepalive '25'
/etc/config/firewall
config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
config zone 'lan'
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'
list network 'LAN'
list network 'WireGuardServer0'
config zone 'wan'
option name 'wan'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
option input 'REJECT'
list network 'wan'
list network 'WAN'
list network 'WireGuardClient1'
config forwarding 'lan_wan'
option src 'lan'
option dest 'wan'
config redirect
option target 'DNAT'
option name 'Wireguard Server'
list proto 'udp'
option src 'wan'
option src_dport '51820'
option dest 'lan'
option dest_ip '10.10.10.1'
option dest_port '51820'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
/etc/config/vpn-policy-routing
config vpn-policy-routing 'config'
option verbosity '2'
option strict_enforcement '1'
option src_ipset '0'
option dest_ipset '0'
option resolver_ipset 'dnsmasq.ipset'
option ipv6_enabled '0'
option boot_timeout '30'
option iptables_rule_option 'append'
option procd_reload_delay '1'
option webui_enable_column '0'
option webui_protocol_column '0'
option webui_chain_column '0'
option webui_show_ignore_target '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 enabled '1'
list ignored_interface 'WireGuardServer0'
config policy
option name 'WireGuardServer'
option proto 'udp'
option chain 'OUTPUT'
option interface 'wan'
option dest_port '51820'
Support output (with public IP redacted)
root@OpenWrt:~# /etc/init.d/vpn-policy-routing support
vpn-policy-routing 0.3.4-8 running on OpenWrt 21.02.1.
============================================================
Dnsmasq version 2.85 Copyright (c) 2000-2021 Simon Kelley
Compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-cryptohash no-DNSSEC no-ID loop-detect inotify dumpfile
============================================================
Routes/IP Rules
default * 0.0.0.0 U 0 0 0 WireGuardClient1
IPv4 Table 201: default via X.X.X.X dev eth1
10.10.10.0/24 dev eth0 proto kernel scope link src 10.10.10.1
10.14.0.0/24 dev WireGuardServer0 proto kernel scope link src 10.14.0.1
10.14.0.3 dev WireGuardServer0 proto static scope link
IPv4 Table 201 Rules:
32760: from all fwmark 0x10000/0xff0000 lookup wan
IPv4 Table 202: default via 10.5.0.2 dev WireGuardClient1
10.10.10.0/24 dev eth0 proto kernel scope link src 10.10.10.1
10.14.0.0/24 dev WireGuardServer1 proto kernel scope link src 10.14.0.1
10.14.0.3 dev WireGuardServer1 proto static scope link
IPv4 Table 202 Rules:
32759: from all fwmark 0x20000/0xff0000 lookup WireGuardClient1
IPv4 Table 203: 10.10.10.0/24 dev eth0 proto kernel scope link src 10.10.10.1
IPv4 Table 203 Rules:
32763: from all fwmark 0x30000/0xff0000 lookup WireGuardServer0
============================================================
Mangle IP Table: PREROUTING
-N VPR_PREROUTING
============================================================
Mangle IP Table: FORWARD
-N VPR_FORWARD
-A VPR_FORWARD -p udp -m multiport --sports 51820 -m comment --comment WireGuardServer0 -c 0 0 -g VPR_MARK0x010000
============================================================
Mangle IP Table MARK Chain: VPR_MARK0x010000
-N VPR_MARK0x010000
-A VPR_MARK0x010000 -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_MARK0x010000 -c 0 0 -j RETURN
============================================================
Mangle IP Table MARK Chain: VPR_MARK0x020000
-N VPR_MARK0x020000
-A VPR_MARK0x020000 -c 0 0 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_MARK0x020000 -c 0 0 -j RETURN
============================================================
Mangle IP Table MARK Chain: VPR_MARK0x030000
-N VPR_MARK0x030000
-A VPR_MARK0x030000 -c 0 0 -j MARK --set-xmark 0x30000/0xff0000
-A VPR_MARK0x030000 -c 0 0 -j RETURN
============================================================
Current ipsets
============================================================
Your support details have been logged to '/var/vpn-policy-routing-support'.
Edit: Consolidated all configs into single post. Also @stangri, I have VPN-Bypass running on OpenWRT to create a split tunnel for two clients on an ancient WNDR3400 being used as a wired switch. Uptime is >3 years. Amazing package!
There is asymmetric routing. Remove route_allowed_ips from wg client and create policy in pbr to route everything towards the wg client.
I've been meaning to update the README -- if the WG (client) is set as a default gateway, the single policy to allow option src_port '61820' is not going to work as intended (as @Smim0 has documented earlier) because the WG server will be replying from a different port. You can try a range of ports to see if it helps.
Thanks for the reply. I did not realize the random UDP port reply was a limitation of the WG protocol.
Do you think the README example is still valid if an OpenVPN server interface is used with the WG Client interface (i.e. hybrid approach with OpenVPN server and WG Client)? Making the WAN the default gateway as you suggest above is not practical for the other applications and services I have running.
the limitation is due to the UDP protocol and not necessarily WG, if you use Openvpn server in udp mode you will have the same exact issue.
But yes, the hibrid approach with Openvpn server and WGclient would work even with making the WGclient as a default gateway IF and only if the Openvpn server is running with TCP protocol.
Got this working but had to ultimately make the WAN the default gateway and set up a ton of rules to direct network traffic to the WireGuard Client.
Can you please share the rules to make the rules to direct the network traffic to the wgclient?
Thanks
Is anyone using VPR on snapshots?
I need help testing VPR/PBR on snapshots which include firewall4 as per https://github.com/openwrt/packages/issues/16818#issuecomment-1007269510
Thanks!
I'll bite. I've got a spare box to play with.
Not long on how to, but I'll assume I need to remove conflicting firewall and luci-app-firewall, add firewall4, and hope for the best with existing config?
Well, so far this has seemed a pretty transparent roll-over. (20 minutes in).
Build-01-08-22-GCC11-FW4-r18523+6-8c501bf9fe-Kernel-5.10.90
make nconfig, select firewall4 save, build. luci-app-firewall appears as with FW3. I'll let it bake overnight and see what transpires.
Thanks! As far as I understand, besides switching from fw3 to fw4 you also need to install iptables-nft instead of iptables.
Select:
Network / Firewall / Enable Nftables support
to enable iptables-nft
Can't find any way of deselecting iptables.
Selected by [y]
- PACKAGE_vpn-policy-routing [=y]
- PACKAGE_ip6tables [=y] && IPV6 [=y] │
- PACKAGE_collectd-mod-iptables [=y] && PACKAGE_collectd [=y]
Running a new build overnight with Nftables support/iptables-nft
next time, i'd happy to build something for you if you have a diffconfig if needed (20min turnaround if i'm awake 
)
These are the nconfig steps I took to run my latest build:
Select Network / Firewall / Enable Nftables support
to enable/select iptables-nft
Checked the Firewall4 Makefile and made sure all Firewall4 DEPENDS were included.
PACKAGE_kmod-nft-core [=y]
PACKAGE_kmod-nft-fib [=y]
PACKAGE_kmod-nft-nat [=y]
PACKAGE_kmod-nft-nat6 [=y]
PACKAGE_kmod-nft-offload [=y]
PACKAGE_nftables-json [=y]
PACKAGE_ucode [=y]
PACKAGE_ucode-mod-fs [=y]
PACKAGE_ucode-mod-ubus [=y]
PACKAGE_ucode-mod-uci [=y]
Let me know if you see anything else that should be included.
Thank you very kindly for that gesture. I'll put a diffconfig on my my google drive for you in that eventuality. IIRC though, we are probably both equidistant and polar opposites 
2 days up and nary a problem of any kind. Policies all working as intended, nothing out of the ordinary anywhere with the switch over from FW3 to FW4. YMMV, but I'm satisfied with performance.