How to Isolate Windows and Linux Servers with MikroTik Routed Public /32 Addresses

Force every server connection through the router for security, visibility, and control.

Assigning public IP addresses directly to servers is common in hosting, ISP, and enterprise environments. However, placing multiple public-addressed servers on the same Layer-2 VLAN can create an unnecessary security problem: the servers may be able to communicate directly with each other without passing through the router or firewall.

This article explains a stronger design using MikroTik RouterOS, VLAN segmentation, DHCP-assigned private transit networks, and routed public /32 addresses. The result is simple: every server must send traffic through the MikroTik router to reach the internet, another server, a management network, or any other destination.

Why a Shared Public VLAN Is Not Enough

A common design assigns a public /28, /27, or larger block directly to a bridge or VLAN. Each server receives an address from that block and uses the MikroTik router as its default gateway.

That works for normal routing, but it does not guarantee isolation. If multiple servers share the same Layer-2 broadcast domain, they can discover each other with ARP and potentially exchange traffic directly. Even if every server is configured with a /32 mask, a compromised or incorrectly configured server could add routes, manipulate ARP, or otherwise attempt to bypass the intended router path.

Recommended Architecture

The recommended design uses one VLAN per server, or one VLAN per security zone when multiple servers have the same trust level. Each server VLAN receives a small private transit subnet. The MikroTik router is the gateway for that transit subnet, and DHCP provides the server address.

The public IP address is then installed as a separate /32 on the Windows or Linux server. The MikroTik router maintains a host route for that public address through the server's private DHCP reservation.

The public addresses in this example use documentation space only. Replace them with your assigned public prefix. This design assumes that the public block is routed to the MikroTik router by an upstream provider or advertised through BGP. The public block should not be bridged directly to all server ports.

How the Traffic Flow Works

Assume 198.51.100.0/28 is routed to the MikroTik router. Server 1 owns 198.51.100.2/32, but it is connected to the router through private transit network 10.255.101.0/30.

1. Traffic from the internet arrives at the MikroTik router for 198.51.100.2.
2. The MikroTik router matches a host route for 198.51.100.2/32.
3. The route points to Server 1's reserved transit IP, 10.255.101.2.
4. The router forwards the packet into VLAN 101.
5. Server 1 replies to its default gateway, 10.255.101.1.
6. The reply returns through the MikroTik firewall and routing table before leaving the server VLAN.

The same rule applies when Server 1 attempts to reach Server 2. They are in separate VLANs, so there is no direct Layer-2 path. The packet must enter the MikroTik, where forward-chain firewall policy determines whether the connection is allowed.

MikroTik VLAN Design

In RouterOS, create a bridge with VLAN filtering, place each server-facing physical port into its own access VLAN, and create a VLAN interface on the bridge for Layer-3 routing. The example below uses three server ports directly connected to the MikroTik.

/interface bridge
add name=bridge-servers vlan-filtering=no

/interface bridge port
add bridge=bridge-servers interface=ether5 pvid=101 frame-types=admit-only-untagged-and-priority-tagged
add bridge=bridge-servers interface=ether6 pvid=102 frame-types=admit-only-untagged-and-priority-tagged
add bridge=bridge-servers interface=ether7 pvid=103 frame-types=admit-only-untagged-and-priority-tagged

/interface bridge vlan
add bridge=bridge-servers vlan-ids=101 tagged=bridge-servers untagged=ether5
add bridge=bridge-servers vlan-ids=102 tagged=bridge-servers untagged=ether6
add bridge=bridge-servers vlan-ids=103 tagged=bridge-servers untagged=ether7

/interface vlan
add name=vlan101-server1 interface=bridge-servers vlan-id=101
add name=vlan102-server2 interface=bridge-servers vlan-id=102
add name=vlan103-server3 interface=bridge-servers vlan-id=103

/interface bridge
set bridge-servers vlan-filtering=yes

If the servers connect through an access switch instead of directly to the MikroTik, configure the switch uplink as a VLAN trunk and configure each server-facing port as an access port in its assigned VLAN.

Assign Private Transit Addresses with DHCP

Use DHCP for the private transit addresses, not for the public addresses. Each DHCP scope has only one available server address, and each server should receive a static DHCP lease based on its MAC address. This keeps the route next hop predictable and makes hardware replacement easier to manage.

/ip address
add address=10.255.101.1/30 interface=vlan101-server1 comment="Server 1 gateway"
add address=10.255.102.1/30 interface=vlan102-server2 comment="Server 2 gateway"
add address=10.255.103.1/30 interface=vlan103-server3 comment="Server 3 gateway"

/ip pool
add name=pool-server1 ranges=10.255.101.2-10.255.101.2
add name=pool-server2 ranges=10.255.102.2-10.255.102.2
add name=pool-server3 ranges=10.255.103.2-10.255.103.2

/ip dhcp-server
add name=dhcp-server1 interface=vlan101-server1 address-pool=pool-server1 authoritative=yes
add name=dhcp-server2 interface=vlan102-server2 address-pool=pool-server2 authoritative=yes
add name=dhcp-server3 interface=vlan103-server3 address-pool=pool-server3 authoritative=yes

/ip dhcp-server network
add address=10.255.101.0/30 gateway=10.255.101.1 dns-server=10.255.101.1
add address=10.255.102.0/30 gateway=10.255.102.1 dns-server=10.255.102.1
add address=10.255.103.0/30 gateway=10.255.103.1 dns-server=10.255.103.1

Create a static lease for each server. Replace the sample MAC address with the server NIC MAC address.

/ip dhcp-server lease
add server=dhcp-server1 address=10.255.101.2 mac-address=00:11:22:33:44:55 comment="Server 1"
add server=dhcp-server2 address=10.255.102.2 mac-address=00:11:22:33:44:66 comment="Server 2"
add server=dhcp-server3 address=10.255.103.2 mac-address=00:11:22:33:44:77 comment="Server 3"

Route Each Public /32 Through Its Server

The MikroTik router needs one host route for each public server address. The gateway is the server's reserved private transit address.

/ip route
add dst-address=198.51.100.2/32 gateway=10.255.101.2 comment="Public route to Server 1"
add dst-address=198.51.100.3/32 gateway=10.255.102.2 comment="Public route to Server 2"
add dst-address=198.51.100.4/32 gateway=10.255.103.2 comment="Public route to Server 3"

No source NAT is required for services using the public addresses. The router is performing normal routing: public traffic arrives at the MikroTik, is routed to the correct private transit next hop, and is delivered to the public /32 configured on the server.

Windows Server Configuration

Windows Server should receive its private transit address and default gateway through DHCP. Add the public address as a secondary /32 address on the same interface. Do not add a second default gateway.

New-NetIPAddress `
  -InterfaceAlias "Ethernet" `
  -IPAddress 198.51.100.2 `
  -PrefixLength 32 `
  -SkipAsSource $false

The server's primary DHCP configuration remains similar to the following:

Responses to inbound connections addressed to the public IP normally retain the public IP as their source. For server-originated outbound traffic, determine whether the server should use its public address, a private address with MikroTik source NAT, or a dedicated source-based routing policy. This should be intentional and documented for each server role.

Linux Server Configuration

Linux servers follow the same model: DHCP provides the private transit address and default route, while the public IP is configured as a secondary /32 address.

ip address add 198.51.100.2/32 dev eth0

Persist the public /32 through Netplan, NetworkManager, or systemd-networkd depending on the Linux distribution. The DHCP-provided default route should remain unchanged:

default via 10.255.101.1 dev eth0

Firewall Policy: Block Lateral Server Traffic by Default

VLAN isolation prevents direct Layer-2 communication. The MikroTik firewall controls routed Layer-3 traffic. Create an interface list containing the server VLAN interfaces, permit only required services, and deny server-to-server forwarding by default.

/interface list
add name=SERVERS

/interface list member
add list=SERVERS interface=vlan101-server1
add list=SERVERS interface=vlan102-server2
add list=SERVERS interface=vlan103-server3

/ip firewall filter
add chain=forward action=accept connection-state=established,related,untracked
add chain=forward action=drop connection-state=invalid

# Example: allow HTTPS to Server 1 from the internet
add chain=forward action=accept in-interface-list=WAN \
    dst-address=198.51.100.2 protocol=tcp dst-port=443 \
    comment="Allow HTTPS to Server 1"

# Example: allow server VLANs to reach the internet
add chain=forward action=accept in-interface-list=SERVERS out-interface-list=WAN \
    comment="Allow server outbound internet access"

# Add specific server-to-server exceptions above this rule if required
add chain=forward action=drop in-interface-list=SERVERS out-interface-list=SERVERS \
    comment="Block server-to-server traffic by default"

Do You Need One VLAN Per Server?

If every server must be forced through the router, the answer is generally yes. One VLAN per server is the clearest and most reliable way to create a hard Layer-2 boundary.

RouterOS bridge split-horizon and switch-chip port-isolation features can also limit direct port-to-port forwarding. Those features can be useful in some environments, but VLAN-per-server designs are easier to document, troubleshoot, scale, and enforce across different switch platforms.

A shared VLAN with public /32 addresses may work for ordinary routing, but it should not be treated as a complete server-isolation solution. Dedicated VLANs ensure that no server can directly ARP, scan, or communicate with another server outside the router and firewall policy.

Deployment Checklist

The Bottom Line

The most secure and manageable way to assign public IP addresses to servers is not to bridge the public subnet directly to every server. Instead, route each public IP as a /32 through a private, DHCP-managed transit network on a dedicated VLAN.

This approach gives the MikroTik router complete visibility and control over traffic. Every packet enters the routing and firewall path, Windows and Linux servers remain isolated from one another, and security policy is enforced centrally instead of relying only on server configuration.

References

• MikroTik RouterOS Bridging and VLAN Filtering Documentation
• MikroTik RouterOS DHCP Documentation
• MikroTik Bridge Split-Horizon Documentation
• Microsoft DHCP Classless Static Route Option Documentation
• Linux ip-route Manual