Can't get dst-nat to work

RouterOS Beginner Basics
1

Hi,
I’m pretty much a beginner… so forgive me if it’s a stupid mistake. I need two dst-nat rules for web traffic, but I can only get one to work. The other one simply does not connect to the target server.

I’ve got the following addresses (public IPs have been changed for privacy):

/ip address
add address=192.168.88.1/24 comment=defconf interface=ether2 network=192.168.88.0
add address=62.100.31.125/27 interface=ether1 network=62.100.31.96
add address=62.100.31.123/27 interface=ether1 network=62.100.31.96
add address=192.168.1.220/24 interface=ether3 network=192.168.1.0

I want to forward web connections (ports 80 and 443) on address 62.100.31.125 to 192.168.88.190, and 62.100.31.123 to 192.168.1.202.

My NAT rules:

/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat dst-address=62.100.31.125 dst-port=80 protocol=tcp to-addresses=192.168.88.190 to-ports=80
add action=dst-nat chain=dstnat dst-address=62.100.31.125 dst-port=443 protocol=tcp to-addresses=192.168.88.190 to-ports=443
add action=dst-nat chain=dstnat dst-address=62.100.31.123 dst-port=80 protocol=tcp to-addresses=192.168.1.202 to-ports=80
add action=dst-nat chain=dstnat dst-address=62.100.31.123 dst-port=443 protocol=tcp to-addresses=192.1.0.202 to-ports=443

The only difference that I can see is that the NAT target for the .123 address is on ether3, and the one for .125 is on ether2. Yet the one to .123 does not work. The target address (192.1.0.202) can be pinged from the MikroTik, and accessing that IP directly from another host in the same physical network as the ether3 interface with a browser works.

I have set up the NAT that works several months ago, so maybe there is something else that’s needed for this to work which I have forgotten…?

Form completeness, here are the filter rules; I believe they are the default.

/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

I would be grateful for any idea on how to solve this.

2

Did you check if the ports are bonded with www and www-ssl services?

3

You mean in the IP > Services section? I though that this would control the ports under which the admin interface (WebFig) of the MikroTik itself can be accessed?

Anyway, the port 80 is bound to www, and the binding of 443 to www-ssl is there but disabled.

Or do you mean this could conflict with the NAT rules? If so, why only with one of them and not the other?

4

Are you doing anything to ensure that responding traffic is being returned with the correct source IP. If you are not doing anything, all your outbound traffic will be coming from the same public IP. That means that if a computer out on the Internet sends traffic to the other address, responses will be coming from a different address and the far end computer will reject the packet.
Please export your complete configuration rather than a few small extracts. Feel free to conceal personal information.

5

Are you doing anything to ensure that responding traffic is being returned with the correct source IP. If you are not doing anything, all your outbound traffic will be coming from the same public IP. That means that if a computer out on the Internet sends traffic to the other address, responses will be coming from a different address and the far end computer will reject the packet.

No, it was my impression that if a client is opening a TCP connection to the public IP xxx.xxx.xxx.125 and the MikroTik per its NAT rules forwards the traffic to 192.xxx.xxx.202, then the NAT will also change the source IP of the response packets to that of the target IP of the original connection… I know that this will be more difficult with UDP, but since we’re talking about pure HTTP(S) here, I assumed the address translation works “automagically”…?

Ok, here’s the full config (redacted):

/interface bridge
add admin-mac=zz:zz:31:E4:zz:zz auto-mac=no comment=defconf name=bridge
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n channel-width=20/40mhz-XX disabled=no distance=indoors frequency=auto installation=indoor mode=ap-bridge ssid=MikroTik-ZZZZZZ \
    station-roaming=enabled wireless-protocol=802.11
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk mode=dynamic-keys supplicant-identity=MikroTik wpa2-pre-shared-key=xxx
/ip pool
add name=dhcp ranges=192.168.88.10-192.168.88.127
/ip dhcp-server
add address-pool=dhcp disabled=no interface=bridge name=defconf
/user group
set full policy=local,telnet,ssh,ftp,reboot,read,write,policy,test,winbox,password,web,sniff,sensitive,api,romon,dude,tikapp
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=pwr-line1
add bridge=bridge comment=defconf interface=wlan1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/ip address
add address=192.168.88.1/24 comment=defconf interface=ether2 network=192.168.88.0
add address=62.100.31.125/27 interface=ether1 network=62.100.31.96
add address=62.100.31.123/27 interface=ether1 network=62.100.31.96
add address=192.168.1.220/24 interface=ether3 network=192.168.1.0
/ip dhcp-client
add comment=defconf interface=ether1
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
/ip dns
set allow-remote-requests=yes servers=8.8.8.8
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat dst-address=62.100.31.125 dst-port=80 protocol=tcp to-addresses=192.168.88.190 to-ports=80
add action=dst-nat chain=dstnat dst-address=62.100.31.125 dst-port=443 protocol=tcp to-addresses=192.168.88.190 to-ports=443
add action=dst-nat chain=dstnat dst-address=62.100.31.123 dst-port=80 protocol=tcp to-addresses=192.168.1.202 to-ports=80
add action=dst-nat chain=dstnat dst-address=62.100.31.123 dst-port=443 protocol=tcp to-addresses=192.1.0.202 to-ports=443
/ip route
add distance=1 gateway=62.100.31.97
/system clock
set time-zone-name=Europe/Berlin
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

