I have an unusual setup, and can't get this to work. I have my router connected to my main network, but I am not using it as a DHCP server or gateway. It is connected to the network on one of the LAN ports (eth0), and is assigned a static IP on the subnet of the main network. I then have the wifi configured in client mode, connected to an access point that has access to the internet (wwan). I also have OpenVPN installed, operating as a server (tun0).

The intent is to allow PCs on my network to connect to the OpenVPN server, and access the internet over the wifi connection.

So far I have been able to connect to the OpenVPN server properly, and have access to the router itself through the OpenVPN connection (can access the luci interface). But I can't get access to the internet. The wifi connection seems to be getting an IP address properly from the wan though. Also, I have been able to setup different scenarios, where I tunnel into the router with SSH, and use it as a SOCKS proxy, and that works. I can access the internet when using the SSH tunnel.

Right now, I can't tell if it's a routing issue on the PCs (not being pushed the proper route commands from OpenVPN), or if it's a routing/firewall issue at the router. I've include my /etc/config/firewall, /etc/config/network, and /etc/config/wireless information below. I feel like it's an incorrect firewall rule between the vpn0 and wwan interfaces, but just can't find the issue...Any help is appreciated.

/etc/config/wireless

config wifi-device 'radio0'
    option type 'mac80211'
    option hwmode '11g'
    option path 'platform/qca953x_wmac'
    option htmode 'HT20'
    option disabled '0'
    option txpower '19'
    option country 'US'
    option channel '11'

config wifi-iface
    option ssid 'optimumwifi'
    option encryption 'none'
    option device 'radio0'
    option mode 'sta'
    option network 'wwan'
    option bssid '52:65:A3:C5:96:28'

/etc/config/network

config interface 'loopback'
    option ifname 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config globals 'globals'
    option ula_prefix 'fdc7:cd43:7970::/48'

config interface 'lan'
    option ifname 'eth0'
    option force_link '1'
    option type 'bridge'
    option proto 'static'
    option netmask '255.255.255.0'
    option ip6assign '60'
    option ipaddr '192.168.1.12'

config interface 'wan'
    option ifname 'eth1'
    option proto 'dhcp'

config interface 'wan6'
    option ifname 'eth1'
    option proto 'dhcpv6'

config switch
    option name 'switch0'
    option reset '1'
    option enable_vlan '1'

config switch_vlan
    option device 'switch0'
    option vlan '1'
    option ports '0 1 2 3 4'

config interface 'vpn0'
    option ifname 'tun0'
    option proto 'none'
    option auto '1'

config interface 'wwan'
    option proto 'dhcp'

/etc/config/firewall

config defaults
    option syn_flood '1'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'REJECT'

config zone
    option name 'lan'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'ACCEPT'
    option network 'lan'

config zone
    option name 'wan'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'
    option mtu_fix '1'
    option network 'wan wan6 wwan'

config forwarding
    option src 'lan'
    option dest 'wan'

config rule
    option name 'Allow-DHCP-Renew'
    option src 'wan'
    option proto 'udp'
    option dest_port '68'
    option target 'ACCEPT'
    option family 'ipv4'

config rule
    option name 'Allow-Ping'
    option src 'wan'
    option proto 'icmp'
    option icmp_type 'echo-request'
    option family 'ipv4'
    option target 'ACCEPT'

config rule
    option name 'Allow-IGMP'
    option src 'wan'
    option proto 'igmp'
    option family 'ipv4'
    option target 'ACCEPT'

config rule
    option name 'Allow-DHCPv6'
    option src 'wan'
    option proto 'udp'
    option src_ip 'fe80::/10'
    option src_port '547'
    option dest_ip 'fe80::/10'
    option dest_port '546'
    option family 'ipv6'
    option target 'ACCEPT'

config rule
    option name 'Allow-MLD'
    option src 'wan'
    option proto 'icmp'
    option src_ip 'fe80::/10'
    list icmp_type '130/0'
    list icmp_type '131/0'
    list icmp_type '132/0'
    list icmp_type '143/0'
    option family 'ipv6'
    option target 'ACCEPT'

