problem with nat port forwarding UDP port

Hi, I’m having problems redirecting UDP port, I have a server with syslog service listening to port 514, I added the redirection and to my surprise there were no statistics.

ip firewall nat print detail
Flags: X - disabled, I - invalid, D - dynamic 
 0    ;;; SYSLOG
      chain=dstnat action=dst-nat to-addresses=10.0.0.7 protocol=udp in-interface=uplink-vlan400 dst-port=514 log=no log-prefix=""

no statistics

ip firewall nat print detail stats
Flags: X - disabled, I - invalid, D - dynamic 
 #    CHAIN               ACTION                            BYTES         PACKETS
 0    ;;; SYSLOG
      dstnat                 dst-nat                               0               0

to confirm receiving packets on the WAN interface I added rule for logging.

ip firewall filter> print detail 
Flags: X - disabled, I - invalid, D - dynamic 
 0    chain=input action=log connection-nat-state="" protocol=udp in-interface=uplink-vlan400 dst-port=514 log=no log-prefix=""



I see packages in the input statistics but dst-nat doesn’t reach dst-nat rule.

ip firewall filter> print detail stats
Flags: X - disabled, I - invalid, D - dynamic 
 #    CHAIN                ACTION                            BYTES         PACKETS
 0    input                  log                           1 350 152           5 320

I confirmed the port opening on the server using nmap.

I’m really out of ideals here

chain=input action=log connection-nat-state=“” protocol=udp in-interface=uplink-vlan400 dst-port=514 log=no log-prefix=“”

I think that this rule, at least the chain, is not correct as you want to forward (hence you should use the forward chain).

Do you have this rule?

add action=drop chain=forward comment="drop all from WAN not DSTNATed" connection-nat-state=!dstnat in-interface-list=WAN

Instead of posting using print, can you please show us:

/ip/firewall export

Make sure to remove any private information.

Port forwarding is through the router, not to the router since you are not accessing a router service, but your own service on the LAN, we are talking WAN to LAN traffic.
The input chain is TO the router, so as noted your logging in the wrong chain.

As for that sucky default forward chain rule, its better expressed in singular functionality…
add chain=forward action=accept comment=“port forwarding” connection-nat-state=dstnat

this rule to confirm packet arrival on the interface WAN. Confirmed arrival.

Do you have this rule?

add action=drop chain=forward comment="drop all from WAN not DSTNATed" connection-nat-state=!dstnat in-interface-list=WAN

>

there are no blocking rules inserted

> Instead of posting using print, can you please show us:
>
> ```text
/ip/firewall export

Make sure to remove any private information.


/ip/firewall export
# sep/26/2023 09:04:30 by RouterOS 6.45.8
# software id = Q86T-6VIJ
#
# model = CCR1036-8G-2S+
# serial number = 742B0700D6FE
/ip firewall nat
add action=dst-nat chain=dstnat comment="SYSLOG" dst-port=514 in-interface=uplink-vlan400 protocol=udp to-addresses=10.0.0.7
add action=dst-nat chain=dstnat comment="GRAYLOG HTTP" dst-port=9000 in-interface=uplink-vlan400 protocol=tcp to-addresses=10.0.0.7 to-ports=9000
add action=masquerade chain=srcnat comment="CGNAT VM" src-address=10.0.0.0/24

deleted input rule

Great that you’re here @anav

I understand this relationship between firewall filters, this rule was to show that the packet arrives on the WAN, generating statistics and starts its flow on the interface

As for that sucky default forward chain rule, its better expressed in singular functionality…
add chain=forward action=accept comment=“port forwarding” connection-nat-state=dstnat

didn’t solve

I know that the packet marks the entry on the interface and for a reason I don’t know it doesn’t cross to the LAN

Regardless, the log rule will not see it as the traffic doesnt go by the input chain at all…
Also dont see any redirection on your syslog server dst nat rule?

I don’t understand, when it says dstnat rule talk about that?

Flags: X - disabled, I - invalid, D - dynamic 
 0    ;;; SYSLOG
      chain=dstnat action=dst-nat to-addresses=10.0.0.7 to-ports=514 protocol=udp in-interface=uplink-vlan400 dst-port=514 log=yes log-prefix=""

Not my words LOL.

I quote from post X: by wallysonp » Tue Sep 26, 2023 12:37 am
Hi, I’m having problems redirecting UDP port, I have a server with syslog service listening to port 514, I added the redirection and to my surprise there were no statistics.

If the traffic hits the router with dst port 514 and you pass along port 514 to the server, there was NO redirection!!
Redirection is typically used to handle an ISP blocking a port…

traffic reaches the router with port WAN udp:514 and does not pass LAN udp:514, I don’t know why the traffic is not chosen to pass LAN

Redirection is typically used to handle an ISP blocking a port…

If ISP blocks port cannot receive data udp:514, mark log input on WAN port udp:514 there are records.
see that I used a rule filter just to confirm packets on the WAN interface in log

ip firewall filter add chain=input protocol=udp in-interface=uplink-vlan400 dst-port=514 action=log log=no log-prefix=""

log print
15:08:00 firewall,info input: in:uplink-vlan400 out:(unknown 0), src-mac f4:de:af:e7:2c:c4, proto UDP, xxx.xxx.241.98:57276->xxx.xxx.241.34:514, len 266 
15:08:00 firewall,info input: in:uplink-vlan400 out:(unknown 0), src-mac f4:de:af:e7:2c:c4, proto UDP, xxx.xxx.241.98:57276->xxx.xxx.241.34:514, len 266 
15:08:00 firewall,info input: in:uplink-vlan400 out:(unknown 0), src-mac f4:de:af:e7:2c:c4, proto UDP, xxx.xxx.241.98:57276->xxx.xxx.241.34:514, len 249 
15:08:00 firewall,info input: in:uplink-vlan400 out:(unknown 0), src-mac f4:de:af:e7:2c:c4, proto UDP, xxx.xxx.241.98:57276->xxx.xxx.241.34:514, len 267

here we watch the package arrive at the door

To test syslog server.
I activated mikrotik syslog remote sending to server was successful

I’ve looked at a lot of things on mikrotik equipment this one really got me

Torch running on WAN interface

I was successful in replacing Mikrotik with debian iptables using the same rule.
This was for testing, I’m interested in mikrotik working.

Now I wonder if there is some RFC or bug unknown to me for this abnormal behavior of the mikrotik firewall

Will never know at this rate… LOL.

do the seam
note:
my pbx ip is 192.168.8.25
Screenshot 2023-09-29 072918.png
Screenshot 2023-09-29 072913.png
Screenshot 2023-09-29 072909.png
Screenshot 2023-09-29 072905.png
Screenshot 2023-09-29 072900.png