SRCNAT to a /32 loopback address works fine, but DSTNAT failed.

realpg · November 8, 2019, 8:59am

ENV: A L3 fixed line from ISP. A single public /32 ip address, static route from ISP, connected to ISP with private /30 IP address.
DEVICE: hEX S
Version: latest v6.45.7

My HEX S:

IP ADDRESS:

sfp1: 100.68.39.194/28 (UPLINK TO ISP, GATEWAY: 100.68.39.193)
bridge1(Ether1~5): 192.168.0.1/24 (MY LAN)
loopback0(A bridge to simulate loopback interface of cisco): 59.43.27.9/32 (Public IP address from my ISP)

I need to USE this single ip in my office. So I copied configuration and translate it to RouterOS’s configuation from my original H3C router.

/32 IP address assign to loopback interface, and disable masquerade, use src-nat to this address.

IP FIREWALL:

/ip firewall nat
add action=src-nat chain=srcnat comment=\
    "SRCNAT-" ipsec-policy=out,none \
    out-interface=sfp1 src-address=192.168.0.0/24 to-addresses=\
    59.43.27.9

And it works as expected. My office lan can access internet via this IP address just like original H3C does.

But when I add a DST-NAT rule to allow clients outside use my SSL VPN (192.168.0.250:443), use public port 8443, it failed.

/ip firewall nat
add action=dst-nat chain=dstnat dst-address=\
    59.43.27.9 dst-port=8443 protocol=tcp \
    to-addresses=192.168.0.250 to-ports=443

It doesn’t work. When I debug with ip filter counters, I found that the packet just go to input chain, but not forward/nat.

How can I make it work as experted?

mkx · November 8, 2019, 9:40am

Just brainstorming from my part: is it really necessary to play with the “fake” bridge just to assign the /32 address to some interface? From ISP side packets with dst-address=/32 will just get routed to your RB. From LAN side it doesn’t get used at all. So it’s all internal to RB and thus you don’t need interface bearing it just to perform NAT on those packets …

If there’s no interface bearing IP address, then packet with such dst-address simply can’t be subject to chain=input …

But I may be completely wrong on this …

xvo · November 8, 2019, 9:56am

Well, I guess you are right, if you don’t need any routing protocol like OSPF announce the route to this address automatically, you can always workaround assigning the address somewhere by dst-nat to any other router’s address. But what’s the point?
Address assigned to the loopback bridge is not the reason that dst-nat doesn’t work.

Sob · November 8, 2019, 1:07pm

The rule is clear, if it’s tcp connection to 59.43.27.9:8443, it’s redirected to 192.168.0.250:443. And if 192.168.0.250 is another device, it can’t end up in input chain. Does this dstnat rule get any hits? Can’t there be some other before this one that would take it and redirect it to router?

mkx · November 8, 2019, 3:38pm

Not to another router address but to address of an internal device … just like usually done with lone router’s address …

xvo · November 8, 2019, 3:49pm

Sure. But you can extend this approach for the router itself too.

Sob · November 8, 2019, 4:59pm

About the address, you can assign it to router, route it further to another device, or even don’t assign it anywhere. But the last option is not very good. It’s probably not too bad if you’d use it for 1:1 NAT, but not if you’re going to dstnat only one port. What if packet comes for another port? Router will say “no thanks” and will forward it back to ISP and they will play ping-pong until TTL expires.

mkx · November 8, 2019, 5:58pm

Yup, a good table tennis game is always fun to watch

Wouldn’t a FW rule

add action=drop chain=forward dst-address=<the singular WAN address> out-interface=<WAN interface>

cure the problem?

Sob · November 10, 2019, 1:23am

It would. But it’s easier to assign address to router and let it handle automatically. OP’s config is fine, but there must be also something else we don’t see.

sindy · November 10, 2019, 9:17am

@realpg, I guess @Sob’s “there must be something we don’t see” is just another wording of “please post the complete (anonymized) configuration rather than just a few lines you assume to be relevant”.

But giving it a try without seeing the full configuration, your dst-nat rule itself is OK, so these are the only configuration-related things I can imagine to prevent it from working:

another rule in the dstnat chain which shadows it, but such an elementary mistake doesn’t match the tone of your OP,
something (an action=notrack rule in /ip firewall raw) preventing connection tracking from handling the packets, which allows them to reach filter but not nat. Even experienced users may not realize that NAT functionality is provided by the connection tracking module.

realpg · November 12, 2019, 6:03am

OK. I make a new test as you told.
I put the single /32 IP address to sfp1 interface.

Result:
Same as assign to fake bridge port.
SRCNAT works fine. But input packets just go to input chain, not forward chain.

realpg · November 12, 2019, 6:04am

DSTNAT rule no hit.

FORWARD chain dummy counter rules no hit too.

realpg · November 12, 2019, 6:07am

I run a wireshark on the uplink switch port mirror. No forward back to ISP.

The debug filter shows that forward chain never get this package.
It just stop at input chain.

realpg · November 12, 2019, 6:12am

For debugging, I’ve already removed any other unrelated configuation.

And, I guess you don’t know what is the meaning of a single /32 address.
How can it handle automatically?

xvo · November 12, 2019, 6:19am

What is your rule in input chain that is being hit by these packets?
Can you add the explicit condition dst-address=59.43.27.9 to it?

My guess is that your ISP is NATing packets with your public IP as a dst-address to you grey IP, instead of routing them to you as is.
That is possibly why they never hit dst-nat rule and end up in your input chain.

Easy to check that: change dst-address in your dst-nat rule to 100.68.39.194 and try to connect from outside to 59.43.27.9.

realpg · November 12, 2019, 9:49am

I’ll try this in my test env later.
But I think ROS FW is a wrapper of iptables/netfilter. This method shouldn’t work.

sindy · November 12, 2019, 10:00am

I’m afraid @xvo’s idea is correct but the formulation was not perfect.

The actual idea is to check, in the input chain, whether the packet which evades the dst-nat rule really arrives to the Mikrotik still with 59.43.27.9 as its dst-address or whether it gets dst-nated before, in the ISP network, by 1:1 NAT to your WAN IP from the shared range (100.64.0.0/12). So two rules at the very beginning of the input chain, action=log dst-address=59.43.27.9 and action=log protocol=tcp dst-port=8443, should answer this question after you try to connect to 59.43.27.9:8443 from the outside.

xvo · November 12, 2019, 10:15am

Yes, sindy, you are right, that’s what I had in mind.

My second idea, to change dst-nat dst-address (or use in-interface matcher instead) will prove the same point: if everything starts working “magically”, that will mean ISP is using 1:1 NAT instead of static routing.

sindy · November 12, 2019, 10:49am

How are these two statements related? Yes, the firewall does use the netfilter part of the kernel network stack; whether RouterOS firewall configures netfilter directly or by means of iptables is not important. However, there is nothing wrong about a dst-nat rule matching on your 100.68.39.194 as dst-address. If the ISP does a 1:1 dstnat, what you send from outside to 59.43.27.9 comes to your Tik with destination IP 100.68.39.194. All Mikrotik’s own services listen on all its local addresses (unless you specifically tell them not to), so it is easy not to notice that the ISP does the dst-nat.