Hello everyone.
I am having the following problem: I am using a web service. Currently, I check the IIS log and I cannot detect the external IP. All the IP I see is the router’s IP gateway.
I want to log IIS into being able to see the external IP instead of the gateway IP.
I have tried the NAT forms on the website: https://wiki.mikrotik.com/wiki/Manual:IP/Firewall/NAT
But not yet. Hope your help. Sincere thanks
It causes to masquerade src-address on every packet leaving router via any of interfaces that are members of bridge1 (and I assume that’s your LAN). I guess this rule might be there due to attempt to establish Hairpin NAT (allowing LAN hosts to use your public IP address to connect to your LAN/DMZ servers), but the rule is not selective enough.
They don’t seem right to me. Why don’t you describe (using plain words) what you want to achieve and we can aide you to construct correct firewall filter and NAT rules?
For example. When I use the public IP is: 113.123.11.11 visit the “myweb.com”
I want the IIS log to register as IP 113.123.11.11 and not the IP gateway
The first part of my previous post (getting rid of one particular NAT rule) should fix the IIS log entries.
The second part of my previous post (question about wanted functionality) still holds … unless you introduced the quoted NAT rules in attempt to fix IIS log entries … in this case, get rid of those entries as well.
So you want to connect to your WAN IP address TCP port 8080 while you’re actually part of LAN? In this case you need to properly configure hairpin NAT.
Your original rule (add action=masquerade chain=srcnat out-interface=bridge1) was a step in the right direction, but was too greedy. Instead make it less greedy like this:
Beware that any LAN devices you will connect by targeting your WAN IP address will see the connection as if it was coming from router (that doesn’t happen for connections originating from internet). There’s no way around it other than connecting to LAN devices directly - by using their LAN IP address.
Except in-interface matching is not possible in srcnat, it needs to be done using src-address. I’m not sure why, connection tracking must know from where the packet came. But that’s how it is.
I have the same problem when load balancing PCC.
I have to remove “src-address=172.20.0.0/16” from nat src - masquerade. Opposite I have to disable mangle load balancing.
At that time, I was able to access the web site on the LAN
/ip firewall nat
add action=masquerade chain=srcnat comment=“NAT Internet VNPT” out-interface=
pppoe-VNPT
add action=masquerade chain=srcnat comment=“NAT Internet Viettel”
out-interface=pppoe-Viettel