Hi,
I sometimes need to connect to the internet with my smartphone via tethering because of a few sporadic problems with my ISP at home.
It has always worked like charm but there was no way for it to work yesterday. I didn’t understand what was wrong with it at once,
since I hadn’t modified anything both on my smartphone and my MK device. After a while, there it is!! I found out the the WAN and the LAN had the
same subnet (say 192.168.111.0/24). I mean the LAN which is automatically set up on my smartphone was also the Mikrotik’s WAN which in turn has its LAN
subnet on the same subnet (192.168.111.0/24). I know that it was an unfortunate event, and it is very unlikely tha it can happen again.
Anyway, I had two choices to fix the problem. Either rebooting my smartphone, hopefully getting a new subnet or changing the LAN subnet. Of course, I went for the first way, and everything started
worked again.
So, I know that having the WAN and the LAN on the same subnet is a NO NO, but I’d like to figure out what EXACTLY happens to packets in such occasions.
I mean, by taking the MK’s packet flow as reference I’d like to ‘picture’ the track of a packet having to deal with such a setup. Is it discarded at once? Does it go back as in a loop?
Thanks
Why not? (ignoring performance and security)
You can have your WAN 192.168.77.x/x inside the same local L2 domain with a LAN 192.168.111.0/24
But if your phone act as gateway, if the RouterBOARD have wifi, add a station and leave the router use the phone as failover.
Or if your router do not have wlan, add a small wireless (ap than act as) client to your phone, and configure failover on router.
My MK uses my phone as failover already, but it happened that WAN and LAN had the same subnet 192.168.111.0/24 this time.
I hope you solve your ISP problem, on meantime consider to switch internal LAN from 192.168.111.0/24 to 10.168.111.0/24
You go from 1 possibility over 256, to 0… 
Yes, and I solved the problem with my cell as well
on meantime consider to switch internal LAN from 192.168.111.0/24 to 10.168.111.0/24
???
Not mind…
anyway, it was not the answer I was asking for
Ignoring the literally description required when “exactly” is writed,
ignoring the fact no diagram are provided,
ignoring the fact no export of the config is provided,
ignoring if something is already provided from the other not working WAN connection
ignoring what I forget to ignore,
ignoring the fact that no one single line is writed on how the routerboard connect to the phone, but just supposed,
if, for example, the router have IP 192.168.111.1 on (bridge)LAN and obtain 192.168.111.2 on WAN (probably 192.168.111.1 or 254 is the phone IP, and 2-253 are the IP assigned by dhcp)
the router internally have 192.168.111.1(/24) on bridge and 192.168.111.2(/24) on WAN
and two dynamic route 192.168.111.0/24 reachable on bridge and reachable 192.168.111.0/24 on WAN
this mean that 192.168.111.0/24 is reachable on both way from the router
at this point the router use ARP cache to contact the correct device when the router want send packet to lan or the phone,
but all the other devices on LAN, and the phone, can not see eachother directly by ARP, but by IP because the router (that for default have forward active) forward packet between IP’s
But if some device have the same IP of the phone (or the phone have same IP of the router), all is broken and act on strange inpredictable behaviour.
(And I hope you IGNORE the quality of my english…)
I appreciate your effort to make me understand what my issue was about,
but it is hard for me to make sense of what you wrote, sorry.
Thanks anyway
A typical MT router does two things: 1. routing of packets and 2. firewalling (statefully according to connection state). Your question is about routing of packets. Router has no notion of packet path or any conceptual things, its operation is simple: which way to send packet in order to get it closer to the destination. It uses routing table and when looking for information how to get packet closer to the destination, it uses the best matching entry. Usually it’s only one so router uses that information. In case when LAN subnet and WAN subnet are different and router searches for best direction towards LAN, it finds one routing table entry which says “for LAN subnet deliver packet directly via interface LAN”. Similarly for packet bound towards internet it finds best entry saying “for everythjng else use xxx.yyy.zzz.www as next router” and further search might yield “for xxx.yyy.zzz.0/24 deliver packet directly via interface WAN”.
Now if LAN and WAN subnets are the same, it finds two equally good entries when looking how to deliver packet to IP address member of both subnets. The only difference is the interface name. So what @rextended implied is that router then consults ARP table for both interfaces to see which interface to use but if IP address is not in ARP table router selects egress interface randomly. There’s another possibility: router takes the first routing table search result and uses that interface either successfully or unsuccessfully. I don’t know which strategy is implemented in ROS, but either way it’s more likely things won’t work.
Following old documentation (when https “do not exist”), when the route have two gateway, is choiced based on arp cache,
if IP is not present, is sended equally one time on gat1 one time on gat2 and so on.
Specifing multiple time the same gateway, from 50/50 (a/b) go to 33,3…/66,6… (a/b/b) and go to 25/75 (a/b/b/b) and so on…
Old methods that with new crypted connection is disused.
Ok, it makes much more sense to me now…overall. I guessed that it was about routing issue. I’d like to go deeper into it with the help of the MK Packet flow diagram, but I don’t know if it is worth it.
Thanks
Reading packet flow descriptions can be very nice mental exercise. But doesn’t help in this case because the case with two subnets with overlapping address space is non-normal while packet flow description describes normal situations.
Yes, I understand. I was trying to find a way to “shape/give form” to the problem by using images…possibly.
Thanks