Masquerade issue

megabitus · February 17, 2023, 2:20pm

Hello everyone!
Some traffic won’t reach a masquerade rule, which is my problem. To separate 2 routing tables, I’m using a VRF. In essence, I want to route all traffic from a few devices on several subnets through a firewall appliance (which doesn’t appear to handle multiple green interfaces) before it reaches the internet. Due to the firewall appliance’s limitations, I wanted to employ a CHR as a middleman. I have deactivated NAT on the firewall appliance because I want to be able to src-nat based on the source IP. Here is a configuration export from the CHR and a semblance of a diagram:

# feb/17/2023 13:46:27 by RouterOS 7.7
# software id = 
#
/interface bridge
add name=bridge_Client_1
add name=bridge_Client_2
add name=bridge_Client_3
add name=bridge_Client_4
add name=bridge_IPFire_LAN
add name=bridge_IPFire_WAN
add name=bridge_WAN
/interface ethernet
set [ find default-name=ether1 ] disable-running-check=no name=ether1_WAN
set [ find default-name=ether2 ] disable-running-check=no name=ether2_ipfire_WAN
set [ find default-name=ether3 ] disable-running-check=no name=ether3_ipfire_LAN
set [ find default-name=ether4 ] disable-running-check=no name=ether4_Client_1
/interface list
add name=WAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip vrf
add interfaces="bridge_IPFire_LAN,bridge_Client_1,bridge_Client_2,bridge_Client_3,bridge_Client_4" name=vrf_exc
/interface bridge port
add bridge=bridge_WAN interface=ether1_WAN
add bridge=bridge_IPFire_WAN interface=ether2_ipfire_WAN
add bridge=bridge_IPFire_LAN interface=ether3_ipfire_LAN
add bridge=bridge_Client_1 interface=ether4_Client_1
/interface list member
add interface=ether1_WAN list=WAN
add interface=bridge_WAN list=WAN
/ip address
add address=10.172.172.1/30 interface=bridge_IPFire_WAN network=10.172.172.0
add address=10.172.173.2/30 interface=bridge_IPFire_LAN network=10.172.173.0
add address=10.10.10.1/30 interface=bridge_Client_1 network=10.10.10.0
add address=10.10.10.5/30 interface=bridge_Client_2 network=10.10.10.4
/ip dhcp-client
add add-default-route=no interface=bridge_WAN
/ip dns
set allow-remote-requests=yes
/ip firewall nat
add action=masquerade chain=srcnat log=yes out-interface-list=WAN \
    src-address=10.10.10.0/30
add action=masquerade chain=srcnat log=yes out-interface-list=WAN \
    src-address=10.10.10.4/30
add action=masquerade chain=srcnat comment="MASQ fro IPFire" \
    out-interface-list=WAN src-address=10.172.172.2
add action=dst-nat chain=dstnat comment="IPFire MGMT" dst-port=444 \
    in-interface-list=WAN protocol=tcp to-addresses=10.172.172.2
add action=dst-nat chain=dstnat comment="IPFire MGMT" dst-port=22 \
    in-interface-list=WAN protocol=tcp to-addresses=10.172.172.2
add action=masquerade chain=srcnat log=yes out-interface-list=WAN
/ip route
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=10.172.173.1@vrf_exc \
    pref-src="" routing-table=vrf_exc scope=30 suppress-hw-offload=no \
    target-scope=10
add disabled=no distance=1 dst-address=10.10.10.0/24 gateway=10.172.172.2 \
    pref-src="" routing-table=main scope=30 suppress-hw-offload=no \
    target-scope=10
add disabled=no dst-address=0.0.0.0/0 gateway=192.168.80.1 routing-table=main \
    suppress-hw-offload=no

As you can see from these 2 pictures, the traffic seems to be routed correctly. My only issue is that it doesn’t hit any of the masquerade rules.

I’m not sure what I’m doing wrong. If I can help with any more information, please let me know.
Thank you!

anav · February 17, 2023, 2:34pm

Dont have a clue what you mean and not identifying what devices you may be talking about without a diagram does not help.

If you mean can the MT ensure traffic from some devices (as you state various ones across multple subnets) can go out a specific WANIP, the answer is yes. No need for Vrrs or adding CHrs etc…
Another firewall appliance I dont care about if its not MT.

Sob · February 17, 2023, 3:15pm

Check VRF and hidden interfaces. I was under impression that it’s already fixed/handled, but maybe not everywhere? I think I didn’t test NAT myself.

megabitus · February 20, 2023, 9:45am

The clients are Windows Server VM’s. I’ve tried to make a diagram, maybe this helps. In the diagram you can see CHR 1 and 2. I want all the traffic from the Clients to be routed through the Applicance because I can use it to filter access by countries, something that the RouterOS, doesn’t seem to have (or I wasn’t able to find it). I want to combine both of the CHRs into one, and that’s the reason for using the VRF. There is no NAT done on the CHR2 and Appliance. I’ve tried the setup from the diagram, and everything works as expected. My issue appears when trying to use VRF to combine the CHRs.
Untitled Diagram.png

