OpenVPN Client connects but no Internet

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...

Have a look at your firewall config again, you need something like this:

config zone
        option name 'vpnclient'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option mtu_fix '1'
        option network 'vpnclient'
        option masq '1'

config forwarding
        option src 'lan'
        option dest 'vpnclient'

Maybe it will help. I think it looks more like wan config. Although this is what I am using from day one and never encountered a problem with VPN.

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...

How is this relevant to the OP's situation? Does OP uses NordVPN?

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.

Try to add this iptables rule:

iptables -t nat -A POSTROUTING -s -o br-lan -j MASQUERADE

replace the with your server ip address defined in /etc/config/openvpn

oops, you are correct. I mistakenly thought I saw nordvpn mentioned earlier in the thread.

Out of the openvpn log:

33]: /sbin/route add -net netmask gw
Tue Dec  4 13:29:52 2018 daemon.notice openvpn(vpnclient)[11533]: /sbin/route add -net netmask gw
Tue Dec  4 13:29:52 2018 daemon.notice openvpn(vpnclient)[11533]: /sbin/route add -net netmask gw
Tue Dec  4 13:29:52 2018 daemon.notice openvpn(vpnclient)[11533]: /sbin/route add -net netmask gw

So I use, I assume ?


cat /etc/config/openvpn

it is in the server line.

But might be correct. was the ip I found in the server.conf. However, even after restarts, same situation, router connects trough VPN, wifi-client does not.

Iptables are not my strongsuite.

Would any of this help maybe ?

echo 1 > /proc/sys/net/ipv4/ip_forward

#Reset iptables

iptables -F

iptables -X

iptables -A FORWARD -o wlan1 -i br-lan -s -m conntrack --ctstate NEW -j ACCEPT

iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

iptables -A POSTROUTING -t nat -j MASQUERADE

echo 1 | /proc/sys/net/ipv4/ip_forward

This enables your forwarding in the kernel, use cat /proc/sys/net/ipv4/ip_forward to verify. For forwarding enabled it should display 1.

iptables -t nat -A POSTROUTING -s -o br-lan -j MASQUERADE

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 source address. In fact is is an equivalent to iptables -A POSTROUTING -t nat -j MASQUERADE but is more strict and safer.

Thanks for explaining.
so I added

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s -o br-lan -j MASQUERADE

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.

What routes gets the client when connected? Can you check openvpn.log in /tmp when connected?

Have you tried pinging the vpn directly?
ping -c 5 -I tun0 (here tun0 is the vpn interface)

Maybe, this is just a guess, try stopping and starting the vpn instead of restarting it. It may help in some cases.

Hi everyone!

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 :smiling_imp: :smiling_imp: It's the OpenWRT guide that you followed to enable your OpenVPN client (this link: 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 :wink:). 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!

1 Like

Thanks for your investigations. I fixed this now.

Thanks! Somehow, the character is still present in the HTML code, but now the copy/paste is OK. Tested and approved fix on the guide :wink: