DstNAT in bridge

pavgre · June 17, 2026, 9:19am

Hello,

I have a mikrotik CRS326-24g-2s. Port 1 and 2 are bridged. Bridge's IP 192.168.100.1. in port 1 there are many device thoset make connection to a MSSQL server in PC in port 2. Let's take a n example with one device. Device's IP 192.168.100.31 and server is 192.168.100.200. Now we have other MSSQL server in port4 and ip 192.168.1.18.

How can i make a dstnat? I enable the bridge firewall, remove hardware offload from ether 1 and make nat rule in ip firewall. I see that the packet counter increase but no connection. What additional configuration i have to do.

Thank you.

CGGXANNX · June 17, 2026, 10:38am

Is the CRS326 the default gateway of the 192.168.100.x devices (do those devices use 192.168.100.1 as gateway router)?
Is the 192.168.1.18 host on the same layer 2 network as all the 192.168.100.x devices, or in a separate VLAN?
Does the 192.168.1.18 also use the CRS326 as default gateway? or is there a separate router?
Is the old server at 192.168.100.200 still on the network?
Should all IP traffic (all protocols and ports) towards 192.168.100.200 be DSTNAT-ed, or only select TC ports?

mkx · June 17, 2026, 12:37pm

And (perhaps most crucially): CRS326-24g-2s+ is a switch. Although it's running ROS (and thus capable of routing and whatnot), its performance is low due to relatively weak CPU. There is a set of L3 (IP) functions that can be offloaded to switch chip. But in case of CRS326-24g-2s+ NAT is not one of them.

pavgre · June 17, 2026, 1:35pm

Hello CGGXANNX

yes the CRS is the default gateway of the device and it uses the 192.168.100.1 as gateway. The bridge is 192.168.100.1 and has the port 1 and 2.
no, they are not on the same layer 2. there are no VLANs. Simple network
the 192.168.1.18 has other separate gateway.
yes. The 192.168.100.200 is on the network.
the only protocol is the TCP 1433. MSSQL port.

Thank you for response

pavgre · June 17, 2026, 2:17pm

Hello mkx.

I was made a mistake. The mikrotik device is RB3011UiAS not CSR326.

CGGXANNX · June 18, 2026, 8:31am

Ok, then use-ip-firewall=yes is not the right solution for your needs. When you turn that on without doing additional bridge DSTNAT and bridge SRCNAT, your IP firewall NAT rules will not be able to do what you want. See: Packet Flow in RouterOS | RouterOS Manual.

Because the destination MAC address is not changed, even after going through the IP firewall with its NAT rules, the ethernet frames will still follow the path of this orange arrow, and will not touch the routing decision needed to direct the packets to other networks (green arrow)

The Bridging Decision part at number 4 in this diagram:

only cares about the destination MAC address, and that MAC address has not changed (still being the MAC address of the 192.168.100.200 host). Which means the decision is to forward the frame to that host, even though your IP firewall DSTNAT rules have modified the destination IP address of the packets. use-ip-firewall might easily help you implement firewall filter rules that drop packets, but when NAT is involved, it's no longer straightforward!

You should do this instead, I am assuming that the current bridge is named bridge1, and the port where the 192.168.100.200 server is plugged in is ether2:

Turn off use-ip-firewall in the bridge settings, we'll not use that. It only slows everything down while not being able to do what you want.
Remove ether2 from the bridge bridge1, make it a standalone port.
Add a /32 IP address entry on ether2:
```
/ip address
add interface=ether2 address=192.168.100.1/32 network=192.168.100.200
```
Please note that the prefix length is /32 and the network address is the IP address of the PC server!
Set ARP mode of the standalone port ether2 (no longer part of any bridge) to proxy-arp:
```
/interface ethernet
set [ find default-name=ether2 ] arp=proxy-arp
```
Either manually configure the IP address on the PC server to 192.168.100.200 netmask 255.255.255.0 gateway 192.168.100.1, or configure a DHCP server instance running on ether2, that provides the network 192.168.100.0/24 gateway 192.168.100.1 information to its client, and make sure that DHCP server has a static lease 192.168.100.200 for the PC server plugged to ether2.

In short, this step assigns the 192.168.100.200 IP address to the server and tell it to use 192.168.100.1 as gateway.
If you also set the DNS server information for the PC server to be 192.168.100.1 (the router), then don't forget to allow that server access to the input chain of the router. If you use a firewall configuration based on defconf from MikroTik, then add ether2 to the LAN interface list, otherwise add accept rule on chain input accordingly.
On the bridge1 interface (the bridge that the other 192.168.100.x devices are connected too, that has the 192.168.100.1/24 address assignment under /ip address), we'll add published ARP entry for the 192.168.100.200 address (the address of the PC server):
```
/ip arp
add interface=bridge1 address=192.168.100.200 published=yes
```
Make sure that the firewall does not block forwarding between the bridge1 interface and the ether2 interface. If you have "drop all else" rules for example, then don't forget to add explicit accept rules between those two interfaces.

After those steps, the devices 192.168.100.x and the PC server 192.168.100.200 will be able to communicate which each other normally, although they now no longer belong to the same layer 2 network anymore. Traffics between 192.168.100.200 and the others are now routed through the router. And this is what will allow us to easily apply DSTNAT to them.

Add the required DSTNAT rule to NAT MSSQL traffic to destination 192.168.100.200:

/ip firewall nat 
add chain=dstnat action=dst-nat dst-address=192.168.100.200 dst-port=1433 \
     protocol=tcp src-address=192.168.100.0/24 to-addresses=192.168.1.18

Add a masquerade rule for the NAT-ed MSSQL traffic towards 192.168.1.18, needed because the current router is not the default router of that host.
```
/ip firewall nat 
add chain=srcnat action=masquerade dst-address=192.168.1.18 dst-port=1433 \
     protocol=tcp src-address=192.168.100.0/24
```
And of course, don't forget to make sure that forwarding from 192.168.100.0/24 to the remote host 192.168.1.18 is not blocked.

This setup should do the work.