forward IPs from different subnets -- is it possible?

RouterOS General
1

We have internet from 2 ISPs. From ISP A we have a fiber connection and a C class, and from ISP B we have a DSL connection and a /29. The C class is routed in the our mikrotik via an IP but the /29 is routed at the far end of the DSL from ISP B. We cannot program ISP B’s remote router (e.g. a standard DSL connection).

We’d like each of our servers to have an IP from the C class but to also be reachable from an IP in the /29 since in certain cases the DSL is a cheaper connection (unmetered bandwidth). The access to the servers must, of course, be seemless for connections from the internet. I.e. a connection from the internet to the /24 should return via the /24 and similarly with the /29. Also, if we are internally connecting from the /24 to the /29 the packets should not go via the internet (as this consumes unnecessary bandwidth – we could be moving packets in router…).

Our issue with all of this is that because we don’t have routing control over the /29 we are looking for an alternative way to accomplish the above. We’ve considered using NAT on our router to translate packets coming in on an IP in the /29 to an ip on a /24 of a server, but since we can only bind one address from the /29 to an interface this is not an option. (Well, our tests have shown this).

So, we’re looking for a way out. Any ideas? A free case of beer to anyone in the Toronto area who can gives a solution.

2

You can do this setup… if you are using differing ip space across providers you need to watch a few things.

  1. Packets need to be mangled on the way in and marked correctly so that they can travel back out the same interface. You might get away with routing ISP 1 traffic out ISP 2 but you shouldn’t. You need policy routing to send those marked packets back out the same interface they came in on. The src-nat / masq rules should take care of sending it using the IP it needs when it leaves the interface.

  2. Packets coming in your dsl modem should probably be dst-natted to your other range. This way you don’t have to dual home those machines really.

  3. Make sure you don’t have async routing, ie, packets coming in one physical router but leave a different physical router … meaning Mikrotik needs to see the packet come in and go back out otherwise it will see broken connections. Both your fiber and dsl should be on the same router.

We’ve considered using NAT on our router to translate packets coming in on an IP in the /29 to an ip on a /24 of a server, but since we can only bind one address from the /29 to an interface this is not an option. (Well, our tests have shown this).

You should be able to add the remaining ips using a /32 for the netmask. We have some interfaces with 15-20 ips on them, the first has the /27 and the remaining have /32. This works fine.

I think what you mean in the first paragraph is that you have one routed and one bridged connection ? It should work either way.

Sam

3

You should be able to add the remaining ips using a /32 for the netmask. We have some interfaces with 15-20 ips on them, the first has the /27 and the remaining have /32. This works fine.

I’ve got a /29 on my Internet interface. All 5 addresses bound to this interface have a /29 subnet mask.

Regards

Andrew

4

Thank you very much Sam. Your excellent reply gave us all that we needed to get things in order.

Yep, exactly.

So, I’d like to share what we did just in case we’ve done something silly. Well, first here’s a simplified picture of how things are:


ISP A - provides C class 2.2.2.x via ip 3.3.3.170 (over fiber)
ISP B - provides /29 bridged (over DSL) 4.4.4.1/29

In our router we have the following interfaces : lan, fiber, dsl

Addresses:

2.2.2.1/24 for interface lan
3.3.3.170/30 for interface fiber
4.4.4.2/29 for interface dsl

So, the first thing we did was create a connection mark for packets coming in on the dsl interface, and then mark packets which have this connection mark and that are from our C class with a routing mark.

/ip firewall mangle 

add chain=prerouting dst-address=4.4.4.0/29 in-interface=dsl action=mark-connection new-connection-mark=dsl_conn_mark

add chain=prerouting src-address=2.2.2.0/24 connection-mark=dsl_conn_mark action=mark-routing new-routing-mark=dsl_route_mark

Then we added a default route for the mangled packets:

/ip route add gateway=216.234.62.1 routing-mark=dsl_routing_mark

Finally we added some NATing rules to map from the DSL ips back to our C class and back. Say for ip 4.4.4.3 on the DSL to be mapped to 2.2.2.3 we first add the dsl address:

/ip address add address=4.4.4.3/32 interface=dsl

and then the NAT rules. We restrict the src NATing to only those packets that have the routing mark (and have therefore been dst-natted):

/ip firewall nat

add chain=dstnat dst-address=4.4.4.3 action=dst-nat to-addresses=2.2.2.3 

add chain=srcnat src-address=2.2.2.3 routing-mark=dsl_route_mark action=src-nat to-addresses=4.4.4.3

And that’s it. I thought I’d write this out in all it’s gory details because i’m still a little unsure this is the best way to do this and I’d really welcome your comments.

There are atleast few issues with this setup though.

  1. We need to add two NAT rules for each IP we want to map. This is fine, but I figure there might be a better way to do it with, as you mentioned, a masquerade rule. Any ideas on this? Will simply setting one up properly map all dsl_route_mark packets back to their external ip?

  2. From a machine on the C class the NAT rules do funky things when we attempt to talk to a machine with its DSL ip. We could add two more rules to direct traffic from the C class to the natted DSP IPs… but my gut tells me there’s a better way (possibly related to #1).

Thanks again everyone,
jeff

5

I’d like to bump this thread. As we are pretty inexperienced with this sort of routing/NAT combination I’d really be interested to hear if others think we’ve done the right thing.

Thanks so much,
jeff

6

Without spending too much time on it at this minute I can see maybe 1 thing that might change things:

add chain=prerouting dst-address=4.4.4.0/29 in-interface=dsl action=mark-connection new-connection-mark=dsl_conn_mark

Try removing the dst-address filter. If it comes in the DSL line you want to mark it, no matter what. Maybe .. : )


Also, are you marking packets or just connections?

7

Hey thanks changeip, I really appreciate you having a look over things.

Yep, I suppose it is a redundant. But to be clear, there shouldn’t be packets destined for any other address range coming in on the DSL. So removing the dst-address shouldn’t really do anything (other than clean up the rule a bit), yes?

We’re just marking connections. I’m not sure I understand why would need to be marking packets here, could you explain?

Thank you,
jeff