config rule
    option name 'Allow-ICMPv6-Input'
    option src 'wan'
    option proto 'icmp'
    list icmp_type 'echo-request'
    list icmp_type 'echo-reply'
    list icmp_type 'destination-unreachable'
    list icmp_type 'packet-too-big'
    list icmp_type 'time-exceeded'
    list icmp_type 'bad-header'
    list icmp_type 'unknown-header-type'
    list icmp_type 'router-solicitation'
    list icmp_type 'neighbour-solicitation'
    list icmp_type 'router-advertisement'
    list icmp_type 'neighbour-advertisement'
    option limit '1000/sec'
    option family 'ipv6'
    option target 'ACCEPT'

config rule
    option name 'Allow-ICMPv6-Forward'
    option src 'wan'
    option dest '*'
    option proto 'icmp'
    list icmp_type 'echo-request'
    list icmp_type 'echo-reply'
    list icmp_type 'destination-unreachable'
    list icmp_type 'packet-too-big'
    list icmp_type 'time-exceeded'
    list icmp_type 'bad-header'
    list icmp_type 'unknown-header-type'
    option limit '1000/sec'
    option family 'ipv6'
    option target 'ACCEPT'

config include
    option path '/etc/firewall.user'

config rule
    option src 'wan'
    option dest 'lan'
    option proto 'esp'
    option target 'ACCEPT'

config rule
    option src 'wan'
    option dest 'lan'
    option dest_port '500'
    option proto 'udp'
    option target 'ACCEPT'

config include 'miniupnpd'
    option type 'script'
    option path '/usr/share/miniupnpd/firewall.include'
    option family 'any'
    option reload '1'

config rule 'Allow_OpenVPN_Inbound'
    option target 'ACCEPT'
    option src '*'
    option proto 'udp'
    option dest_port '1194'

config zone 'vpn'
    option name 'vpn'
    option network 'vpn0'
    option input 'ACCEPT'
    option forward 'REJECT'
    option output 'ACCEPT'
    option masq '1'

config forwarding 'vpn_forwarding_wan'
    option src 'vpn'
    option dest 'wan'

Looking at your configuration, the interfaces 'wan' and 'wan6' are bound to the 'eth1' adapter. They are not bridged together, so they create two distinct networks, one for IPv4 and one for IPv6 traffic. The 'wwan' interface is bound to an IPv4 network coming through (or hosted by) the 'optimumwifi' AP. All three interfaces are governed by the firewall rules of the 'wan' firewall zone.

