Hello,
We’re using a Mikrotik router in front of a few web/reverse proxy servers, and while checking on the web/reverse proxy logs we can see instead of the public ip - the gateway ip.
As an example I will take one of the servers, which has a dstnat from public IP to ether4-dmz interface, and as you can see in the logs the gateway IP is appearing.
Any ideas/suggestions on how to get the public IP displayed in logs instead?
Thank you!
It looks like a hairpin nat issue; whether doing hairpin nat is actually necessary or not depends on whether you are testing from clients in the same subnet as the servers. If you do, @Sob’s solution is to use action=netmap instead of mere action=srcnat, which makes it possible to identify the clients by changing only the prefix of their addresses.
If the above makes no sense to you, follow the hint in my automatic signature below.
It’s the rule #59 from the screenshot which does the (excess) src-address translation.
For the record, even though it’s probably OT here, the thing you referenced (ROS Hairpin NAT - preserving origin IP for log purpose) is possible when someone wants to tell internal clients apart. But personally I don’t see a reason to do that. Hairpin NAT is convenient hack to allow access to public services from internal network. If I have ten clients in some remote network, I will see only one common public address for all of them (for most common config). If I can live with that, why shouldn’t it be enough for local network? The only thing I don’t like about the most popular hairpin NAT rule:
/ip firewall nat
add chain=srcnat src-address=<local subnet> dst-address=<local subnet> action=masquerade
is that all connections look like they come from router (its internal address), which is not true and can be confusing. That’s why I prefer:
/ip firewall nat
add chain=srcnat src-address=<local subnet> dst-address=<local subnet> action=src-nat to-address=<router's public address>
which is true, connection comes from client hidden behind <router’s public address>. Downside is that it needs scripted updates if there’s dynamic address.
Well Sob, you silly, you already provide the script for the dst nat solution just use the same firewall address list name for the source nat rule…
Oh lookie, RoS does no allow us to use address-list in to-addresses, what a pita!! how inconsistent of MT…
Thank you very much all for your help.
Actually just figured out that rule 59 was messing everything, and I simply don’t need it (it does nothing, just was messing the things). All good now!