port mapping outside to inside, but "preserve" destination address

RouterOS General
1

Hi,

is there a way to have a packet that comes from WAN reach a server behind the router, but preserving the original destination address of packet?
If I use classic dstnat, destination address is changed. I need dstnat (as packet is coming from WAN) and need that packet goes to a defined internal server,
but I would like the packet to also have original destination address so that this internal server will then reroute packet outside to proper destination.

I know it’s a weird setup, I used to do this with a Cisco using policy based routing, but that was between 2 interfaces of same router.
Is there a way to obtain this? Any hint will be greatly appreciated!

Thanks
Rick

2

Is this a custom protocol or could you use something in the Service Ports nat helper section?

3

Instead of dstnat, it should be possible to route it where you want it. You can’t use regular way with different routing tables, but there’s more direct action=route in prerouting.

4

it’s http and https.

5

could you please provide an example? I am not so prolific with routeros… :slight_smile:

Thanks
Rick

6

It should be:

/ip firewall mangle
add chain=prerouting dst-address=<original address> protocol=tcp dst-port=80,443 action=route route-dst=<internal server>
7

Thanks. The mangle rule is matched, however nothing reaches the internal server.
I guess the packets are dropped by the default firewall config?
Should I add an explicit rule to allow this? After all, packets are coming from WAN side…
Sorry for the naive questions…

Thanks
Rick

8

Yeah, dropped by “defconf: drop all from WAN not DSTNATed” :slight_smile:
It worked!! Thank you so much!

Rick

9

I think I also need source nat though… or the replies can’t go back to the client in WAN… am I correct?
Should I set up a srcnat to go with this?

Rick

10

You should probably share a little bit more about what you’re doing, I can’t say that I know what exactly is going on. You wrote that you want packets delivered to internal server, and “internal server will then reroute packet outside to proper destination”. Is “outside” back through this router or somewhere else? If the former, why can’t the router itself do it? Etc..

11

Yeah so this is basically what I am trying to do

2 mikrotik routers, one in private network 192.168.166.0/24, one in private network 192.168.2.0/24
both share same gateway to the Internet, default firewall config, so their WAN port is on same LAN (ISP router LAN) .
I have assigned two static IP addresses for WAN, 99 and 100, both are on ISP network 192.168.1.0/24

Host 192.168.166.12 needs to access http and https through server 192.168.2.12 , which then will masquerade as itself and accessing the web on behalf of 192.168.166.12.
The reason for this weird setup is, on server 192.168.2.12 there may be a VPN active to send all traffic through another ISP instead of the default one.
The original host 192.168.166.12 should never know whether if it’s using usual ISP or the other one via VPN.

That’s why the classic dst-nat is not working for me: the server 192.168.2.12 would receive packets addressed to him, it needs to see the original destination in packets instead, so
when it masquerades, these packets will be sent to the real destination.

With the suggestion above the packets are properly sent to 192.168.2.12 with the original destination address but for some reason the TCP handshake does not complete,
it will receive the SYN, forward it masqueraded to original destination, will receive the ACK from destination and forward it back to 192.168.166.12 but then it breaks
and SYN-ACK is never received from remote. Client receives a RST. I believe I need to have connection tracking in place other than that mangle rule, but am not sure.

Capture from the masquerading server 192.168.2.12:
00:03:51.196237 IP 192.168.1.99.49676 > 176.56.236.150.http: Flags [S], seq 3459563457, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 455012378 ecr 0,sackOK,eol], length 0
00:03:51.196272 IP 192.168.2.12.49676 > 176.56.236.150.http: Flags [S], seq 3459563457, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 455012378 ecr 0,sackOK,eol], length 0
00:03:51.224336 IP 176.56.236.150.http > 192.168.2.12.49676: Flags [S.], seq 1662790402, ack 3459563458, win 27760, options [mss 1400,sackOK,TS val 1669808764 ecr 455012378,nop,wscale 7], length 0
00:03:51.224363 IP 176.56.236.150.http > 192.168.1.99.49676: Flags [S.], seq 1662790402, ack 3459563458, win 27760, options [mss 1400,sackOK,TS val 1669808764 ecr 455012378,nop,wscale 7], length 0
00:03:51.225187 IP 192.168.1.99.49676 > 176.56.236.150.http: Flags [.], ack 1, win 8241, options [nop,nop,TS val 455012407 ecr 1669808764], length 0
00:03:51.225205 IP 192.168.2.12.49676 > 176.56.236.150.http: Flags [.], ack 1, win 8241, options [nop,nop,TS val 455012407 ecr 1669808764], length 0
Thanks for reading all this and for your help…

Rick

12

An addendum: while TCP seem to fail, this is working fine for UDP, i.e. DNS resolution works using the mangle rule…

13

After better looking at the capture on client (192.168.166.12) the TCP handshake is completed, then remote sends an RST. See screenshot…
IMG_2159.jpg

14

Further tests… sometimes the http connection completes, sometimes it gets reset.
Puzzled…