Joined: 06 Jun 2006 Posts: 7492 Location: Dresden, Germany
Posted: Sun Feb 23, 2020 10:55 Post subject:
i dont know what to fix here. the interface doesnt exist and this is why this is returned. so if the interface doesnt exist nothing can work anyway. so your openvpn setu seem to be broken or modified in a strange way, so that this interface has a different name or simple wasnt existing while running that code _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
Joined: 08 May 2018 Posts: 14221 Location: Texas, USA
Posted: Sun Feb 23, 2020 12:18 Post subject:
Alozaros wrote:
well it smells like my bug...
42460 not letting me to update/boot without reset from 42054
tried almost everything but not that, sadly after 35 hours in total
struggle, ill wait for the next build
thx for sharing it
Joined: 16 Nov 2015 Posts: 6437 Location: UK, London, just across the river..
Posted: Sun Feb 23, 2020 13:06 Post subject:
although im sick of try's , its so tempting....
as i said WAN never comes up nor DHCP... so it very likely source of the issue...will do on next update..i guess... _________________ Atheros
TP-Link WR740Nv1 ---DD-WRT 55630 WAP
TP-Link WR1043NDv2 -DD-WRT 55723 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear XR500 --DD-WRT 55779 Gateway/DoH,Forced DNS,AP Isolation,4VLAN,Ad-Block,Firewall,Vanilla
Netgear R7800 --DD-WRT 55819 Gateway/DoT,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla
Netgear R9000 --DD-WRT 55779 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Broadcom
Netgear R7000 --DD-WRT 55460 Gateway/SmartDNS/DoH,AD-Block,Firewall,Forced DNS,x3VLAN,VPN
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 by mac913
Joined: 21 Jul 2006 Posts: 1898 Location: Fortaleza Ce Brazil
Posted: Sun Feb 23, 2020 13:08 Post subject:
Mine openVPN is working fine ... 42490 .. since always
Wireguard works just fine in R7800 .. Its not working in Broadcom units ( WHZ1750 ) It connects but no Nat
@ BS .. Samba is working in Linux box and Windows . but in FTPserver and Android devices ( remote access ) it is not getting the files in directories .. since a mounth ago .
_________________ DDwrt ...it rocks ....
1 R7800 54420 AP Wireguard webserver JFFS SAMBA FTP usb HD Mesh
1 R7800 54420 Cli Mesh
1 WZR1750 54389 AP Webserver Samba Wireguard
1 TP link Archer C7v5 54420 Cli Mesh
1 DD x86_64 48296 Gateway Samba Ftp Webserver
Joined: 18 Mar 2014 Posts: 12887 Location: Netherlands
Posted: Sun Feb 23, 2020 16:25 Post subject:
stalonge wrote:
Mine openVPN is working fine ... 42490 .. since always
Wireguard works just fine in R7800 .. Its not working in Broadcom units ( WHZ1750 ) It connects but no Nat
@ BS .. Samba is working in Linux box and Windows . but in FTPserver and Android devices ( remote access ) it is not getting the files in directories .. since a mounth ago .
@Stalonge we are getting off topic, but do you mean the NAT out via the WAN is missing (so that your wireguard clients do not have internet access?)
Joined: 18 Mar 2014 Posts: 12887 Location: Netherlands
Posted: Sun Feb 23, 2020 16:32 Post subject:
egc wrote:
stebie wrote:
egc wrote:
arran wrote:
CVE-2019-14899 Mitigation setting in firmware
Firmware: DD-WRT v3.0-r41954 std (01/09/20)
has caused a bit of a problem for me that I think I solved and I want to share.
I just bought a new R7000P Netgear router and after swapping the stock Netgear firmware with DD-WRT I manually re-entered all my config.
DHCP stopped working. If I set a static address, everything was working. After a lot of investigation disabling CVE-2019-14899 Mitigation allowed DHCP to work again.
Hmm, if that would be the case I suppose we would have seen more reports mentioning this, so I would not exclude another cause of your problem.
I was bitten by this bug, having just upgraded from "DD-WRT v3.0-r41321 std (10/14/19)" on my Netgear R8000 to "DD-WRT v3.0-r42460 std (02/20/20)" .
Code:
root@DD-WRT:~# iptables -nvL -t raw
Chain PREROUTING (policy ACCEPT 51555 packets, 21M bytes)
pkts bytes target prot opt in out source destination
0 0 DROP 0 -- !tun1 * 0.0.0.0/0 10.8.0.0/24
3306 1046K DROP 0 -- !tun1 * 0.0.0.0/0 255.255.255.255
Chain OUTPUT (policy ACCEPT 2874 packets, 472K bytes)
pkts bytes target prot opt in out source destination
The DROP rule on 255.255.255.255 is what appears to be the blocker. Once I delete it, DD-WRT responds to DHCP requests from br0.
Disabling the mitigation also removes these iptables rules, therefore DHCP works with the mitigation disabled, but only after a reboot (same goes for enabling the mitigation; its impact is only experienced after a reboot).
EDIT: I assume 255.255.255.255 shouldn't be there, and it may be getting there as a call to command getipmask in function create_openvpnrules(fp) in file openvpn.c may be made with a non-matching interface or an interface with no IP address at the time run, which in turn echoes "255.255.255.255/32". Not sure why this happens, but it may be avoidable if a sanity check is performed before running the iptables command, ensuring the string returned from getipmask isn't "255.255.255.255/32" .
I am on holidays so cannot investigate this myself but I am sure you are on to something.
The create_openvpnrules(fp) is relatively new to solve another bug.
Although your patch will work, there might be even better ways to solve this.
Like making the rule conditional (only running when the interface is up) or use nvram variables (which are always available)
I will ping BS (main developer) to have a look
Thanks again
@stebie, BS has made modifications, he now uses the environment variable which is only available when the interface is up (and also excluded the use of /32, which should not be necessary but you never know)
But I have one question, are you using a non default interface?
The interface is showing as tun1 but the ip address tells me it is an openVPN Server setup which should use tun2?
Joined: 08 May 2018 Posts: 14221 Location: Texas, USA
Posted: Sun Feb 23, 2020 18:22 Post subject:
stalonge wrote:
Mine openVPN is working fine ... 42490 .. since always
Wireguard works just fine in R7800 .. Its not working in Broadcom units ( WHZ1750 ) It connects but no Nat
@ BS .. Samba is working in Linux box and Windows . but in FTPserver and Android devices ( remote access ) it is not getting the files in directories .. since a mounth ago .
Joined: 21 Jul 2006 Posts: 1898 Location: Fortaleza Ce Brazil
Posted: Sun Feb 23, 2020 19:47 Post subject:
egc wrote:
stalonge wrote:
Mine openVPN is working fine ... 42490 .. since always
Wireguard works just fine in R7800 .. Its not working in Broadcom units ( WHZ1750 ) It connects but no Nat
@Stalonge we are getting off topic, but do you mean the NAT out via the WAN is missing (so that your wireguard clients do not have internet access?)
If so just review Setup/Networking the oet1 interface should be unbridged and have Masquerade/NAT enabled.
Newer builds post 40267 should do this automatically.
Thanks for you reply .. i got it working in a broadcom unit .. The point is .. in this setup .. wireguard dd-wrt router is not the first router of this network .. it gets the ip from other dhcp router ( dmz ) .. I need to change the endpoint to real wan ip and it works .. I have a wireguard running in one r7800 a long time .. but it is the first router of this network ..
Sorry for off topic ..
_________________ DDwrt ...it rocks ....
1 R7800 54420 AP Wireguard webserver JFFS SAMBA FTP usb HD Mesh
1 R7800 54420 Cli Mesh
1 WZR1750 54389 AP Webserver Samba Wireguard
1 TP link Archer C7v5 54420 Cli Mesh
1 DD x86_64 48296 Gateway Samba Ftp Webserver
@stebie, BS has made modifications, he now uses the environment variable which is only available when the interface is up (and also excluded the use of /32, which should not be necessary but you never know)
But I have one question, are you using a non default interface?
The interface is showing as tun1 but the ip address tells me it is an openVPN Server setup which should use tun2?
Edit: forget the last question, tun2 is hard coded for openVPN server
I believe I'm using the default interface. That's why in my excerpt provided both 255.255.255.255 and 10.8.0.0/24 had an in iface of !tun1.
Code:
root@DD-WRT:~# ip a | grep tun
13: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc sfq state UNKNOWN qlen 100
inet 10.8.2.5/24 brd 10.8.2.255 scope global tun1
Below is my OpenVPN Client's Additional Config section.
Code:
remote-cert-tls server
remote-random
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
ping-timer-rem
reneg-sec 0
#log /tmp/vpn.log
#Delete `#` in the line below if your router does not have credentials fields and you followed the 3.1 step
#auth-user-pass /tmp/openvpncl/user.conf
Do let me know if there's anything in it that could be contributing.
@BrainSlayer: thanks for correcting my unescaped double-quotes in your implemented fix.
Joined: 18 Mar 2014 Posts: 12887 Location: Netherlands
Posted: Mon Feb 24, 2020 17:08 Post subject:
Almost all of your settings can be set in the GUI but that is not important leave it as is.
The remote random is what probably is causing the /24 normally it is a point to point interface with a netmask of 255.255.255.255. (ifconfig shows the interface)
The remote random is what probably is causing the /24 normally it is a point to point interface with a netmask of 255.255.255.255. (ifconfig shows the interface)
I think the /24 mask is what the VPN server is returning upon connection. remote-random is used to randomize server selection if you have more than one server (which I don't).
With regards to the 255.255.255.255 rule in the iptables raw table, it appears the route-up script is running before a successful connection. I can replicate it by putting in an invalid password, which won't connect therefore shouldn't trigger route-up.sh however the 255.255.255.255 rule is still added.
Unless it's not route-up.sh that's adding the rule?
I tried removing more potential factors out of the equation, including removing everything from OpenVPN Client's Additional Config and removing my cron jobs (in case there was some odd behaviour/interactions going on), however it persists.
After manually deleting the 255.255.255.255 rule, manually running stopservice openvpn and startservice openvpn does not seem to reintroduce the rule; it only appears to happen during boot time (or close to).
I've seen BS has recently changed the logic for openvpn_mit, now using env variables provided by OpenVPN, so I'll need to wait for the new beta and hope it fixes this.
EDIT: Have just tested r42514 and all appears well! Thanks again BS.
Joined: 18 Mar 2014 Posts: 12887 Location: Netherlands
Posted: Tue Feb 25, 2020 15:14 Post subject:
stebie wrote:
egc wrote:
The remote random is what probably is causing the /24 normally it is a point to point interface with a netmask of 255.255.255.255. (ifconfig shows the interface)
I think the /24 mask is what the VPN server is returning upon connection. remote-random is used to randomize server selection if you have more than one server (which I don't).
With regards to the 255.255.255.255 rule in the iptables raw table, it appears the route-up script is running before a successful connection. I can replicate it by putting in an invalid password, which won't connect therefore shouldn't trigger route-up.sh however the 255.255.255.255 rule is still added.
Unless it's not route-up.sh that's adding the rule?
I tried removing more potential factors out of the equation, including removing everything from OpenVPN Client's Additional Config and removing my cron jobs (in case there was some odd behaviour/interactions going on), however it persists.
After manually deleting the 255.255.255.255 rule, manually running stopservice openvpn and startservice openvpn does not seem to reintroduce the rule; it only appears to happen during boot time (or close to).
I've seen BS has recently changed the logic for openvpn_mit, now using env variables provided by OpenVPN, so I'll need to wait for the new beta and hope it fixes this.
He recently changed it again, one potential problem is that the rule is not preceded with a delete rule which is good practice IMHO, I will upload a patch when I am home next week.
The real problem is that the rules are not only invoked on route up because that should work as the interface should be up by then, the problem is that the rules can also be invoked by the firewall (which is new, and was necessary because the rules where missing when the firewall restarted).
Will look into the matter next week when we have the new build to test. _________________ Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399 Install guide R7800/XR500:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614 Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
The real problem is that the rules are not only invoked on route up because that should work as the interface should be up by then, the problem is that the rules can also be invoked by the firewall (which is new, and was necessary because the rules where missing when the firewall restarted).
I don't know what I'm missing but CVE-2019-14899 Mitigation kills my OpenVPN. It has never worked for me. I get connected to the server but none of the clients can pass traffic. So far, I don't see any clues in syslog or openvpn.log.