OpenWrt Forum Archive

Topic: mwan3; multi-wan policy routing (general topic)

The content of this topic has been archived between 22 May 2013 and 6 May 2018. Unfortunately there are posts – most likely complete pages – missing.

kpv wrote:

However, mwan3 complains that vpn1/tun1 doesn't have a default route. I tried a separate "config route ..." in /etc/config/network, but it didn't seem to work either. Any suggestions?

Is the default route really absent, or is it a false postive?

Did you edit the openvpn config file as altuhovd did?

#push "redirect-gateway def1"
push "route 0.0.0.0 0.0.0.0 vpn_gateway 3"

(Last edited by Adze on 30 Mar 2015, 12:18)

Adze wrote:
altuhovd wrote:

2) But not working at router itself (can not ping any host, nslookup not working).
from router I can not ping 8.8.8.8, but can ping IPs in OpenVPN (LAN at office).

Probably because replies are not routed back over openvpn tunnel wink. If you ping from router, your router will create an ip packet based on main routing table. So if you ping 8.8.8.8, it will create an icmp packet with source 9.9.9.9 (ip address on interface eth0) and destination 8.8.8.8, which will be routed over OpenVPN tunnel. Please try "ping -I tun0 8.8.8.8" to confirm.

I'm watching (tcpdump) at OpenVPN tunnel and do not see any packets with target 8.8.8.8. So, packet is not goging to OpenVPN tunnel (with source 9.9.9.9).

What the difference between traffic from LAN and traffic from device's kernel?

from router = ping -I tun0 8.8.8.8 = is working.
from LAN PC = ping 8.8.8.8 = is working
from router = ping 8.8.8.8 = is not working.

Can I fix that with iptables -t mangle OUTPUT chain?
I want to mark outgoing (from device's kernel) packets/connections and route it with ip rule.

In the OUTPUT chain (mangle) already presents rules for mwan3_hook, but why the do not work for packets from device's kernel

Chain OUTPUT (policy ACCEPT 922K packets, 734M bytes)
 pkts bytes target     prot opt in     out     source               destination
1218K  829M mwan3_hook  all  --  *      *       0.0.0.0/0            0.0.0.0/0
1218K  829M mwan3_output_hook  all  --  *      *       0.0.0.0/0            0.0.0.0/0

(Last edited by altuhovd on 30 Mar 2015, 13:39)

Hi altuhovd,

You should not have to manual edit mwan3 tables... It should work. Is conntrack enabled for the openvpn zone? If you tcpdump, can you see which interface it does leave?

Adze wrote:

Hi altuhovd,

You should not have to manual edit mwan3 tables... It should work. Is conntrack enabled for the openvpn zone? If you tcpdump, can you see which interface it does leave?

Oh, sorry, you were right.
Packets going to OpenVPN tunnel with source 9.9.9.9 (ip on eth0).
But why? Lowest metric on default gateways?

Yup. You have to use NAT if necessairy..

(Last edited by Adze on 30 Mar 2015, 13:46)

I'm done! It's all working now! I will test switching between ovpn->wan-wan2

Thank you Adze!

For device's generated traffic we need NAT, lines in the Firewall - Custom Rules (/etc/firewall.user) do that job:

iptables -t nat -A postrouting_ovpn_rule -s 192.168.0.0/16 -j RETURN
iptables -t nat -A postrouting_ovpn_rule -j SNAT --to-source 192.168.70.1

And script /etc/hotplug.d/iface/16-mwan3-kill-sessions:

#!/bin/sh

case "$ACTION" in
       ifup)
        conntrack -F
        logger -t mwan3user "mwan3user $ACTION of $INTERFACE ($DEVICE)"
       ;;

       ifdown)
        conntrack -F
        logger -t mwan3user "mwan3user $ACTION of $INTERFACE ($DEVICE)"
       ;;
esac

exit 0

(Last edited by altuhovd on 31 Mar 2015, 10:47)

Adze wrote:
kpv wrote:

However, mwan3 complains that vpn1/tun1 doesn't have a default route. I tried a separate "config route ..." in /etc/config/network, but it didn't seem to work either. Any suggestions?

Is the default route really absent, or is it a false postive?

Did you edit the openvpn config file as altuhovd did?

#push "redirect-gateway def1"
push "route 0.0.0.0 0.0.0.0 vpn_gateway 3"

I'm trying to make this setup work by only making changes at my end (OpenWrt running the OpenVPN client), without assuming that I can make changes to the OpenVPN server (which in my usage scenario might be a 3rd party commercial service).

