Routing

I will try to explain this as good as possible.
My configuration is a RB2011UiA , i have set ether1 as WAN1, ether2 as LAN, and ether 6 as WAN2 (for failover) i also have some gre tunnels, in tunnel 1 i have routed a /29 ip range in to me, and another /29 range routed in via another tunnel, in linux i would easily source route these nets via iptables, and im looking for a way to source-route it in routeros, the command in linux would be:

/usr/sbin/ip route add default via 172.16.100.10 dev gre_1 table 2
/usr/sbin/ip route add ???.???.???.??/29 dev eth0 table 2
/usr/sbin/ip rule add from 172.16.100.9 table 2 priority 2002
/usr/sbin/ip rule add from ???.???.???.?/29 table 2 priority 2002

How would i get the same result in routeros?

The ip ranges are set on their own interfaces with their own dhcp servers. and

Using Winbox/Webfig you can go into “IP” then to “Routes” and add anything you need.

Via cli, I don’t remember the commands off the top of my head.

The equivalent command in RouterOS is:
/ip route
add dst=172.16.100.10 gateway=gre1 routing-mark=table2
add dst=x.x.x.x/24 gateay=ether1 routing-mark=table2

I’m assuming that priority is the route metric - in ROS (and Cisco and Juniper and others) the metric ranges from 0 to 255, and it’s also known as “administrative distance” - where the lower value = the higher preference, so 0 = top dog, and 254 = bottom banana, and 255 = unreachable.
This is set by adding distance=X to your route commands.

You set route marks in the mangle table of the IP firewall configuration - if you’re familiar with iptables, then the mangle table should be a snap for you to figure out since it’s just a front-end for iptables anyway. The key there is action=mark routing new-route-mark=table2 for any routes you want to mark on the packets.


What i want to do:
I want to route some ip ranges i have available, to ether8 and ether9 (like 197.209.60.32/29 and 197.209.61.32/29)
and be able to use them with a dhcp server on ether8 and ether9.

The configuration today is as follows:
ether1 is WAN, there are also some GRE tunnels where i have the mentioned ip ranges routed to the
endpoint ips on my side of the gre tunnels. The tunnels are working fine. (i can ping the endpoints) and
if i add the first ip of the range to the interface (like 197.209.60.33/29) i can ping it from the outside.
In other words, all routing into my router is as it should be.

Here comes the first question, do i need another route setting for getting the ips from the routers gre
endpoint ip onward to the interface (ether8).
And second question how to i sourceroute the traffic back to internet?


ether1 - isp public ip
ether2 - LAN (10.1.1.0/24) (masqueraded to ether1)

gre1 - tunnel to another isp, link is up, ips routed.
gre2 - tunnel to another isp, link is up, ips routed.

ether8 - has the first ip of the range routed in via gre1, can connect externally to the set ip from outside.
ether9 - has the first ip of the range routed in via gre2, can connect externally to the set ip from outside.

With current configuration i can surf with computer connected to ether8 and has set a ip from the range, but
i cant connect to the ip from outside, so the traffic stops in the router i suppose.

So what rule / mangle / source route setting do i need to make the ips accessible for the “world” ?
today im using a mangle setting with prerouting via action “mark routing” so the ip’s work from the inside, but are not accessibale from the outside.

If you can surf, that means routing is probably good to go. It sounds more like a firewall filter issue (it could be other things, but that’s the most common) - As a quick test, you can make a rule in the forward chain that simply allows packets whose destination IP is your testbed. Make this the first rule in the forward chain. If it allows inbound connections, then you know that was the problem, and then you can start tailoring that rule down to allowing only the ports you want, and move the rule into its proper sequence in the forward chain. (at the very least, it should come after the allow/fasttrac established,related connections rule(s)).

As for routing and interface configuration…

If the /29 subnets from the ISPs are located on the GRE link, then you could actually remove the IP from the GRE interface and place it on the ether1/ether2/ whatever local interface you like, as GRE is a true point-to-point type of interface and doesn’t actually need an IP on it directly. Just make sure there’s a /32 for the ISP’s router in your routing table. /ip route add x.x.x.33/32 gateway=gre1

range 1 main ip is set on ether8, range 2 main ip is set on ether9, /ip route add ip/mask gateway=greintf did not work
Im running completely without any firewall rules, it seems that the router doesnt forward the packages thru / past ether8/9 since if i externally try to connect to the main ip, the RB2011 interface shows up, so yes routing is in place, but somehow the router doesnt understand that traffic to the range, should be forwarded further beyond ether8/9 to the machine(s) beyond ether 8/9

Honestly, I think the problem is in the hosts on those interfaces, not the routing.

One thing that stands out is that I see exactly the same MAC address (000c.d956.530c)

appearing as a.a.a.38 on ether9 and as b.b.b.38 on ether8

You shouldn’t have both networks appearing to the same host on the same interface. This shows up as a VMWare MAC address, so I’m assuming you’ve got a virtual host running. Try simplifying your host configuration and network configuration. If the same virtual host should appear in both networks, I would recommend that you either do this by using two virtual ethernet interfaces, or by using NAT and mapping the public IP addresses to the box…

First, just try removing the 193.x.x.x address and the link to ether9 from your virtual configuration.

I am able to ping and log into your router using the tunneled IP addresses, so it’s obvious that your routerboard is set up correctly. I had considered removing (er - disabling) the VRF setting on ether8 - that shouldn’t be necessary…

ok - just to update this thread for posterity - I helped set the mangle rules to use connection-marking for the policy, and then set the mark-routing rules to match based on the connection marks, instead of trying to just mark the packets themselves.

Thanks for all the help, awesome people, awesome forum :slight_smile:
And a huge thanks to ZeroByte