what about
ls -la /etc/sysctl.d/
root@DietPi-VPNServer:~# ls -la /etc/sysctl.d/
total 24
drwxr-xr-x 2 root root 4096 Aug 8 18:53 .
drwxr-xr-x 67 root root 4096 Aug 8 18:54 …
-rw-r–r-- 1 root root 51 Jun 8 06:06 98-rpi.conf
lrwxrwxrwx 1 root root 16 Aug 8 16:33 99-sysctl.conf → /etc/sysctl.conf
-rw-r–r-- 1 root root 220 Jul 26 20:55 dietpi.conf
-rw-r–r-- 1 root root 324 Jun 8 06:06 protect-links.conf
-rw-r–r-- 1 root root 639 May 31 2018 README.sysctl
root@DietPi-VPNServer:~#
ok that’s fine. The links is present. Therefore you have some content on both files 
. did you try to reboot? Usually net.ipv4.ip_forward = 1 should be activated than.
Yes I did reboot. Client connects, gets 10.8.0.2 Ip and can ping 10.8.0.1 but nothing behind.
Pi’s LAN side address is 192.168.240.227 and I have pushed the route for this subnet thru server.conf.
Client ( a windows for my test, using openVPN) when I do router print, shows that it has route for 192.168.240.0 /24 pointed to 10.8.0.1.
Here is full config from server.config file on the PiVPN server.
root@DietPi-VPNServer:~# cat /etc/openvpn/server.conf
dev tun
proto tcp
port 4430
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/DietPi_ae242b48-b770-4163-80c5-e4c023aeb38a.crt
key /etc/openvpn/easy-rsa/pki/private/DietPi_ae242b48-b770-4163-80c5-e4c023aeb38a.key
dh none
ecdh-curve prime256v1
topology subnet
server 10.8.0.0 255.255.255.0
Set your primary domain name server address for clients
push “dhcp-option DNS 8.8.8.8”
push “dhcp-option DNS 8.8.4.4”
Prevent DNS leaks on Windows
push “block-outside-dns”
Override the Client default gateway by using 0.0.0.0/1 and
128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
overriding but not wiping out the original default gateway.
#push “redirect-gateway def1”
push “route 192.168.240.0 255.255.255.0”
client-to-client
client-config-dir /etc/openvpn/ccd
keepalive 15 120
remote-cert-tls client
tls-version-min 1.2
tls-crypt /etc/openvpn/easy-rsa/pki/ta.key
cipher AES-256-CBC
auth SHA256
user openvpn
group openvpn
persist-key
persist-tun
crl-verify /etc/openvpn/crl.pem
status /var/log/openvpn-status.log 20
status-version 3
syslog
verb 3
#DuplicateCNs allow access control on a less-granular, per user basis.
#Remove # if you will manage access by user instead of device.
#duplicate-cn
Generated for use by PiVPN.io
root@DietPi-VPNServer:~#
And same client, connects fine and is able to ping the inside network when it connects to PiVPN server setup on dietPi install on the virtualbox. So it is something that happens on Pi 4B and Pi 3B or VM / Virtualbox don’t run into those issues. That is why I was thinking that it is a bug, but then you tested on your own Pi4B and you dont see this issue. I have done it with two different SD cards even, so it is something to do with hardware. Maybe there is some firmware / drivers that are different on my version that yours, but all RPi hardware is manufactured by same company in UK.
usually it should work if you have sysctl net.ipv4.ip_forward returning 1. Will do some more testing tomorrow. Already quite late at my side
Thank you and God bless you. No rush at my end. Worst case, I will try this on a 3B RPi also as a server. Just ordered that one.
Just did this and it works.
root@DietPi-VPNServer:~# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0
root@DietPi-VPNServer:~# sysctl net.ipv4.ip_forward=1
Since config files already have this set to 1, I will try rebooting it. Hopefully this persists.
Did a reboot and it stopped working.
Then did the following again, and it starts working.
Have a look at it sometime tomorrow or when you get chance. At least we know that routing gets messed up and there is something overriding that references some other files than the where it should.
root@DietPi-VPNServer:~# !36
sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0
root@DietPi-VPNServer:~# !65
sysctl net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1
root@DietPi-VPNServer:~#
Another thing I find is that I had copied the /etc/sysctl.conf and /etc/sysctl.d folder and then when I do a reboot, these files actually go blank and that explains as to why my echoing 1 to the Ip forwarding works but does not persist.
So now the issue is that these files themselves go missing on reboot.
but you don’t use any r/w protected file system or any overlay?
Since I was desperate to make it work, I ended up downloading the beta 64 bit. I again wiped the card and imaged it with the 64 bit beta.
I did run into some issues in installing the Pi-VPN thru the DietPi-Software section. It will fail to fully install and thus terminate with error that iptables persistent could not be installed etc. So I separately installed iptables persistent and I still had the issues with not much reason.
Then I tried the curl script based method. Again it will fail. Then I did sudo su and then tried curl again. This time, it proceeded further but was complaining of things like grepcidr and expect. Then I installed these packages using apt. And then I tried DietPi-software and this time it found all these dependencies and it finally completed without further errors.
And VPN now works exactly the way it should and routing is no longer broken. So it does look like that there is some bug in the 32bit version. Plus 64 bit being beta also has issues in the Pi-VPn script.
And yes, no r/w protection was used. And I has not installed nothing else yet.
I will now proceed to install XRDP and then Pi-Hole. I need XRDP so that I can then login to launch a browser to get into ISP router.
On dhcp scope I have Pi-VPN IP as primary DNS and 1.1.1.1 as secondary DNS. I am hoping that if RPi were to ever fail, Guests browsers will first try to use Pi-hole for DNS and not hearing back, will proceed to use the 1.1.1.1.
Thanks for your great help and support.
XRDP works great from windows client computer to the Pi VPN server. My need though will be on the RPi Client devices, but I wanted to test. Speed test from the server (Pi) is about 120Mbps download, better than I had expected.
for remote access, you could have used RealVNC. It’s pre-license on a Raspberry Pi board and you could have connected your systems to a RealVNC account. This way, you could get access without any VPN solution. Maybe something to play with, if you are still on testing phase.
Anyway still strange your issue with the empty /etc/sysctl.conf. Is the fill already empty after initial setup? Or just after installation of PiVPN?
I only noticed the files being empty after reboot, after I installed PiVPN server. For now, I dont have a spare one and will get one on Wednesday and I will test again with 32bit version.
RealVNC is not free, else I would have used that. They only allow 2 connections. It is very expensive for my needs. The whole project is a free project offering free WiFi at few locations.
Thanks again and stay well.
If you use a Raspberry Pi board, RealVNC is pre-licensed and free for non-commercial use.
https://www.realvnc.com/en/raspberrypi/
With VNC® Connect, you can establish direct and cloud connections, free for non-commercial use.