Separating 2 LANs with different gateways

RouterOS General
1

Hi all,

I’m experiencing a strange issue, so I would really appreciate some help.

The setup I have is like the following:

For some time I’ve been using only LAN-1 with 2 ISPs (switching default gateway to ISP-2 when ISP-1 is down).

Then a new network (LAN-2) joined and I had to provide LAN-2 with internet connectivity as well. I decided to use ISP-2, since it’s idle most of the time anyway. Also, I had to isolate them not to be able to reach each other, for security reasons. So, I added a routing mark in the prerouting phase to mark all the packets originating from LAN-2 with:

ip firewall mangle add chain=prerouting in-interface=eth2 action=mark-routing new-routing-mark=packets-from-lan-2

and also added a default gateway for that traffic with:

ip route add dst-address=0.0.0.0/0 gateway=eth6 routing-mark=packets-from-lan1

When doing a traceroute from LAN-2 to a random ip address on the internet I could see the following:

C:\> tracert -d google.com

Tracing route to google.com [216.58.214.206]
over a maximum of 30 hops:

  1     2 ms     1 ms     2 ms  10.2.0.1
  2     6 ms     3 ms     3 ms  2.2.2.2
  3     7 ms     5 ms     8 ms  ...

so I assumed everything was working as expected. Until I noticed an interesting thing recently.

I configured a port forwarding for LAN-1, in order to have some servers visible from the internet, like this:

ip firewall nat add chain=dstnat dst-address=3.3.3.3 action=dst-nat to-addresses=10.1.x.x

Btw, I had to add an ip address 3.3.3.3 to the router, otherwise this dst-nat thing wouldn’t work. Is that supposed to work like that?

Anyway, the problem I have now is that I can’t reach 3.3.3.3 from LAN-2. I was expecting a traceroute from LAN-2 to 3.3.3.3 would give me something like this:

10.2.0.1
2.2.2.2
...
1.1.1.1
3.3.3.3

but that doesn’t happen. I don’t even see the first hop. Everything just times out :slight_smile:

Does anyone have any idea what could be the issue here or how could I try to troubleshoot this properly?

2

How did you add 3.3.3.3 to the router? Your diagram doesn’t show what port the IP is assigned to. That IP has to be bound to an Interface it just can’t be the whole router. Whatever the WAN IPs the ISPs give you are the WAN IPs on Eth5 and Eth6. Those would be the IPs to reach the router over the Internet while 10.1.0.1 and 10.2.0.1 would be the LAN gateways (or whichever IP you made the gateway) and that’s how the LAN would reach the router.

Is this 3.3.3.3 IP from the LAN? Is it part of one of those /16’s? It is part of the WAN IPs one of the ISPs are giving you? Or did you assign a new subnet for this? If so, what is it and what Interface is it bound to?

3

Thanks for your reply. I didn’t show it properly, I’ll update the image. The IP address 3.3.3.3 is a public ip assigned from ISP-1, so it’s on the eth5, and reachable from the internet.
Edit: I’ve updated the original image.

4

You forgot (don’t worry, you’re not alone) that once you assign a routing-mark to a packet, that routing-mark is used to find routes to all destinations, including local subnets directly attached to the Mikrotik itself. And I’m afraid (i.e. not completely sure) that it includes also Mikrotik’s own local addresses. So packets to 3.3.3.3 are sent out via LAN2’s gateway.

So make an exception from the action=mark-routing rule for local destinations, because I have no idea how to add a routing-marked route to local address.

If that does not help, come back with the output of /export hide-sensitive sanitized by systematically substituting every occurrence of each public IP address by a meaningful pattern like my.public.ip.1

5

Concur it will be like playing whackamole unless you post your config.
https://www.youtube.com/watch?v=D0n8N98mpes

6

Nope, local addresses don’t use visible routing tables.

7

First of all, sorry about the big delay for the feedback. I wasn’t able to easily remove all the sensitive data from the config, to be able to conveniently paste it here, because the config is quite big and highly customized.
But, what I can confirm is that Sob was probably right, because, as soon as I removed the ip address 3.3.3.3, the packets started going out of the router (but they never came back, due to the missing ip address on the interface eth5). So, I guess that’s where I should be looking more closely.

Thanks a lot guys. At least I have something that I can test and play with, to see if I’ll be able to make it work :slight_smile: