Setting Up a Home Server Network with MikroTik Router (Troubleshooting Process) 🌐

Hello there! Today I’d like to share the network configuration challenges I faced while setting up my home server project ‘MoolMeow’ and how I resolved them. 😊

🌟 Why Create a Separate Network?

First, let me explain why I decided to create a separate network for my home server:

1. Preventing IP Conflicts: My existing home network already had many devices (smartphones, TVs, laptops, etc.) connected with DHCP-assigned IPs. When setting up Kubernetes with fixed IPs, there was a risk of IP conflicts with existing devices.

2. Enhanced Security: The home server would host services that might need external access. By separating the network, I could open only the necessary ports while keeping my home devices protected.

3. Traffic Management: Server traffic wouldn’t impact the performance of the regular home network.

4. Independent Administration: Changes to firewall rules or routing for the server network wouldn’t affect the regular network used by family members.

For these reasons, I decided to add a dedicated server network to my MikroTik router.

🧩 The Problem

I was trying to set up a Kubernetes cluster using my Mac Mini as a home server, but ran into a major issue: no internet connection from the Mac Mini! The virtual machines were created successfully, but I couldn’t download any external packages, which completely blocked my progress. 😱

ping: cannot resolve google.com: Unknown host

🔍 Examining the Network Configuration

1️⃣ Basic Network Structure

My network was configured as follows:

• MikroTik router (model: L009UiGS-RM) connected to the internet via ether1
• Internal network divided into two bridges:
  • bridge: Regular home devices (192.168.10.0/24)
  • bridge-moolmeow: Dedicated for Mac Mini (192.168.20.0/24)
• Mac Mini assigned IP 192.168.20.250 via DHCP

2️⃣ Checking the Routing Table

First, I checked the routing table:

/ip route print

Result:

0 ADS  0.0.0.0/0 via 58.123.45.1 on ether1 [defconf]
1 ADC  192.168.10.0/24 via bridge
2 ADC  192.168.20.0/24 via bridge-moolmeow

The default route looked properly configured! 🆗

3️⃣ Checking Interface Settings

/interface print

Result:

0 ether1        ethernet  ether      1500 up
1 bridge        bridge    bridge     1500 up
2 bridge-moolmeow bridge    bridge     1500 up

4️⃣ Checking Interface List Configuration

/interface list member print

Result:

0 WAN ether1
1 LAN bridge

Wait, bridge-moolmeow isn’t included in any list! 😮

🛠️ Troubleshooting Attempts

1️⃣ Checking NAT Settings

I checked the NAT (Network Address Translation) settings:

/ip firewall nat print

Result:

0 chain=srcnat action=masquerade out-interface-list=WAN

This looks fine. NAT is applied to traffic going out through interfaces in the WAN list.

2️⃣ Checking DNS Settings

/ip dns print

Result:

servers: 8.8.8.8,1.1.1.1
allow-remote-requests: yes

DNS servers are properly configured too! 👍

3️⃣ Testing from the Mac Mini

I checked the network status on the Mac Mini with these commands:

cat /etc/resolv.conf
ping 8.8.8.8

Result:

nameserver 192.168.20.1

ping: sendto: Network is unreachable

DNS is set to the router (192.168.20.1), but packets can’t reach the outside world! 😕

4️⃣ Additional Debugging

I added bridge-moolmeow to the WAN list on the router:

/interface list member add list=WAN interface=bridge-moolmeow

And manually added a route on the Mac Mini:

sudo route add default 192.168.20.1

But it still didn’t work. 😫

💡 Finding the Core Issue!

I examined the firewall rules more carefully:

/ip firewall filter print

Found this rule among the results:

;;; defconf: drop all from WAN not DSTNATed
chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN

Finally found the issue! 🎉

This rule was blocking all new connections coming from interfaces in the WAN list. It was originally meant to block attacks from the outside, but the problem arose when I added bridge-moolmeow to the WAN list, causing traffic from the Mac Mini to be blocked by this rule! 😅

✅ The Solution

There were two possible solutions:

1. Remove bridge-moolmeow from the WAN list and add it to the LAN list
2. Modify the firewall rule to allow traffic from bridge-moolmeow

I chose the first option:

/interface list member remove [find interface=bridge-moolmeow]
/interface list member add list=LAN interface=bridge-moolmeow

Then verified the NAT settings were correct:

/ip firewall nat print

Everything was properly configured! Now the Mac Mini could access the internet. 🎊

🔄 Final Network Configuration

1. ether1: Internet connection, included in WAN list
2. bridge: Regular home network, included in LAN list
3. bridge-moolmeow: Dedicated Mac Mini network, included in LAN list
4. NAT: masquerade applied to traffic going from LAN list → WAN list
5. Firewall: New connections from WAN list are blocked (default security)

💭 Lessons Learned

1. Importance of Interface Lists: In MikroTik, interfaces are classified into logical groups (WAN/LAN), and firewall rules and NAT are applied based on these groups.

2. Understanding Firewall Rules: It’s crucial to understand conditions like connection-state=new connection-nat-state=!dstnat and their implications.

3. Methodical Debugging: Networking issues are best approached systematically, checking routing → NAT → DNS → firewall in sequence.

MikroTik routers are incredibly powerful, but sometimes a small setting like this can bring your entire network to a halt. The process of systematically solving the problem was quite interesting! 😄