Set Upstream Gateway for WAN Subnet & How to use Subnet IPs

RouterOS Beginner Basics
1

Maybe not a beginner question, but since I am a MikroTik beginner, I think it is valid here. Currently, I am using OPNsense as my Router/Firewall and want to replace it with a CCR2116. To test RouterOS and its features before changing my network, I am using GNS3 with virtual Cloud Hosted Router with RouterOS v7.6.

I get the following info from my ISP for my network:
IPv4 Subnet: x.y.z.0/28, Netmask: 255.255.255.240, Gateway: x.y.z.1
I also get a /64 IPv6 Prefix, but want to understand how to set up IPv4 first.
My Goal is to assign the /28 IPv4 Subnet to my WAN interface ether1, but I don’t know where I can set the upstream gateway IP.

To Test this out, I am using the cgNAT IP Net 100.64.31.0/28 with 2 CHRs called ProviderEdge and CoreRouter connected like this:
Internet <==> [ether1] ProviderEdge [ether2] <==> [ether1] CoreRouter [ether2] <==> Client Server

# ProviderEdge
/ip/address/add address=100.64.31.1/28 interface=ether2
# CoreRouter
/ip/address/add address=100.64.31.2/28 interface=ether1

I can ping both routers from each other, but how do I set 100.64.31.1 as the upstream gateway for CoreRouter?
Is this somehow detected automatically or assumed to be the first IP of the subnet?

How do I use the other 13 IPs from the /28 Subnet? On OPNsense I would simply create an IP alias and add a firewall rule for an IP of that subnet, for example 100.64.31.3.
Is there something similar to this in RouterOS? I added a Firewall Rule on the CoreRouter but am unable to ping that IP from ProviderEdge:

/ip/firewall/filter/add action=accept chain=input dst-address=100.64.31.3 protocol=icmp src-address=0.0.0.0

Edit:
I found a way to use the additional subnet IPs using veth interface:

/interface/veth/add address=100.64.31.3/28 gateway=100.64.31.2 name=ether1_ip3
/ip/address/add address=100.64.31.3 interface=ether1_ip3 network=100.64.31.0

Is that the right way of doing that?

2

Bump, since my post took a long time to be approved

3

Re. gateway:

/ip/route
add gateway=x.y.z.1 dst-address=0.0.0.0/0 pref-src=x.y.z.1

(pref-src property hints router which of own addresses to use when initiating connections … e.g. if you run ping or if you run check if there are ROS upgrades. Doesn’t preclude WAN IP address for NATed traffic).


And re. additional address(es): just add them to WAN interface:

/ip/address
add address=x.y.z.a/28 interface=ether1
add address=x.y.z.b/28 interface=ether1

How to use it? SRC-NAT is pretty straight forward. I’m not sure about DST-NAT, probably it’s straight forward as well, connection tracking machinery should do the trick. It would get complicated if there were more than one WAN interface and mangle would be necessary to push return packets via vcrrect interface.


And a note re. IPv6: see if you can get shorter prefix, e.g. /60. The problem is that many implementations, MT included, work with /64 subnets. Often (but not always) one /64 subnet has to be “wasted” for WAN interface … but that depends on how ISP does it. Anyways, it’s good to have possibility to have a few IPv6 subnets (NAT is generally not desirable in IPv6), /60 prefix allows 16 of /64 subnets.

4

If I understand correctly, pref-src defines what WAN IP the Router should use by default. In your code example above, you set it to

.1

which is the upstream gateway, shouldn’t this be

.2

for the WAN IP? When I ping 100.64.31.1(ProviderEdge) from the CoreRouter, the outgoing WAN IP is 100.64.31.2, however if I set pref-src to 100.64.31.6, still 100.64.31.2 is used…

# CoreRouter
/ip/route/add gateway=100.64.31.1 dst-address=0.0.0.0/0 pref-src=100.64.31.6

ProviderEdge Packet Sniffer:
winbox64_7zExWzjrr1.png

Thanks for that, I didn’t realise it was that simple.


