Forward secondary IP to web server

Disclaimer: All IP addresses appearing in this post are fictitious. Any resemblance to real IP addresses is purely coincidental.

I have 2 IP addresses assigned by my ISP via DHCP. 1.1.1.225 is the original IP address of my router. The second IP address 1.1.2.85 was added recently. When I added the second IP address I removed ether2 from bridge and created a new DHCP client, and now I can see both IP addresses here:

[admin@MikroTik] /ip address> print
Flags: X - disabled, I - invalid, D - dynamic 
 #   ADDRESS            NETWORK         INTERFACE                                                                                                                         
 0   ;;; defconf
     192.168.88.1/24    192.168.88.0    bridge                                                                                                                            
 1 D 1.1.1.225/24       1.1.1.0         ether1                                                                                                                            
 2 D 1.1.2.85/24        1.1.2.0         ether2

I have a web server running on 192.168.88.71 which I want to make available externally via the second IP address. I added netmap rules to NAT configurations (the two at the bottom):

[admin@MikroTik] /ip firewall nat> print
Flags: X - disabled, I - invalid, D - dynamic 
 0    ;;; defconf: masquerade
      chain=srcnat action=masquerade out-interface-list=WAN ipsec-policy=out,none 

 1    ;;; Terraria
      chain=dstnat action=dst-nat to-addresses=192.168.88.24 to-ports=7777 protocol=tcp dst-port=7777 log=no log-prefix="" 

 2    ;;; Terraria
      chain=dstnat action=dst-nat to-addresses=192.168.88.24 to-ports=7778 protocol=tcp src-port="" dst-port=7778 log=no log-prefix="" 

 3 X  ;;; Jupyterhub
      chain=dstnat action=dst-nat to-addresses=192.168.88.32 to-ports=80 protocol=tcp dst-port=5384 log=no log-prefix="" 

 4    ;;; VRising
      chain=srcnat action=masquerade protocol=udp dst-address=192.168.88.64 out-interface=bridge log=no log-prefix="" 

 5    ;;; VRising
      chain=dstnat action=dst-nat to-addresses=192.168.88.64 to-ports=9876 protocol=udp dst-port=9876 log=no log-prefix="" 

 6    ;;; VRising
      chain=dstnat action=dst-nat to-addresses=192.168.88.64 to-ports=9877 protocol=udp dst-port=9877 log=no log-prefix="" 

 7    chain=dstnat action=netmap to-addresses=192.168.88.71 dst-address=1.1.2.85 in-interface=ether2 log=no log-prefix="" 

 8    chain=srcnat action=netmap to-addresses=1.1.2.85 src-address=192.168.88.71 out-interface=ether2 log=no log-prefix=""

When I attempt to connect to this IP from my local network I get this error straight away:

❯ curl 1.1.2.85
curl: (7) Failed to connect to 1.1.2.85 port 80: Connection refused

But when I attempt to connect to this IP from an external network the connection times out, which feels like a firewall misconfiguration:

$ curl 1.1.2.85
curl: (28) Failed to connect to 1.1.2.85 port 80: Connection timed out

Here is my firewall configuration:

[admin@MikroTik] /ip firewall filter> print
Flags: X - disabled, I - invalid, D - dynamic 
 0  D ;;; special dummy rule to show fasttrack counters
      chain=forward action=passthrough 

 1    ;;; defconf: accept established,related,untracked
      chain=input action=accept connection-state=established,related,untracked 

 2    ;;; allow IPsec NAT
      chain=input action=accept protocol=udp dst-port=4500 

 3    ;;; allow IKE
      chain=input action=accept protocol=udp dst-port=500 

 4    ;;; allow l2tp
      chain=input action=accept protocol=udp dst-port=1701 

 5    ;;; allow pptp
      chain=input action=accept protocol=tcp dst-port=1723 

 6    ;;; allow sstp
      chain=input action=accept protocol=tcp dst-port=443 

 7    ;;; defconf: drop invalid
      chain=input action=drop connection-state=invalid 

 8    ;;; defconf: accept ICMP
      chain=input action=accept protocol=icmp 

 9    ;;; defconf: accept to local loopback (for CAPsMAN)
      chain=input action=accept dst-address=127.0.0.1 

10    ;;; defconf: drop all not coming from LAN
      chain=input action=drop in-interface-list=!LAN 

11    ;;; defconf: accept in ipsec policy
      chain=forward action=accept ipsec-policy=in,ipsec 

12    ;;; defconf: accept out ipsec policy
      chain=forward action=accept ipsec-policy=out,ipsec 

13    ;;; defconf: fasttrack
      chain=forward action=fasttrack-connection connection-state=established,related connection-mark=!ipsec log=no log-prefix="" 

14    ;;; defconf: accept established,related, untracked
      chain=forward action=accept connection-state=established,related,untracked 

15    ;;; defconf: drop invalid
      chain=forward action=drop connection-state=invalid 

16    ;;; defconf: drop all from WAN not DSTNATed
      chain=forward

What should I change in order to make the web server on 192.168.88.71 accessible by IP 1.1.2.85?

hello,

7    chain=dstnat action=netmap to-addresses=192.168.88.71 dst-address=1.1.2.85 in-interface=ether2 log=no log-prefix="" 

 8    chain=srcnat action=netmap to-addresses=1.1.2.85 src-address=192.168.88.71 out-interface=ether2 log=no log-prefix=""

please note that netmap is 1 to 1 ip translation, so you need to be very careful with it.

and I don’t see any fw rules for your netmap - allowing the internet to contact your server?

Thanks for the disclaimer. :wink:

Try with line 8 in NAT disabled.

I added the following firewall rule, but it did not change anything:

/ip firewall filter add chain=input protocol=tcp dst-port=80,443 dst-address=1.1.2.85 action=accept

I noticed that dstnat rule packet counters go up when I run curl with or without the firewall rule. srcnat packet counter never goes up, it is still at 0. Disabling rule 8 (netmap scrnat) has no effect.

I also tried disabling both netmap rules and adding this instead:

/ip firewall nat add chain=dstnat protocol=tcp dst-port=80,443 dst-address=1.1.2.85 action=dst-nat to-addresses=192.168.88.71

But the behavior remains the same: incoming packets are counted, but they do not reach the web server.

Any more ideas?

If the WAN connections have different gateways you have to use mangle rules and additional routing tables or VRFs to ensure return traffic uses the same WAN as the inbound traffic arrived on.