How will OpenWRT work in the presence of two WAN links if i do not install mwan3 or multi-WAN ?
For a site thats mostly managed remotely, i want to have connections to two WAN links. The most important thing to me is that connections from the internet to WAN1 IP address will have their return traffic also go back onto WAN1 and likewise connections from the internet to WAN2 IP address return their traffic back to WAN2.
Thanks!
As the routing of packets to you is "at the whim" of the last-hop router and assuming that it hasn't been strangely configured, it should "just work" if the source address for packets leaving "WAN1" is with an IP assigned to WAN1 and similarly for "WAN2". That the two destination addresses happen to be on the same host doesn't change the return routing.
jeff: but thats the point.
Consider a standard linux without complex iptables setup, two WAN interfaces, each gets an address by eg.: DHCP (from the ISP that each WAN port connects to). Linux puts both interfaces into the same routing table and the primary default route will point let's say to WAN2.
Now i have an incoming TCP connection to the routers WAN1 IP address. the return traffic will (in default linux routing config) simply be routed back by the default route, so it would go out to WAN2. And today, every ISP should do source IP check and filter/discard those packets, because you're not supposed to send a foreign IP source address to an ISP. Aka: does not work.
I don't know if openwrt has the same default behavior. Alas, i can't test easily right now. One can fix this through some iptables rules where the source IP address determines the outgoing interface, but it would of course be lovely if that wouldn't have to be manually configured but was done by openwrt itself by default.
Consider that when you ssh to the router from the LAN, it responds back to you on the LAN. And when you ssh in from the WAN, it responds back to you on that same interface. Adding another WAN will not change that. An incoming connection will be maintained on the interface it arrived on.
To the best of my knowledge, this is not true when the incoming connection is from across the internet, unless openwrt does establish some source route policies.
OpenWrt isn't going to do anything "special" as compared to any other Linux-based implementation.
I can see why there are concerns when there is a default route on your device back to the source that isn't through the interface that is assigned to the IP address associated with the connection. All of my multi-homed devices return link-specific packets with non-default routes, either implicit due to the destination being link local, or explicit static routes to the destination. So I'm not sure that a "rest of world" packet with a source IP of WAN2 ("IP2") would necessarily go out WAN2 if the default route was via WAN1.
If it is the case that the Linux kernel routes packets with a source of IP2 out of WAN1 due to a default route via WAN1's gateway, then you would likely have to implement source-based (or "policy-based") routing.
It will not work (without complex routing rules).
Example WAN2, add to /etc/config/network:
(THESE ARE NOT FIREWALL RULES - I've had a lot of posters confused on this.)
config route
option interface 'wan2'
option target '0.0.0.0'
option netmask '0.0.0.0'
option gateway 'xxx.xxx.xxx.xxx'
option table '2'
config rule
option in 'lan_xxx'
option dest '0.0.0.0/0'
option priority '2'
option lookup '2'
Thanks, lleachiii
According to this URL:
https://oldwiki.archive.openwrt.org/doc/uci/network
it seems to be possible to use "config rule" to configure all the supported iproute2 rule options, including "src". That should allow to match return traffic based on its src IP address. I am just not clear if this will actually work when the connection is not terminating on the router itself but also going through NAT to a device behind the router.
Btw: why is this documentation only on an "oldwiki" ?
Just very basic options in that URL. How is a reader supposed to learn the complete supported syntax of /etc/config/network in the new wiki ?
Did you scroll down? There's quite a bit of detail there.
Advanced users often look at the files that extract the UCI to determine, well, advanced settings. The wiki is a guide for use of OpenWrt, but not complete documentation.
i scrolled through and did rough comparison. The oldwiki is a lot more complete. "config rule" for example is not mentioned at all on the new wiki page.
Why was a more complete older dcumentation replaced with less complete newer one ?
That's a good question -- Perhaps we should have an "Advanced /etc/config/network" page as well.
There's a challenging balance between making the content readable and comprehendible for general users and supporting advanced users that already have a good understanding on network protocols and how a Linux-based system operates. Overloading a single page has caused many headaches for users unfamiliar with OpenWrt being unable to locate the common and important content that they need for success.
The same info was split into different articles that can be found in the Network Configuration section of the user guide page because imho it was better to have each topic in its own article instead of dumping everything in the same article. https://openwrt.org/docs/guide-user/start#network_configuration
The part about "config rule" is in an article called IP Rules (policy routing) here https://openwrt.org/docs/guide-user/network/ip_rules
Other routing articles have "routing" in the title.
A simple concept in the industry is "configuration guides" vs "(commands) reference". Commands references being terse but complete and structured so that you can find easily any existing config with them, but if you're not familiar with the subject matter, you then go from there to the appropriate config guide mentioned in the reference guide.
You can also think of command references as the most simple way to create specifications for what the product is supposed to do. If a config guide thats explanatory to the user doesn't match what the software does, it should be seen as a bug in the config guide. If the software doesn't do what the command reference says, its a bug in the software. Thats at least if you want to have something where the source code is not the specification. 
The old wiki documents where a lot closer to a commands reference, the new ones a lot more task oriented config guides.
And yes, i don't know a good way that does not incur duplication of work if you want to have both easily understood taks oriented docs and normative docs.
As far as command references go, there is the article called UCI networking options cheatsheet where there are the tables of UCI options with basic description but no fluff text, explanations or examples which are found only in the dedicated articles. https://openwrt.org/docs/guide-user/network/ucicheatsheet
Do you have any feedback on that? Expanding it somehow, renaming (to something like "UCI Networking Options reference"), making it more important in the pages with a dedicated link or whatever so it's easier to find or understand?
i don't know a good way that does not incur duplication of work if you want to have both easily understood taks oriented docs and normative docs.
As seen if you try to edit the wiki page above, the UCI networking cheatsheet article is using internal wiki functions to dynamically assemble a page taking the actual tables of options from the individual articles, so we don't have to go around and copy-paste stuff every time there is some change.
We can also use the same method to expand it a bit up to the point of creating again the huge page like the old wiki but I think reaching that point is kind of silly, that was not a "command reference", it was a "all networking info in the same place" page.
Yes, nice page (ucicheatsheet)
Are the old wiki pages meant to be read-only ? If so, then one final step should be to add to those old wiki pages near the beginning some text like "This page has been superseeded by... [new wiki page(s)] - more than one if the old text is only represented my multiple new ones.". Especially because google still finds first a lot of old pages (only).
The main reason for example why google gives me only the old page(s) is because i am googling for something like "config rule" and the ucicheatsheet does not contain text to find this. It does not have text like "config rule" or "config rule6" ? aka: it does not include the syntactical explanations, only the parameters.
Is that file describing only content of /etc/config/network or also aspects of other /etc/config/ ?
Hm, ok. Will include the default config of each section in that page too so it has the right keywords to find it from search engines, thanks.
Is that file describing only content of /etc/config/network or also aspects of other /etc/config/ ?
Only network, as it was supposed to replace the "all networking uci options in one page" functionality that was lost when I split the "all networking info in one page" article.
That's the only thing I got requests for (i.e. to still have a quick lookup for networking UCI options) when I rearranged the wiki after the re-merge of LEDE/OpenWrt.
From what I understand, other topics like Firewall or VPN or external storage (or random optional things) are more involved and require far more than just adjusting UCI parameters to work so having a cheatsheet for that would not be as useful. But still, I'm open to listen any opinion on this.