Mikrotik, 7

content/snippets/0250-configuring-a-mikrotik.md

@@ -90,19 +90,11 @@ This was a hard one.
 
 I've this Kubernetes cluster providing services like Nextcloud and Bitwarden, which I want to access from my mobile from my Intranet WLAN but also from off-road via 5G. 
 
-This is working perfectly in the current setup using a LANCOM router. But when switching to Mikrotik with naively the same rules, I was able to access the Internet from my Intranet and
-I was able to access the services on the Kubernetes cluster from the world (using my mobile via 5G), but I was not able to access the services on the Kubernetes cluster from the Intranet 
-using the public address of my Internet connection.
+This is working perfectly in the current setup using a LANCOM router. But when switching to Mikrotik with naively the same rules, I was able to access the Internet from my Intranet and I was able to access the services on the Kubernetes cluster from the world (using my mobile via 5G), but I was not able to access the services on the Kubernetes cluster from the Intranet using the public address of my Internet connection.
 
-It was a lot of debugging to understand the problem: the masquarading rule (`srcnat`), which is bound to the outgoing interface WAN is not triggered, because packets are no leaving the router through the WAN interface 
-since they are addressed to an address which is configured directly on the router. Those, the source address of the packets will not be rewritten. The port-forwarding rule (`dstnat`) in turn is triggered, because a
-configured port is accessed via the public address of the router. The service itself consequently sees the original source address of the packet (the actual client address, which is in the scope of the router) and sends response
-packets to this address. These packets will be routed directly to the client without passing the connection handling of the masquarading engine. And then, the client sends to the public address of the router and receives directly
-from the service and thereby can not associate the request and response packet to the same connection.
+It was a lot of debugging to understand the problem: the masquarading rule (`srcnat`), which is bound to the outgoing interface WAN is not triggered, because packets are no leaving the router through the WAN interface since they are addressed to an address which is configured directly on the router. Those, the source address of the packets will not be rewritten. The port-forwarding rule (`dstnat`) in turn is triggered, because a configured port is accessed via the public address of the router. The service itself consequently sees the original source address of the packet (the actual client address, which is in the scope of the router) and sends response packets to this address. These packets will be routed directly to the client without passing the connection handling of the masquarading engine. And then, the client sends to the public address of the router and receives directly from the service and thereby can not associate the request and response packet to the same connection.
 
-The solution is to setup a dedicated masquarading rule which has the service addresses as `dst-address` condition and the addresses of the internal client networks as `src-address` condition. This rule will be triggered in the 
-above described scenario and the source address is replaced by the local address of the interface, where the packet is leaving the router. That in turn will be used by the server to send responses to and then is handling correctly 
-by the masquarading engine.
+The solution is to setup a dedicated masquarading rule which has the service addresses as `dst-address` condition and the addresses of the internal client networks as `src-address` condition. This rule will be triggered in the above described scenario and the source address is replaced by the local address of the interface, where the packet is leaving the router. That in turn will be used by the server to send responses to and then is handling correctly by the masquarading engine.
 
 In the end I came to this rule:
 
@@ -115,8 +107,7 @@ add action=masquerade chain=srcnat \
 
 The both mentioned lists `CLIENTS` and `SERVICES` are maintained at `/ip/firewall/address-list`.
 
-To be honest, this special case is described in the [Mikrotik documentation](https://help.mikrotik.com/docs/spaces/ROS/pages/3211299/NAT#NAT-HairpinNAT), but I didn't understood it and had to learn it myself with 
-an interesting test setup
+To be honest, this special case is described in the [Mikrotik documentation](https://help.mikrotik.com/docs/spaces/ROS/pages/3211299/NAT#NAT-HairpinNAT), but I didn't understood it and had to learn it myself with an interesting test setup
 
 ![](/static/IMG_6139.jpg)