Reverse Porxy doesn't work without 2nd masquerading for specific IP

RouterOS General
1

Hi everyone,

I hope someone can help me on this one. I’m strungling to understand why the masquerading for the web/mail VM server (add action=masquerade chain=srcnat src-address=172.16.20.12) is required for the reverse proxy to work. I do not wish to use the single IP masquerade because the login session logs show the gateway IP (172.16.20.1) for every login (local & remote).
So if i remove the single IP masquerading the reverse proxy will not work.

Reverse proxy on Centos 7 apache server → https://hosting.cso******.com:10000 to https://hosting.cso******.com

The Internet is FTTH with Static IP using PPPoE Client and it’s connected like this → ISP ONT device → Mikrotik RB5009 (ether1) → Vlan42 on ether1 (required by ISP for internet access) → PPPoE Client with dummy credentials.

# 2024-01-27 21:49:52 by RouterOS 7.13.3
# software id = GID6-7H3W
#
# model = RB5009UG+S+
# serial number = HE408SK2AR9
/ip firewall nat
add action=masquerade chain=srcnat out-interface=pppoe-ctfiber
add action=masquerade chain=srcnat src-address=172.16.20.12
add action=dst-nat chain=dstnat comment=VWM dst-address=213.7.xxx.xxx dst-port=25,110,143,465,587,993,995,80,443 protocol=tcp to-addresses=172.16.20.12
add action=dst-nat chain=dstnat dst-address=213.7.xxx.xxx dst-port=10000,20000 protocol=tcp to-addresses=172.16.20.12
/ip address
add address=192.168.40.1/30 comment=CCTV interface=ether4 network=192.168.40.0
add address=192.168.50.1/24 comment=CAPsMAN interface=br_adus network=192.168.50.0
add address=192.168.20.1/24 comment="DHCP for VMs" interface=ether2 network=192.168.20.0
add address=172.16.20.1/24 comment="VMware / Core Servers" interface=ether2 network=172.16.20.0
add address=10.1.2.1/24 interface=WireGuard network=10.1.2.0
add address=10.1.1.1/24 interface=gre_to_cisco-1 network=10.1.1.0
add address=10.0.0.1 interface=Loopback network=10.0.0.1
add address=172.16.21.1/29 interface=br_adus network=172.16.21.0
add address=10.0.60.1/24 interface=ether6 network=10.0.60.0
add address=10.0.53.1/24 interface=v53-mgmt network=10.0.53.0
2

When doing DST NAT with certain new destination address (in your case 172.16.20.12) the problem arises when client connecting to NAT-ed service resides in same IP subnet as destination address. In this case server, seeing that client is coming from same subnet, chooses to reply directly. Reply packets thus bypass NAT device. As client originally started connection towards WAN IP, reply from server’s LAN IP is not valid. One of solutions is implementation of hairpin-NAT and your second src-nat rule is a variation of it. One of side effects of hair-pin nat is that all connections appear to come from router itself, but that’s necessary to make server send replies towards router so it can “undo” original DST-NAT.

From the rule it seems like server is configured to conect itself (via WAN IP) not realizing it’s connecting itself (but on different port) and hence traffic which is esentially intra-server flows via router. I’m pretty sure you could reconfigure RP and web server to do the magic without (ab)using router, how exactly largely depends on ehich software pieces you’re running on RP and what exactly all the stages do.