Take a backup of the configuration file and uninstall vpn-pbr
cp /etc/config/vpn-policy-routing /root/ ; service vpn-policy-routing stop ; opkg remove vpn-policy-routing
reboot and check again that tun0 comes up and is appearing in routing table with metric 30.
OK, the issue with my Mac was that once I stopped the VPN pbr, mwan3 entries took over and I had been experimenting with one last night that was clearly not working! Redirected it from tun0 tour to my balanced rule and the internet was back.
cli did not like the package removal so I have done it through luci instead. It has not gone and I have rebooted the router. I have re-enabled the VPN client on the router and tun0 is showing in the Load Balancing Status page.
Here is the table listing output:
root@OpenWrt:~# ip -4 ro list table all
default via 192.168.1.1 dev wan table 1 proto static metric 10
10.0.0.0/24 dev br-lan table 1 proto kernel scope link src 10.0.0.1
192.168.1.0/24 dev wan table 1 proto kernel scope link src 192.168.1.20
192.168.1.0/24 dev wan table 1 proto static scope link metric 10
default via 192.168.0.1 dev lan4 table 2 proto static metric 20
10.0.0.0/24 dev br-lan table 2 proto kernel scope link src 10.0.0.1
192.168.0.0/24 dev lan4 table 2 proto static scope link metric 20
10.0.0.0/24 dev br-lan table 3 proto kernel scope link src 10.0.0.1
10.8.0.0/24 dev tun0 table 3 proto kernel scope link src 10.8.0.6
default via 192.168.1.1 dev wan proto static metric 10
default via 192.168.0.1 dev lan4 proto static metric 20
10.0.0.0/24 dev br-lan proto kernel scope link src 10.0.0.1
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.6
192.168.0.0/24 dev lan4 proto static scope link metric 20
192.168.1.0/24 dev wan proto static scope link metric 10
broadcast 10.0.0.0 dev br-lan table local proto kernel scope link src 10.0.0.1
local 10.0.0.1 dev br-lan table local proto kernel scope host src 10.0.0.1
broadcast 10.0.0.255 dev br-lan table local proto kernel scope link src 10.0.0.1
broadcast 10.8.0.0 dev tun0 table local proto kernel scope link src 10.8.0.6
local 10.8.0.6 dev tun0 table local proto kernel scope host src 10.8.0.6
broadcast 10.8.0.255 dev tun0 table local proto kernel scope link src 10.8.0.6
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
broadcast 192.168.0.0 dev lan4 table local proto kernel scope link src 192.168.0.20
local 192.168.0.20 dev lan4 table local proto kernel scope host src 192.168.0.20
broadcast 192.168.0.255 dev lan4 table local proto kernel scope link src 192.168.0.20
broadcast 192.168.1.0 dev wan table local proto kernel scope link src 192.168.1.20
local 192.168.1.20 dev wan table local proto kernel scope host src 192.168.1.20
broadcast 192.168.1.255 dev wan table local proto kernel scope link src 192.168.1.20
root@OpenWrt:~#
I cannot see the metric listed for tun0
These are very wrong. Delete all of them first and then post:
uci export network; uci export mwan3; ip -4 ro list table all; ip -4 ru; ip -4 addr
Yes I think I know they are wrong. I was trying to learn how to use static routes and they are all disabled.
However I have now deleted them all. Here are the outputs:
root@OpenWrt:~# uci export network; uci export mwan3; ip -4 ro list table all; i
p -4 ru; ip -4 addr
package network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option packet_steering '1'
option ula_prefix 'fd33:1ec6:00a8::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option ipaddr '10.0.0.1'
option gateway '192.168.1.1'
config interface 'tun0'
option proto 'none'
option device 'tun0'
option metric '30'
config device
option type '8021q'
option ifname 'lan4'
option vid '1'
option name 'lan4.1'
option mtu '1500'
option mtu6 '1500'
config interface 'wan_free'
option proto 'static'
option device 'wan'
option ipaddr '192.168.1.20'
option netmask '255.255.255.0'
option gateway '192.168.1.1'
option metric '10'
list dns '8.8.8.8'
list dns '8.8.4.4'
config interface 'wan_sfr'
option proto 'static'
option device 'lan4'
option ipaddr '192.168.0.20'
option netmask '255.255.255.0'
option gateway '192.168.0.1'
option metric '20'
list dns '8.8.8.8'
list dns '8.8.4.4'
config device
option name 'tun0'
option mtu '1500'
option mtu6 '1500'
package mwan3
config policy 'tun0_Only'
list use_member 'tun0_m1_w1'
option last_resort 'default'
config policy 'load_bal_gjj'
option last_resort 'default'
list use_member 'wan_sfr_m1_w1'
list use_member 'wan_free_m1_w1'
config rule 'HiSenseTV2VPN'
option src_ip '10.0.0.40'
option proto 'all'
option sticky '0'
option use_policy 'load_bal_gjj'
config rule 'https'
option sticky '1'
option dest_port '443'
option proto 'tcp'
option use_policy 'load_bal_gjj'
config rule 'default_rule_v4'
option dest_ip '0.0.0.0/0'
option family 'ipv4'
option proto 'all'
option sticky '0'
option use_policy 'load_bal_gjj'
config rule 'default_rule_v6'
option dest_ip '::/0'
option family 'ipv6'
option proto 'all'
option sticky '0'
option use_policy 'load_bal_gjj'
config globals 'globals'
option mmx_mask '0x3F00'
config interface 'wan_free'
option enabled '1'
option initial_state 'online'
option family 'ipv4'
list track_ip '8.8.8.8'
list track_ip '8.8.4.4'
list track_ip '1.1.1.1'
option track_method 'ping'
option reliability '1'
option count '1'
option size '56'
option max_ttl '60'
option check_quality '0'
option timeout '4'
option failure_interval '5'
option recovery_interval '5'
option interval '5'
option down '3'
option up '3'
config interface 'wan_sfr'
option enabled '1'
option initial_state 'online'
option family 'ipv4'
list track_ip '8.8.8.8'
list track_ip '8.8.4.4'
list track_ip '1.1.1.1'
option track_method 'ping'
option reliability '1'
option count '1'
option size '56'
option max_ttl '60'
option check_quality '0'
option timeout '4'
option interval '5'
option failure_interval '5'
option recovery_interval '5'
option down '3'
option up '3'
config member 'wan_sfr_m1_w1'
option interface 'wan_sfr'
option metric '1'
option weight '1'
config member 'wan_free_m1_w1'
option interface 'wan_free'
option metric '1'
option weight '1'
config interface 'tun0'
option enabled '1'
option initial_state 'online'
option family 'ipv4'
list track_ip '1.1.1.1'
list track_ip '8.8.8.8'
list track_ip '9.9.9.9'
option track_method 'ping'
option reliability '1'
option count '1'
option size '56'
option max_ttl '60'
option check_quality '0'
option timeout '4'
option interval '10'
option failure_interval '5'
option recovery_interval '5'
option down '5'
option up '5'
config member 'tun0_m1_w1'
option metric '1'
option weight '1'
option interface 'tun0'
default via 192.168.1.1 dev wan table 1 proto static metric 10
10.0.0.0/24 dev br-lan table 1 proto kernel scope link src 10.0.0.1
192.168.1.0/24 dev wan table 1 proto static scope link metric 10
default via 192.168.0.1 dev lan4 table 2 proto static metric 20
10.0.0.0/24 dev br-lan table 2 proto kernel scope link src 10.0.0.1
192.168.0.0/24 dev lan4 table 2 proto static scope link metric 20
10.0.0.0/24 dev br-lan table 3 proto kernel scope link src 10.0.0.1
10.8.0.0/24 dev tun0 table 3 proto kernel scope link src 10.8.0.6
default via 192.168.1.1 dev wan proto static metric 10
default via 192.168.0.1 dev lan4 proto static metric 20
10.0.0.0/24 dev br-lan proto kernel scope link src 10.0.0.1
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.6
192.168.0.0/24 dev lan4 proto static scope link metric 20
192.168.1.0/24 dev wan proto static scope link metric 10
broadcast 10.0.0.0 dev br-lan table local proto kernel scope link src 10.0.0.1
local 10.0.0.1 dev br-lan table local proto kernel scope host src 10.0.0.1
broadcast 10.0.0.255 dev br-lan table local proto kernel scope link src 10.0.0.1
broadcast 10.8.0.0 dev tun0 table local proto kernel scope link src 10.8.0.6
local 10.8.0.6 dev tun0 table local proto kernel scope host src 10.8.0.6
broadcast 10.8.0.255 dev tun0 table local proto kernel scope link src 10.8.0.6
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
broadcast 192.168.0.0 dev lan4 table local proto kernel scope link src 192.168.0.20
local 192.168.0.20 dev lan4 table local proto kernel scope host src 192.168.0.20
broadcast 192.168.0.255 dev lan4 table local proto kernel scope link src 192.168.0.20
broadcast 192.168.1.0 dev wan table local proto kernel scope link src 192.168.1.20
local 192.168.1.20 dev wan table local proto kernel scope host src 192.168.1.20
broadcast 192.168.1.255 dev wan table local proto kernel scope link src 192.168.1.20
0: from all lookup local
1001: from all iif wan lookup 1
1002: from all iif lan4 lookup 2
1003: from all iif tun0 lookup 3
2001: from all fwmark 0x100/0x3f00 lookup 1
2002: from all fwmark 0x200/0x3f00 lookup 2
2003: from all fwmark 0x300/0x3f00 lookup 3
2061: from all fwmark 0x3d00/0x3f00 blackhole
2062: from all fwmark 0x3e00/0x3f00 unreachable
3001: from all fwmark 0x100/0x3f00 unreachable
3002: from all fwmark 0x200/0x3f00 unreachable
3003: from all fwmark 0x300/0x3f00 unreachable
32766: from all lookup main
32767: from all lookup default
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
3: lan4@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 192.168.0.20/24 brd 192.168.0.255 scope global lan4
valid_lft forever preferred_lft forever
7: wan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 192.168.1.20/24 brd 192.168.1.255 scope global wan
valid_lft forever preferred_lft forever
10: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 10.0.0.1/24 brd 10.0.0.255 scope global br-lan
valid_lft forever preferred_lft forever
13: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
inet 10.8.0.6/24 scope global tun0
valid_lft forever preferred_lft forever
root@OpenWrt:~#
Is the tunnel connected?
I am not sure how to test it?
I have written a rule that has a source address of 10.0.0.40 (iMac) and a destination address of 10.8.0.6 (VPN link address?) with only udp packets and the VPN connection is up but it is not connecting. The Policy defaults to the main routing table so I assume that if it cannot access the link address it defaults to the standard gateway which is why I am getting my ISP internet address and not the VPN address when I test what's my ip on google.
It is still showing error 16 in the Status : Load Balancing : Detail page and in Diagnostics, if I try to ping tun0 it still tells me there is no gateway set.
A bit strange though. Sometimes I get a 33.x.x.x address but then it changes to a 84.6.x.x address. The 33 I recognise as one of the addresses from my ISP, the 84.6.x.x I do not recognise at all.
PS. Just checked and it must just be an alternative server as it is an SFR address. So the two addresses are for wan_free (33.x.x.x) and wan_sfr (84.6.x.x). So the VPN tunnel is not working.
How is the gateway set?
OK it looks like I have discovered what is stopping it. Here is the main part of the ovpn config file:
client
dev tun
proto udp
remote 77.68.100.23 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
# ignore-unknown-option block-outside-dns
# block-outside-dns
verb 3
# pull-filter ignore "redirect-gateway"
# route no-exec
# route no-pull
I commented out the last two but it made no difference. However, as soon as I commented out the redirect-gateway command, my iMac accessed my VPN.
I am now going to try to set up a rule for the TV interface.
No that is not the solution. It seems that in taken the redirect gateway out, everything on the LAN is now going out over the VPN so the mwan3 rules are not doing anything (other than the load balancing but even then I am not sure that the VPN goes through load balancing.
First of all fix the format of the ovpn configuration file. (use preformatted text, the </> button)
Did you change the ovpn configuration file?
I don't think the pull-filter ignore was there.
If you make any changes to the configuration, state them here so we are all on the same page.
Some strange behaviour. I tried to test the interfaces to see if the load balancing was working and it stopped the VPN. It seems load balancing is not operating and restarting the interfaces affects the tun0 for some reason.
The pull-filter ignore "redirect-gateway" rule was not in the original config but it was needed for the openVPN pbr if I remember correctly. I will repost it as it does not appear to have shown the commenting properly. (Actually, the commenting is the pound sign # which acts as a bold trigger in the
standard window so I have now posted it in the reformatted text area).
client
dev tun
proto udp
remote 77.68.100.23 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
verb 3
# pull-filter ignore "redirect-gateway"
# route no-exec
# route no-pull
So with the above, it appears that some but not all items are going through the VPN with or without the mwan3 rules. The VPN appears to have selected wan_free to use and my computer and my portable are both connected over it. however other devices (both my and my wife's phones are not accessing the VPN but are still reading as if in France and I suspect it is because they are connecting through the wan_sfr link?
Even though tun0 is clearly connected at the moment, I am still getting error 16 and unable to ping tun0 as it says there is still not gateway. So what is going on (that is the verbalisation of my thoughts and not aimed as a question to you!)?
Geoff
We need to solve one problem at a time. And the first is to have the vpn properly up with a default route in the routing table. You can stop temporarily mwan3 if you think it is interfering.
Is the routing table correct?
ip -4 ro list table all
Hi again,
I wondered if naming the interface tun0 then pointing it at tun0 might be a problem so I have deleted that interface and rebuilt it as ovpn_wan_free. I have made the changes right through in mwan3 as well to replicate where we were.
I also uncommented the - pull-filter ignore "redirect-gateway" - line in the ovpn config file but as soon as I did that I lost the VPN completely so I have commented it back out again and now the VPN is working through the wan_free interface (I assume) on any device that connects over that interface.
So here is the current routing table detail which looks to have changed slightly but I cannot tell if it is right or wrong. I still cannot see any metric for tun0. Should I be able to? :
root@OpenWrt:~# ip -4 ro list table all
default via 192.168.1.1 dev wan table 1 proto static metric 10
10.0.0.0/24 dev br-lan table 1 proto kernel scope link src 10.0.0.1
77.68.100.23 via 192.168.1.1 dev wan table 1
192.168.1.0/24 dev wan table 1 proto static scope link metric 10
default via 192.168.0.1 dev lan4 table 2 proto static metric 20
10.0.0.0/24 dev br-lan table 2 proto kernel scope link src 10.0.0.1
192.168.0.0/24 dev lan4 table 2 proto static scope link metric 20
0.0.0.0/1 via 10.8.0.1 dev tun0 table 3
10.0.0.0/24 dev br-lan table 3 proto kernel scope link src 10.0.0.1
10.8.0.0/24 dev tun0 table 3 proto kernel scope link src 10.8.0.6
128.0.0.0/1 via 10.8.0.1 dev tun0 table 3
0.0.0.0/1 via 10.8.0.1 dev tun0
default via 192.168.1.1 dev wan proto static metric 10
default via 192.168.0.1 dev lan4 proto static metric 20
10.0.0.0/24 dev br-lan proto kernel scope link src 10.0.0.1
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.6
77.68.100.23 via 192.168.1.1 dev wan
128.0.0.0/1 via 10.8.0.1 dev tun0
192.168.0.0/24 dev lan4 proto static scope link metric 20
192.168.1.0/24 dev wan proto static scope link metric 10
broadcast 10.0.0.0 dev br-lan table local proto kernel scope link src 10.0.0.1
local 10.0.0.1 dev br-lan table local proto kernel scope host src 10.0.0.1
broadcast 10.0.0.255 dev br-lan table local proto kernel scope link src 10.0.0.1
broadcast 10.8.0.0 dev tun0 table local proto kernel scope link src 10.8.0.6
local 10.8.0.6 dev tun0 table local proto kernel scope host src 10.8.0.6
broadcast 10.8.0.255 dev tun0 table local proto kernel scope link src 10.8.0.6
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
broadcast 192.168.0.0 dev lan4 table local proto kernel scope link src 192.168.0.20
local 192.168.0.20 dev lan4 table local proto kernel scope host src 192.168.0.20
broadcast 192.168.0.255 dev lan4 table local proto kernel scope link src 192.168.0.20
broadcast 192.168.1.0 dev wan table local proto kernel scope link src 192.168.1.20
local 192.168.1.20 dev wan table local proto kernel scope host src 192.168.1.20
broadcast 192.168.1.255 dev wan table local proto kernel scope link src 192.168.1.20
root@OpenWrt:~#
Let's focus on the tunnel interface only. Disregard if it is lost or not.
At least now it is visible that the OpenVPN tunnel is creating 2 routes for the internet. However we don't want that.
- Remove comment from
pull-filter ignore "redirect-gateway" - Restart the tunnel
- Verify that there is no default gateway from tun0 in the routing table.
If all goes as planned proceed to: - Add a static route for default gateway:
config route
option target '0.0.0.0'
option metric '30'
option netmask '0.0.0.0'
option interface 'ovpn_wan_free' <- use whatever name it has, I would suggest something shorter though.
- Verify that there is default gateway
0.0.0.0/0from tun0 in the routing table with metric 30.
Also, I have as recommended stopped mwan3 and also disabled the second wan (wan_sfr) to simplify the fault finding. So currently everything is going over wan_free via the VPN.
OK.
ovpn file uncommented
cipher AES-256-CBC
verb 3
pull-filter ignore "redirect-gateway"
# route no-exec
# route no-pull
VPN tunnel stopped and started.
I assume the routing table is the one in Status : Routes? Here is the extract:
Active IPv4-Routes
Network Target IPv4 gateway Metric Table Protocol
wan_free 0.0.0.0/0 192.168.1.1 10 main static
lan 10.0.0.0/24 - 0 main kernel
(tun0) 10.8.0.0/24 - 0 main kernel
wan_free 192.168.1.0/24 - 10 main static
So tun0 has no default gateway.
I hope I have done the static route correct? (using long names is just easier for me to understand which bit I am adjusting)
I hope this is what you wanted to see?
ovpn_wan_free = tun0
Yes, you can enable back wan_sfr and start mwan3, after you remove default_rule_v6
You also need to add a rule to use tun0_Only policy, because there isn't any in the last post with the configuration.
OK wan_sfr enabled and my IP immediately changed to the 84.6.x.x range.
Removed the default v6 rule.
I have added a rule but this is where I am unclear. I have set the source address as 10.0.0.40 (the iMac) and tried 10.8.0.0, 10.8.0.1, 10.8.0.6 and 0.0.0.0/0 but none of them change the ip address on the machine.
Then I rebooted (with the 0.0.0.0/0 setting in place and it started to work. my iMac isa seeing the VPN, my iPhone and the TV are not.
Being called to dinner so I will try to set up the TV after eating and post a report here later.
Thanks for all your help and patience thus far.
This is not needed. Like the other rules, when there is no destination ip defined, the default is to match everything.