My router has the IP 172.21.1.1 and DHCP starts at 172.21.1.2. I tried the following Wireguard config:
After setting up the tunnel in my phone (using the QR Code) it connects to the router however I have no internet access, I can't access the router GUI via 172.21.1.1 nor ping it. What am I missing?
Or go into Dnsmasq options and add interface=br0,oet1. _________________ 1x Netgear R7800 (latest); 3x Netgear R7000 (latest); 2x Asus RT-N16 (v3.0-r47656); 2x Fonera 2100 (v3.0-r45454).
Last edited by TCB13 on Fri Aug 21, 2020 9:46; edited 1 time in total
Update: after rebooting the router the tunnel doesn't work again I can't ping anything or access any IP / hostname.
Firewall and routes seems to be ok:
Code:
Chain POSTROUTING (policy ACCEPT 972 packets, 70139 bytes)
pkts bytes target prot opt in out source destination
0 0 SNAT all -- * oet1 0.0.0.0/0 0.0.0.0/0 to:172.21.3.1
72 3828 SNAT all -- * vlan2 172.21.1.0/24 0.0.0.0/0 to:85.xxx.xxx.xxx
0 0 SNAT all -- * vlan2 172.21.3.0/24 0.0.0.0/0 to:85.xxx.xxx.xxx
Code:
ip route show
default via 85.xxx.xxx.xxx dev vlan2
85.xxx.xxx.0/24 dev vlan2 scope link src 85.xxx.xxx.xxx
127.0.0.0/8 dev lo scope link
172.21.1.0/24 dev br0 scope link src 172.21.1.1
172.21.2.0/24 dev tun2 scope link src 172.21.2.1
172.21.3.0/24 dev oet1 scope link src 172.21.3.1
172.21.3.2 dev oet1 scope link
I don't know if this is a timing issue with something after boot but it seems to works randomly sometimes...
Sometimes I connect my client and it says it's connected however in the router page under "WireGuard Status (F5 to refresh)" it doesn't show up. Seems like disconnecting the client and connecting again 2 or 3 times makes it show up under the "Status" section and then it works. _________________ 1x Netgear R7800 (latest); 3x Netgear R7000 (latest); 2x Asus RT-N16 (v3.0-r47656); 2x Fonera 2100 (v3.0-r45454).
Found the issue, my DDNS wasn't updating at boot because the router wasn't able to resolve the DDNS server domain due to not having the date/time updated yet.
The strangest part is that my mobile client was saying it was connected to an IP that my router didn't have after reboot / probably wasn't even assigned to anyone by the ISP.
Thank you for the help jwh7 and egc. Your guides really helped along the process _________________ 1x Netgear R7800 (latest); 3x Netgear R7000 (latest); 2x Asus RT-N16 (v3.0-r47656); 2x Fonera 2100 (v3.0-r45454).
Joined: 18 Mar 2014 Posts: 12837 Location: Netherlands
Posted: Fri Aug 21, 2020 10:56 Post subject:
Depending on DDNS provider it can take up to 10 minutes before the DDNS is updated.
However most ISP's will hand out the same public IP address to your router but maybe yours does not?
WG also needs the correct time.
From the WG guide Troubleshooting section:
Code:
Be Patient
It can take up to minutes before the WireGuard tunnel suddenly starts to work.
So after setting up or reboot wait at least 3-4 minutes before thinking it is not working!
Workarounds for CVE 14899This is the short version assuming you use the first tunnel interface
iptables -t nat -I POSTROUTING -o br0 -s $(nvram get oet1_ipaddr)/$(nvram get oet1_netmask) -j MASQUERADE
What are the security considerations / extra troubles one might get in by using this workaround?
Depending on DDNS provider it can take up to 10 minutes before the DDNS is updated.
It doesn't seem related to the DDNS provider because on the log it says that the router time is 1 Jan and:
Code:
W:'RC_IP_INVALID_REMOTE_ADDR' (0x12) updating the IPs. (it 0)
It looks like it's NTP/DNSCrypt Resolver related because after some time the router tries again and it is able to update the IP. At this point the NTP client already updated the time of the router and everything works fine...
egc wrote:
However most ISP's will hand out the same public IP address to your router but maybe yours does not?
Joined: 18 Mar 2014 Posts: 12837 Location: Netherlands
Posted: Fri Aug 21, 2020 12:06 Post subject:
TCB13 wrote:
Btw,
Quote:
Workarounds for CVE 14899This is the short version assuming you use the first tunnel interface
iptables -t nat -I POSTROUTING -o br0 -s $(nvram get oet1_ipaddr)/$(nvram get oet1_netmask) -j MASQUERADE
What are the security considerations / extra troubles one might get in by using this workaround?
Thank you.
All traffic from your WG clients now originate from the router so you can not track or route/block on the clients IP.
I do not want some of my WG clients to access my NAS so those clients are blocked with this rule you can no longer do that for me that is bad.
I have CVE disabled, but the best of both worlds (just my opinion) is actually the rule to allow traffic from your internal network:
iptables -t raw -I PREROUTING -i br0 -j ACCEPT
If clients on your LAN are hacked they could then use the attack vector described in the CVE 14899, but frankly if those clients are hacked you have got bigger problems (I assume that you have your IOT clients separated as they are often vulnerable)
But As I said the security risk of the CVE 14899 vulnerablitly is minimal, your traffic cannot be decrypted only the IP addresses of the other side of the tunnel can be seen and only from something directly attached to your WAN (like a hacked modem) or from your LAN.
But As I said the security risk of the CVE 14899 vulnerablitly is minimal, your traffic cannot be decrypted only the IP addresses of the other side of the tunnel can be seen and only from something directly attached to your WAN (like a hacked modem) or from your LAN.
Great, thank you for the clarification. I was about worried about disabling the mitigation because of Protons VPN disclaimer about the CVE:
Quote:
Provided there is no reverse path filtering, an attacker that controls your L2 link (i.e., your WiFi or LAN) can send specially crafted packets to your device. The attacker can then use those packets to actively probe for certain properties of the TCP connections originating from your device. In other words, by controlling a device’s access point to the Internet, an attacker can infer if the user is connected to a specific host and port.
Additionally, if a TCP connection is unencrypted inside the VPN tunnel (if you visit a page that uses HTTP instead of HTTPS, for instance), the attacker can inject packets into that specific unencrypted stream. This would allow an attacker to feed your device fake HTML content for that particular stream. That would be dangerous, but as previously stated, the attacker must target a specific TCP connection, so it is not a simple vulnerability to exploit.
They frame it like Wireguard is completely and utterly broken if someone has control over your LAN or WAN. If what they say about "TCP connection is unencrypted inside the VPN tunnel (...) the attacker can inject packets into that specific unencrypted stream" is true, then I don't really believe that Wireguard encrypts anything. Everything send over the tunnel is allegedly encrypted (by Wireguard) how on earth is it possible for someone to inject packages? _________________ 1x Netgear R7800 (latest); 3x Netgear R7000 (latest); 2x Asus RT-N16 (v3.0-r47656); 2x Fonera 2100 (v3.0-r45454).
I know this is an old Post, but TCB, would you mind sharing what sort of bandwidth could you get from that wireguard tunnel?
I'm currently using an OLD raspberry pi to setup a wireguard Server and tunnel between two locations, but can only get 12Mbps which is not enough for my needs.
Could you possibly share the speed that you managed to get out of the R7000?