Connection NAT state srcnat?

RouterOS General
1

Hi,

I just discovered that invalid packets do not get srcnated, and so am trying to prevent these from leaking out on the WAN interface.

I found the connection NAT state option, which sounded exactly like what I needed. However, it doesn’t seem to work as expected. Namely, there seems to be some confusion as to whether packets are srcnated.

I created the following rule to verify:

/ip firewall filter add action=log chain=forward connection-nat-state=!srcnat out-interface=sfp-sfpplus1

This is logging lots of packages that to me looks srcnated.

10:49:25 firewall,info forward: in:vlan50 out:sfp-sfpplus1, src-mac 00:0c:29:61:2d:94, proto TCP (ACK), 192.168.50.15:5655->90.227.129.61:60968, NAT (192.168.50.15:5655->10.35.1.15:5655)->90.227.129.61:60968, len 41 
10:49:25 firewall,info forward: in:vlan50 out:sfp-sfpplus1, src-mac 00:0c:29:61:2d:94, proto TCP (ACK), 192.168.50.15:5655->83.251.176.86:50581, NAT (192.168.50.15:5655->10.35.1.15:5655)->83.251.176.86:50581, len 41 
10:49:25 firewall,info forward: in:vlan50 out:sfp-sfpplus1, src-mac 00:0c:29:61:2d:94, proto TCP (ACK,PSH), 192.168.50.15:5655->90.228.161.103:49221, NAT (192.168.50.15:5655->10.35.1.15:5655)->90.228.161.103:49221, len 48 
10:49:25 firewall,info forward: in:vlan50 out:sfp-sfpplus1, src-mac 00:0c:29:61:2d:94, proto TCP (ACK,PSH), 192.168.50.15:5655->90.228.161.103:49221, NAT (192.168.50.15:5655->10.35.1.15:5655)->90.228.161.103:49221, len 144 
10:49:25 firewall,info forward: in:vlan50 out:sfp-sfpplus1, src-mac 00:0c:29:61:2d:94, proto TCP (ACK,PSH), 192.168.50.15:5655->213.64.175.58:51932, NAT (192.168.50.15:5655->10.35.1.15:5655)->213.64.175.58:51932, len 48 
10:49:25 firewall,info forward: in:vlan50 out:sfp-sfpplus1, src-mac 00:0c:29:61:2d:94, proto TCP (ACK,PSH), 192.168.50.15:5655->62.20.18.50:2143, NAT (192.168.50.15:5655->10.35.1.15:5655)->62.20.18.50:2143, len 48 
10:49:25 firewall,info forward: in:vlan50 out:sfp-sfpplus1, src-mac 00:0c:29:cc:33:bf, proto TCP (SYN,ACK), 192.168.50.47:8080->81.94.168.190:46620, NAT (192.168.50.47:8080->10.35.1.15:8080)->81.94.168.190:46620, len 60 
10:49:25 firewall,info forward: in:vlan50 out:sfp-sfpplus1, src-mac 00:0c:29:cc:33:bf, proto TCP (ACK), 192.168.50.47:8080->81.94.168.190:46620, NAT (192.168.50.47:8080->10.35.1.15:8080)->81.94.168.190:46620, len 52 
10:49:25 firewall,info forward: in:vlan50 out:sfp-sfpplus1, src-mac 00:0c:29:cc:33:bf, proto TCP (ACK,PSH), 192.168.50.47:8080->81.94.168.190:46620, NAT (192.168.50.47:8080->10.35.1.15:8080)->81.94.168.190:46620, len 69

What is going on here?

I saw something in the wiki about only being able to read the state from the first package, but it was not entirely clear when that applied.

2

Yes, only the initial packet of a connection is matched by the rule chains in /ip firewall nat. All the rest of packets belonging to the connection inherits the NAT behavior from the first one, as the handling of the first packet is rmembered in the connection tracking and applied appropriately to downstream and upstream packets.

No tools available in /ip firewall are able to prevent packets with wrong source address from leaking through the WAN. To do that, you have to use /interface bridge filter rules, so if the WAN is not part of any bridge, you’ll have to create one and rearrange the WAN configuration accordingly.

There’s an older topic on the same issue.

3

Invalid packets are blocked on the input chain and forward chain by default.
Suggest you
a. provide a diagram
b. state the functionality desired (in terms of users and not config)
c. /export hide-sensitive file=anynameyouwish

4

Sure, but should the following packets not still be considered srcnated in

/ip firewall filter

? (connection-nat-state)

You mean “default” as in the default factory configuration? We’ve implemented our own configuration.

My issue isn’t really with invalid packets, but with private addresses leaking out. Supposedly they leak out because the packets are invalid, and so do not get srcnated.

