SRCNAT issue

RouterOS General
1

Hello,
we are trying to migrate from zyxel router to cloudcore box in production env. Once we have built a test lab to simulate traffic an issue showed up.
In this case we have:
public IP 1.1.1.1
local gateway 192.168.1.254
local device1 192.168.1.1
local device2 12.168.1.2

DST NATs
1.1.1.1:80 dstnat 192.168.1.1:80
1.1.1.1:443 dstnat 192.168.1.1:443
1.1.1.1:25 dstnat 192.168.1.2:25
SRC NAT
192.168.1.0/24 srcnat 1.1.1.1

After setting this up we applied also incoming firewall rules to accept only 80,443,25 according to dstnat setup. After we have turned on fw rules device2 were unable to reach its gateway.
When fw rules are turned off everything is wokring fine, outgoing traffic from device2 to internet(outside its subnet) is flowing. QUestion is if it is safe to have only DSTNAT set up without any other FW rules or is there a way how to setup this particular config with firewall rules?

thanks

2

Post the explicit firewall rules (i.e. /ip firewall export).

3

add chain=forward dst-address=192.168.1.1 dst-port=80 in-interface=ether1-wan protocol=tcp
add chain=forward dst-address=192.168.1.1 dst-port=443 in-interface=ether1-wan protocol=tcp
add chain=forward dst-address=192.168.1.2 dst-port=25 in-interface=ether1-wan protocol=tcp
add action=drop chain=forward dst-address=192.168.1.1 in-interface=ether1-wan
add action=drop chain=forward dst-address=192.168.1.2 in-interface=ether1-wan

4

Is that all of it? I see no NAT rules.
Post the whole lot, as requested. Don’t filter stuff out…

5

hello, sorry for late reply

add action=src-nat chain=srcnat comment=mail log=yes out-interface=ether1-wan src-address=192.168.1.0/24 to-addresses=1.1.1.1
add action=dst-nat chain=dstnat comment=mail dst-address=1.1.1.1 dst-port=80 in-interface=ether1-wan protocol=tcp to-addresses=192.168.1.1 to-ports=80
add action=dst-nat chain=dstnat dst-address=1.1.1.1 dst-port=443 in-interface=ether1-wan protocol=tcp to-addresses=192.168.1.1 to-ports=443
add action=dst-nat chain=dstnat comment=smtp dst-address=1.1.1.1 dst-port=25 in-interface=ether1-wan log=yes protocol=tcp to-addresses=192.168.1.2 to-ports=25

6

First thing - to answer your initial question “is it safe to have just the dstnat without the firewall rules?”

  • if you only map individual ports through, then in general the answer is yes because only those ports will be able to reach the internal IP addresses, but as many have stated in many blogs / tech videos / etc - NAT is not the same thing as a firewall, and it’s good that you’re not thinking of them as being the same thing…

You need to have rules in your filter chains which allow packets whose connection state = established or related. Generally these should be among the first rules in the chain for performance purposes.

Second - if you specify the dst-address in your match criteria (of the NAT rules) then you generally don’t need to specify in-interface also. It can work this way, but understand that narrowing the scope of your rules might have unexpected results. E.g. if you’re trying to do hairpin NAT, then you can’t really use the in-interface criteria on your pinhole dstnat rules.

I’d suggest these rules for your setup (assuming that you don’t want/need hairpin NAT)

/ip firewall filter
add chain=forward connection-state=established,related action=fasttrack-connection
add chain=forward connection-state=established,related action=accept
add chain=forward in-interface=!ether1-wan action=accept
add chain=forward dst-address=192.168.1.1 protocol=tcp dst-port=80,443 action=accept
add chain=forward dst-address=192.168.1.2 protocol=tcp dst-port=25 action=accept
add chain=forward action=drop
/ip firewall nat
add chain=dstnat dst-address=1.1.1.1 protocol=tcp dst-port=80,443 action=dst-nat to-addresses=192.168.1.1
add chain=dstnat dst-address=1.1.1.1 protocol=tcp dst-port=25 action=dst-nat to-addresses=192.168.1.2
add chain=srcnat out-interface=ether1-wan action=src-nat to-addresses=1.1.1.1
add chain=srcnat dst-address=192.168.1.0/24 src-address=192.168.1.0/24 action=src-nat to-addresses=192.168.1.254 comment="hairpin rule"

This should do what you want and allow hairpin NAT as well. It assumes that your WAN IP is static. Otherwise, you’ll need to use MASQUERADE in the outbound srcnat actions, and a little bit different matching logic for the dstnat rules that create the NAT pinholes.

Also note that I didn’t specify the INPUT firewall rules, which are pretty important as well. Don’t forget those for protecting the router itself, especially DNS ports!

Good luck!