whats the difference between the dns server setting on wireguard page vs using forced dns redirection for wireguard interface on the networking page im currently using?
That is a very good question.
The Optional DNS target uses iptables rules to redirect queries on port 53.
I assumed that it would not work as the interface is not unbridged.
Your question led me to actually try it :)
I set an optional DNS target to 11.0.0.0 (non existent so it should stop DNS) and nothing happened and the rules are not hit either:
When the DNS server (or servers you can set more than one) are set in the WG GUI those are placed in resolv.dnsmasq to use by DNSMasq but only after the connection is made and the route is setup so that when a DNS server is not publicly available you will not get in a dead lock situation where DNSMasq tries to resolve the time server and endpoint URL but cannot.
Furthermore a static route is made so that the DNS server is always routed via the tunnel.
I loaded egc's test build 44980 on a spare r7800 and testing the new DNS severs via tunnel. As a test I used Quad9 servers 9.9.9.9, 149.112.112.9 and looked for changes. If you telnet/ssh and use command "ip route" (without quotes) you will see these new lines added....
9.9.9.9 dev oet1 scope link
149.112.112.9 dev oet1 scope link
In the telnet/ssh session I ran "traceroute 9.9.9.9" and it's was going through the VPN Provider.
EDIT UPDATE the spare r7800 is using the default DHCP also needed to update the Policy Based Routing with 192.168.1.128/25 so all DHCP clients go through the VPN tunnel.
Now if you use your write up on IPSET Route-Up Script the DNS will more likely go through your ISP.
In this example I used 9.9.9.9,149.112.112.9 in the DNS servers via tunnel and added these firewall commands ( I used mark 64 because of your IPSET Route-up write up)...
iptables -t mangle POSTROUTING -d 9.9.9.9 -j MARK --set-mark 64
iptables -t mangle POSTROUTING -d 149.112.112.9 -j MARK --set-mark 64
Test with command "traceroute 9.9.9.9". In my test the DNS servers went to the VPN tunnel. Try it out. _________________ Home Network on Telus 1Gb PureFibre - 10GbE Copper Backbone
2x R7800 - Gateway & WiFi & 3xWireGuard - DDWRT r53562 Std k4.9
Off Site 1
R7000 - Gateway & WiFi & WireGuard - DDWRT r54517 Std
E3000 - Station Bridge - DDWRT r49626 Mega K4.4
Off Site 2
R7000 - Gateway & WiFi - DDWRT r54517 Std
E2000 - Wired ISP IPTV PVR Blocker - DDWRT r35531
Hi egc,
I would like to try WG, but im unaware, how its going to work with DoT...im using...last time i tried WG i messed up with PIA settings and was not working.
Ill give it a go again...
Any tips...?? Will it work with stubb resolver...??? or any resolver that works on loopback interface...
I guess, it must not be an issue...???
So, far the advantage of Open VPN prior WG is only in terms of options and configuration, but speed could be a major 'plus' for WG, that outcomes the cons of it...
My 2x r7800s at home are still on build 44483 only because I have over 75days uptime. By experimenting with a spare r7800 and egc's test build 44980 I was able to get Quad9 DNSCrypt v2 to use the VPN Tunnel. Looking at the DNSCrypt Server List online the Quad9 Filtered DNSCrypt & DoH both use ip addresses 9.9.9.9 & 149.112.112.9 and I used these addresses to run through the tunnel. Trace routing the addresses will show you the path it's taking ISP or VPN, in my case it's the VPN path.
In your case you will have to find what ip addresses does your stubb resolver use. _________________ Home Network on Telus 1Gb PureFibre - 10GbE Copper Backbone
2x R7800 - Gateway & WiFi & 3xWireGuard - DDWRT r53562 Std k4.9
Off Site 1
R7000 - Gateway & WiFi & WireGuard - DDWRT r54517 Std
E3000 - Station Bridge - DDWRT r49626 Mega K4.4
Off Site 2
R7000 - Gateway & WiFi - DDWRT r54517 Std
E2000 - Wired ISP IPTV PVR Blocker - DDWRT r35531
I'm running a Site-Site WG between a R7800 and a RT-AC66U. Couldn't find the file for the latter.
I have made IPv6 work through manual configuration.
1) The oet interface does not have a Link Local Address (FE80::). Probably because it does not have a MAC either.
2) DHCP6C does not assign a PD when one interface that is given a SLA ID is not up when run.
Per Yngve, thanks for testing, BS decided to go forward and have the build publicly available already (a bit to soon for my liking as I wanted more time to test)
I do not have IPv6 (and only have basic knowledge about it) so could not test/try anything.
Can you give some instruction how to setup IPv6 for other users?
Perhaps you can use the route-up script to setup IPv6 routes ?
The route-up script kicks in after the connection is made.
<See my updated post below about HE IPv6 with PBR.> _________________ Home Network on Telus 1Gb PureFibre - 10GbE Copper Backbone
2x R7800 - Gateway & WiFi & 3xWireGuard - DDWRT r53562 Std k4.9
Off Site 1
R7000 - Gateway & WiFi & WireGuard - DDWRT r54517 Std
E3000 - Station Bridge - DDWRT r49626 Mega K4.4
Off Site 2
R7000 - Gateway & WiFi - DDWRT r54517 Std
E2000 - Wired ISP IPTV PVR Blocker - DDWRT r35531
I followed your directions to get IPv6 to work through the WG tunnel, but my IPv6 breaks when I put the 3 HE addresses into the "Allowed Ips" tab. Once I remove them, IPv6 works again.
I updated the MTU in my HE Account to be -20 of my WG MTU, and I changed the MTU value also in the Setup>Ipv6.
I have condensed my posts on HE IPv6 & DNS tunnelling through WireGuard using PBR.
This is based on egc's build 44980 on my spare r7800. My write-up is generic and will work with DD-WRT v4.x kernels with different SoC's. Didn't test DD-WRT with 3.x kernels but it should work.
I looked into my WireGuard Provider and they currently do NOT support IPv6. I was able to tunnel both HE IPv6 and DNSMasq DNS Servers through the WireGuard tunnel.
Make sure your HE IPv6 is working with your WAN before continuing.
Update your HE IPv6 MTU to be 20 less than the oet1 tunnel MTU. Also make the MTU changes on your HE account under Advanced. Example if WireGuard MTU=1460 subtract 20 for HE IPv6 MTU=1440 in the IPv6 GUI.
With this setup in the Tunnel oet1 GUI
- Set DNS servers via tunnel to 9.9.9.9,149.112.112.9 (or whatever you like, this case QUAD9)
- Allowed IPs is disabled when PBR is in use
- Advanced settings Enabled -> Policy Based Routing 192.168.1.128/26
Policy Based Routing with 192.168.1.128/26 for an IP Range 192.168.1.128 to 191. On the Basic Setup I have DHCP Start IP as 192.168.1.128 with Max DHCP to 64. You can use any range you like it's an example I used. Client addresses outside the Policy Based Routing Range will have IPv4 going through the WAN but HE IPv6 service IPs in the Firewall and DNS Servers in the Tunnel oet1 GUI will still be going through WireGuard.
This firewall is setup route and HE IPv6 to WireGuard with PBR.
UPDATED Firewall to automatically add your your HE IPv4 Server used in your IPv6 GUI's "Tunnel Endpoint IPv4 Address" and egc reworked the Firewall Inbound the addition isn't needed...
# Firewall to Route HE 6in4 IPv6 to WireGuard (WG) oet1 tunnel while using PBR
# Routing DNS to WireGuard by editing WireGuard's "DNS servers via tunnel" GUI
# Tested on egc's build 44980
#
# WAN table route is main, (WG) oet1 table route is 21 when PBR is used
HE_Ping="66.220.2.74"
HE_UpdateURL="64.62.200.2"
HE_IPv4Server="$(nvram get ipv6_tun_end_ipv4)"
# Update Route Tables
# Route HE IPv6 to WireGuard
ip route add $HE_UpdateURL dev oet1
ip route add $HE_Ping dev oet1
ip route add $HE_IPv4Server dev oet1
ip route add $HE_UpdateURL dev oet1 table 21
ip route add $HE_Ping dev oet1 table 21
ip route add $HE_IPv4Server dev oet1 table 21
# Respond to HE Ping Requests
iptables -I INPUT 2 -p icmp -s $HE_Ping -j ACCEPT
# Put back on TOP is required (test if newer builds require it)
iptables -D INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Force HE IPv6 (Ping,Upadte,Server) to (WG) oet1 table route 21
iptables -t mangle -D POSTROUTING -d $HE_IPv4Server -j MARK --set-mark 21 > /dev/null 2>&1
iptables -t mangle -A POSTROUTING -d $HE_IPv4Server -j MARK --set-mark 21
iptables -t mangle -D POSTROUTING -d $HE_Ping -j MARK --set-mark 21 > /dev/null 2>&1
iptables -t mangle -A POSTROUTING -d $HE_Ping -j MARK --set-mark 21
iptables -t mangle -D POSTROUTING -d $HE_UpdateURL -j MARK --set-mark 21 > /dev/null 2>&1
iptables -t mangle -A POSTROUTING -d $HE_UpdateURL -j MARK --set-mark 21
You may ask how I found oet1 to be using route table 21 by telnet/ssh to router...
- run without quotes "ip route show table all" you will see in the list "table 21"
- now run without quotes "ip route show table 21" and you will see the default route at the top is oet1
- the main or default route table be seen without quotes "ip route" or "ip route show table main"
Once you finished setting up, reboot and your clients more likely will not have IPv6 access but your Client IPv6 looks correct more likely means you will have to Update your new Pubic Address from you WireGuard connection. To update your HE account with your new Public Address; in the router telnet/ssh session update your HE Account with your WireGuard's Public IP address using your HE Update URL under Advanced...
curl -s -k https://xxxxxxxxxx.tunnelbroker.net/nic/update?hostname=000000
The update is not instant you have to wait for some kind of reply. Your HE Client IPv4 Address in your HE account will reflect the change (different from your router's WAN IPv4 address).
If you have HE IPv6 working with Radvd you can ignore below.
You can use DNSMasq to handle IPv6 to your clients, you will need to go to the IPv6 GUI to disable Radvd and Apply to save. Client DNS IPv4/v6 are from QUAD9. I prefer to have NTP to used a DNS (in this case OpenDNS) that goes through the WAN to get the clock updated quickly and correctly for other services to start...
Joined: 18 Mar 2014 Posts: 12877 Location: Netherlands
Posted: Tue Dec 22, 2020 16:18 Post subject:
Nice work!
If you do not use PBR and a route is established before the the tunnel is up that might stop the NTP server to get the correct time and thus the tunnel will not start at all.
So without PBR you have to place all your routing rules in a script and call that from the route-up box.
Instead of using allowed IP of 0.0.0.0/0 use:
0.0.0.0/1,128.0.0.0/1
In this case it does not matter as the default routes (like 0.0.0.0/0 but also 0.0.0.0/1,128.0.0.0/1) are removed when PBR is activated.
If you do not use PBR and a route is established before the the tunnel is up that might stop the NTP server to get the correct time and thus the tunnel will not start at all.
So without PBR you have to place all your routing rules in a script and call that from the route-up box.
Instead of using allowed IP of 0.0.0.0/0 use:
0.0.0.0/1,128.0.0.0/1
In this case it does not matter as the default routes (like 0.0.0.0/0 but also 0.0.0.0/1,128.0.0.0/1) are removed when PBR is activated.
Thanks for testing :)
Okay, I understand now. I thank you for adding/supporting WireGuard to DD-WRT! _________________ Home Network on Telus 1Gb PureFibre - 10GbE Copper Backbone
2x R7800 - Gateway & WiFi & 3xWireGuard - DDWRT r53562 Std k4.9
Off Site 1
R7000 - Gateway & WiFi & WireGuard - DDWRT r54517 Std
E3000 - Station Bridge - DDWRT r49626 Mega K4.4
Off Site 2
R7000 - Gateway & WiFi - DDWRT r54517 Std
E2000 - Wired ISP IPTV PVR Blocker - DDWRT r35531
I have condensed my posts on HE IPv6 & DNS tunnelling through WireGuard using PBR.
This is based on egc's build 44980 on my spare r7800. My write-up is generic and will work with DD-WRT v4.x kernels with different SoC's. Didn't test DD-WRT with 3.x kernels but it should work.
I looked into my WireGuard Provider and they currently do NOT support IPv6. I was able to tunnel both HE IPv6 and DNSMasq DNS Servers through the WireGuard tunnel.
Make sure your HE IPv6 is working with your WAN before continuing.
Update your HE IPv6 MTU to be 20 less than the oet1 tunnel MTU. Also make the MTU changes on your HE account under Advanced. Example if WireGuard MTU=1460 subtract 20 for HE IPv6 MTU=1440 in the IPv6 GUI.
With this setup in the Tunnel oet1 GUI
- Set DNS servers via tunnel to 9.9.9.9,149.112.112.9 (or whatever you like, this case QUAD9)
- Allowed IPs is disabled when PBR is in use
- Advanced settings Enabled -> Policy Based Routing 192.168.1.128/26
Policy Based Routing with 192.168.1.128/26 for an IP Range 192.168.1.128 to 191. On the Basic Setup I have DHCP Start IP as 192.168.1.128 with Max DHCP to 64. You can use any range you like it's an example I used. Client addresses outside the Policy Based Routing Range will have IPv4 going through the WAN but HE IPv6 service IPs in the Firewall and DNS Servers in the Tunnel oet1 GUI will still be going through WireGuard.
This firewall is setup route and HE IPv6 to WireGuard with PBR.
UPDATED Firewall to automatically add your your HE IPv4 Server used in your IPv6 GUI's "Tunnel Endpoint IPv4 Address" and egc reworked the Firewall Inbound the addition isn't needed...
# Firewall to Route HE 6in4 IPv6 to WireGuard (WG) oet1 tunnel while using PBR
# Routing DNS to WireGuard by editing WireGuard's "DNS servers via tunnel" GUI
# Tested on egc's build 44980
#
# WAN table route is main, (WG) oet1 table route is 21 when PBR is used
HE_Ping="66.220.2.74"
HE_UpdateURL="64.62.200.2"
HE_IPv4Server="$(nvram get ipv6_tun_end_ipv4)"
# Update Route Tables
# Route HE IPv6 to WireGuard
ip route add $HE_UpdateURL dev oet1
ip route add $HE_Ping dev oet1
ip route add $HE_IPv4Server dev oet1
ip route add $HE_UpdateURL dev oet1 table 21
ip route add $HE_Ping dev oet1 table 21
ip route add $HE_IPv4Server dev oet1 table 21
# Respond to HE Ping Requests
iptables -I INPUT 2 -p icmp -s $HE_Ping -j ACCEPT
# Put back on TOP is required (test if newer builds require it)
iptables -D INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Force HE IPv6 (Ping,Upadte,Server) to (WG) oet1 table route 21
iptables -t mangle -D POSTROUTING -d $HE_IPv4Server -j MARK --set-mark 21 > /dev/null 2>&1
iptables -t mangle -A POSTROUTING -d $HE_IPv4Server -j MARK --set-mark 21
iptables -t mangle -D POSTROUTING -d $HE_Ping -j MARK --set-mark 21 > /dev/null 2>&1
iptables -t mangle -A POSTROUTING -d $HE_Ping -j MARK --set-mark 21
iptables -t mangle -D POSTROUTING -d $HE_UpdateURL -j MARK --set-mark 21 > /dev/null 2>&1
iptables -t mangle -A POSTROUTING -d $HE_UpdateURL -j MARK --set-mark 21
You may ask how I found oet1 to be using route table 21 by telnet/ssh to router...
- run without quotes "ip route show table all" you will see in the list "table 21"
- now run without quotes "ip route show table 21" and you will see the default route at the top is oet1
- the main or default route table be seen without quotes "ip route" or "ip route show table main"
Once you finished setting up, reboot and your clients more likely will not have IPv6 access but your Client IPv6 looks correct more likely means you will have to Update your new Pubic Address from you WireGuard connection. To update your HE account with your new Public Address; in the router telnet/ssh session update your HE Account with your WireGuard's Public IP address using your HE Update URL under Advanced...
curl -s -k https://xxxxxxxxxx.tunnelbroker.net/nic/update?hostname=000000
The update is not instant you have to wait for some kind of reply. Your HE Client IPv4 Address in your HE account will reflect the change (different from your router's WAN IPv4 address).
If you have HE IPv6 working with Radvd you can ignore below.
You can use DNSMasq to handle IPv6 to your clients, you will need to go to the IPv6 GUI to disable Radvd and Apply to save. Client DNS IPv4/v6 are from QUAD9. I prefer to have NTP to used a DNS (in this case OpenDNS) that goes through the WAN to get the clock updated quickly and correctly for other services to start...
Testing r45454 I was able to reduce the use of "iptables" in the firewall by using "ip route" with updated startup & firewall. Have it running on my spare R7800 tunneling HE_IPv6 and DNS to WireGuard oet1 i/f.
Code:
# Startup - Route HE 6in4 IPv6 to WireGuard (WG) oet1 tunnel while using PBR
# Routing DNS to WireGuard by editing WireGuard's "DNS servers via tunnel" GUI
# WAN table route is "main" & WireGuard oet1 table route is "21" when PBR is used
# Maximize the use of "ip route" commands
# Minimize the use of "iptables" commands
# Tested on r45454
#
# HE Ping Reply from arc.he.net (last used 66.220.2.74)
HE_Ping="66.220.2.74"
# HE Update URL from tunnelbroker.net (last used 64.62.200.2)
HE_UpdateURL="64.62.200.2"
# Tunnel Endpoint IPv4 Address from IPv6 GUI
HE_IPv4Server="$(nvram get ipv6_tun_end_ipv4)"
#
# Update IP Route Tables
# Route HE IPv6 to WireGuard
ip route add $HE_UpdateURL dev oet1
ip route add $HE_Ping dev oet1
ip route add $HE_IPv4Server dev oet1
#
# Clear Cache
ip route flush cache
Code:
# Firewall - Route HE 6in4 IPv6 to WireGuard (WG) oet1 tunnel while using PBR
# Routing DNS to WireGuard by editing WireGuard's "DNS servers via tunnel" GUI
# WAN table route is "main" & WireGuard oet1 table route is "21" when PBR is used
# Maximize the use of "ip route" commands
# Minimize the use of "iptables" commands
# Tested on r45454
#
# HE Ping Reply from arc.he.net (last used 66.220.2.74)
HE_Ping="66.220.2.74"
#
# NOW very few iptables commands required
# Respond to HE Ping Requests
iptables -I INPUT 2 -p icmp -s $HE_Ping -j ACCEPT
# Put back on TOP is required (still required on r45454)
iptables -D INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
_________________ Home Network on Telus 1Gb PureFibre - 10GbE Copper Backbone
2x R7800 - Gateway & WiFi & 3xWireGuard - DDWRT r53562 Std k4.9
Off Site 1
R7000 - Gateway & WiFi & WireGuard - DDWRT r54517 Std
E3000 - Station Bridge - DDWRT r49626 Mega K4.4
Off Site 2
R7000 - Gateway & WiFi - DDWRT r54517 Std
E2000 - Wired ISP IPTV PVR Blocker - DDWRT r35531
I loaded r45493 on my spare R7800 and made some changes to my working WireGuard tunnel that tunnels PBR, DNS and HE-IPv6. The updated Startup creates a oet1_routeup.sh script file in the /tmp directory, therefore add /tmp/oet1_routeup.sh to the WireGuard Route up script in the GUI.
Code:
# Startup - Tested on r45493
# WireGuard, PBR and routed DNS along with HE 6in4 IPv6
#
# --- Create file /tmp/oet1_routeup.sh ---
#
# NOTE: any script with any 3 of these $ \ ` requires \ in front of it
# to create the script correctly with cat command
#
cat - > /tmp/oet1_routeup.sh << EOF
#!/bin/sh
# HE Ping Reply from arc.he.net (last used 66.220.2.74)
HE_Ping="66.220.2.74"
# HE Update URL from tunnelbroker.net (last used 64.62.200.2)
HE_UpdateURL="64.62.200.2"
# Tunnel Endpoint IPv4 Address from IPv6 GUI
HE_IPv4Server="\$(nvram get ipv6_tun_end_ipv4)"
#
# Route HE IPv6 to WireGuard by updating table main
ip route add \$HE_UpdateURL dev oet1
ip route add \$HE_Ping dev oet1
ip route add \$HE_IPv4Server dev oet1
#
# Clear Cache
ip route flush cache
EOF
#
# ^^^ Create file /tmp/oet1_routeup.sh ^^^
#
chmod +x /tmp/oet1_routeup.sh
Code:
# Firewall - Tested on r45493
# WireGuard, PBR and routed DNS along with HE 6in4 IPv6
#
# Respond to HE Ping Requests
iptables -I INPUT 2 -p icmp -s 66.220.2.74 -j ACCEPT
# Put back on TOP is required (test if newer builds require it)
iptables -D INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
_________________ Home Network on Telus 1Gb PureFibre - 10GbE Copper Backbone
2x R7800 - Gateway & WiFi & 3xWireGuard - DDWRT r53562 Std k4.9
Off Site 1
R7000 - Gateway & WiFi & WireGuard - DDWRT r54517 Std
E3000 - Station Bridge - DDWRT r49626 Mega K4.4
Off Site 2
R7000 - Gateway & WiFi - DDWRT r54517 Std
E2000 - Wired ISP IPTV PVR Blocker - DDWRT r35531
I've been loading newer builds and have run into issues where 6in4 IPv6 doesn't work through a WireGuard tunnel. After doing some digging and testing on Build 46836 on a R7800 I found a solution with my current configuration. Run command...
ip tunnel show
You will see a tunnel like this one without real ip addresses...
ip6tun: ipv6/ip remote xxx.xxx.xxx.xxx local yyy.yyy.yyy.yyy ttl 64
xxx.xxx.xxx.xxx is your 6in4 Server IPv4 Address which is nvram value ipv6_tun_end_ipv4
yyy.yyy.yyy.yyy is currently setup to use your WAN IPv4 Address by default
I created a start script to be added to your Startup GUI that basically changes the the default WAN IP to the WireGuard oet1 IP Address...
Code:
#
# Change IPv6 6in4 to go through WireGuard oet1
ip_oet1addr=$(nvram get oet1_ipaddr)
ip_heserver=$(nvram get ipv6_tun_end_ipv4)
(ip tunnel change ip6tun mode sit remote $ip_heserver local $ip_oet1addr ttl 64)
#
Other changes I made are the MTUs values I now use -40 (minus 40) from each other, for example:
WAN MTU=1500
WG MTU=1460
IPv6 MTU=1420 _________________ Home Network on Telus 1Gb PureFibre - 10GbE Copper Backbone
2x R7800 - Gateway & WiFi & 3xWireGuard - DDWRT r53562 Std k4.9
Off Site 1
R7000 - Gateway & WiFi & WireGuard - DDWRT r54517 Std
E3000 - Station Bridge - DDWRT r49626 Mega K4.4
Off Site 2
R7000 - Gateway & WiFi - DDWRT r54517 Std
E2000 - Wired ISP IPTV PVR Blocker - DDWRT r35531
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Wed Jun 02, 2021 18:57 Post subject:
mac913 wrote:
I've been loading newer builds and have run into issues where 6in4 IPv6 doesn't work through a WireGuard tunnel. After doing some digging and testing on Build 46836 on a R7800 I found a solution with my current configuration. Run command...
ip tunnel show
You will see a tunnel like this one without real ip addresses...
ip6tun: ipv6/ip remote xxx.xxx.xxx.xxx local yyy.yyy.yyy.yyy ttl 64
xxx.xxx.xxx.xxx is your 6in4 Server IPv4 Address which is nvram value ipv6_tun_end_ipv4
yyy.yyy.yyy.yyy is currently setup to use your WAN IPv4 Address by default
I created a start script to be added to your Startup GUI that basically changes the the default WAN IP to the WireGuard oet1 IP Address...
Code:
#
# Change IPv6 6in4 to go through WireGuard oet1
ip_oet1addr=$(nvram get oet1_ipaddr)
ip_heserver=$(nvram get ipv6_tun_end_ipv4)
(ip tunnel change ip6tun mode sit remote $ip_heserver local $ip_oet1addr ttl 64)
#
Other changes I made are the MTUs values I now use -40 (minus 40) from each other, for example:
WAN MTU=1500
WG MTU=1460
IPv6 MTU=1420
WG mtu supposedly needs 1440 for ipv4 & 1420 for ipv6 (according to WG pages) _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
