Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision | ||
| ru:doc:howto:mwan3 [2016/01/25 14:23] – [Mwan3 опции командной строки] tarasfrompir | ru:doc:howto:mwan3 [2019/12/10 05:57] – [Mwan3 архитектура] vaha | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ====== Использование нескольких WAN интерфейсов с пакетом mwan3 ====== | ||
| + | * Ссылки: | ||
| + | * [[https:// | ||
| + | * there is documentation available for policy routing on Linux, e.g. [[http:// | ||
| + | * source code on github.com: [[https:// | ||
| + | * source code on github.com: [[https:// | ||
| + | * old source code and/or development versions on github.com: [[https:// | ||
| + | |||
| + | * Связанные страницы: | ||
| + | * '' | ||
| + | |||
| + | ===== Последний релиз: ===== | ||
| + | |||
| + | Пакет mwan3 юыл обновлен 2015-12-17 и находится: | ||
| + | |||
| + | * mwan3_1.4-25_all.ipk (for OpenWrt 12.09 " | ||
| + | * mwan3_1.5-10_all.ipk (for OpenWrt 14.07 " | ||
| + | * mwan3_1.6-2_all.ipk (for OpenWrt 15.05 "Chaos Calmer" | ||
| + | * mwan3_2.0-1_all.ipk (for OpenWrt trunk only) скачать здесь https:// | ||
| + | * luci-app-mwan3_1.3-5_all.ipk (for OpenWrt 14.07 " | ||
| + | * luci-app-mwan3_1.4-3_all.ipk (for OpenWrt 15.05 "Chaos Calmer" | ||
| + | * luci-app-mwan3_1.4-4_all.ipk (for OpenWrt trunk only) скачать здесь https:// | ||
| + | |||
| + | См. процедуру загрузки и настройки ниже. | ||
| + | |||
| + | ===== Описание ===== | ||
| + | |||
| + | ==== Возможности ==== | ||
| + | |||
| + | Пакет '' | ||
| + | * балансировка исходящего WAN-траффика через несколько WAN интерфейсов с возможностью задать им разные весовые коэффициенты | ||
| + | * мониторинг каждого WAN соединения при помощи ping тестов с возможностью при падении одного WAN интерфейса автоматически перенаправить траффик через другой интерфейс | ||
| + | * воможность задать свои правила для каждого из WAN интерфейсов на основе IP и порта источника(source) и получателя (destination) и типе IP протокола | ||
| + | * работу со всем этим через веб интерфейс LuCI | ||
| + | * до 250 физических и/или логических WAN интерфейсов | ||
| + | |||
| + | ==== Авторы ==== | ||
| + | |||
| + | * Форумчанин Adze написал mwan3 | ||
| + | * Форумчанин Arfett написал the LuCI web interface | ||
| + | |||
| + | Огромное им человеческое СПАСИБО!!! | ||
| + | |||
| + | |||
| + | ==== Зачем использовать mwan3? ==== | ||
| + | |||
| + | * Если Вы используете несколько интернет соединений и хотите их соединить в один поток а также контролировать весь трафик Ваших соединений. | ||
| + | * Mwan3 может иметь заголовки для определения уровня интерфейса в качестве главного или запасного канала, | ||
| + | * Mwan3 uses netfilter mark mask to be compatible with other packages (such as OpenVPN, PPTP VPN, QoS-script, Tunnels, etc) as you can configure traffic to use the default routing table. | ||
| + | * Mwan3 может сбалансировать Ваш трафик через роутер в котором установлен Openwrt | ||
| + | |||
| + | ==== Как mwan3 производит баллансировку трафика ==== | ||
| + | |||
| + | * mwan3 реализует обычную для Linux политику балансирования трафика через несколько WAN, когда балансировка базируется на per-IP connection основе и это not channel-bonding, | ||
| + | * Такая балансировка нагрузки поможет ускорить несколько отдельных загрузок или трафик, | ||
| + | ==== Mwan3 архитектура ==== | ||
| + | |||
| + | * Mwan3 запускается событиями hotplug. Когда появляется интерфейс, | ||
| + | * Как только все маршруты и правила установлены, | ||
| + | * Сценарий мониторинга (mwan3track) выполняется в фоновом режиме, | ||
| + | ==== Mwan3 Роутинг==== | ||
| + | |||
| + | The following steps are taken to route a packet with mwan3 (version 2.0 or higher): | ||
| + | |||
| + | Every incoming packet (this includes router originated traffic) is handled by the iptables mwan3_hook. This hook takes 5 steps: | ||
| + | |||
| + | - Restore mark if previous set. If successful marked, goto step 5. | ||
| + | - Check if the packet arrives on a wan interface. If originated from a local connected ip network, then mark packet with iface_id 255 (default). If the packet is from another (non-local) network and arrives on wan interface, then mark it with iface_id. If successful marked, goto step 5. | ||
| + | - Check if packet destined for a known ip network (has a route for it other than default). If so then mark packet with iface_id 255 (default) and goto step 5. | ||
| + | - Check if packet source address is that of a wan interface. If so use that wan interface for routing regardless of user defined rules and mark packet with iface_id of corresponding wan. | ||
| + | - Apply user rules and mark with configured iface_id. If no match leave unmarked. | ||
| + | - If marked then save mark. | ||
| + | |||
| + | Remember that iptables only marks the packet, it does not make routing decisions. Next in line are the ip rules. In following order they are: | ||
| + | |||
| + | - Ip rules 1001 till 1250 are for wan interface 1 till 250 respectively. This rule says: If packet is incoming from wan interface use main routing table, regardless of mark. | ||
| + | - Ip rules 2001 till 2250 are for wan interface 1 till 250 respectively. This rule says: If packet is marked with iface_id [1-250], use the corresponding wan interface routing table. | ||
| + | - Ip rule 2253 is a blackhole rule. This rule states: If packet is marked with iface_id 253 (blackhole), | ||
| + | - Ip rule 2254 is a blackhole/ | ||
| + | |||
| + | Next up are the routing tables. These are really simple. There is just the standard main routing table and one routing table containing one gateway for each wan interface. Route table 1 for the first wan, route table 2 for the second and so on. Hopes this make troubleshooting easier. | ||
| + | ==== Mwan3 and IPv6 ==== | ||
| + | |||
| + | It is ok to have ipv6 and mwan3 running on the same router. Up until version 2.0 ipv6 is ignored by mwan3. Ipv6 routing is done without intervention of any mwan3 rule/route. (Source: Adze's post at https:// | ||
| + | |||
| + | ==== Mwan3 опции командной строки ==== | ||
| + | |||
| + | Здесь описаны некоторые cli команды для выяснения проблем или просмотра статуса Ваших соединений: | ||
| + | |||
| + | < | ||
| + | root@OpenWrt: | ||
| + | Syntax: mwan3 [command] | ||
| + | |||
| + | Присутствующие комманды: | ||
| + | start | ||
| + | stop Выгрузка правил для iptables , ip правил и ip маршрутов | ||
| + | restart | ||
| + | ifup < | ||
| + | ifdown < | ||
| + | interfaces | ||
| + | policies | ||
| + | connected Показать существующие подключенные соединения | ||
| + | rules | ||
| + | status | ||
| + | </ | ||
| + | |||
| + | * Пример: | ||
| + | |||
| + | < | ||
| + | root@OpenWrt: | ||
| + | Interface status: | ||
| + | Interface wan is online (tracking active) | ||
| + | Interface wan2 is online (tracking active) | ||
| + | </ | ||
| + | |||
| + | ===== Требования ===== | ||
| + | |||
| + | ==== версии OpenWrt ==== | ||
| + | |||
| + | * OpenWrt 12.09 или версии старше | ||
| + | |||
| + | ==== Оборудование ==== | ||
| + | |||
| + | Any router configured with multiple WAN interfaces running OpenWrt 12.09 or later should work. Just pick a device with good OpenWrt support, preferably one with VLAN support for the additional interface flexibility VLAN support provides. | ||
| + | |||
| + | At least three interfaces need to exist for the minimal configuration: | ||
| + | |||
| + | * As examples, the following specific devices are working well with mwan3: | ||
| + | * A TP-LINK TL-WR1043ND hardware version 1.10 router (ar71xx platform) ([[toh/ | ||
| + | * A TP-LINK TL-WDR3600 router (ar71xx platform) ([[toh/ | ||
| + | * A openwrt 12.09 mips metarouter over a mikrotik r493g routeros 6.27 ([[docs: | ||
| + | * A NetGear WNDR3800 router (ar71xx platform) ([[toh/ | ||
| + | |||
| + | ==== Зависимости пакетов ==== | ||
| + | |||
| + | * The following packages are required, but they should be installed automatically if missing when mwan3 is installed so there is no need to manually install them beforehand | ||
| + | * libc, ip, iptables, iptables-mod-conntrack-extra, | ||
| + | |||
| + | ==== Конфликты пакетов ==== | ||
| + | |||
| + | * Ensure no other multiple WAN package is installed such as '' | ||
| + | |||
| + | ==== Test external DNS/ | ||
| + | |||
| + | * Users in the forum have reported problems with DNS resolution or being unable to send e-mail after implementing WAN load-balancing or failover using mwan3 | ||
| + | * The usual cause is they are using the DNS servers or a mail (SMTP/ | ||
| + | * Option 1: Before implementing any multiple WAN configuration, | ||
| + | * Option 2: Change settings to switch to using servers that are known to be accessible from anywhere | ||
| + | * For DNS servers, using Google Public DNS (at IPs 8.8.8.8 and 8.8.4.4) is a good choice | ||
| + | * Option 3: Create user rules for traffic destined to " | ||
| + | |||
| + | ===== Пре-конфигурация ===== | ||
| + | |||
| + | до установки рекомендуется провести пре-конфигурацию и тестирование ваших соединений. Это не обязательно, | ||
| + | |||
| + | Сперва Вы должны открыть несколько WAN интерфейсов и проверить их работоспособность. Это облегчит Ваши действия после установки даного пакета. Больше информации Вы сможете прочитать сдесь позже после дополнения даной статьи.. | ||
| + | |||
| + | ==== Первый WAN интерфейс (wan) ==== | ||
| + | |||
| + | The mwan3 default configuration file assumes two WAN interfaces named " | ||
| + | ==== Второй WAN интерфейс (wan2) ==== | ||
| + | |||
| + | Самый простой способ создать несколько интерфейсов WAN использовать VLAN маршрутизатора. Это позволяет каждому отдельному порту назначить его собственный отдельный интерфейс в OpenWrt. | ||
| + | |||
| + | * Here is the basic example procedure to create a new VLAN and assign a single port to it so as to create a second WAN interface | ||
| + | * go to Network > Switch | ||
| + | * remove a single physical port from the default VLAN 1; this port will be the new physical WAN2 port | ||
| + | * assign the port to a new VLAN number such as 3 and set the port to be untagged in this single new VLAN and off in all other VLANs (note this VLAN, as with all VLANs, should also include the built-in CPU port as a tagged member, so there are a total of two ports in the new VLAN) | ||
| + | * reboot the router for the new VLAN interface to become active (e.g. eth0.3 for what will be the new WAN2 interface) | ||
| + | * Go to Network > Interfaces and add a new interface name for the new eth0.x adapter | ||
| + | * name the new VLAN physical interface " | ||
| + | * configure the new wan2 interface IP details | ||
| + | * assign the new wan2 interface to the wan firewall zone | ||
| + | |||
| + | Create additional WAN interfaces (e.g. wan3, ...) as desired if more than two WAN connections will be used. More information on howto create interfaces can be found at https:// | ||
| + | |||
| + | ==== The routable loopback (self) ==== | ||
| + | |||
| + | On routers with just one wan interface (and one default route), there is no issue on which source address to use for new initiated sessions. But with two or more wan interfaces you may wish to have control over this. Up until version 2.0, mwan3 did not respect the already set source address of router originated packets. Packets were load-balanced regardless of source address, based on configured user rules. | ||
| + | |||
| + | As of version 2.0 mwan3 does respect the already set source address. The advantage of this is that an applications can have control over which wan interface to use. The downside of this is that when an application does not specify which source address to use (most of the time) the kernel will pick a source address based on the routing table. In practice this means the default route with the lowest metric is used to determine which source address to use. So if you don't configure a routable loopback address with corresponding more preferred default route, all traffic originating from the router itself will leave the primary wan with the source address of that wan interface, regardless of configured user mwan3 rules. | ||
| + | |||
| + | This however only effects router initiated traffic. Traffic from LAN clients will always be balanced based on mwan3 configured rules even if no routable loopback address is configured. | ||
| + | |||
| + | Configuring a routable loopback with default route is easy: | ||
| + | |||
| + | < | ||
| + | config interface ' | ||
| + | option ifname ' | ||
| + | option proto ' | ||
| + | option ipaddr ' | ||
| + | option netmask ' | ||
| + | option gateway ' | ||
| + | </ | ||
| + | |||
| + | After this all traffic originating from router itself (if no more specific route is found) will have source address of 192.168.1.1 (before NAT). Extra advantage is that configuring mwan3 rules for router only traffic is much easier. | ||
| + | ==== Prepare and the check the default routing table for the wan interfaces ==== | ||
| + | |||
| + | * :!: **IMPORTANT: | ||
| + | |||
| + | === Step 1: Configure a different metric for each WAN interface === | ||
| + | |||
| + | * :!: **IMPORTANT: | ||
| + | * You must configure each WAN interface with a **different** routing metric. This metric will only have an effect on the default routing table, not on the mwan3 routing tables. | ||
| + | * The default (primary) WAN interface should have the lowest metric (e.g. 10) and each additional WAN interface a higher metric (e.g. 20, 30, etc.). Values are not important, but should always be unique. | ||
| + | * Every WAN interface should have a default gateway configured. | ||
| + | |||
| + | Note: PPPoE connections only show the "Use gateway metric" | ||
| + | |||
| + | === wan setting === | ||
| + | |||
| + | wan is the default wan interface in this example, and so will get a metric of 10. | ||
| + | |||
| + | * Network > Interfaces | ||
| + | * wan > Edit | ||
| + | * Advanced Settings | ||
| + | * Use default gateway: enabled | ||
| + | * Use gateway metric: 10 | ||
| + | * Save & Apply | ||
| + | |||
| + | === wan2 setting === | ||
| + | |||
| + | wan2 is the second wan interface in this example, and so will get the a metric of 20. | ||
| + | |||
| + | * Network > Interfaces | ||
| + | * wan2 > Edit | ||
| + | * Advanced Settings | ||
| + | * Use default gateway: enabled | ||
| + | * Use gateway metric: 20 | ||
| + | * Save & Apply | ||
| + | |||
| + | === Verify the routing table === | ||
| + | |||
| + | If configured correctly, you should have a default gateway (the lines with a target address of 0.0.0.0/0) with a unique metric set for each WAN interface. For example: | ||
| + | |||
| + | < | ||
| + | default via 10.0.3.2 dev eth1 proto static | ||
| + | default via 10.0.4.2 dev eth2 proto static | ||
| + | </ | ||
| + | |||
| + | * :!: **IMPORTANT: | ||
| + | |||
| + | === Troubleshooting === | ||
| + | |||
| + | == Interfaces are missing a metric value == | ||
| + | |||
| + | * There was a report of some wireless interfaces missing a metric value and a gateway. The mwan3 syslog message error was " | ||
| + | * the fix is to add manual static routes -- see the forum thread at [[https:// | ||
| + | ==== Verify outbound traffic on each WAN interface ==== | ||
| + | |||
| + | Check that each WAN interfaces works by trying to ping www.google.com out from each interface. Ensure all interfaces are correctly sending and receiving traffic before proceeding. | ||
| + | |||
| + | === Проверка первого интернет (first WAN) соединения === | ||
| + | |||
| + | * wan в данном случае является интерфейсом eth0.1 : | ||
| + | |||
| + | < | ||
| + | root@openwrt: | ||
| + | PING www.google.com (209.85.148.103): | ||
| + | 64 bytes from 209.85.148.103: | ||
| + | |||
| + | --- www.google.com ping statistics --- | ||
| + | 1 packets transmitted, | ||
| + | round-trip min/avg/max = 19.637/ | ||
| + | </ | ||
| + | |||
| + | * Убедитесь что пинг проходит по этому интерфейсу ("1 packets transmitted, | ||
| + | |||
| + | === Проверка wan2 соединения === | ||
| + | |||
| + | * wan2 в данном случае является интерфейсом eth0.2 : | ||
| + | |||
| + | < | ||
| + | root@openwrt: | ||
| + | PING www.google.com (209.85.148.99): | ||
| + | 64 bytes from 209.85.148.99: | ||
| + | |||
| + | --- www.google.com ping statistics --- | ||
| + | 1 packets transmitted, | ||
| + | round-trip min/avg/max = 25.552/ | ||
| + | </ | ||
| + | |||
| + | * Ensure the single ping is successful on this interface ("1 packets transmitted, | ||
| + | |||
| + | === Проверка всех остальных WAN соединений === | ||
| + | |||
| + | * Проведите проверку всех остальных WAN соединений на предмет работоспособности | ||
| + | ===== Ensure the CONNTRACK module is enabled in OpenWrt ===== | ||
| + | |||
| + | mwan3 requires that the CONNTRACK module is enabled and active on its WAN interfaces. | ||
| + | |||
| + | * If the interfaces are in the " | ||
| + | * If masquerading/ | ||
| + | |||
| + | < | ||
| + | option ' | ||
| + | </ | ||
| + | |||
| + | * Reboot after making this change | ||
| + | * For more information, | ||
| + | |||
| + | ===== Ручная загрузка пакетов ===== | ||
| + | |||
| + | This step is only **required** for OpenWrt 12.09. In OpenWrt 14.07 " | ||
| + | |||
| + | Adze and Arfett keep the OpenWrt package repositories up to date and you are more likely to download the recommended latest " | ||
| + | |||
| + | * [[https:// | ||
| + | * [[https:// | ||
| + | |||
| + | Рекомендованый метод загрузки заключается в подключении к роутеру посредством telnet или SSH и загрузки пакетов в директорию /tmp. | ||
| + | |||
| + | * Здесь описан пример команд для роутера посредством telnet или SSH и загрузки пакетов в директорию /tmp через команду wget для загрузки пакетов из интернета. | ||
| + | |||
| + | для версии 1.4 | ||
| + | < | ||
| + | root@OpenWrt: | ||
| + | root@OpenWrt:/ | ||
| + | root@OpenWrt:/ | ||
| + | root@OpenWrt:/ | ||
| + | root@OpenWrt:/ | ||
| + | </ | ||
| + | |||
| + | или для версии 2.0 | ||
| + | < | ||
| + | root@OpenWrt: | ||
| + | root@OpenWrt:/ | ||
| + | root@OpenWrt:/ | ||
| + | </ | ||
| + | |||
| + | ===== Установка ===== | ||
| + | |||
| + | ==== OpenWrt 14.07 and later ==== | ||
| + | |||
| + | * В этом методе описано использование mwan3 packages из стандартного репозитория OpenWrt | ||
| + | |||
| + | === Метод использующий веб интерфейс LuCi === | ||
| + | |||
| + | * Перейдите System > Software | ||
| + | * нажмите " | ||
| + | * In the " | ||
| + | |||
| + | === SSH method === | ||
| + | |||
| + | < | ||
| + | # обновите список пакетов для подготовки их к загрузке | ||
| + | opkg update | ||
| + | |||
| + | # сделайте back up текущей конфигурации mwan3 в случае не правильного сохранения их автоматически | ||
| + | cp -a / | ||
| + | |||
| + | # установите luci-app-mwan3, | ||
| + | opkg install luci-app-mwan3 | ||
| + | </ | ||
| + | |||
| + | ==== OpenWrt 12.09 и версии старше ==== | ||
| + | |||
| + | * Таким способом Вы можете вручную установить пакет mwan3 а также для версий старших от 12.09. (Смотрите ниже) | ||
| + | |||
| + | < | ||
| + | cd /tmp | ||
| + | |||
| + | # обновите список пакетов для подготовки их к загрузке | ||
| + | opkg update | ||
| + | |||
| + | # сделайте back up текущей конфигурации mwan3 в случае не правильного сохранения их автоматически | ||
| + | cp -a / | ||
| + | |||
| + | # установите mwan3 и все необходимые зависимости | ||
| + | opkg install mwan3_*.ipk | ||
| + | |||
| + | # установите luci-app-mwan3 | ||
| + | opkg install luci-app-mwan3_*.ipk | ||
| + | </ | ||
| + | |||
| + | |||
| + | ==== Перезагрузите роутер через веб интерфес LuCI или другим доступным методом если это необходимо ==== | ||
| + | |||
| + | To ensure the new menu item for mwan3 appears, restart the web server hosting the LuCI interface (or just reboot the router). | ||
| + | |||
| + | * Перейдите System > Startup | ||
| + | * нажмите кнопку " | ||
| + | * Войдите по новой в веб интерфейс LuCi | ||
| + | |||
| + | В меню веб интерфейса LuCi должна появится новая запись " | ||
| + | |||
| + | ==== Обновление ==== | ||
| + | |||
| + | Обновление производится только установкой пакетов со старшими версиями. FIXME | ||
| + | |||
| + | * Install mwan3 as per above, in the same way as in a new installation | ||
| + | * The configuration file / | ||
| + | * Manually update the new version of / | ||
| + | * Restart mwan3 | ||
| + | * Check its status in LuCI or from the command line (see below) to confirm all expected interfaces are up and testing OK | ||
| + | |||
| + | ===== MWAN3 configuration ===== | ||
| + | |||
| + | A mwan3 configuration consists of four section elements, namely: | ||
| + | |||
| + | * interface | ||
| + | * member | ||
| + | * policy | ||
| + | * rule | ||
| + | |||
| + | ==== Interface configuration ==== | ||
| + | |||
| + | For each wan interface configure an interface section and define how each WAN interface is tested for up/down status. Each interface section must have a name that corresponds with the interface name in your network config. The settings are described below: | ||
| + | |||
| + | ^ Name ^ Type ^ Required ^ Default ^ Description ^ | ||
| + | | '' | ||
| + | | '' | ||
| + | | '' | ||
| + | | '' | ||
| + | | '' | ||
| + | | '' | ||
| + | | '' | ||
| + | | '' | ||
| + | | '' | ||
| + | |||
| + | The primary reason to change the default settings is to shorten the time before an interface is failed-over (by reducing the ping interval and number of pings before the interface is down) or lengthen the time to avoid a false link failure report. Please note that if you change the timeout value on low bandwidth interfaces (e.g. 3g) or busy interfaces, that false time-outs can occur. A timeout value of less then 2 seconds is not recommended. | ||
| + | |||
| + | A typical interface section looks like this: | ||
| + | < | ||
| + | config interface ' | ||
| + | option enabled ' | ||
| + | list track_ip ' | ||
| + | list track_ip ' | ||
| + | list track_ip ' | ||
| + | list track_ip ' | ||
| + | option reliability ' | ||
| + | option count ' | ||
| + | option timeout ' | ||
| + | option interval ' | ||
| + | option down ' | ||
| + | option up ' | ||
| + | </ | ||
| + | |||
| + | * The default configuration has wan2 disabled -- enable the wan2 interface in the mwan3 configuration | ||
| + | |||
| + | ==== Member configuration ==== | ||
| + | |||
| + | Each member represents an interface with a metric and a weight value. Members are referenced in policies to define a pool of interfaces with corresponding metric and load-balancing weight. Members can't be used for rules directly. The default settings are described below: | ||
| + | |||
| + | ^ Name ^ Type ^ Required ^ Default ^ Description ^ | ||
| + | | '' | ||
| + | | '' | ||
| + | | '' | ||
| + | |||
| + | A typical member section looks like this: | ||
| + | < | ||
| + | config ' | ||
| + | option ' | ||
| + | option ' | ||
| + | option ' | ||
| + | </ | ||
| + | |||
| + | * A working mwan3 config has at least 2 members configured. | ||
| + | |||
| + | ==== Policy configuration ==== | ||
| + | |||
| + | Policies define how traffic is routed through the different WAN interface(s). Every policy has to have one or more members assigned to it, which defines the policy' | ||
| + | |||
| + | If there is more than one member assigned to a policy, members within the policy with a lower metric have precedence over higher metric members. Members with the same metric will load-balance. Load-balancing members (with same metric) will distribute load based on assigned weights values. | ||
| + | |||
| + | A typical policy section looks like this: | ||
| + | < | ||
| + | config policy ' | ||
| + | list use_member ' | ||
| + | list use_member ' | ||
| + | </ | ||
| + | |||
| + | * If a policy is not referenced by a specific traffic rule, the policy will not do anything, so it is fine to leave unused policies in place in case they are desired in the future. | ||
| + | |||
| + | * If you have a traffic rule that matches a policy, but all the members (interfaces) for that policy are down, the exit strategy for that policy defaults to " | ||
| + | |||
| + | * A working mwan3 config has at least 1 policy configured. | ||
| + | |||
| + | * **Ensure no policy name is longer than 15 characters** | ||
| + | |||
| + | ==== Rule configuration ==== | ||
| + | |||
| + | A rule describes what traffic to match and what policy to assign for that traffic. These are the available options: | ||
| + | |||
| + | ^ Name ^ Type ^ Required ^ Default ^ Description ^ | ||
| + | | '' | ||
| + | | '' | ||
| + | | '' | ||
| + | | '' | ||
| + | | '' | ||
| + | | '' | ||
| + | | '' | ||
| + | | '' | ||
| + | | '' | ||
| + | |||
| + | * There are a number of sample rules defined to show how they work. Edit the rules as desired and delete all the rest of the default rules. | ||
| + | * The options ipset, sticky and timeout are only available in version 1.6 or higher. | ||
| + | |||
| + | A typical rule section looks like this: | ||
| + | < | ||
| + | config rule ' | ||
| + | option dest_ip ' | ||
| + | option use_policy ' | ||
| + | </ | ||
| + | |||
| + | === Stickiness and ipset === | ||
| + | |||
| + | Mwan3 version 1.6 has sticky and ipset support. Stickiness lets you route new session over the same wan interface as the previous session, as long as the time between the new and the previous session is shorter then the timeout value (default 600s). This can solve some problems with https sites, which don't allow a new source address within the same cookie/ | ||
| + | |||
| + | < | ||
| + | config rule ' | ||
| + | option sticky ‘1' | ||
| + | option timeout ‘300' | ||
| + | option ipset ' | ||
| + | option dest_port ' | ||
| + | option proto ' | ||
| + | option use_policy ' | ||
| + | </ | ||
| + | |||
| + | With sticky set to 1, this rule has now sticky enabled. When a packet for a new session matches this rule, its source ip address and interface mark are stored in an ipmark set with a timeout of 300 seconds (default 600). When packet for a second new session from the same lan host within the timeout period matches this rule, it will use the same wan interface as the first packet and the timeout counter is reset back to 300 again. | ||
| + | |||
| + | **Stickiness is on a per rule basis. With this example, all traffic from lan hosts will use the same wan interface for all youtube hosts, even if the source or destination ip address differs.** | ||
| + | |||
| + | The option ipset matches only destination ip addresses. This example will only work if your lan clients use the dnsmasq server as their one and only dns server. Mwan3 will create the ipset set for you if it does not exist already. For this to work you need to configure a rule in your / | ||
| + | |||
| + | < | ||
| + | ipset=/ | ||
| + | </ | ||
| + | |||
| + | * **Order is important.** Rules are evaluated in top-to-bottom order, with the first matching rule applying. The rule name is just descriptive and has no operational impact. If no match is found, routing lookup is done via the default routing table. | ||
| + | |||
| + | * A working mwan3 config has at least 1 rule configured. | ||
| + | |||
| + | ==== Example configuration ==== | ||
| + | |||
| + | < | ||
| + | config interface ' | ||
| + | option enabled ' | ||
| + | list track_ip ' | ||
| + | list track_ip ' | ||
| + | list track_ip ' | ||
| + | list track_ip ' | ||
| + | option reliability ' | ||
| + | option count ' | ||
| + | option timeout ' | ||
| + | option interval ' | ||
| + | option down ' | ||
| + | option up ' | ||
| + | |||
| + | config interface ' | ||
| + | option enabled ' | ||
| + | list track_ip ' | ||
| + | list track_ip ' | ||
| + | option reliability ' | ||
| + | option count ' | ||
| + | option timeout ' | ||
| + | option interval ' | ||
| + | option down ' | ||
| + | option up ' | ||
| + | |||
| + | config member ' | ||
| + | option interface ' | ||
| + | option metric ' | ||
| + | option weight ' | ||
| + | |||
| + | config member ' | ||
| + | option interface ' | ||
| + | option metric ' | ||
| + | option weight ' | ||
| + | |||
| + | config member ' | ||
| + | option interface ' | ||
| + | option metric ' | ||
| + | option weight ' | ||
| + | |||
| + | config member ' | ||
| + | option interface ' | ||
| + | option metric ' | ||
| + | option weight ' | ||
| + | |||
| + | config policy ' | ||
| + | list use_member ' | ||
| + | |||
| + | config policy ' | ||
| + | list use_member ' | ||
| + | |||
| + | config policy ' | ||
| + | list use_member ' | ||
| + | list use_member ' | ||
| + | |||
| + | config policy ' | ||
| + | list use_member ' | ||
| + | list use_member ' | ||
| + | |||
| + | config policy ' | ||
| + | list use_member ' | ||
| + | list use_member ' | ||
| + | |||
| + | config rule ' | ||
| + | option src_ip ' | ||
| + | option dest_port ' | ||
| + | option proto ' | ||
| + | option use_policy ' | ||
| + | |||
| + | config rule ' | ||
| + | option src_ip ' | ||
| + | option dest_port ' | ||
| + | option proto ' | ||
| + | option use_policy ' | ||
| + | |||
| + | config rule ' | ||
| + | option dest_ip ' | ||
| + | option use_policy ' | ||
| + | </ | ||
| + | |||
| + | ===== Further configuration tips ===== | ||
| + | |||
| + | ==== Configuring rules with large numbers of destination IPs or subnets using ipsets ==== | ||
| + | |||
| + | According to forum posts, there is a limit of around 300 specific destination IP addresses or subnets in mwan3 rules. Starting with Mwan3 version 1.6, ipset address groups can be used to bypass this limit. See the forum post at https:// | ||
| + | |||
| + | ==== OpenWrt hotplug script fix (OpenWrt 12.09 only) ==== | ||
| + | |||
| + | **This is for OpenWrt 12.09 only. The OpenWrt 14.07 hotplug scripts were substantially re-written and there is no evidence yet that the workaround below is needed on OpenWrt 14.07.** | ||
| + | |||
| + | * Forum member tcherenato found that adding a 1 second pause to the OpenWrt hotplug launch script helps prevent occasional segmentation faults when mwan3 performs hotplug operations. It is not known currently what the root issue is (or even if it is in mwan3 at all) but the change is recommended. | ||
| + | * see [[https:// | ||
| + | |||
| + | < | ||
| + | vi / | ||
| + | </ | ||
| + | |||
| + | * add "sleep 1" at the indicated location | ||
| + | |||
| + | < | ||
| + | ... | ||
| + | |||
| + | [ \! -z " | ||
| + | for script in $(ls / | ||
| + | [ -f $script ] && . $script | ||
| + | ## customization: | ||
| + | sleep 1 | ||
| + | ); done | ||
| + | } | ||
| + | </ | ||
| + | |||
| + | ===== Start mwan3 ===== | ||
| + | |||
| + | * Mwan3 automatically will start after each reboot but if a reboot has not occurred yet, the package can be manually started. | ||
| + | * see the " | ||
| + | |||
| + | ===== Preserve configuration files in an OpenWrt upgrade ===== | ||
| + | |||
| + | * the configuration file "/ | ||
| + | |||
| + | ===== Verification of basic operation ===== | ||
| + | |||
| + | ==== Check MWAN3 status in cli ==== | ||
| + | |||
| + | < | ||
| + | root@OpenWrt: | ||
| + | Interface status: | ||
| + | Interface wan is online (tracking active) | ||
| + | Interface wan2 is online (tracking active) | ||
| + | |||
| + | Policy balanced: | ||
| + | wan2 (40%) | ||
| + | wan (60%) | ||
| + | |||
| + | Policy wan1_only: | ||
| + | wan (100%) | ||
| + | |||
| + | Policy wan2_only: | ||
| + | wan2 (100%) | ||
| + | |||
| + | Policy wan2_wan: | ||
| + | wan2 (100%) | ||
| + | |||
| + | Policy wan_wan2: | ||
| + | wan (100%) | ||
| + | |||
| + | Local connected networks: | ||
| + | destination | ||
| + | ------------------------------------------------ | ||
| + | 127.0.0.0/ | ||
| + | 224.0.0.0/ | ||
| + | 192.168.1.0/ | ||
| + | 192.168.33.0/ | ||
| + | 213.154.232.8/ | ||
| + | |||
| + | Active rules: | ||
| + | source | ||
| + | --------------------------------------------------------------------------------------------------- | ||
| + | 0.0.0.0/ | ||
| + | 1.2.3.4 | ||
| + | 0.0.0.0/ | ||
| + | </ | ||
| + | |||
| + | ==== Check status in the MWAN3 overview page ==== | ||
| + | |||
| + | * Network > Load Balancing | ||
| + | * Overview | ||
| + | * MWAN3 Multi-WAN Interface Live Status | ||
| + | * this area should show all WAN interfaces as " | ||
| + | * MWAN3 Multi-WAN Interface Systemlog | ||
| + | * this area will show recent mwan3 log messages | ||
| + | |||
| + | ==== Check kernel routing tables ==== | ||
| + | |||
| + | * "ip route show table x" (where x is interface ID) should show a routing table specifically for that interface -- these tables are generated by mwan3 | ||
| + | |||
| + | ===== Verification of WAN interface load-balancing ===== | ||
| + | |||
| + | * Go to Network > Interfaces | ||
| + | * Send traffic from a test inside PC | ||
| + | * **Note: Load-balancing is connection-based (not channel bonding), so use multiple programs accessing different servers to generate traffic (such as two downloads, each from a separate site)** | ||
| + | * Observe the interface packet counts (counters are updated automatically) | ||
| + | * Verify that traffic is going out all expected WAN interfaces | ||
| + | |||
| + | ===== Verification of WAN interface failover ===== | ||
| + | |||
| + | ==== Test interface failover ==== | ||
| + | |||
| + | * Go to Network > Load Balancing > Overview | ||
| + | * Manually disconnect a WAN connection | ||
| + | * Wait for interface failure detection to happen -- the mwan3 status display should update | ||
| + | * Go to Network > Interfaces | ||
| + | * Send traffic from a test inside PC and observe the interface packet counts to ensure traffic is now going out the alternate WAN port (counters are updated automatically) | ||
| + | * Check that the external IP address has changed to the wan2 interface (such as by going to [[http:// | ||
| + | |||
| + | ==== Test interface fail-back ==== | ||
| + | |||
| + | * Restore the primary WAN connection | ||
| + | * Wait for detection that the WAN link is back up | ||
| + | * Repeat the same tests as above to ensure traffic has moved back to the now-working WAN interface | ||
| + | |||
| + | ===== Управление ===== | ||
| + | |||
| + | ==== Остановка mwan3 ==== | ||
| + | |||
| + | * Это отключит все ip правила маршруты и таблицы и возвратит назад все настройки для WAN интерфейса | ||
| + | * Это отключит все запущенные процессы по mwan3track | ||
| + | * Это нормально для остановки mwan3 без нарушений | ||
| + | |||
| + | === LuCI === | ||
| + | |||
| + | * Network > Load Balancing > Advanced > Diagnostics | ||
| + | * MWAN Service Control > нажмите "Stop MWAN" для остановки сервиса | ||
| + | |||
| + | === SSH === | ||
| + | |||
| + | < | ||
| + | mwan3 stop | ||
| + | </ | ||
| + | |||
| + | ==== Запуск mwan3 ==== | ||
| + | |||
| + | * Эта команда возвратит в нормальное состояние mwan3 со всеми его настройками | ||
| + | |||
| + | === LuCI === | ||
| + | |||
| + | * Network > Load Balancing > Advanced > Diagnostics | ||
| + | * MWAN Service Control > нажмите "Start MWAN" для запуска сервиса | ||
| + | |||
| + | === SSH === | ||
| + | |||
| + | < | ||
| + | mwan3 start | ||
| + | </ | ||
| + | |||
| + | ===== Monitoring mwan3 ===== | ||
| + | |||
| + | ==== Ручная проверка статуса ==== | ||
| + | |||
| + | * Network > Load Balancing | ||
| + | * Overview > MWAN Interface Live Status | ||
| + | * смотрите на все интерфесы у них должен быть " | ||
| + | ==== Automated status check ==== | ||
| + | |||
| + | It would be good to be able to automatically monitor interface status through mwan3 using a monitoring system (for example, OpenNMS or monit). | ||
| + | |||
| + | * FIXME | ||
| + | * How to do this? Ideas: | ||
| + | * send the local syslog to a remote monitoring station and do syslog scraping? | ||
| + | * do LuCI mwan3 web status screen scraping? need to log in somehow and the interface ONLINE string is actually generated using JavaScript so simple HTML string matching won't work... | ||
| + | |||
| + | ===== Alerting ===== | ||
| + | |||
| + | It would be good for mwan3 to send some kind of alert (e.g. e-mail, SNMP trap) if it detects a failed interface and performs a failover, or if it performs a fail-back. | ||
| + | |||
| + | If you install the luci-app-mwan3 (mwan3-luci) package it comes with / | ||
| + | ===== Controlling the mapping between internal IP sources and external IPs and interfaces ===== | ||
| + | |||
| + | When using multiple WAN connections, | ||
| + | |||
| + | ==== Step 1: Set mwan3 rules to send traffic out the right interface ==== | ||
| + | |||
| + | Add an mwan3 traffic rule that directs the specific desired source IP out the correct WAN interface. Rules are processed in top-down order, so be sure this specific rule is higher in the list (thus higher priority) than more general rules below that implement load-balancing or failover in the default case. | ||
| + | |||
| + | * Define a mwan3 interface member setting for the desired external interface (called " | ||
| + | * Create a mwan3 policy that only sends traffic out the external interface that has the desired external IP | ||
| + | |||
| + | < | ||
| + | config policy ' | ||
| + | list use_member ' | ||
| + | </ | ||
| + | |||
| + | * Create a mwan3 rule to have traffic from the internal IP 172.16.1.20 always go out the interface named wan3 using the policy " | ||
| + | |||
| + | < | ||
| + | config rule ' | ||
| + | option src_ip ' | ||
| + | option proto ' | ||
| + | option use_policy ' | ||
| + | </ | ||
| + | |||
| + | If the external WAN interface only has a single external IP, this is all that is needed. If the interface has multiple external IPs, both the next two steps are also needed. | ||
| + | |||
| + | ==== Step 2: Assign multiple external IP addresses selected interface (optional) ==== | ||
| + | |||
| + | * References | ||
| + | * 12.09: see [[https:// | ||
| + | |||
| + | This step is only needed if the desired external interface needs to have multiple external IP addresses assigned to it. | ||
| + | |||
| + | The specified external interface may have multiple IPs assigned to it. For OpenWrt 12.09, the preferred way to do this is using multiple interface definitions -- see reference. | ||
| + | |||
| + | * Network > Interfaces > Add new interface... | ||
| + | * Create Interface | ||
| + | * Name of the new interface: e.g. " | ||
| + | * Protocol of the new interface: Static address | ||
| + | * Create a bridge over multiple interfaces: do not enable | ||
| + | * Cover the following interface: select the physical interface that will have this (additional) IP address, e.g. eth0.2 | ||
| + | * Submit | ||
| + | |||
| + | * Network > Interfaces > Interfaces - (new interface name) | ||
| + | * Common Configuration > General Setup | ||
| + | * Protocol: Static address | ||
| + | * IPv4 address: (enter the desired additional external IP) | ||
| + | * IPv4 netmask: select or enter the correct netmask | ||
| + | * IPv4 gateway: (leave blank as the already defined default gateway will be used) | ||
| + | * IPv4 broadcast: (leave blank to auto-set this) | ||
| + | * Use custom DNS servers: (leave blank as DNS servers should be set through the WAN interface settings) | ||
| + | * Common Configuration > Firewall Settings | ||
| + | * Create / Assign firewall-zone: | ||
| + | * Save & Apply | ||
| + | |||
| + | ==== Step 3: Set OpenWrt NAT rules to send traffic out the right IP on the selected interface (optional) ==== | ||
| + | |||
| + | This step is only needed if the desired external interface has multiple external IP addresses assigned to it. | ||
| + | |||
| + | With multiple external IP addresses, we want to control which address is used when sending out traffic from particular servers. This is configured using a source NAT rule in OpenWrt. | ||
| + | |||
| + | Note that //both// a mwan3 rule to select the interface and an SNAT rule to select the specific IP on that interface are needed to correctly send traffic out a specific external IP. | ||
| + | |||
| + | * Network > Firewall > Traffic Rules | ||
| + | * Source NAT | ||
| + | * add a source NAT rule and edit details to specify the desired inside source IP and the desired external IP -- the following code block is an example of the resulting configuration in / | ||
| + | |||
| + | < | ||
| + | config redirect | ||
| + | option target ' | ||
| + | option name 'Mail server goes out 170.53.100.25' | ||
| + | option src ' | ||
| + | option dest ' | ||
| + | option src_ip ' | ||
| + | option src_dip ' | ||
| + | option proto ' | ||
| + | </ | ||
| + | |||
| + | ===== mwan3 and other programs ===== | ||
| + | |||
| + | ==== ddns-scripts ==== | ||
| + | |||
| + | * Related pages: | ||
| + | * [[docs: | ||
| + | |||
| + | === Example 1: Register the external IP of the active WAN interface === | ||
| + | |||
| + | This is the case where you want external clients using a DDNS name to automatically reconnect to the alternate WAN interface if the primary WAN interface fails. | ||
| + | |||
| + | * Configure ddns-scripts to use the " | ||
| + | |||
| + | === Example 2: Register the external IP of a specific WAN interface using the " | ||
| + | |||
| + | This is the case where you want each specific WAN interface to register its own DDNS name and the WAN interface in question has an external IP directly assigned to it. | ||
| + | |||
| + | * Configure ddns-scripts to use the " | ||
| + | |||
| + | === Example 3: Register the external IP of a specific WAN interface using the " | ||
| + | |||
| + | This is the case where you want each specific WAN interface to register its own DDNS name but the WAN interface in question is behind a NAT device and so does not directly have the correct external IP. | ||
| + | |||
| + | This is tricky when the WAN interface is not the default WAN interface, as ddns-scripts cannot be configured to use a specific interface to check its IP. | ||
| + | |||
| + | == Option 1: use a static route == | ||
| + | |||
| + | * Looking up the dyndns.org checkip.dyndns.org hostname shows there are four valid IPs for this DNS name | ||
| + | * Choose one of them and create a static route to that specific IP through the desired (non-default) WAN interface | ||
| + | * Do a traceroute to the IP to verify traffic is going out the desired WAN interface | ||
| + | * Change the ddns-scripts ip_url to be this specific IP, e.g. < | ||
| + | * Ensure any other web update ddns-scripts configurations don't use the hostname checkip.dyndns.org, | ||
| + | |||
| + | == Idea for option 2: use curl == | ||
| + | |||
| + | * ddns-scripts has the option of using curl instead of wget to check a web site to retrieve an IP address | ||
| + | * curl has an option to force it to use a specified interface | ||
| + | * This option would involve installing curl and modifying the ddns-scripts to specify on the curl command line which interface to use | ||
| + | * **UNTESTED** | ||
| + | |||
| + | ==== OpenVPN ==== | ||
| + | |||
| + | * Related pages: | ||
| + | * [[docs: | ||
| + | |||
| + | === Possible problems === | ||
| + | If the openwrt system is an openvpn client | ||
| + | and a zone ' | ||
| + | and this zone has the masquerading active, for | ||
| + | reasons (yet) unknown the traffic from the internal lan | ||
| + | to the vpn will be able to reach the destination and | ||
| + | go back to the router but then will be not dispatched back to the | ||
| + | lan clients. Disabling mwan3, instead, let the traffic be dispatched | ||
| + | properly. | ||
| + | |||
| + | It could be a misconfiguration, | ||
| + | |||
| + | === Example 1: Have OpenVPN Server be accessible through multiple WAN interfaces (server mode) === | ||
| + | |||
| + | If load-balancing between multiple WAN interfaces, it is desirable to have OpenVPN clients be able to connect through all active WAN interfaces. | ||
| + | |||
| + | In a multiple WAN interface failover scenario, OpenVPN will not accept client connections on the secondary WAN interface after a failover, as it started listening on the primary WAN interface when it was started. | ||
| + | |||
| + | The following configuration will allow multiple WAN interface to be used with OpenVPN Server. | ||
| + | |||
| + | == Step 1: Listen only on the internal LAN interface == | ||
| + | |||
| + | * Configure OpenVPN Server to listen on the **internal** LAN interface only, not on any WAN interface. The internal LAN interface will not go down or change, and so it provides a stable listening interface for OpenVPN. | ||
| + | |||
| + | < | ||
| + | vi / | ||
| + | </ | ||
| + | |||
| + | < | ||
| + | ... | ||
| + | # Which local IP address should OpenVPN | ||
| + | # listen on? (optional) | ||
| + | ;local a.b.c.d | ||
| + | ## Customization: | ||
| + | local 192.168.1.1 | ||
| + | |||
| + | ... | ||
| + | </ | ||
| + | |||
| + | == Step 2: Set up port-forward(s) == | ||
| + | |||
| + | * Configure a port-forward on the " | ||
| + | * Create a firewall rule like the following: | ||
| + | * Network > Firewall > Port Forwards | ||
| + | * Name: OpenVPN forward to unchanging inside IP | ||
| + | * Protocol: UDP | ||
| + | * Source zone: wan | ||
| + | * Source IP address: any | ||
| + | * External IP address: any | ||
| + | * External port: 1194 (the default OpenVPN UDP port) | ||
| + | * Internal zone: lan | ||
| + | * Internal IP address: (the internal LAN interface IP address) . Careful on this point. If the internal LAN ip address mentioned is the same of the one mentioned in '' | ||
| + | * Internal port: 1194 (this is not really needed) | ||
| + | * Enable NAT Loopback: enabled | ||
| + | |||
| + | == Step 3: OpenVPN client and DNS configuration == | ||
| + | |||
| + | * If load-balancing between multiple active WAN interfaces, the suggested approach is to register multiple DNS A records for the same DNS name. Clients will use just one of the IPs. As per the OpenVPN man page description of the --remote client parameter, "If host is a DNS name which resolves to multiple IP addresses, one will be randomly chosen, providing a sort of basic load-balancing and failover capability." | ||
| + | * If failing over from a primary to a secondary WAN interface, one approach is to use ddns-scripts to update the IP of the DNS name used by OpenVPN clients | ||
| + | |||
| + | === Example 2: Use OpenVPN tunnels as virtual wan(s) (client mode) === | ||
| + | |||
| + | If you want to use your OpenVPN client tunnels as virtual wan interfaces in mwan3, you have to make sure that you set a default route with different metric for each tunnel interface. Also most commercial VPN solutions push two static routes to override the standard default gateway. In most cases you don't want this override when using OpenVPN client tunnels in conjunction with mwan3. | ||
| + | |||
| + | As a solution you can add the following lines to your OpenVPN client config: | ||
| + | |||
| + | < | ||
| + | route-nopull | ||
| + | route 0.0.0.0 0.0.0.0 vpn_gateway 20 | ||
| + | </ | ||
| + | |||
| + | This example will ignore the routes pushed from the OpenVPN server and will add a default route with metric 20 over the OpenVPN tunnel interface. | ||
| + | |||
| + | ==== privoxy transparent HTTP proxy ==== | ||
| + | |||
| + | * References: | ||
| + | * Forum posts from headless.cross and Adze, see [[https:// | ||
| + | |||
| + | * Related pages: | ||
| + | * [[docs: | ||
| + | |||
| + | Transparent HTTP proxying relies on using iptables rules to transparently redirect outgoing traffic to port 80 first through the local proxy at another port number. | ||
| + | |||
| + | For example, here is a OpenWrt redirect rule to redirect outgoing traffic to TCP 80 port and re-send it to the local proxy listening on TCP port 8118. This will go into iptables NAT table rules. | ||
| + | |||
| + | < | ||
| + | config redirect | ||
| + | option target ' | ||
| + | option dest ' | ||
| + | option proto ' | ||
| + | option src ' | ||
| + | option src_dip ' | ||
| + | option src_dport ' | ||
| + | option dest_ip ' | ||
| + | option dest_port ' | ||
| + | option name ' | ||
| + | option enabled ' | ||
| + | </ | ||
| + | |||
| + | The problem is that mwan3 adds rules to the iptables' | ||
| + | |||
| + | Next, iptable nat rule handling takes place and diverts the web page request to privoxy. The reply from privoxy however is part of the same session and is already marked to leave a wan interface. The reply from privoxy is then send over the internet, which is obviously incorrect. | ||
| + | |||
| + | To fix this add the following rules to your mwan3 config: | ||
| + | |||
| + | < | ||
| + | config ' | ||
| + | option ' | ||
| + | option ' | ||
| + | option ' | ||
| + | option ' | ||
| + | option ' | ||
| + | |||
| + | config ' | ||
| + | option ' | ||
| + | option ' | ||
| + | option ' | ||
| + | option ' | ||
| + | option ' | ||
| + | |||
| + | config ' | ||
| + | option ' | ||
| + | option ' | ||
| + | </ | ||
| + | |||
| + | The policy " | ||
| + | |||
| + | |||
| + | ==== nodogsplash ==== | ||
| + | |||
| + | Out of the box, mwan3 does not work with nodogsplash. The problem is that both mwan3 and nodogsplash use the same iptables mark bits. A common symptom of this is the nodogsplash splash page appearing for every page even as an authenticated client. | ||
| + | |||
| + | However, it is possible to fix this with a minor change! Fortunately, | ||
| + | |||
| + | < | ||
| + | # Change the default marking flags to work with mwan3 and qos-scripts | ||
| + | FW_MARK_AUTHENTICATED 262144 | ||
| + | FW_MARK_TRUSTED 131072 | ||
| + | FW_MARK_BLOCKED 65536 | ||
| + | </ | ||
| + | |||
| + | These values let nodogsplash work together with mwan3 and also work with standard Openwrt qos-scipts. | ||
| + | |||
| + | |||
| + | |||
| + | ===== Usage reports ===== | ||
| + | ==== 12.09, tplink wdr3600, mwan3 - 1.4-24, two wan connections ==== | ||
| + | Premise: very nice piece of work given to the internet community, congrats to the contributors. | ||
| + | We, users, can only give back a bit of experience and documentation, | ||
| + | |||
| + | In a simulated test environment described as follows: | ||
| + | < | ||
| + | external network | ||
| + | <---> (ip a.b.c.224) router2 (ip 192.0.10.1) <---> (ip 192.0.10.166 - wan2) (ip 192.168.10.1) <---> (ip 192.168.10.101)pcB | ||
| + | </ | ||
| + | |||
| + | The mwan3 was installed on the tplink with the following configuration (apart from wan and wan2) in ''/ | ||
| + | < | ||
| + | ...lines.... | ||
| + | |||
| + | config member ' | ||
| + | option interface ' | ||
| + | option metric ' | ||
| + | |||
| + | config member ' | ||
| + | option interface ' | ||
| + | option metric ' | ||
| + | |||
| + | config member ' | ||
| + | option interface ' | ||
| + | option metric ' | ||
| + | |||
| + | config member ' | ||
| + | option interface ' | ||
| + | option metric ' | ||
| + | |||
| + | config policy ' | ||
| + | list use_member ' | ||
| + | list use_member ' | ||
| + | |||
| + | config policy ' | ||
| + | list use_member ' | ||
| + | list use_member ' | ||
| + | |||
| + | config rule ' | ||
| + | list comment | ||
| + | option src_ip | ||
| + | option dest_ip | ||
| + | option use_policy ' | ||
| + | |||
| + | config rule ' | ||
| + | list comment | ||
| + | option src_ip | ||
| + | option dest_ip | ||
| + | option use_policy ' | ||
| + | </ | ||
| + | |||
| + | === Using different wan connections from different Pc-s === | ||
| + | Then with the pcA and pcB two different download were started, and every pc used a different connection. Great. | ||
| + | |||
| + | === Line fail === | ||
| + | When one wan connection was physically disconnected, | ||
| + | but after ' | ||
| + | line backup. Great. | ||
| + | |||
| + | === Line recovered === | ||
| + | If a wan line recovers (let's say A), then the pc that was using the other wan line (configured as backup, let'S say B) is | ||
| + | switched back to the wan line A, and this cause another disruption of tcp connections. | ||
| + | |||
| + | //Edit: On recovery, connections already established over backup links will not be terminated and continue to traverse over backup wan. Only new connections will be routed over preferred wan.// | ||
| + | |||
| + | === Incoming connections routed behind the router === | ||
| + | Rdp connections to the pc behind the tplink are stable, this means that a service behind the tplink with | ||
| + | mwan3 is reachable in a reliable way. | ||
| + | |||
| + | Therefore does not happen that an external request coming on one wan connection gets the replies | ||
| + | through the other wan connection (at least for failover policies) | ||
| + | |||
| + | === Incoming connections to services on the router === | ||
| + | At least testing with ssh, does not happen that one connection through a wan line is router on the other wan line | ||
| + | in case of line failover. Therefore ssh is stable. | ||
| + | |||
| + | === mwan3 status hints === | ||
| + | '' | ||
| + | like for web traffic. This is a bit misleading if in reality the traffic was | ||
| + | split by other rules. I do not know why iptables reports this (mwan3 status just reports what iptables | ||
| + | says) but analyzing it with iftop and bmon there is better to asses if the traffic is | ||
| + | directed properly using the wan connections. | ||
| + | ==== Reliable public ip addresses to ping ==== | ||
| + | After some weeks of continous pinging to opendns Ips (208.67.222.222) and (208.67.220.220), | ||
| + | |||
| + | Some possible choices: | ||
| + | < | ||
| + | # Level3 communications (large network carrier) | ||
| + | 4.2.2.2 | ||
| + | |||
| + | # google dnses | ||
| + | 8.8.4.4 | ||
| + | 8.8.8.8 | ||
| + | |||
| + | # facebook.com | ||
| + | 173.252.120.6 | ||
| + | |||
| + | # Opendns (with limits after a certain amount of days?) | ||
| + | 208.67.220.220 | ||
| + | 208.67.222.222 | ||
| + | |||
| + | </ | ||
| + | |||
| + | === Possible work arounds to test connection not only by ping ? === | ||
| + | Could be possible to implement other ways to test connections, | ||