IIS cannot see the external IP when NAT

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

My code

/ip firewall nat
add action=masquerade chain=srcnat out-interface=bridge1
add action=masquerade chain=srcnat out-interface=pppoe-out1

add action=dst-nat chain=dstnat  dst-address=\
    115.77.218.118 dst-port=8080 protocol=tcp to-addresses=192.168.1.148 \
    to-ports=80
add action=src-nat chain=srcnat  dst-port=80 protocol=tcp \
    src-address=192.168.1.148 to-addresses=115.77.218.118 to-ports=8080

add action=netmap chain=srcnat  dst-port=80 protocol=tcp \
    src-address=192.168.1.148 to-addresses=115.77.218.118 to-ports=8080
add action=netmap chain=dstnat  dst-address=\
    115.77.218.118 dst-port=8080 protocol=tcp to-addresses=192.168.1.148 \
    to-ports=80

Settings you shown are not conclusive, but I think you should get rid of this config line:

add action=masquerade chain=srcnat out-interface=bridge1

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.

I’m not sure about these rules as well:

add action=src-nat chain=srcnat  dst-port=80 protocol=tcp \
    src-address=192.168.1.148 to-addresses=115.77.218.118 to-ports=8080

add action=netmap chain=srcnat  dst-port=80 protocol=tcp \
    src-address=192.168.1.148 to-addresses=115.77.218.118 to-ports=8080
add action=netmap chain=dstnat  dst-address=\
    115.77.218.118 dst-port=8080 protocol=tcp to-addresses=192.168.1.148 \
    to-ports=80

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

#Software: Microsoft Internet Information Services 10.0
#Version: 1.0
#Date: 2019-10-09 04:53:51
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
2019-10-09 04:53:51 192.168.1.148 GET / - 80 - > 192.168.1.1 > Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/77.0.3865.90+Safari/537.36 - 200 0 0 48
2019-10-09 04:53:51 192.168.1.148 GET /favicon.ico - 80 - > 192.168.1.1 > Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/77.0.3865.90+Safari/537.36 > http://115.77.218.118:8080/ > 404 0 2 46
2019-10-09 04:57:10 192.168.1.148 GET / - 80 - 192.168.1.1 Mozilla/5.0+(compatible;+MSIE+10.0;+Windows+NT+7.0;+InfoPath.3;+.NET+CLR+3.1.40767;+Trident/6.0;+en-IN) - 200 0 0 388
2019-10-09 05:00:47 192.168.1.148 GET / - 80 - 192.168.1.1 Mozilla/5.0+(Windows+NT+10.0;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/51.0.2704.103+Safari/537.36 - 200 0 0 225
2019-10-09 05:00:51 192.168.1.148 GET / - 80 - 192.168.1.1 Mozilla/5.0+(Windows+NT+6.1;+WOW64)+AppleWebKit/537.11+(KHTML,+like+Gecko)+Chrome/23.0.1271.95+Safari/537.11+_zbot - 200 0 0 38
2019-10-09 05:11:37 192.168.1.148 GET / - 80 - 192.168.1.1 Mozilla/5.0+zgrab/0.x - 200 0 0 192

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.

I removed them all as you said. And the IIS log receives the external IP.
If I remove it, I cannot access the camera or the website on the LAN

add action=masquerade chain=srcnat out-interface=bridge1

Current code.

add action=masquerade chain=srcnat out-interface=pppoe-out1
add action=dst-nat chain=dstnat dst-address=
115.77.218.118 dst-port=8080 protocol=tcp to-addresses=192.168.1.148
to-ports=80

OK, got it I did it. Sincerely thank you

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:

add action=masquerade chain=srcnat in-interface=bridge1 out-interface=bridge1

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 used src-add and was successful

Sincere thanks

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

add action=masquerade chain=srcnat out-interface=“ether7-Khu C”
src-address=172.20.0.0/16

add action=dst-nat chain=dstnat dst-address=1xx.xx.xx.xx dst-port=8083
protocol=tcp to-addresses=172.20.48.48 to-ports=80



/ip firewall mangle
add action=accept chain=prerouting in-interface=pppoe-Viettel
add action=accept chain=prerouting in-interface=pppoe-VNPT

add action=mark-connection chain=input in-interface=pppoe-Viettel
new-connection-mark=wan_viettel_conn passthrough=yes
add action=mark-connection chain=input in-interface=pppoe-VNPT
new-connection-mark=wan_vnpt_conn passthrough=yes
add action=mark-routing chain=output connection-mark=wan_viettel_conn
new-routing-mark=to_wan_viettel passthrough=yes
add action=mark-routing chain=output connection-mark=wan_vnpt_conn
new-routing-mark=to_wan_vnpt passthrough=yes

(***NOTE – Mangle disable)
add action=mark-connection chain=prerouting connection-mark=no-mark
dst-address-type=!local in-interface=“ether7-Khu C”
new-connection-mark=wan_viettel_conn passthrough=yes
per-connection-classifier=both-addresses-and-ports:2/1
add action=mark-connection chain=prerouting connection-mark=no-mark
dst-address-type=!local in-interface=“ether7-Khu C”
new-connection-mark=wan_vnpt_conn passthrough=yes
per-connection-classifier=both-addresses-and-ports:2/0
add action=mark-routing chain=prerouting connection-mark=wan_viettel_conn
in-interface=“ether7-Khu C” new-routing-mark=to_wan_viettel
passthrough=yes
add action=mark-routing chain=prerouting connection-mark=wan_vnpt_conn
in-interface=“ether7-Khu C” new-routing-mark=to_wan_vnpt
passthrough=yes