I was able to setup SRC-NAT without any problem using a specific IP from the Subnet.
Not exactly sure what the issue with DST-NAT and multiple WAN interfaces would be, but since I only have 1 WAN it shouldn’t be a problem. If you could expand on that and give an example of how to set the correct return interface I would be appreciated it, but it isn’t necessary.


I am very inexperienced with IPv6. I know that the goal is to not use NAT and was thinking I just give the WAN Interface the /64 subnet and the Router Uses that Subnet to assign IPs to LAN devices. Or alternatively, can’t the IPv6 /64 subnets be split in multiple subnets, for example /96 and those be used for LAN devices?

5

You’re right about error in my example regarding setting pref-src, it should be set to one of addresses owned by your router. I’m not sure if all the tools available on router (e.g. ping, traceroute, etc.) fully honour pref-src setting, could be that some implement own algorithms to select src-address (they shouldn’t IMO).
However, what I observed is that router uses pref-src setting when replying to pings … and replies are to be routed through certain egress interface. This comes particularly handy if that interface is a true PtP (e.g. IPIP tunnel) which doesn’t need own IP address and then router has to select one of local addresses as source address … with pref-src selection becomes deterministic.

Re. DST-NAT and multiple WAN interfaces: consider having two WAN Interfaces, provided by different ISPs. And you have default route set on one of lines (e.g. WAN1). Then you have DST NAT set on WAN2. When a packet comes in through WAN2, router does NAT, passes packet to internal server. Internal server replies, router undoes NAT. Then it check routing table and sees it has to use WAN1 as egress interface. Very probably ISP1 will drop such packet as it uses src-address which is not valid inside its network. To overcome this problem, it is necessary to mark packets, arriving via WAN2 and then use packet mark to add routing mark in order to use routing table particular to WAN2 (which will also contain default route but using ISP2 gateway). There are quite a few forum topics, solving the same problem, one of them is this one.

Re IPv6: in theory it is possible to use subnets with prefix longer than 64 bits. However support seems to be flakey on some devices / OSes, so it’s best to go with /64. Many ISPs follow the suit and provide customers with shorter prefixes (e.g. /60 or /56, for corporate customers they often provide /48), which gives possibility to use multiple /64 subnets. One of reasons for using /64 subnets is that when one uses SLAAC (as opposed to proper DHCPv6), devices construct their permanent IPv6 address by using prefix and adding own MAC address (and insert additional two octets ff:fe in between) which doesn’t work with longer prefixes. Also devices tend to construct temporary IPv6 addresses (to improve security, remember NATv6 was not supposed to exist) and depending on implementation also this could break when using longer prefixes. It is possible to set DHCPv6 client with property prefix-hint … set it to something like “::/60” and see if ISP’s DHCPv6 server honours such request by giving out prefix shorter than /64. Some ISP’s don’t honour such requests, I just tried to set prefix-hint to “::/60”, but yet router received prefix with length of /56 … which is fine with me but I expect the request for e.g. /52 would also fail the same way. Recently somebody mentioned that it is possible to set prefix-hint to a more defined value than “::/len”, e.g. prefix-hint=“2a00:1450:4002:406::/56” and if possible, router will receive that prefix … making IPv6 addresses pseudo-static even if your subscription doesn’t include one.

There are a few other gotchas with IPv6 on ROS:

  • don’t set add-default-route property to yes under DHCPv6 client settings. This option means that DHCPv6 client will add DHCPv6 server’s address as default gateway. While this might work in certain cases, it’s plain wrong in most cases. For correct solution see next bullet.
  • set property accept-router-advertisements=yes under /ipv6 settings. Default value is yes-if-forwarding-disabled which works for end device but not for router (which has forward=yes). This means that router will accept router announcements on WAN interface. It’ll construct it’s WAN address as per SLAAC and will accept upstream router’s address. Note that due to bug in all ROS versions so far this address and gateway are not seen in list of IPv6 addresses and IPv6 routes.
    The side effect of setting this property is that misconfigured devices (both on WAN side as well as LAN side) can mess your router and if that happens, you’ll have to deal with it appropriately (assuming you control LAN side you’ll have to find misbehaving device and destroy it … or execute devices’ admin … for WAN side you’ll probably have to complain to ISP and then they’ll perform necessary steps).