Most clients on your network have their own firewall and will not allow any clients from another network.
The VPN clients have the 10.8.0.0 subnet and the local clients have the 192.168.50.0 subnet.
The trick is to adapt the firewall of the local clients to allow incoming traffic from the 10.8.0.0. subnet.
As a test that this is the case just disable the firewall on one of the machines you have difficulty connecting to.
As an alternative you can SNAT the traffic from the OVPN on to the network with this firewall rule:
iptables -t nat -I POSTROUTING -o br0 -s 10.8.0.0/24 -j SNAT --to $(nvram get lan_ipaddr)
I have the instructions to tweak the Windows firewall here somewhere and can look them up if you need them (something like: set a new incoming rule, set scope to allow local IP access from the OVPN subnet)
I'm just now getting back to this (I lost connection while I was away due to changing a setting), but I appreciate the quick reply you gave. I have tried disabling the windows firewall, but I am still unable to connect with remote desktop or see the PC in network places (i can ping them okay). I have tried adding the firewall rule that you suggested but I still cannot see the local PCs or connect using remote desktop. Do you have any other ideas?
I appreciate you taking the time to do this, it was very nice of you to make the guide.
Thanks,
Bret
EDIT: (more info) When connected remotely to the vpn I see the following behaviour:
1. I can login to my routers dd-wrt page.
2. I can login into the admin page for my switch. (a wrt54g running dd-wrt acting as a switch)
3. I can login into my synology NAS through the my browser but I cannot map any network drives, I cannot anything in my network places.
4. I can successfully ping all the devices on the network.
5. I disabled windows firewall on the computer that I am trying to remote desktop to but it doesn't help.
Joined: 18 Mar 2014 Posts: 12837 Location: Netherlands
Posted: Sun Feb 23, 2020 10:16 Post subject:
There is no network discovery over a routed VPN, so you can only connect by ip address, so remote desktop will only work by ip adress (I have no experience with remote desktop, if applicable I use teamviewer).
(you can use local DNS if you setup that way)
you have redundant firewall rules, the following rules are doing the same:
Providing you have declared the WAN_IF variable, if not then delete that rule
However that has nothing to do with your problem.
The fact that you can ping all your devices indicates that routing is working, firewall rules on the client can allow pinging the device but not allow things like remote desktop so check firewall and remote desktop settings allowing to connect, and as said you can only connect by ip address _________________ 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
There is no network discovery over a routed VPN, so you can only connect by ip address, so remote desktop will only work by ip adress (I have no experience with remote desktop, if applicable I use teamviewer).
(you can use local DNS if you setup that way)
you have redundant firewall rules, the following rules are doing the same:
Providing you have declared the WAN_IF variable, if not then delete that rule
However that has nothing to do with your problem.
The fact that you can ping all your devices indicates that routing is working, firewall rules on the client can allow pinging the device but not allow things like remote desktop so check firewall and remote desktop settings allowing to connect, and as said you can only connect by ip address
Everything is working now! I thought I was connecting by ip using remote desktop but apparently I was doing it wrong. I can also map all my network drives by ip successfully. I have also deleted the redundant firewall rule. Thank you very much for all your help and the guide!!!
You do not need a DH parameter (as you specified the dh none in additional config) but you do need a Public Key (server Cert)
If the server does not start it is a major configuration error, usually certificates/keys
Edit: do not forget the disable the CVE patch (in the GUI) or take additional measures (see the guide)!
Many thanx for the help. Now everything woks like a charm.
I had to do some changes to get what I want.
1st: On the ovpn file for Android, I added "comp-lzo no" only on the client cause I was able to connect but with errors and it was connected to nothing (no lan machines nor web).
2nd: I changed "iptables -t nat -A POSTROUTING -s 192.171.0.0/24 -o $(get_wanface) -j MASQUERADE"
by:
"iptables -t nat -A POSTROUTING -s 192.171.10.0/24 -j MASQUERADE" for web access, this instruction you gave didn't work on my side, but cause I'm not familiar with iptables, I don't know the risk of my solution.
3rd: I've unticked the CVE patch but with or without tick, my setup is usable identically.
4th: I did some other iptables to connect all clients on vpn and lan between them (shared files) and router settings access pages from vpn.
With some minors mods on additional params, it's okay for me and you saved me a lot of time.
The only things impossible are having a same IP for one machine on Lan or VPN when I'm out of home, and using UPNP/DLNA servers over tun vpn and tap is'nt stable with the android app which has this option.
Thank you and feel free to comment if I did a mistake.
Joined: 18 Mar 2014 Posts: 12837 Location: Netherlands
Posted: Thu Mar 05, 2020 8:38 Post subject:
Alkap wrote:
egc wrote:
I took a quick glance (busy compiling)
You do not need a DH parameter (as you specified the dh none in additional config) but you do need a Public Key (server Cert)
If the server does not start it is a major configuration error, usually certificates/keys
Edit: do not forget the disable the CVE patch (in the GUI) or take additional measures (see the guide)!
Many thanx for the help. Now everything woks like a charm.
I had to do some changes to get what I want.
1st: On the ovpn file for Android, I added "comp-lzo no" only on the client cause I was able to connect but with errors and it was connected to nothing (no lan machines nor web).
2nd: I changed "iptables -t nat -A POSTROUTING -s 192.171.0.0/24 -o $(get_wanface) -j MASQUERADE"
by:
"iptables -t nat -A POSTROUTING -s 192.171.10.0/24 -j MASQUERADE" for web access, this instruction you gave didn't work on my side, but cause I'm not familiar with iptables, I don't know the risk of my solution.
3rd: I've unticked the CVE patch but with or without tick, my setup is usable identically.
4th: I did some other iptables to connect all clients on vpn and lan between them (shared files) and router settings access pages from vpn.
With some minors mods on additional params, it's okay for me and you saved me a lot of time.
The only things impossible are having a same IP for one machine on Lan or VPN when I'm out of home, and using UPNP/DLNA servers over tun vpn and tap is'nt stable with the android app which has this option.
Thank you and feel free to comment if I did a mistake.
Glad you got it working, if you are happy keep it like this but some comments
You have set Compression to no which translates to comp-lzo no. Compression does not help in throughput, the compresion itself does use valuable CPU cycles so that the net result of compression is around zero. As there is a security problem with compression the general advice is to disable it (set Compression to Disabled) and then you do not have to add comp-lzo no
You are probably the victim of a bug (which I already patched in the next build), if you disable the CVE patch it stays active till the next reboot, your POSTROUTING rule is a workaround for the CVE patch, I think you can use the original rule with -o $(get_wanface) if you have the CVE patch disabled and reboot.
There are other advantages when using this workaround and that is that the VPN traffic is NATted on to your own subnet so you do not have firewall problems when reaching your LAN clients (for me it is a big disadvantage as you can not see the origin of the traffic, so I do have it disabled, the security risk is real but minimal)
Bridged (tap) setup is not working on Android and iOS (there are workarounds but as you found out it does not work reliable) it works OK for Windows and router to router
When using TUN you have to use different subnets for router, VPN and client otherwise you have a routing problem
Glad you got it working, if you are happy keep it like this but some comments
You have set Compression to no which translates to comp-lzo no. Compression does not help in throughput, the compresion itself does use valuable CPU cycles so that the net result of compression is around zero. As there is a security problem with compression the general advice is to disable it (set Compression to Disabled) and then you do not have to add comp-lzo no
You are probably the victim of a bug (which I already patched in the next build), if you disable the CVE patch it stays active till the next reboot, your POSTROUTING rule is a workaround for the CVE patch, I think you can use the original rule with -o $(get_wanface) if you have the CVE patch disabled and reboot.
There are other advantages when using this workaround and that is that the VPN traffic is NATted on to your own subnet so you do not have firewall problems when reaching your LAN clients (for me it is a big disadvantage as you can not see the origin of the traffic, so I do have it disabled, the security risk is real but minimal)
Bridged (tap) setup is not working on Android and iOS (there are workarounds but as you found out it does not work reliable) it works OK for Windows and router to router
When using TUN you have to use different subnets for router, VPN and client otherwise you have a routing problem
But if you are happy like it is, just keep it
Glad to read your reply.
Assuming server on DD-WRT has compression off (Screenshot below), I tested removing "comp-lzo no" on Android client. The result is connected but unable to reach WEB neither other machines on my LAN and I have an error 22 on client (See screenshot attached).
If I set "comp-lzo no", I don't have error 22 and I can reach machines on Lan.
With your instruction "-o $(get_wanface)", I can reach LAN and can't reach WEB.
So I would like to make my setup perfect but usable And I have no choice to suppress "-o $(get_wanface)" and to add "comp-lzo no".
I tried but no luck.
I think I have 2 problems, the 1st is the compression and the second is the nat rule.
Please have a look on my log for the 1st problem. I'll solve the second after the 1st.
Other, I saw MTU strange values too highlighted on screenshot.
Thanx for support.
[EDIT] : I had a look inside /tmp/openvpn/openvpn.conf and here is what I see : "comp-lzo no". Now everything is clear why my client needs that. Is it a bug in my build ?
[EDIT2] : I'm stupid, there is an option "NO" and an option "DISABLED". I'll try "DISABLED" and will make some tests with your "-o $(get_wanface)" instruction.
1st problem solved !
[EDIT3] : No MTU message, no error 22, it's okay, my compression issue is far away.
I confirm I can't use "-o $(get_wanface)" only if I want to go on web over VPN otherwise my home LAN only is allowed. It's frustrating cause I don't know why.
For people who wanna know what I did, I simply added a line like on this screenshot :
Joined: 18 Mar 2014 Posts: 12837 Location: Netherlands
Posted: Fri Mar 06, 2020 11:26 Post subject:
Thanks for your feedback I have made a note in the guide that Disabled is different from No
Regarding your other problem, do you not have internet access out of your server or are you not being able to reach clients on your local LAN?
If you do not have internet access please send output of the following 4 commands (entered via CLI/Putty/telnet):
Code:
nvram get wan_iface
nvram get wan_ifname
get_wanface
echo WAN_IF="$(route -n | awk '/^0.0.0.0/{wif=$NF} END {print wif}')"
If you cannot reach your local clients make sure you have disabled the CVE-2019-14899 Mitigation that is the second radio button in the OpenVPN GUI and if you have done Save and Apply reboot the router.
Then send output of:
Regarding your other problem, do you not have internet access out of your server or are you not being able to reach clients on your local LAN?
Unable to reach internet acces and able to reach clients.
egc wrote:
you do not have internet access please send output of the following 4 commands (entered via CLI/Putty/telnet):
Code:
nvram get wan_iface
nvram get wan_ifname
get_wanface
echo WAN_IF="$(route -n | awk '/^0.0.0.0/{wif=$NF} END {print wif}')"
nvram get wan_ifname ==> eth0
nvram get wan_ifname ==> eth0
get_wanface ==> eth
echo WAN_IF="$(route -n | awk '/^0.0.0.0/{wif=$NF} END {print wif}')" ==> WAN_IF=eth0
egc wrote:
If you cannot reach your local clients make sure you have disabled the CVE-2019-14899 Mitigation that is the second radio button in the OpenVPN GUI and if you have done Save and Apply reboot the router.
CVE-2019-14899 Mitigation is disabled.
egc wrote:
Then send output of:
Code:
iptables -t raw -vnL
See screenshot below:
Router is rebooted on every changes, I understood what you told me before.
The screenshot is done with my 2nd instruction.
[EDIT] I did the same test with your instruction only and the result is the same.
Great to see you follow my particularity
Thank you.
Joined: 18 Mar 2014 Posts: 12837 Location: Netherlands
Posted: Sat Mar 07, 2020 9:04 Post subject:
Thanks for coming back, things now get really interesting.
The rule is to NAT traffic out over the WAN interface to get internet access.
For different routers/chipsets the WAN interface is named differently:
on older Broadcom routers the WAN interface is vlan0, on newer Broadcom it is vlan2, on Atheros it is eth0 and on Marvell it is also supposed to be eth0
In the old days the WAN interface was identified with nvram parameter wan_iface and later wan_ifname, and that still works on a lot of routers but not always (it does not work with PPPoE), the newer method to identify is an external command: get_wanface and that is supposed to always work
But it is not as your case points out.
My tutor (@eibgrad) did not trust any of those and always advocate to just query the routing table, a drawback is that the route has to be up already which is not always the case but normally for a VPN server it should be.
Although the order in which rules are executed is important, it is not in this case.
To be sure I used -I to insert the rule so that it will be executed first, but as said in this case it does not matter
Okay, and thank you for everything and your quick replies. My little knowledge is bigger now and my setup runs exactly how I want.
Excepting upnp/dlna, everything works (I know I can't get dlna working over tun vpn).
File closed on my side. Have a nice W.E.
You are a king !