I'm trying to configure the two default routes that I need to have for mwan3 configuration. I'm using a docker image of OpenWrt (OpenWrt 21.02-SNAPSHOT r16009-121f2461e5 ). The topology that i'm trying to create is:
The configuration of the /etc/config/network file is the following one:
Don't you need to have different networks on your two default gateways in relation to the main one to avoid loop back again?
63.34.8.3 when accessing to public IP in the case of going to 10.5.2.2 will later be able to go to 10.5.2.1 ? are you sure?
if you are new setting mwa3 you can take a look here: [Solved] Mwan3 - MWAN Interface Live Status showing offline for all interfaces - #2 by braian87b
I have noticed that if i remove the first default route with gateway 10.5.1.2, it works correctly. So i guess the problem is with the default routes...See:
ip route show
default via 10.5.2.2 dev eth2 proto static metric 20
......................................................................................
ping -c 1 -I eth2 63.45.8.3
PING 63.45.8.3 (63.45.8.3): 56 data bytes
64 bytes from 63.45.8.3: seq=0 ttl=62 time=0.200 ms
--- 63.45.8.3 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.200/0.200/0.200 ms
I'm not understanding well why i should have different networks...Maybe that's why it is not working. This is just an own project where i'm trying to configure mwan3 using docker. The other routers are running in docker too.
And the server in 63.45.8.3, it's just another docker container that simulates Internet (it isn't real, actually it's running in local, in my computer). I don't know if in this case can cause the loop that you are saying...
Thanks for the link! And your help.
EDITED:
I was reading the link...is it mandatory to use vlans to make mwan3 work?
It is better to have completely different networks (ip/mask) in order to let system decide where to route packages using rules and routes and prevent conflicts.
Also take in consideration that virtualization of network must have some things in mind like promiscuous mode but I'm not expert on the topic: https://openwrt.org/docs/guide-user/virtualization/virtualbox-vm it is for virtual machines but surely applies also for docker or other similar container technologies. You may need to simulate link using force-link.
it is not mandatory to use vlans for your case, vlans is to allow convert physical router LAN ports 1,2,3 and 4 into a dedicated additional WAN ports (by disconnecting them from the CPU-switch).
If you get that working please share your conf files. It's an interesting experiment that you are doing there.
The problem is not with the routes. Routing is not involved in this scenario, as you are specifying which interface it's going to use. The reply not getting back to the OpenWrt sounds more like a misconfiguration of the docker. Do you see the ping reply on a tcpdump on eth2?
If you mean simulate link between the containers, i use docker bridge networks which forwards traffic between my containers. Link: https://docs.docker.com/network/bridge/ And this was working for me, until now that i'm trying to have two default routes.
Thanks for your help braian! And yes, if i get this working, i will share the conf files.
I'm far from expert in docker. But this is something that would work in a normal router with 2 interfaces scenario.
However if you are using bridging functionality in docker, I don't see why the multiple default routes would matter.
After a few headaches with this issue, i found the solution! I reply with the problem and how i solve it in order to help other people with similar problems.
The problem was the reverse path filtering.
Reverse path filtering is a mechanism adopted by the Linux kernel, as well as most of the networking devices out there to check whether a receiving packet source address is routable. So in other words, when a machine with reverse path filtering enabled receives a packet, the machine will first check whether the source of the received packet is reachable through the interface it came in. Therefore:
If it is routable through the interface which it came, then the machine will accept the packet
If it is not routable through the interface, which it came, then the machine will drop that packet.