kpv wrote:
Adze wrote:

Is the default route really absent, or is it a false postive?

I'm trying to make this setup work by only making changes at my end (OpenWrt running the OpenVPN client), without assuming that I can make changes to the OpenVPN server (which in my usage scenario might be a 3rd party commercial service).

So the default route... is it actually there?

arfett wrote:
kpv wrote:
Adze wrote:

Is the default route really absent, or is it a false postive?

I'm trying to make this setup work by only making changes at my end (OpenWrt running the OpenVPN client), without assuming that I can make changes to the OpenVPN server (which in my usage scenario might be a 3rd party commercial service).

So the default route... is it actually there?

No, it wasn't there.

Note: I tried a "config route ... " statement in /etc/config/network but didn't give it much testing, as I am first trying to ensure that my general approach is correct.

Any ideas / suggestions ?

Hi kpv,

When you have an interface configured in network configuration with proto set to none, openwrt will not start this interface during boot and thus the static(s) for that interface will not be set. I think it will work if you manually UP the interface.

(Last edited by Adze on 31 Mar 2015, 19:41)

Hi Adze and thank you for mwan3

For now everything works fine when using as load balancing, but that's not my final goal here
I tried to configure it to do one thing. I have two network:

The first one is a simple internet connection than I connect to wan interface. As it's coming from my internet provider it give me
a IP: 192.168.2.0/24  // GW: 192.168.2.1  // DNS:192.168.2.1 by DHCP

The second one is a private network. It give also everything by DHCP: IP: 128.127.15.0/24 // GW: 128.127.15.1 //DNS: 172.26.101.1. This network is here to provide just a few "url" like "timing-data.aks"

So What I want to do is to force the DNS resolution of "timing-data.aks" with 172.26.101.1 DNS and show the page with the good network. All the others web access will be redirect to the internet connection.

After reading a lot of page here, I've seen "fovecifer" who wanted to do almost the same with a vpn but maybe not in DNS point of view.

1. He create an "ipset" for his particular url
As I've never configured network whitout GUI, I don't really know which file to modify with my ssh access and what to write in it.

2. I think I have to configure my DNSMasq to resolv timing-data.aks with the good DNS and write it into ipset
I think that everything as to be done in /etc/config/dhcp but I don't really know which line to add.

3. I think that here I have to configure mwan3 rules to transfer all the network to wan exept for my ipset to wan2.
This one, I think I understand how to type it  but I will see when I will succeed for 1 and 2.

Am I in the good direction to make my network working?

PS: sorry for my bad english

Hi darkdje,

What you are trying to do is pretty straightforward. First make sure you have the correct software versions running. You need dnsmasq with ipset support; ipset version 6.24 and mwan3 version 1.6-1 (or higher ofcourse). Make sure that you have a mwan3 rule configured that routes traffic towards 172.26.101.1 over correct wan.

You need to edit /etc/dnsmasq.conf and add the following lines.

#Lookup timing-data.aks at specific dns server
server=/timing-data.aks/172.26.101.1
#populate ipset timing-data with timing-data.aks resolv results 
ipset=/timing-data.aks/timing-data

After dnsmasq restart, you can use the ipset "timing-data" in your mwan3 rules. Good luck

(Last edited by Adze on 1 Apr 2015, 19:07)

It seems to work fine for the internet part. For the other one, I can't check before next weeks since I have no access to the network now. I'll let you know.

Thanks you very much Adze!

Another problem is DNAT.
It's not working.

I added an iptables rule (for transparent proxy):

Chain prerouting_rule (1 references)
 pkts bytes target     prot opt in     out     source               destination
   29  1508 DNAT       tcp  --  *      *       192.168.70.0/24      0.0.0.0/0            tcp dpt:80 to:192.168.29.5:3128

And I have no traffic on 192.168.29.5:3128 from 192.168.70.0/24

From tcpdump on br-lan interface:

15:58:16.158917 IP 192.168.70.200.21724 > 90.156.201.98.80: Flags [S], seq 3798717873, win 65535, options [mss 1460,nop,wscale 1,nop,nop,sackOK], length 0
15:58:16.159872 IP 90.156.201.98 > 192.168.70.200: ICMP host 90.156.201.98 unreachable, length 36

forwarding is allowed. I can telnet to 192.168.29.5:3128 from 192.168.70.200

Hi altohovd,

