MikroTik and 192.168.0.0/24

    At first glance, the customer came to me with the simple task of “raising two providers and setting up a VPN between two offices”.

    For such small tasks, TK is usually not written, and a maximum of a scheme in Visio is enough.
    And here is the circuit itself

    And here is the problem.
    The problem is that there are three 192.168.0.0/24 networks on the R1 router, as well as the third problem - the remote network also has a network 192.168.0.0/24.

    At the beginning of work, the problem with two providers was solved by connecting routers to each of the providers, There was no VPN connection.
    The task is to configure the central router to work with two providers and remove two intermediate routers from the network, configure the VPN between R1 and R2, and evenly divide the traffic between offices across the channels.

    Well, the task is set, it seems to be understandable, we are starting to build the lab in UnetLab.

    I needed to fully provide the config for the equipment, so I did it “one to one”, all real IP addresses and so on.
    This is what UnetLab looks like

    Between routers of “providers” and the central router “internet”, BGP was raised; all providers are connected to AS 65530.

    Transport network 10.0.0.0/8
    In order to eliminate a configuration error and not block a bunch of networks for control, RoMON is enabled on all routers, which allows connect using winbox on mac to the router via other routers.

    The first problem that had to be solved was of course the providers on the R1 router.


    The problem is that the router has an IP address of 192.168.0.1/24, and the provider provides DHCP address from the same network 192.168.0.0/24.
    It is good that the gateway did not change.
    If you leave it as it is, then MikroTik begins to build ECMP on Connected routes, the expected behavior. But we need to separate these networks, pure Policy Base Routing will not help us, since it applies only to traffic in mangle.
    Our solution is to use static VRF, which is positioned on the interface.
    The main difference between RBP and VRF is that with RBP by default, if no suitable route is found in the table, then the search will continue in the main table, for VRF, by default, traffic will be searched only in its table.

    And so let's get down to setting up R1.


    /ip address
    add address=192.168.0.1/24 interface=ether4
    /ip firewall nat
    add action=masquerade chain=srcnat out-interface=ether1
    add action=masquerade chain=srcnat out-interface=ether2
    /ip dhcp-client
    add default-route-distance=0 dhcp-options=hostname,clientid disabled=no interface=ether1
    add default-route-distance=0 dhcp-options=hostname,clientid disabled=no interface=ether2
    /ip route vrf
    add interfaces=ether1 routing-mark=ISP1
    add interfaces=ether2 routing-mark=ISP2
    

    Pay attention to the last three lines, this is static VRF.
    At the moment, the routing table is as follows.


    All would be nothing, but as I said earlier from VRF it is not so easy to get out, and for these purposes MikroTik provides a “route leak”.
    We realize the leak, we indicate two default routes.
    /ip route
    add check-gateway=ping distance=10 gateway=192.168.0.1%ether1
    add check-gateway=ping distance=20 gateway=192.168.0.1%ether2
    

    Pay attention to how the gateway is written, an interface is added to it at the end through the percent sign, the same one that is in VRF.
    Now, when accessing from the main table through the default route, traffic will go to the VRF table. But here lies the catch, since this is VRF, then the returned traffic itself will not get into the main table from VRF, it needs to be helped =)
    /ip firewall mangle
    add action=mark-connection chain=input in-interface=ether1 new-connection-mark=Input/ISP1
    add action=mark-routing chain=prerouting connection-mark=Input/ISP1 new-routing-mark=ISP1 passthrough=no
    add action=mark-routing chain=prerouting in-interface=ether1 new-routing-mark=main passthrough=no
    add action=mark-connection chain=input in-interface=ether2 new-connection-mark=Input/ISP2
    add action=mark-routing chain=prerouting connection-mark=Input/ISP2 new-routing-mark=ISP2 passthrough=no
    add action=mark-routing chain=prerouting in-interface=ether2 new-routing-mark= main passthrough=no
    


    1,2,4,5 - these are standard rules; there is nothing interesting in them; they guarantee the return of local traffic back.
    And here are the third and sixth rules where new-routing-mark = main is the exception of the traffic table from the VRF.
    And so the configuration of the two providers is completed, go to the VPN

    VPN setup


    Since there is no real address on R1, and the provider refuses to forward at least a couple of ports, it was decided to use one of the Client-to-Server tunnels, the choice fell on SSTP.
    I started setting up SSTP server profiles and so on, as it dawned on me that the client I will not be able to specify src-address as in an ipip or gre tunnel, in other words, I will not be hooked on the traffic so that the second tunnel can be sent through the second provider. The destination address of the two tunnels is the same, on the server, do not raise two sstp servers on different IP or different ports.

    The decision was not long in coming, I remembered about dst-nat, who is stopping us from changing the port on the server using the firewall ?! no one! Moreover, MikroTik has an action redirect, one of the subsets of dst-nat. As a result, we use two ports 443 (ISP1) and 1443 (ISP2) on the client

    R2
    /ppp profile
    set *0 local-address=172.31.255.254
    /ppp secret
    add name=ppp1 password=ppp1 remote-address=172.31.255.1 service=sstp
    add name=ppp2 password=ppp2 remote-address=172.31.255.2 service=sstp
    /interface sstp-server server
    set enabled=yes
    /ip firewall nat
    add action=redirect chain=dstnat dst-port=1443 in-interface=ether1 protocol=tcp to-ports=443
    

    The last rule is just responsible for the redirect from 1443 to 443 (sstp Server)
    R1
    /interface sstp-client
    add connect-to=1.1.1.2 disabled=no mrru=1600 name=ISP1/R2 password=ppp1 profile=default-encryption user=ppp1
    add connect-to=1.1.1.2:1443 disabled=no mrru=1600 name=ISP2/R2 password=ppp2 profile=default-encryption user=ppp2
    /ip firewall mangle
    add action=mark-routing chain=output dst-address=1.1.1.2 dst-port=1443 new-routing-mark=ISP2 passthrough=no protocol=tcp
    

    The last rule is responsible for exiting the sstp client through the second provider.

    Configure OSPF and NAT



    Of course, I can’t configure the work between the two networks at their original addresses, if there was one DHCP server with a relay, then it would be possible to raise a common broodcast domain, or to raise arp-proxy on routers, but this is a different story.
    And so there is a solution, we will replace the destination address and the sender address and appeal with entire networks.

    From the side of R1 there will be a network 192.168.3.0/24
    From the side of R2 there will be a network 192.168.4.0/24

    Configure R1 and OSPF

    /routing ospf instance
    set [ find default=yes ] disabled=yes redistribute-static=as-type-1 router-id=192.168.3.1
    /routing filter
    add action=accept chain=ospf-in prefix=192.168.0.0/16 prefix-length=24
    add action=discard chain=ospf-in
    add action=accept chain=ospf-out prefix=192.168.0.0/16 prefix-length=24
    add action=discard chain=ospf-out
    /routing ospf network
    add area=backbone network=172.31.255.0/24
    /ip route
    add distance=1 dst-address=192.168.3.0/24 type=prohibit
    


    Configure R2 and OSPF

    /routing ospf instance
    set [ find default=yes ] redistribute-static=as-type-1 router-id=192.168.4.1
    /routing filter
    add action=accept chain=ospf-in prefix=192.168.0.0/16 prefix-length=24
    add action=discard chain=ospf-in
    add action=accept chain=ospf-out prefix=192.168.0.0/16 prefix-length=24
    add action=discard chain=ospf-out
    /routing ospf network
    add area=backbone network=172.31.255.0/2
    /ip route
    add distance=1 dst-address=192.168.4.0/24 type=prohibit
    

    As you can see, we published along a single static route like prohibit, we only need them for publishing via OSPF and raising ECMP.
    OSPF is easy to configure and it makes no sense to describe it, just say that with these settings over VPN tunnels, networks will automatically exchange, and if there are two live tunnels, ECMP will rise.
    Let's go through the filters a bit. The
    rules in the filters are terminating, so first we allow something, and then we forbid everything.
    add action=accept chain=ospf-in prefix=192.168.0.0/16 prefix-length=24 
    

    Allow all routes from the network 192.168.0.0/16 and long / 24
    add action=discard chain=ospf-in
    

    Forbidding all routes

    I remind you once again that in any dynamic routing protocol it is necessary to use filters and not to publish all networks in a row. Remember the sad experience of yandex.
    How will we replace whole networks?
    Everything is banal and simple, we will use special rules in NAT same and netmap.
    Let's look from the side of router R1

    Actually, the
    Network 192.168.0.0/24 on R1 will be available from R2 over the network 192.168.3.0/24
    The network 192.168.0.0/24 on R2 will be available from R1 over the network 192.168.4.0/24

    Actually, the NAT rules themselves

    For R1


    /ip firewall nat
    add action=same chain=srcnat dst-address=192.168.4.0/24 src-address=192.168.0.0/24 to-addresses=192.168.3.0/24
    add action=netmap chain=dstnat dst-address=192.168.3.0/24 src-address=192.168.4.0/24 to-addresses=192.168.0.0/24
    

    For R2


    /ip firewall nat
    add action=same chain=srcnat dst-address=192.168.3.0/24 src-address=192.168.0.0/24 to-addresses=192.168.4.0/24
    add action=netmap chain=dstnat dst-address=192.168.4.0/24 src-address=192.168.3.0/24 to-addresses=192.168.0.0/24
    


    Proof
    MikroTik - OSPF
    MikroTik - VRF
    MikroTik - NAT
    MikroTik - RoMON
    UnetLab

    If someone wants to deploy such a configuration on UnetLab, please use a personal message, my website will not stand the habraeffect

    Also popular now: