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 the maximum is enough scheme in Visio.
And here is the scheme itself
But what is the actual problem?
The problem is that on router R1 there are three 192.168.0.0/24 networks, and the third problem is that the remote network also has a network of 192.168.0.0/24
At the time of the start of work, the problem with two providers was decided 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 VPN between R1 and R2, and evenly divide traffic between offices across channels.
Well, the task is set, it seems clear, we proceed to build labs in UnetLab
')
I had to fully provide the config for the equipment, so I did “one to one”, all the real IP addresses and so on.
Here is the scheme in UnetLab
All providers are connected to AS 65530 between the “ISP” routers and the “internet” central router.
Transport network 10.0.0.0/8
In order to eliminate a configuration error and not to fence a bunch of networks for management, RoMON is enabled on all routers, which allows you to connect via winbox via mac to the router via other routers.
The problem is that the router has an IP address of 192.168.0.1/24, and the provider gives it a DHCP address from the same 192.168.0.0/24 network.
It is good that the gateway has not changed.
If you leave everything as it is, MikroTik starts building ECMP on Connected routes, the behavior is expected. But we need to separate these networks; pure Policy Base Routing will not help us, as 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, the search will continue in the main table, for VRF, traffic will only be searched for in its own table by default.
Pay attention to the last three lines, this is a static VRF.
At the moment, the routing table is as follows.
All would be nothing, but as I said earlier from the VRF is not so easy to get out, and for these purposes, MikroTik provides for “route leakage”.
We implement leakage we specify two default routes.
Notice how the gateway is written, the interface, the one that is in the VRF, is added to the end via the percent sign.
Now, when accessing from the main table through the default route, the traffic will go to the VRF table. But here lies a hitch, since this is a VRF, then the returned traffic itself will not fall into the main table from the VRF it needs to be helped =)
1,2,4,5 - these are standard rules. They have nothing interesting there, they guarantee the return of local traffic back.
But the third and sixth rules, where new-routing-mark = main, is an exception to the traffic table VRF
And so the configuration of the two providers is completed, go to the VPN
Since there is no real address on R1, and the provider refuses to push 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 I couldn’t specify the src-address from the client’s side as in an ipip or gre tunnel, in other words, I won’t catch traffic to send a second tunnel through a second provider. The destination address of the two tunnels is the same; on the server, do not pick up two sstp servers on different IP or different ports.
The decision was not long in coming, I remembered about dst-nat, who's stopping us from changing the port already on the server using firewalls ?! no one! Moreover, in MikroTik there is an action redirect, one of the subsets of dst-nat. As a result, on the client we use two ports 443 (ISP1) and 1443 (ISP2)
R2
The last rule is responsible for the redirect from 1443 to 443 (sstp Server)
R1
The last rule is responsible for the output of the sstp client through the second provider.
Of course, I will not be able to configure work between the two networks at their original addresses, if there was one DHCP server with a relay, then you could either raise a common brudkast domain, or raise arp-proxy on routers, but this is a separate story.
And so there is a solution, we will substitute the destination address and the sender address and appeal with whole networks.
From the side of R1 there will be a network 192.168.3.0/24
From the R2 side there will be a network 192.168.4.0/24
As you can see, we published one static route of the prohibit type, we need them only for publishing via OSPF and raising ECMP.
OSPF is easy to configure and there is no point in describing it, I’ll just say that with these settings, VPNs will automatically exchange networks, 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 deny everything.
Allow all routes from the network 192.168.0.0/16 and long / 24
Ban all routes
Once again, I remind you that in any dynamic routing protocol, you must use filters and you do not need to publish all the networks in a row. Remember the sad experience of yandex
How are we going to replace whole networks?
Everything is trite and simple, we will use special rules in NAT same and netmap.
Let's look from the side of router R1
Proper
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 to R2 will be available from R1 via the network 192.168.4.0/24
Actually, the NAT rules themselves
Proof
MikroTik - OSPF
MikroTik - VRF
MikroTik - NAT
MikroTik - RoMON
UnetLab
If someone wants to deploy this configuration on UnetLab, go to PM, my site will not be able to handle
For such small tasks TK is usually not written, and the maximum is enough scheme in Visio.
And here is the scheme itself
But what is the actual problem?
The problem is that on router R1 there are three 192.168.0.0/24 networks, and the third problem is that the remote network also has a network of 192.168.0.0/24
At the time of the start of work, the problem with two providers was decided 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 VPN between R1 and R2, and evenly divide traffic between offices across channels.
Well, the task is set, it seems clear, we proceed to build labs in UnetLab
')
I had to fully provide the config for the equipment, so I did “one to one”, all the real IP addresses and so on.
Here is the scheme in UnetLab
All providers are connected to AS 65530 between the “ISP” routers and the “internet” central router.
Transport network 10.0.0.0/8
In order to eliminate a configuration error and not to fence a bunch of networks for management, RoMON is enabled on all routers, which allows you to connect via winbox via mac to the router via other routers.
The first problem that had to be solved was of course the providers on router R1.
The problem is that the router has an IP address of 192.168.0.1/24, and the provider gives it a DHCP address from the same 192.168.0.0/24 network.
It is good that the gateway has not changed.
If you leave everything as it is, MikroTik starts building ECMP on Connected routes, the behavior is expected. But we need to separate these networks; pure Policy Base Routing will not help us, as 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, the search will continue in the main table, for VRF, traffic will only be searched for in its own table by default.
And so proceed to configure 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 a static VRF.
At the moment, the routing table is as follows.
All would be nothing, but as I said earlier from the VRF is not so easy to get out, and for these purposes, MikroTik provides for “route leakage”.
We implement leakage we specify 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 Notice how the gateway is written, the interface, the one that is in the VRF, is added to the end via the percent sign.
Now, when accessing from the main table through the default route, the traffic will go to the VRF table. But here lies a hitch, since this is a VRF, then the returned traffic itself will not fall into the main table from the 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. They have nothing interesting there, they guarantee the return of local traffic back.
But the third and sixth rules, where new-routing-mark = main, is an exception to the traffic table VRF
And so the configuration of the two providers is completed, go to the VPN
VPN configuration
Since there is no real address on R1, and the provider refuses to push 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 I couldn’t specify the src-address from the client’s side as in an ipip or gre tunnel, in other words, I won’t catch traffic to send a second tunnel through a second provider. The destination address of the two tunnels is the same; on the server, do not pick up two sstp servers on different IP or different ports.
The decision was not long in coming, I remembered about dst-nat, who's stopping us from changing the port already on the server using firewalls ?! no one! Moreover, in MikroTik there is an action redirect, one of the subsets of dst-nat. As a result, on the client we use two ports 443 (ISP1) and 1443 (ISP2)
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 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 the output of the sstp client through the second provider.
Configure OSPF and NAT
Of course, I will not be able to configure work between the two networks at their original addresses, if there was one DHCP server with a relay, then you could either raise a common brudkast domain, or raise arp-proxy on routers, but this is a separate story.
And so there is a solution, we will substitute the destination address and the sender address and appeal with whole networks.
From the side of R1 there will be a network 192.168.3.0/24
From the R2 side 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 one static route of the prohibit type, we need them only for publishing via OSPF and raising ECMP.
OSPF is easy to configure and there is no point in describing it, I’ll just say that with these settings, VPNs will automatically exchange networks, 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 deny 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 Ban all routes
Once again, I remind you that in any dynamic routing protocol, you must use filters and you do not need to publish all the networks in a row. Remember the sad experience of yandex
How are we going to replace whole networks?
Everything is trite and simple, we will use special rules in NAT same and netmap.
Let's look from the side of router R1
Proper
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 to R2 will be available from R1 via 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 this configuration on UnetLab, go to PM, my site will not be able to handle
Source: https://habr.com/ru/post/282858/
All Articles