It is working; you are doing it wrong. Please read mwan3 wiki about privoxy.

(Last edited by Adze on 3 Apr 2015, 12:03)

Adze wrote:

Hi altohovd,

It is working; you are doing it wrong. Please read mwan3 wiki about privoxy.

I'm so ashamed, all written long ago, went to read

My solution is forward all tcp:80 traffic to OpenVPN tunnel (with squid transparent proxy on gateway):

Active rules:
source             destination        proto  src-port      dest-port     policy          hits
--------------------------------------------------------------------------------------------------
0.0.0.0/0          0.0.0.0/0          tcp    0:65535       80          ovpn_wan_wan2  

(Last edited by altuhovd on 3 Apr 2015, 12:16)

kpv wrote:
Adze wrote:

Is the default route really absent, or is it a false postive?

Did you edit the openvpn config file as altuhovd did?

#push "redirect-gateway def1"
push "route 0.0.0.0 0.0.0.0 vpn_gateway 3"

I'm trying to make this setup work by only making changes at my end (OpenWrt running the OpenVPN client), without assuming that I can make changes to the OpenVPN server (which in my usage scenario might be a 3rd party commercial service).

Hi kpv,

I ran into this problem just now as well, for the same reason (third party OpenVPN server pushes 'redirect-gateway def1', so mwan3 says "Could not find gateway for interface"). The routing entries for the OpenVPN interface when "def1" is enabled are:

0.0.0.0/1 via 10.0.0.1 
128.0.0.0/1 via 10.0.0.1 

... taken together obviously equivalent to a default route, but 'ip route list dev tun0 default' doesn't output anything.

According to the OpenVPN wiki there's no simple way to override when 'redirect-gateway def1' is pushed from the server.

A hack that works for me in mwan3 is to change the two places in /etc/hotplug.d/iface/15-mwan3 that currently read:

ip -4 route list dev $DEVICE default | head -1

To read:

ip -4 route list dev $DEVICE match 0.0.0.0/1 | head -1

... this prints the gateway both for OpenVPN 'def1' routes, and for default gateways. It's obviously a hack though.

It would be possible to make a function that checked the same gateway matches both 128.0.0.0/1 and 0.0.0.0/1, which would avoid any weird corner cases if someone routed 128.0.0.0/1 differently to 0.0.0.0/1 (is this likely?!)

Adze, please let me know if you'd like to see a patch for either of these possibilities (the hack, or the workaround function). Thanks very much for all your work on mwan3, btw. Finding that it exists was a massive relief!


Angus

(Last edited by projectgus on 14 Apr 2015, 23:25)

Hi Angus,

While your hack does work to let mwan3 think that there is a route, the routes 0.0.0.0/1 and 128.0.0.0/1 will be added to known networks. As a result all wan traffic will traverse over openvpn link, regardless of rules. To conclude, this will not work.

I have seen this comming up on other threads where i have been looking for solutions to my vpn problem but i am not sure if this will help me in the right path.

i want to use a seperate wifi instance to go over openvpn while the other regular two use my default internet.
can this be set-up with MWAN3?

Adze wrote:

While your hack does work to let mwan3 think that there is a route, the routes 0.0.0.0/1 and 128.0.0.0/1 will be added to known networks. As a result all wan traffic will traverse over openvpn link, regardless of rules. To conclude, this will not work.

Hi Adze,

Yes, of course. Sorry, I should have realised this last night before posting.

I think then that the thing to do is to just to add a hotplug hook before mwan3 that replaces the two routes with a single default route on ifup, and deletes them on ifdown. Still hacky but it should work OK. I'll see how I go.

Hmm whenever i try to install mwan3 on latest trunk (archer c5) my router becomes unusable no matter what i do and i have to TFTP restore it, is this a known issue?

This is a really great work. <3 to Adze and contributors. I always relied on http://213.136.13.52/mwan3_latest_all.ipk  that now it is not available anymore (maybe temporarily).

Does someone knows other locations/mirrors ?

pier4r wrote:

I always relied on http://213.136.13.52/mwan3_latest_all.ipk  that now it is not available anymore (maybe temporarily).

Server is back online. Crashed somehow... Please keep in mind that only version 1.4 is available from that server. For version 1.5 and up you need to compile it yourself.

Nice, thanks. Maybe we could write it on the wiki page? I didn't know it (i thought was the latest)

Suggestion: i don't know if github provides a bit of space for distribution of binaries, in the case github does not, what about a public dropbox folder o similar?