(End of config)

6

So you just use someone else’s public IP? Why not use the IP addresses reserved for documentation and examples? See rfc5737.
TEST-NET-1 192.0.2.0/24
TEST-NET-2 198.51.100.0/24
TEST-NET-3 203.0.113.0/24

7

No. I’m not “using” someone else’s IP addresses. This is not a tech documentation, and I don’t want to concentrate on finding the right replacement IP addresses, subnet masks and other stuff, just to make my redacted config look neat. I’m trying to solve a NAT problem.

8

Hi,

I see something wrong here:

add action=dst-nat chain=dstnat dst-address=62.100.31.123 dst-port=443 protocol=tcp to-addresses=192.1.0.202 to-ports=443

IP 192.1.0.202??


Besides, maybe you should also create two different srcnat rules, one for each subnet, to make sure that the server would respond via the same public IP from which it gets requests.
Not sure though. I’ve never tried it.

9

Wow, thanks for noticing that. I fixed that, still no luck.

What would these rules look like?

10

Maybe something like this:

 add action=src-nat chain=srcnat out-interface=ether1 src-address=192.168.88.0/24 to-addresses=62.100.31.125
 add action=src-nat chain=srcnat out-interface=ether1 src-address=192.168.1.0/24 to-addresses=62.100.31.123

careful though, I may have overlooked something, or miss a step to make it work properly or as expected.

Just give it a try and let us know.

11

I see. This would change the source ip of every packet that has an original source IP in the 192.168.1.x network to be “62.100.31.123” if the packet goes out through the ether1 interface.

I tried it, and it didn’t work. The counter for this rule stays at 0, so apparently no packet matching the rule is ever received by the firewall.

It was my understanding that this should have been done already by the existing “masquerade” rule, (see https://wiki.mikrotik.com/wiki/Manual:IP/Firewall/NAT#Masquerade).

Th curious thing is that it works with the other host/IP address, and I can’t find any difference that looks relevant to me.

12

As I said, I may have overlooked something.

13

Having multiple ip addresses on your ether1 interface complicates things.

Do a google search for mikrotik nat masquerade when exit interface has mulitple addresses there are many threads, I didn’t read them because I don’t have multiple addresses on my router’s WAN.

14

Be sure masquerade is the last in srcnat chain, if you want to keep it.

15

hello karlisi,

want to forward web connections (ports 80 and 443) on address 62.100.31.125 to 192.168.88.190, and 62.100.31.123 to 192.168.1.202

all you need to do is add src nat for each specific incoming dst nat. the reply address should be the same as requested.

example:

dst nat on 31.125 to 88.190,

you should add a src nat from 88.190 (or .88 subnet for simplicity) to outside ip of 31.125

and so forth.

(can be basic subnet masquerade as well, if you want).

aa.. and do check your src nat or masquerade sequence. put those special src nat on top of other masquerade rules.

hope this helps.

16

There’s no need to put src-nat rule matching a dst-nat rule … connection tracking machinery will recognise return packets and un-do the dst-nat on them.

17

@ mkx

well, from your conntrack and "basic* masquerade pov, then I could tell there will be a lot of misaligned request and reply sessions - if you have more than one outside ip on single interface - and doing basic masquerade.

18

As I wrote: conntrack machinery will un-do the dst-nat action … exactly. It doesn’t matter how many addresses might be bound to any interface.

It is different with src-nat which has to decide which address (and port) will be used as src-address (and src-port). However, src nat and dst nat are pretty much unrelated and independent. src nat (or masquerade as special case) doesn’t even have to be configured/active for dst nat to do its job …