Joined: 18 Mar 2014 Posts: 12882 Location: Netherlands
Posted: Wed Jan 26, 2022 8:59 Post subject:
If you just add the static leases in the Additional DNSMasq Options like described and have saved them then those should be saved in nvram.
See attachment
If not then perhaps your nvram is at its max?
Look at the Status /Router page under NVRAM
I looked briefly at your settings and did not see any thing strikingly wrong.
On your phone use 0.0.0.0/0 as allowed IP for testing, although what you have should work to only connect to your home network but for testing use 0.0.0.0/0
There is no activity on the iptables maybe you are not trying to connect but that should be the next step.
Connect from your phone on cellular (with 0.0.0.0/0 as allowed ips) and look at the iptables rules if they are hit:
iptables -vnL INPUT
iptables -vnL FORWARD
You should see the packet counter of oet2 (the server tunnel) and the following rule:
Joined: 18 Oct 2016 Posts: 96 Location: Copenhagen, Denmark
Posted: Wed Jan 26, 2022 12:17 Post subject:
Hi Eric!
Unfortunately, it did not work - no traffic on 51810.
I checked port forwarding and no rule uses port 51810.
I disabled VPN and oet1.
Used 0.0.0.0/0 for testing. Using cellular connection directly to IP (not to DDNS).
About the other minor issue. My NVRAM is at 50Kb used of 128Kb. Free RAM is at 70%. It's no problem, I'll just do what you posted - just wanted to let you know of this odd behaviour.
It would seem that something is blocking the traffic elsewhere in the chain. I can only suspect the cellular network...?
Joined: 18 Oct 2016 Posts: 96 Location: Copenhagen, Denmark
Posted: Thu Jan 27, 2022 11:27 Post subject:
So, I contacted my ISP and they can't help but I have requested a pass-thorugh on my modem for WireGuard (and OpenVPN).
In the meantime I have experimented with PPTP, which connects fine.
My problem remains the same and applies to every VPN server solution: how do I route traffic from one subnet (say 10.4.1.32/24) to another (say 192.168.1.100/24) - on the same router?
My challenge is still that the client (192.168.1.101/OpenVPN) is perfectly reachable behind LAN, but not via VPN. There's no problem connecting to other devices on the LAN via VPN.
This defies the VPN idea, that it makes LAN clients reachable as if the connecting device were on the samme network...
Do I need a static route, a forwarding rule and how is that put together? I believe this would be possible and should be simpler than my initial port forwarding issue...
Joined: 18 Mar 2014 Posts: 12882 Location: Netherlands
Posted: Thu Jan 27, 2022 12:10 Post subject:
Most VPN solutions are routed i.e. they are on different subnets.
Exception is OpenVPN TAP setup.
However routing is/should be in place (I cannot vouch for PPtP) so when connected although you come from your VPN's subnet you can route to all the LAN clients (for OpenVPN and WireGuard you need to disable the CVE mitigation)
You can check routing with: ip route show
Of course your LAN clients often have their own firewall and will by default not allow other then their local subnets, so you have to tweak the LAN clients to allow traffic from the VPN's subnet.
One workaround (which will cost you your logging and access control, so I am not a great fan of it) is to NAT all traffic coming out of br0 (and if you have brx you should do that for other interfaces or use br+)
So that traffic coming out of the VPN server destined for your LAN clients has br0 as its source address so all traffic then seemingly comes from br0.
So with hesitation that rule:
For OpenVPN:
Code:
iptables -t nat -I POSTROUTING -o br0 -s $(nvram get openvpn_net)/$(nvram get openvpn_tunmask) -j MASQUERADE
For WireGuard (this is for oet1):
Code:
iptables -t nat -I POSTROUTING -o br0 -s $(nvram get oet1_ipaddr)/$(nvram get oet1_netmask) -j MASQUERADE
One workaround (which will cost you your logging and access control, so I am not a great fan of it) is to NAT all traffic coming out of br0 (and if you have brx you should do that for other interfaces or use br+)
As far as access control is concerned, nothing prevents you from controlling access "on the router" using its firewall *before* the traffic is dropped and masquerade'd onto the private network (br0). In fact, I prefer it, since many times there is no such control on the target device.
As far as logging is concerned, you could always add logging to the router too.
Code:
iptables -I FORWARD -s $(nvram get openvpn_net)/$(nvram get openvpn_tunmask) -m state --state NEW -j LOG --log-prefix "OVPN_SERVER"
These can be extracted from dmesg at any time.
Code:
dmesg | grep OVPN_SERVER
Come to think of it, either or both of these might be worth considering as options for the OpenVPN server GUI, perhaps the masquerading too! Consider it my contribution to the "egc full employment policy" @ dd-wrt! LOL
If you think about it, the only reason you even have such control is because you're using a routed tunnel (tun). But if you chose to use a bridged tunnel, you'd have no better logging or access control than if the client was patched directly to the router's switch w/ an ethernet cable. The client would be assumed to be trusted. In most cases, the fact a routed tunnel is used is NOT due to a concern over trust (although that's certainly possible), but simply because few ppl bother to consider the alternative; a bridged tunnel (or their client device doesn't support it (e.g., because it's a mobile device)).
My point is, in the vast majority of cases, masquerading your traffic in this fashion is no big deal. The fact you even have this capability is simply an artifact of how you chose to implement the remote access. I doubt most ppl take into consideration whether they should use a routed vs. bridged tunnel on that basis. The thought process rarely goes that deep.
I just don't want to leave the impression that this is somehow of great concern in most cases. Like anything, there are exceptions. But for most home users, esp. when they and other trusted family members are the only users, it's rarely worth worrying about imo. OTOH, if you're providing access to less than fully trusted users (e.g., the neighbor up the street w/ whom you're sharing your video collection), then yes, that would be a different story.
Joined: 18 Mar 2014 Posts: 12882 Location: Netherlands
Posted: Thu Jan 27, 2022 14:04 Post subject:
@eibgrad your contributions and advice are as always gratefully accepted.
Will put in on my list to add, Thanks!
It is exactly the last situation I am referring to, I give access to family members and friends, they are allowed to use some servers on the network but not all
I even hand out specific ovpn leases with CCD
But you are of course right for the vast majority it is no problem.
Joined: 18 Oct 2016 Posts: 96 Location: Copenhagen, Denmark
Posted: Fri Jan 28, 2022 13:06 Post subject:
egc wrote:
@eibgrad your contributions and advice are as always gratefully accepted.
Will put in on my list to add, Thanks!
It is exactly the last situation I am referring to, I give access to family members and friends, they are allowed to use some servers on the network but not all
I even hand out specific ovpn leases with CCD
But you are of course right for the vast majority it is no problem.
P.S. I am also working on incorporating a watchdog script for OpenVPN (one of your earlier remarks )
I'm glad I could help you two guys
No seriously, thank you for your help. I did catch this rule that made it all work (using PPTP - before I saw your contributions):
Joined: 18 Mar 2014 Posts: 12882 Location: Netherlands
Posted: Fri Jan 28, 2022 19:03 Post subject:
That rule is to allow attached VPN clients a way out to the internet so actually WAN access.
WireGuard and OpenVPN do that by default.
It is a long time ago I used PPtP.
It is unsafe to use, actually surprised it works as it is not maintained at all.
So unfortunately I cannot help you with it either
We were discussing LAN access and actually testing it at this moment.
Of course you have LAN access but as the VPN clients have a different subnet not all your local LAN clients will allow traffic from VPN clients.
You can tweak the firewall of the local LAN clients to allow VPN traffic (my favourite solution but needs work and skills) alternatively NAT all traffic out of br0 onto the local LAN so that all traffic comes from br0 (and thus from the same subnet).
The setting in the GUI to do that might be in a future build, see attachment last setting "Allow clients full LAN access".
Joined: 18 Oct 2016 Posts: 96 Location: Copenhagen, Denmark
Posted: Thu Feb 03, 2022 11:53 Post subject:
egc wrote:
That rule is to allow attached VPN clients a way out to the internet so actually WAN access.
WireGuard and OpenVPN do that by default.
It is a long time ago I used PPtP.
It is unsafe to use, actually surprised it works as it is not maintained at all.
So unfortunately I cannot help you with it either
We were discussing LAN access and actually testing it at this moment.
Of course you have LAN access but as the VPN clients have a different subnet not all your local LAN clients will allow traffic from VPN clients.
You can tweak the firewall of the local LAN clients to allow VPN traffic (my favourite solution but needs work and skills) alternatively NAT all traffic out of br0 onto the local LAN so that all traffic comes from br0 (and thus from the same subnet).
The setting in the GUI to do that might be in a future build, see attachment last setting "Allow clients full LAN access".
The setting above that is for the rule you needed for PPtP
Sorry about my last post - my wireless network kicked in and for a short while it would seem that I had access to the client behind VPN.
Meanwhile I have experimented with all VPN servers possible with DD-WRT: WireGuard, PPTP and OpenVPN.
PPTP server is possible out of the box (no access to OVPN client)
WireGuard server is not possible (UDP protocol/passthrough being blocked by my ISP)
OpenVPN server is possibe over TCP (no access to OVPN client)
I even managed to get a working connection to PIA-VPN over WireGuard with DD-WRT but that's out of this topic's scope.
So, a few questions:
Is WireGuard possible over TCP and if yes, how?
When do we get "Allow clients full LAN access"?
Do you now of any Android(12) apps that can make an OpenVPN TAP connection to DD-WRT?
I understand the problem with LAN clients being tunneled through tun1 is, that they respond over tun1 thus not reaching br0, correct?
I guess I just find it difficult to understand why clients respond correctly over straight "LAN to LAN" but not over "WAN(VPN) masquerated as LAN to LAN"...