Traffic forwarding for the 'wan' zone is restricted by default (the zone's configuration). You also have a 'forwarding' section defined between 'vpn0' and 'wan' zones. This configuration allows traffic in the OpenVPN virtual network's interfaces to be forwarded into the interfaces belonging to the 'wan' zone.

However, you do not seem to have any rules governing how traffic is routed between the individual interfaces of the 'wan' zone itself. How does the router know which interface to pick when traffic wants to go out to the Internet? Bear in mind that all of the interfaces belong to different networks with different IPv4 and IPv6 ranges. Packets are allowed to be forwarded to any of the three interfaces of the 'wan' zone from the 'vpn0' zone, but how do they know where to go from there?

You could examine the routing configuration by issuing the 'route' command in an SSH session. There is also some nice documentation regarding iptables behavior in https://wiki.openwrt.org/inbox/doc/ipta … d_firewall with examples on how to interpret the routing table, if you are unsure about that.

Another thing you could try is creating an individual zone for 'wwan', and essentially duplicate the configuration that is currently in 'wan', but so that only the 'wwan' interface belongs to this zone. Then configure forwarding between 'vpn0' and 'wwan' zone. After this configuration, you can test if your OpenVPN clients can reach the Internet? It might not be exactly what you want, depending on how 'wan' and 'wan6' are supposed to be used, but I think it might be a step in the correct direction?

The UCI configuration system is intended to simplify the process of configuring the underlying components (netfilter, dnsmasq etc.) which actually make stuff work. As a side-effect, the UCI config needs to be written in such a manner that the parser can create understandable, straightforward configurations for the underlying components. From this perspective, the more verbose your UCI config is, the easier it is to get things right

I followed your recommendations and removed the 'wwan' interface from the 'wan' zone. The 'wan' and 'wan6' interfaces are irrelevant to me, I would be fine ignoring them completely (or removing them if it makes it easier to diagnose). I have nothing plugged into the wan port of the router, and don't plan on using the wired wan connections at all.

Here are some of the updates I made to my config files. I did not repeat the files in their entirety, only the additions or changes that have been made to each file.

/etc/config/network

# added ifname 
config interface 'wwan'   
    option ifname 'wlan0'
    option proto 'dhcp'

# added new route option to try and force a route to the wifi gateway
config route   
    option interface 'vpn0'
    option gateway '25.224.0.1'
    option target '0.0.0.0'
    option netmask '0.0.0.0'

/etc/config/firewall

# removed 'wwan' from 'wan' zone
config zone
    option name 'wan'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option network 'wan wan6'
    option masq '1'
    option mtu_fix '1'

config zone 'vpn'
    option name 'vpn'
    option network 'vpn0'
    option input 'ACCEPT'
    option forward 'REJECT'
    option output 'ACCEPT'
    option masq '1'

# created new zone just for 'wwan'
config zone 'wwan'
    option name 'wwan'
    option network 'wwan'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'
    option mtu_fix '1'

# updated forwarding to reference 'wwan' 
config forwarding 'vpn_forwarding_wwan'
    option src 'vpn'
    option dest 'wwan'

# added new rule for routing from 'vpn' to 'wwan'
config rule
    option src 'vpn'
    option dest 'wwan'
    option target 'ACCEPT'
    option name 'vpn_to_wwan'
    option proto 'all'

Those changes have produced the following routing table.

routing table

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         25.224.0.1      0.0.0.0         UG    0      0        0 wlan0
10.0.0.0        10.0.0.2        255.255.255.0   UG    0      0        0 tun0
10.0.0.2        *               255.255.255.255 UH    0      0        0 tun0
25.224.0.0      *               255.248.0.0     U     0      0        0 wlan0
25.224.0.1      *               255.255.255.255 UH    0      0        0 wlan0
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan

Still no success. I feel like my routing changes in /etc/config/network should have added another entry to the routing table like this:

default         25.224.0.1      0.0.0.0         UG    0      0        0 tun0

But no such luck. Admittedly, I am a novice at this type of configuration, and I'm still learning how to use the tools. Should I be creating entries with iptables to perform the routing? Do I need relayd? I feel like this would be a common task (routing vpn traffic to wifi wan), but I have found practically no resources online to help with this. Most of the discussions are about the inverse process (routing wifi AP traffic to vpn), or about routing from the physical lan to the wifi wan.

Thanks for your help so far...this will likely be my weekend project.

Quick update, I tried to force a routing entry by using the route command as follows, but I get an error:

/etc/config$ route add default netmask 0.0.0.0 gw 25.224.0.1 dev tun0
route: SIOCADDRT: Network is unreachable

So it seems there is no route possible from the vpn to the wifi wan, but I don't understand why...I've hit the limits of my knowledge at this point. I will start educating myself some more, but if you have suggestions I'd appreciate them.

I think you will need to change at least the 'Allow-DHCP-Renew' rule so it uses the new 'wwan' zone as the source. Otherwise your wi-fi interface will not receive the DHCP-Renew message sent by the DHCP server. Afterall, it is your wi-if interface that is acting as the gateway to the outside.

In my opinion, you can remove the rule 'vpn_to_wwan'. The forwarding option above this rule does exactly the same thing, so no need to do things twice.

You can also remove the two following rules from the firewall:

config rule
    option src 'wan'
    option dest 'lan'
    option proto 'esp'
    option target 'ACCEPT'

config rule
    option src 'wan'
    option dest 'lan'
    option dest_port '500'
    option proto 'udp'
    option target 'ACCEPT'

These two rules are intended for IPSec traffic. Since you do not have such a service, you can remove them.

I think the new route option that you added to the '/etc/config/network' is unnecessary. I would remove it for now. The wireless interface is using DHCP, and thus receives a gateway from the DHCP server. This, in combination with the 'defaultroute' option that 'proto "dhcp"' has set to '1' (https://wiki.openwrt.org/doc/uci/network#protocol_dhcp) and the 'vpn_forwarding_wwan' firewall rule should be enough.

I think you can also remove the 'option type bridge' from the 'lan' interface in the network config. We are not bridging any interfaces together, so this just adds unnecessary overhead.

I would also remove the 'ifname' option from the 'wwan' entry in '/etc/config/network'. The '/etc/config/wireless' is already stating that the wireless interface should be bound to the 'wwan' interface. The reason why we do things like this is because the names of the wireless interfaces are sometimes unpredictable. The 'wwan' interface name in the network config is, however, a stable thing, so binding from the other direction is somewhat more reliable.

And yes, the nomenclature of interfaces and networks in OpenWRT is really confusing sometimes.

Let's do these changes, and then look at the 'route' command again. You can also run the following command on any of the PCs in the LAN network:

• For Unix/Linux, run 'ping -R -c 1 25.244.0.1'

• For Windows, run 'tracert 25.244.0.1'

This should show the route that packets heading to the gateway at the other end of the Wi-Fi link are taking. They should go through VPN tunnel '10.0.0.2' first, and then through the wi-fi link.

(Last edited by Antek on 2 Jun 2017, 20:16)

@Antek - I tried all of your suggestions, but no change. Most of the items you noted were things I added after my original post, trying to find something that would work. I reverted to my original config, and trimmed some of the extra things you noted as well.

My primary PC is a windows 10 box, and I tried a "tracert 25.224.0.1" from there, but it just times out without going a single hop. I then tried a "traceroute 25.224.0.1" from OpenWRT itself, and I get the same result. That confuses me, because the wifi interface has resolved a DHCP address properly, and if I tunnel into the router with SSH and use it as a SOCKS proxy, I can browse the web through the wifi connection without issue.

I'm really confused why the SSH SOCKS tunnel works, but nothing else seems to...

I'm trying to reduce the variables in the system now, and have removed the router from my main network. I now have a laptop connected directly to the router lan port (eth0), and that's it. Same results. Traceroute from both the PC and the router fail without making a single hop. But SOCKS proxy through SSH tunnel works fine.

I have no idea how the SSH system routes traffic though. I don't know how it's properly selecting the wifi wan as the connection to the internet. But it is at least proof that the wifi wan connection has properly resolved IP and DNS information, and can access the internet.

Another strange finding...DNS resolution with "nslookup" works on both the PC and the router. But I can't tell if the lookup is going over the lan interface (eth0) to the wifi wan, or if it is going through the OpenVPN connection (tun0).

Not a single hop? That's extremely strange. I understand you can login to the OpenWRT's SSH daemon from the same PC? Or do you need to open a OpenVPN connection to the router in order to do that? The trace should at least show the hop from your PC to the router.

You can check this from the OpenVPN config file. If you are pushing the 'redirect-route def1' (https://wiki.openwrt.org/doc/howto/vpn. … ng_traffic) to the client, then it should route all traffic through the tunnel. If you are not pushing this rule to the client, then it might go either way.

I'll see if I can replicate your setup in a test environment. Maybe that brings about fresh ideas.

I built a similar setup to yours, with the exception that the physical link over which my VPN runs is a Wi-Fi network, and the outside access is done through a DSL modem.

You can find the Before and After configurations from my Dropbox at <link removed>, as this issue was resolved.

If there's no corresponding file in After, it means that this file was not changed.

Interestingly, I only needed to add a forwarding rule from the VPN zone to WAN in order to make Internet available for the OpenVPN clients. Without this rule, the clients were able to access services in the router, but could not reach the Internet if OpenVPN client app was running.

In the Before and After folders, there are also logfiles from client's route and ping commands, and in the After folder, there's the OpenWRT server's routing table. The logs show that when the VPN connection is up on the client, traffic goes through an extra hoop to reach the destination.

Hopefully this offers you some insight into your situation

(Last edited by Antek on 5 Jun 2017, 07:00)

The output of this command is quite logical, once you get a hold of how the routing table works. The command says "Add a route so that packets belonging to 0.0.0.0/0 are routed to address 25.224.0.1 and then sent out through the 'tun0' interface".

When you think about it logically, it doesn't make sense. The tun0 device does not belong to the 25.224.0.0 -network. The wlan0 device does. But this default route (to wlan0) is already present in your routing table. So that is not the issue.

I resolved the issue yesterday. Turns out it was a local routing issue on the PCs, nothing wrong with the router config. The local PCs had the following route, to send all traffic through the OpenVPN connection:

Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0         10.0.0.0        10.0.0.6      21

The router was configured to use 10.0.0.0 as the gateway for the OpenVPN network, but part of the routes pushed to the clients remapped the gateway to 10.0.0.5 instead (not sure why OpenVPN does this). So I just changed the routing to the following:

Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0         10.0.0.5        10.0.0.6      21

And everything worked.

The router config from the original post, plus the first set of recommendations were enough to make it work. Thanks for your help, and helping me learn more about the system.

This might answer your question: https://serverfault.com/questions/74234 … -to-client

Glad you got it solved