Dear,

I need to achieve something that's quite easy but for some reason I can't get this working.

A client has a server at home running a website at port 9090 the reasong why the site is running on 9090 is because the ISP is blocking all ports < 1024, now we want to assign another public ip address and forward it to the customer address.

https://public --> forward to --> https://customerip:9090

I tried the following DST nat rule but that isn't working:

chain=dstnat action=dst-nat to-addresses=CUSTOMERIP to-ports=9090 protocol=tcp dst-address=PUBLICIP dst-port=443

On the firewall itself I create a forward and input rule to allow anything.

Can someone help me on this ?

The PUBLICIP in your command will also need to exist as an address on the router performing the DST-NAT and "ip services" cannot have anything enabled for port 443. Additionally, remember that NAT can not return out the same interface that it arrived in from.

If you're trying to forward the port to some completely different network, then you need additional source NAT rule: Client connecting to server PUBLICIP expects reply coming from PUBLICIP. When you just forward the request to CLIENTIP, the server does not know anything about it and tries to send reply directly to original source IP. But the client does not expect anything from CLIENTIP. With the above rule, the source IP seen by server will be PUBLICIP, so it will send reply to it and the router will then correctly forward it to original client.

So something like this:

/ip firewall nat
add action=dst-nat chain=dstnat disabled=no dst-address=PUBLICIP dst-port=443 protocol=tcp to-addresses=CUSTOMERIP to-ports=4343
add action=masquerade chain=srcnat disabled=no dst-address=CUSTOMERIP dst-port=4343 protocol=tcp

This is for forwarding all request on port 443 on PUBLIC ip to port 4343 on CUSTOMERIP but for some reason it is not working.

Any ideas ?

It may be blocked by some rule in forward chain. Do counters increase for both rules?

The suggested masquerade NAT rule is incorrect. You should specify src-address of CUSTOMERIP instead of dst-address. Additionally, if there are multiple public IPs on this router, you will need to specify which one to appear as using the src-nat action instead of masquerade. Last, the web server will reply on a random high port, so it will not be coming FROM 4343 back out the router, so we drop those matchers.

The suggested masquerade NAT rule is incorrect.

I'd like to disagree.

You should specify src-address of CUSTOMERIP instead of dst-address.

The only packets with src-address=CUSTOMERIP coming to router will be already part of established connections. They don't need any extra rules.

Additionally, if there are multiple public IPs on this router, you will need to specify which one to appear as using the src-nat action instead of masquerade.

It doesn't really matter, it can be any address that will lead the reply packets back to router.

Last, the web server will reply on a random high port, so it will not be coming FROM 4343 back out the router, so we drop those matchers.

It's TCP, once the connection is established, the ports don't change.

-

So, are we really talking about the same thing?

With just this: It will be like this:
1.) User tries to connect to PublicIP:443 (way 1)
2.) Router will forward the packet to CustomerIP:4343 (way 3)
3.) Server will see packet from UserIP (assuming something does not block it on the way for having seemingly spoofed source)
4.) Server will send reply directly to UserIP (way 2)
5.) User will discard the reply, because it does not expect anything from CustomerIP (more likely the firewall on User's router will drop it as invalid)

With additional rule: It will be like this:
1.) User tries to connect to PublicIP:443 (way 1)
2.) Router will forward the packet to CustomerIP:4343 (way 3)
3.) New rule will catch the outgoing packet to CustomerIP:4343 and change source to PublicIP (* or any other IP on Router)
4.) Server will see packet from PublicIP (*)
5.) Server sends the reply to PublicIP (*) (way 3)
6.) Thanks to connection tracking, Router will know where the reply packet belongs to, it will automatically rewrite its source address from CustomerIP to PublicIP and send it back to UserIP (way 1)
7.) User will get reply from PublicIP as expected
8.) User is happy, because it works

It's poor man's reverse proxy. It kind of sucks (e.g. there's no way for Server to know User's address), but it works. Try it. I did.

Additionally, remember that NAT can not return out the same interface that it arrived in from.

If traffic which has been subject to DST NAT an SRC NAT couldn't have the same ingress and egress interface then it would be tough to make hairpin NAT work in many situations where it is required. In fact it is possible.

The detailed explanation laid out by Sob is in fact very like hairpin NAT except that it is being implemented on the WAN interfaces.

Hi,

When I configure the 2 rules as described above and try to reach is over https://publicip, nothings happens even the counters for both NAT rules didn't increase...

Even if it was blocked by some filter rule, packets would hit at least first dstnat rule, i.e. the counter would have to go up on that one. Unless there's some other dstnat rule catching tcp/443 before this one. Or for some reason packets are not reaching router at all.

Hi ,

Sorry it was my fault, I forgot to add the PUBLIC ip on the IP-->Addresses list, after that is was working.

Now I need to create a firewall filter rule to allow all traffic to PUBLIC IP, when I create a forward rule with any any everything works Ok, but for some reason when I enter PUBLIC IP in the forward rule as dst address it is no longer working, i guess that this comes due to the masquerade.

- How can I create a filter rule to only allow traffic to this IP ?

It's because of dstnat rule, which changes destination address. When packet gets to forward chain, it no longer has PUBLICIP as destination, but instead there's CUSTOMERIP. You can either allow that (which strictly speaking is not exactly what you want, but probably should not bring any problems) or do something like this: