Your config seems okay to me, I use vpn-policy-routing with VPN so that not all the traffic goes through VPN but only the selected one and for that reason I put route-nopull in the VPN config. Are you using any other packages with VPN to bypass the traffic? Have you tried restarting the router? Maybe some config changes haven't been committed yet. So restarting would probably make it work.
Edit: You can create another network and map the LAN ports with that network. That way VPN will not be affecting PS4 or use the above package.
Thanks ahmar! I rebooted, and did a ping from the router. By the huge delay, it looks like it is going through the server. However, any client connecting to the router has no internet.
I think this is not openvpn related, but rather about forwarding. Thoughts on this continue to be very apreciated...
Thats the config from the manual which i entered line by line. Right now, Uplink, Lanport and Wifi-Master are bridged. Would that setup require a different firewall-setup maybe ?
This config should work out of box. Most of the time errors happen in the openvpn config itself but yours seems fine and Vpn is connected and other config seems fine to me as well. So I'm not really sure what I'm missing here. Because practically it should work.
Can you try a different vpn server? Can someone else provide any help here? @tmomas
Weird right ? Just tried disabling SQM QoS but to no avail. Again, the Router can ping and resolve hostnames, just connected clients cannot. Also tried a different ClientComputer, but no success...
I see the relevance- openvpn connects, router has internet but router-clients don´t. Unfortunately I am not seeing any ideas there, except downgrading to 17.06.
Enables the masquerading of the packets that does not do not find the destination within your LAN.
You need to Postroute and masquerade the packets originating from the 10.8.0.0 source address. In fact is is an equivalent to iptables -A POSTROUTING -t nat -j MASQUERADE but is more strict and safer.
No success though. Are there any more logs, that may show why traffic to to wifi-client is dropped ? As soon as I disable openvpn, it works flawlessly.
I had the exact same issue than you @zorn, but I may have a very good news for you: I have found my issue (and so yours too, since I assume they are the same). Forget about iptables rules or other OpenVPN config problem. Your issue is way much more vicious than that It's the OpenWRT guide that you followed to enable your OpenVPN client (this link: https://openwrt.org/docs/guide-user/services/vpn/openvpn/client). I also followed this guide. And I assume that you are like me, a lazy guy, and did some copy/paste to setup everything.
However there is an invisible character that you copied and that mess up with the firewall. If you look carefully at the HTML code of this page at the line where you set uci set firewall.@zone[-1].masq="1" there is an HTML entitiy ​ which is an UNICODE zero width space! To fix the problem, simply type the following commands:
uci set firewall.@zone[2].masq="1" service firewall restart && service openvpn restart
If you want to be 100% sure, don't copy paste those lines, but type it (normally they are zero width space free ). Also pay attention to the zone number. In your case it is 2, the same as me, but if you create other zone before or after setting this one, this number may change.
The question is "how the hell did I noticed that?", well, I wanted to compare your UCI config with mine, so I copied all your config in a blank new page of WinMerge and did the same with my config. I then I noticed on the line firewall.@zone[2].masq='1' that it was actually displayed like that firewall.@zone[2].masq=' 1 ' in WinMerge. So I wonder why it was like that in both your and my config while the line for @zone[1] was OK. So I used an HEX editor and found this mystery UNICODE charater. I re-push the config to UCI, restart everything and it worked. Then I investigated and found this character that we both have comes from the OpenWRT guide.
I hope it helps to solve your problem. I guess the next step would be to contact some OpenWRT staff to correct this invisible typo!