Community discussions

 
Academia
just joined
Topic Author
Posts: 1
Joined: Tue Jul 23, 2019 9:31 am

Q: src.port <> dst.port

Tue Jul 23, 2019 9:50 am

Hi.
Old hack in UNIX-moderate understanding of network, back after several years disability, new to Mikrotik devices.

Regarding firewall > nat forwarding settings ..

In general>src.port field there is "25,80,443,587" and in action>dst.port field there is "25-587"

I wish to double check that this is ok? If I were to write the rule I would use exact same values in both fields (just to keep things neet and simple).

It is also my understanding that one can direct desired src.port "25" to another dst.port "888" (if such redirection is desired) .. now is this correct?..and followup question .. dose mikrotik use one-to-one port forwarding if there is more than one src.port OR more than one dst.port?

Thank you for taking the time to read this and post advice/pointers on subject!
 
mkx
Forum Guru
Forum Guru
Posts: 3223
Joined: Thu Mar 03, 2016 10:23 pm

Re: Q: src.port <> dst.port

Tue Jul 23, 2019 10:44 am

Regarding firewall > nat forwarding settings ..

In general>src.port field there is "25,80,443,587" and in action>dst.port field there is "25-587"

Be careful. There are 3 distinct port settings: src-port , dst-port and to-ports ... src-port check the port used by client. Usually that's some random high port and not really useful for usual NAT rules. dst-port is the port that client tries to connect, in most usual scenarios that's port that client sees as service port on router's WAN address. And then to-ports sets the port number which is used by service inside the DMZ/LAN.

Example: if one wants to establish port forwarding for https (TCP port 443), but to obfuscate things one uses TCP port 13443 on the WAN side while https server on the DMZ host actually uses standard port. We don't care which local port is used by client's browser. So the NAT rule would look like this
/ip firewall nat
add action=dst-nat dst-port=13443 to-ports=443 protocol=tcp dst-address=<WAN IP address> to-address=<DMZ host IP address>
If you don't obfuscate port numbers (e.g. you only want to do address translation), then you don't have to use to-ports at all. And if you want to forward a few ports to same DMZ host, you can use something you already hinted at:
add action=dst-nat dst-port=25,80,443,587 protocol=tcp dst-address=<WAN IP address> to-address=<DMZ host IP address>
Another thing to be careful about: do use as many filtering attributes as possible to make the NAT rule as specific as possible. If there wasn't the "dst-address=" part, this rule would grab any packet passing router and was targeting the enumerated ports. Those connections from LAN users directed at internet hosts as well ...
BR,
Metod
 
anav
Forum Guru
Forum Guru
Posts: 3132
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Q: src.port <> dst.port

Tue Jul 23, 2019 5:46 pm

A bit more info.
In the dst nat rules is where you can also add source address list, to specify or limit which external WANIPs are allowed to access the server.
When one attaches an address source list the outcome is that the ports appear NOT visible from an external port scan.
Without an address list attached to a dst nat rule, the port is visible but appears as closed.

Finally, one has to ensure one has a forward chain rule that allows port forwarding in general.
Nat occurs first (before forward filter rules) and thus if doing port translation, one has to consider the local server port, not the external incoming port for firewall filter rules.
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
Sob
Forum Guru
Forum Guru
Posts: 4812
Joined: Mon Apr 20, 2009 9:11 pm

Re: Q: src.port <> dst.port

Tue Jul 23, 2019 9:31 pm

And the forward chain part is best handled using magic rule with connection-nat-state=dstnat. Factory config, which has accept as default action, uses it in reverse, i.e. drops new connections from WAN that are not dstnatted.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply.
 
anav
Forum Guru
Forum Guru
Posts: 3132
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Q: src.port <> dst.port

Wed Jul 24, 2019 5:01 pm

Hi Sob I find !rules (negative based rules) to be very tricky and often affect traffic not necessarily intended or understood (probably my lack of acumen).
So I prefer a clear rule just for dstnat alone and in general clearly delineate what is allowed traffic.
As you know I follow my forward filter rules with a drop all else rule at the end.
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
Sob
Forum Guru
Forum Guru
Posts: 4812
Joined: Mon Apr 20, 2009 9:11 pm

Re: Q: src.port <> dst.port

Wed Jul 24, 2019 6:42 pm

I agree that simpler rules are easier to understand.

If default firewall has something like:
/ip firewall filter
add chain=forward in-interface-list=WAN connection-nat-state=!dstnat action=drop
you can instead use two rules:
/ip firewall filter
add chain=forward connection-nat-state=dstnat action=accept
add chain=forward in-interface-list=WAN action=drop
It's not the best example, because it's only two conditions, so the difference is not great. But with some more complex rules it can help.

Of course every small detail matters, so even in this example there's a difference between original and modified version. In original, connection-nat-state refers only to traffic that matches in-interface-list=WAN, and dstnatted traffic from elsewhere depends on other rules (default firewall would accept it with implicit accept at the end). Modified version allows dstnatted traffic from anywhere (you probably want that, but someone may have a reason why not). So you need to always watch for everything.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply.
 
anav
Forum Guru
Forum Guru
Posts: 3132
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Q: src.port <> dst.port

Wed Jul 24, 2019 10:38 pm

Lots of options, but prefer to only allow dstnat from wan interface if no intentions to nat internally. In fact due to my limited experience I cannot even contemplate a nat scenario within ones network?? I thought internally one would simply use routing rules if there was some complex scenario.
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
Sob
Forum Guru
Forum Guru
Posts: 4812
Joined: Mon Apr 20, 2009 9:11 pm

Re: Q: src.port <> dst.port

Wed Jul 24, 2019 10:56 pm

Hairpin NAT is common one. You're connecting from LAN to public address on WAN, but dstnat makes it go from LAN to LAN (that's how forward filter sees it). So if you'd only allow dstnatted connections from WAN, it wouldn't work (with default-drop firewall, without another rule allowing LAN to LAN forwarding).
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply.
 
anav
Forum Guru
Forum Guru
Posts: 3132
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Q: src.port <> dst.port

Thu Jul 25, 2019 4:45 am

Thanks thats very useful info!
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)

Who is online

Users browsing this forum: No registered users and 33 guests