I want to either prevent anything that’s not srcnated from going out on the WAN interface (which I thought would be doable using the connection-nat-state firewall filter option), or fix the underlying cause of the packets being invalid.

My primary objective with this thread however, is learning the intended behaviour of the firewall filter connection-nat-state option, because it does not match my expectations.

5

Invalid packets, passing any kind of firewall, are a big issue anywhere. You really don’t want to land on some abusers list because one of your users/clients manages to bombard internet with invalid packets (tripping other firewalls / DPIs). Default config (which you ditched for reasons only you know) has this rule:

/ip firewall filter
filter add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"

And this rule works for any packet passing L3 of router regardless the direction (can be between LAN and WAN and thus would be natted eventually or between different LAN subnets).

Other than that, I suggest you to sniff (using wireshark on a PC) traffic off WAN interface and analyze offending packets … to see, what actually makes SRC-NAT to miss them.

6

IIRC, that is exactly one of the purposes mentioned in the wiki article of invalid drop rule, will drop packets not source NATed for whatever reason, i.e. resource utilization, etc

7

If going by invalid packets is the only or best way to solve this, I will do that. But once again, that was not my primary concern.

Either way, I have done some more testing, and have more or less pinpointed one of my issues. As far as I can tell, outgoing return traffic is not considered srcnated per connection-nat-state. Possibly only for connections that were dstnated in.

The other thing I realised is, because I was trying to only allow outgoing traffic that was srcnated, that new packets have not yet been srcnated during firewall filtering.

8

Without providing your config
/export hide-sensitive file=anynameyouwish

I am not sure how you expect assistance.

9

I guess I did not expect that my configuration can change how the _connection-nat-stat_e option works.

I have now come to the conclusion that the srcnated return traffic is in fact considered dstnated rather than srcnated, (as far as the connection-nat-state option is concerned) if the connection was dstnated in.

I suppose it makes sense given the previously stated fact of the first packet determining the entire connection’s state. So in my case, the individual packets are srcnated, but the connection is considered dstnated, which is what matters for the _connection-nat-stat_e option.

Reproduced with this configuration: (RouterOS and firmware 6.47.4)

/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.254
/ip dhcp-server
add address-pool=default-dhcp disabled=no interface=ether2 name=defconf
/ip neighbor discovery-settings
set discover-interface-list=all
/ip address
add address=192.168.88.1/24 interface=ether2 network=192.168.88.0
/ip dhcp-client
add comment=defconf disabled=no interface=ether1
/ip dhcp-server network
add address=192.168.88.0/24 gateway=192.168.88.1
/ip dns
set allow-remote-requests=yes
/ip firewall filter
add action=log chain=forward connection-nat-state=!srcnat dst-address=192.168.120.95 log-prefix=OUT out-interface=ether1 protocol=tcp src-port=80
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 in-interface=ether1
/ip firewall nat
add action=masquerade chain=srcnat ipsec-policy=out,none out-interface=ether1
add action=dst-nat chain=dstnat dst-port=80 in-interface=ether1 protocol=tcp to-addresses=192.168.88.254
/system clock
set time-zone-name=Europe/Stockholm
/system routerboard settings
set auto-upgrade=yes
10

/ip firewall filter
add action=log chain=forward connection-nat-state=!srcnat dst-address=192.168.120.95 log-prefix=OUT out-interface=ether1 protocol=tcp src-port=80
/ip firewall nat
add action=masquerade chain=srcnat ipsec-policy=out,none out-interface=ether1
add action=dst-nat chain=dstnat dst-port=80 in-interface=ether1 protocol=tcp to-addresses=192.168.88.254

>

Both your NAT rules can affect same outgoing packet, but (due to config you did) only one at a time[*], which one depends on previous activity. If packet (you're catching using firewall filter rule) is response to incoming connection, then _dst-nat_ rule marked whole connection-nat-state with state dstnat and all subsequent packets, belonging to same connection, will have same connection-nat-state. If, however, the packet is part of connection which was not established from outside (can even be initial packet), then src-nat rule will (or should) do its job and in that case, connection-nat-state should be set to srcnat.
[*] Both rules could affect the same packet only if target of dst-nat rule was accessible through ether1 interface ... but I guess that's not the case.

But then ... address 192.168.120.95 is neither publicly routable address (so it doesn't really belong to any normal internet host) nor it seems to be part of your LAN. So you should investigate why is it used and what makes it special to web server behind your router. Either you miss some static route (if 192.168.120 is another subnet connected via direct route or via some tunnel) or it's used by your ISP and some other client of same ISP is connecting your web service ...

BTW, be aware that firewall filter rule is actually executed before src-nat does its job. So whatever you see in logs will have src-address still set to original (i.e. your internal web server), not the final IP address (WAN address of your router). If you want to see whole NAT story, you have to add logging rules in firewall nat section.