megabitus · February 20, 2023, 9:55am

I’ve added as in your post, some rules for logging, and besides the (unknown 0) interface, everything seems correct, as it matches the interfaces as in the packet sniffer.

09:49:43 firewall,info prerouting: in:bridge_Client_1 out:(unknown 0), connection-state:new src-mac 00:15:5d:50:04:0e, proto ICMP (type 8, code 0), 10.10.10.2->9.9.9.9, len 60
 09:49:43 firewall,info prerouting: in:bridge_Client_1 out:(unknown 0), connection-state:new src-mac 00:15:5d:50:04:0e, proto ICMP (type 8, code 0), 10.10.10.2->9.9.9.9, len 60
 09:49:43 firewall,info forward: in:bridge_Client_1 out:bridge_IPFire_LAN, connection-state:new src-mac 00:15:5d:50:04:0e, proto ICMP (type 8, code 0), 10.10.10.2->9.9.9.9, len 60
 09:49:43 firewall,info postrouting: in:bridge_Client_1 out:bridge_IPFire_LAN, connection-state:new src-mac 00:15:5d:50:04:0e, proto ICMP (type 8, code 0), 10.10.10.2->9.9.9.9, len 60
 09:49:43 firewall,info prerouting: in:bridge_IPFire_WAN out:(unknown 0), connection-state:new src-mac 00:15:5d:50:04:10, proto ICMP (type 8, code 0), 10.10.10.2->9.9.9.9, len 60
 09:49:43 firewall,info forward: in:bridge_IPFire_WAN out:bridge_WAN, connection-state:new src-mac 00:15:5d:50:04:10, proto ICMP (type 8, code 0), 10.10.10.2->9.9.9.9, len 60
 09:49:43 firewall,info postrouting: in:bridge_IPFire_WAN out:bridge_WAN, connection-state:new src-mac 00:15:5d:50:04:10, proto ICMP (type 8, code 0), 10.10.10.2->9.9.9.9, len 60

Sob · February 20, 2023, 11:48am

Try similar logging rule in srcnat. Use some other condition like source address to match only testing traffic. And check if it shows the right outgoing interface, or if it’s another unknown one.

megabitus · February 20, 2023, 1:17pm

Tried that, and it seems strange. It seems that the connection doesn’t hit the dstnat/srcnat chains after passing through the appliance and into the main table.

This part should be inside the VRF routing table and looks all right.

13:03:33 firewall,info prerouting: in:bridge_Client_1 out:(unknown 0), connection-state:new src-mac 00:15:5d:50:04:0e, proto ICMP (type 8, code 0), 10.10.10.2->9.9.9.9, len 60
13:03:33 firewall,info dstnat: in:bridge_Client_1 out:(unknown 0), connection-state:new src-mac 00:15:5d:50:04:0e, proto ICMP (type 8, code 0), 10.10.10.2->9.9.9.9, len 60
13:03:33 firewall,info prerouting: in:bridge_Client_1 out:(unknown 0), connection-state:new src-mac 00:15:5d:50:04:0e, proto ICMP (type 8, code 0), 10.10.10.2->9.9.9.9, len 60
13:03:33 firewall,info forward: in:bridge_Client_1 out:bridge_IPFire_LAN, connection-state:new src-mac 00:15:5d:50:04:0e, proto ICMP (type 8, code 0), 10.10.10.2->9.9.9.9, len 60
13:03:33 firewall,info postrouting: in:bridge_Client_1 out:bridge_IPFire_LAN, connection-state:new src-mac 00:15:5d:50:04:0e, proto ICMP (type 8, code 0), 10.10.10.2->9.9.9.9, len 60
13:03:33 firewall,info srcnat: in:bridge_Client_1 out:bridge_IPFire_LAN, connection-state:new src-mac 00:15:5d:50:04:0e, proto ICMP (type 8, code 0), 10.10.10.2->9.9.9.9, len 60

This part should be from the main routing table, and I see no logs hitting the dstnat/srcnat chains. It seems weird.

13:03:33 firewall,info prerouting: in:bridge_IPFire_WAN out:(unknown 0), connection-state:new src-mac 00:15:5d:50:04:10, proto ICMP (type 8, code 0), 10.10.10.2->9.9.9.9, len 60
13:03:33 firewall,info forward: in:bridge_IPFire_WAN out:bridge_WAN, connection-state:new src-mac 00:15:5d:50:04:10, proto ICMP (type 8, code 0), 10.10.10.2->9.9.9.9, len 60
13:03:33 firewall,info postrouting: in:bridge_IPFire_WAN out:bridge_WAN, connection-state:new src-mac 00:15:5d:50:04:10, proto ICMP (type 8, code 0), 10.10.10.2->9.9.9.9, len 60