Hi,
So I have a pretty messed up network due to CPEs I got from 2 providers that can’t do either static routing or go into bridge mode. The only thing they can do is nat from a /24 to it’s public address.
So my original idea was to have primary-5 and backup-4 these would be the interfaces connected to the CPE’s LAN interfaces (primary-5 would get a dhcp address from the 192.168.1.0/24 network, backup-4 would get a dhcp address from the 192.168.2.0/24 pool) and have my real LAN (192.168.88.0/24 bridge). To overcome the different subnet issues (no static routes or any routing protocol on the CPEs) I have come up with 4 rules:
1 chain=srcnat action=netmap to-addresses=192.168.1.0/24 out-interface=primary-5 log=no
2 chain=dstnat action=netmap to-addresses=192.168.88.0/24 in-interface=primary-5 log=no
3 chain=srcnat action=netmap to-addresses=192.168.2.0/24 out-interface=backup-4 log=no
4 chain=dstnat action=netmap to-addresses=192.168.88.0/24 in-interface=backup-4 log=no
when I’m pinging from 192.168.88.254 (connected to the bridge interface) to 192.168.1.10 (connected to the primary-5 interface for the test purpuses), I get the following tcpdump on the host:
15:24:39.443457 IP 192.168.1.254 > 192.168.1.10: ICMP echo request, id 10114, seq 1495, length 64
15:24:39.443511 ARP, Request who-has 192.168.1.254 tell 192.168.1.10, length 28
I have enabled proxy-arp on all interfaces but either i misunderstand how proxy-arp should work or it’s not working when it’s related to connected routes.
So my biggest problem is that I need to netmap to the directly connect subnet and there can be no routing involved as the CPEs are pretty dumb and the mikrotik would need to respond to each arp-request that he has an arp entry for in the bridge interface and also netmap those requests. Can anybody think of a solution?
It would be much easier to just use srcnat out each interface and not try to make your LAN appear exactly 1:1 on both wans…
Anyway, to answer your question, here’s how proxy arp works:
If an interface performing proxy arp receives an ARP request for an IP which is found in the routing table (including even the default gateway) and the destination leads towards any interface other than the one where the ARP was received, then the interface should respond to the arp request with its own MAC address.
So if you want your router to answer arps for 192.168.1.x, then it needs to think that 192.168.1.x lives in some other direction.
There are lots of ways to skin that cat. I think the easiest would be to sacrifice the first 64 addresses of the range (i.e. never use 192.168.88.1-63)
This assumes that the two routers are 192.168.1.1 and 192.168.2.1
Then blackhole route the “overlap” portions:
/ip route
add dst=192.168.1.64/26 type=blackhole
add dst=192.168.1.128/25 type=blackhole
add dst=192.168.2.64/26 type=blackhole
add dst=192.168.2.128/25 type=blackhole
If you want to sacrifice less space, then you can add the .32-.63 ranges:
add dst=192.168.1.32/27 type=blackhole
add dst=192.168.2.32/27 type=blackhole
I suggest that your router’s WAN addresses should be static (not DHCP) as 192.168.1.2 and 192.168.2.2
Now you can netmap 192.168.1.x → 192.168.88.x and 192.168.2.x → 192.168.88.x
This will work for all addresses which you’ve covered in the blackhole routes.
You only need to set arp=proxy-arp on the two WAN interfaces.
If the only devices on your WAN segments are the ISP modem and your router, then you can continue to blackhole the remaining space:
192.168.1.16/28
192.168.1.8/29
192.168.1.4/30
192.168.2.16/28
192.168.2.8/29
192.168.2.4/30
Thanks for this info. I will make this happen. Having the 1-on-1 mappings on between lans will make port forwarding somewhat easier i hope, hence the requirment.
Just thought will share with the class my solution to this problem, will let you know if it breaks something, as there will be no reachability between the LANs.
I have changed the backup ISP’s CPE’s LAN to 192.168.0.0/24, which makes the 2 ISPs ip space to be 192.168.0.0/23, after this I have modified the 2 interfaces to be 192.168.0.2/30 and 192.168.1.2/30.
The blackhole route didn’t seem to do the trick, it didn’t seem to trigger proxy arp responses, so I just added the 192.168.1.254/23 address to my lan interface. This means that proxy-arp will be triggered for everything but it also means that if there are devices connected to the wifi/lan of the ISPs CPEs it will just not work as the mikrotik thinks they are on the local segment.