VRRP Masquerade Out on Virtual IP

RouterOS General
1

Hi all,

I’m tearing my hair out with this one.

I’m trying to set up VRRP and have two CHRs (6.44.5) configured successfully with External VRRP interface (EXT) and internal (INT) VRRP interface

Everything on LAN is configured to use the virtual IP on INT as their gateway (192.168.80.254) and can ping that address.

I can ping the EXT VRRP interface from another machine on a different subnet.

What I am trying to achieve is to get all LAN traffic masqueraded from the EXT IP rather than the address of the individual router. However try as I might I can’t quite get it right.

I’d be grateful for any assistance that someone may have.

Also promiscious mode is enabled on the VMware vswitches.

Config below

# jul/18/2019 19:03:36 by RouterOS 6.44.5
# software id = 
#
#
#
/interface ethernet
/interface vrrp
add authentication=ah interface=ether1 name=EXT password=XXXXXX \
    preemption-mode=no version=2
add authentication=ah interface=ether2 name=INT password=XXXXXX \
    preemption-mode=no version=2 vrid=2
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip settings
set rp-filter=loose
/ip address
add address=12.34.56.30/28 interface=ether1 network=12.34.56.16
add address=192.168.80.253/24 interface=ether2 network=192.168.80.0
add address=192.168.80.1 interface=INT network=192.168.80.1
add address=12.34.56.28 interface=EXT network=12.34.56.28
/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=\
    established,related
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward connection-state=""
add action=accept chain=input dst-port=8291 protocol=tcp src-address=\
    22.33.44.55
add action=accept chain=input dst-port=22 protocol=tcp src-address=\
    22.33.44.55
add action=accept chain=input in-interface=EXT protocol=icmp
add action=accept chain=input protocol=icmp
add action=accept chain=input dst-address=224.0.0.18 protocol=ipsec-ah \
    src-address=12.34.56.29
add action=accept chain=input dst-address=224.0.0.18 protocol=vrrp \
    src-address=12.34.56.29
add action=accept chain=input dst-address=224.0.0.18 protocol=ipsec-ah \
    src-address=192.168.80.254
add action=accept chain=input dst-address=224.0.0.18 protocol=vrrp \
    src-address=192.168.80.254
add action=accept chain=input connection-state=established,related
add action=drop chain=input connection-state=""
/ip firewall nat
add action=masquerade chain=srcnat out-interface=EXT
add action=dst-nat chain=dstnat dst-port=2222 in-interface=EXT protocol=tcp \
    to-addresses=192.168.80.100 to-ports=2222
/ip route
add distance=1 gateway=12.34.56.17
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set api disabled=yes
set api-ssl disabled=yes
/system identity
set name=rr02.XX.XX
2

As the address attached to the VRRP EXT interface is static, use action=srcnat to-addresses=12.34.56.28 instead of action=masquerade. Also, the actual outgoing interface is not the VRRP one (EXT) but ether1, so out-interface in the rule should be ether1.

3

Thanks Sindy,

I’ve made those changes but they don’t seem to have resolved my issue. I’ll investigate further today.

4

Just one question, what do you expect to happen once you succeed? It would be nice to have a high availability setup where any of the two machines can do the job, but the NAT functionality is a stateful one - only the initial packet of each connection goes through the /ip firewall nat table, the result is stored in the context of that connection in connection-tracking and then applied to all subsequent packets of that connection with regard to their direction. And Mikrotik doesn’t support (yet, hopefully) synchronisation of connection tracking context between machines, so if machine A dies and machine B takes over, and the first packet belonging to a previously NATed connection arrives from the public side after the takeover, it will be dropped as it doesn’t belong to any tracked connection on machine B if the firewall is set that way; if it is not, the packet will create a tracked connection with no NAT handling and a packet from the private side to public side will create a separate NATed connection, so the directions won’t match and the packets from the public side will never get to the proper private side destination as they will not be “un-src-nated” by the conntrack module.

5

Yeah. I understand the NAT side of it. it would be nice to have something like Carp from the BSDs. I know that the features of Carp aren’t fully achievable on routerOS but I was seeing how close I could get.

Thanks again for you help!