Hi,

played today with NAT. Are my assumptions correct:

- NAT-Rules match only against connection-state New packets? Thats maybe the reason there is no connection-state matcher within NAT-rules?
- user-defined NAT-Rules are applied only on the initial way to the destination, not on the returing packets (the "NAT-undo-operation" during conn-tracking is not user-editable)?
- When exposing a LAN-server to the WAN via a DNAT-rule, it matches only this DNAT-rule. The general SNAT-rule (for all LAN-to-WAN traffic) does NOT match, because then a user-defined NAT-Rule would match agianst a returning packet.

I tried if I can "fool" NAT: I created a RAW-rule to "no track" the frames to the server and catch the returning Frames with a NAT rule. I testet with plain HTTP, and HTTP worked as I thought (this NAT-rule matched against the retunring packets). But not for the inital SYN+ACK. The TCP-handshake was not NAT-treated even with the RAW-no-track-rule. It seems there still some "Magic" between.

You can check out the Packet Flow diagrams, which shows where src-nat, dst-nat and connection tracking all get triggered:

https://help.mikrotik.com/docs/display/ ... n+RouterOS

Your assumptions are correct - only the initial packet of each connection is handled by the rules in the NAT table. The final outcome of this treatment is stored in the context of that connection, and the corresponding NAT operations are then repeated on every subsequent packet of that connection as appropriate depending on direction - i.e. responses to dst-nated requests are "un-dst-nated" (src-nated to the address to which the request has originally come), and responses to src-nated requests are "un-src-nated" (dst-nated to the address from which the request has originally come) whereas further requests are treated the same like the initial one.

Since the whole NAT handling is tightly integrated with connection tracking, by flagging a packet as untracked in raw you prevent any NAT treatment as well. The "stateless NAT" supported by the underlying netfilter is not made available in RouterOS configuration.

Besides the academic are there specific user requirements you wish to communicate???

By the way, DONT TELL ME ANOTHER USER wants to use servers and yet Zero Trust Tunnel is not available like wireguard ( unless you like the complexity of containers and happen to have an arm device ) SHAME!!

Thank you sindy!
Sometimes its hard to find a confirmation for the assumptions which arise to some topic... And a lot wiki/help/man-pages left a lot room for interpretation.