Dropping 'invalid' state connections or not?

RouterOS General
1

Some adviced me to set a firewall rule that drops and log packages with connections state “invalid”.

It seems logic to me to drop invalid traffic as close as possible to the source which in my case is at the CPE.
Its done at the forward chain.

But now I set same rule in an AP and suddenly I can’t reach my CPE’s anymore by winbox! Huh! Why not?
Since when is my winbox session an ‘invalid state’ connection?
AP has its ethernet and wlan bridged;

0    ;;; jump to forward allow chain
      chain=forward action=jump jump-target=forward-allow log=no log-prefix="" 

 1    ;;; allow new connections
      chain=forward-allow action=accept connection-state=new log=no log-prefix="" 

 2    ;;; allow established connections
      chain=forward-allow action=accept connection-state=established log=no log-prefix="" 

 3    ;;; allow related connections
      chain=forward-allow action=accept connection-state=related log=no log-prefix="" 

 4 X  ;;; drop passing through invalid connections and log them
      chain=forward action=drop connection-state=invalid out-interface=bridge1 log=yes log-prefix="fwd invalid" 

 5    ;;; accept established connections
      chain=input action=accept connection-state=established log=no log-prefix="" 

 6    ;;; accept related connections
      chain=input action=accept connection-state=related log=no log-prefix="" 

 7    ;;; allow access to router from known network
      chain=input action=accept src-address-list=safe log=no log-prefix="" 

 8    ;;; drop everything else
      chain=input action=drop log=no log-prefix="" 

 9    ;;; drop invalid outgoing connections and log them
      chain=output action=drop connection-state=invalid out-interface=bridge1 log=yes log-prefix="out invalid"

Enable no.4 rule and no more winbox access to CPEs…

2

According my firewall rule ALL traffic passing router/bridge is jumped to the forward-allow chain
After that new connections are accepted, as well as established and related connections.
That should therefore basically allow winbox sessions behind the firewall.

After the connections are allowed all other traffic/connections should just leave the chain and leave router?
Rule 4 actually already filtered for ‘invalid’ state connections and is dropping the winbox session (and a lot of other shit. But clients just keep on browsing etc…)

I tried to set the rule 4 as rule 0 but that didn’t change anything. The moment ‘invalid’ state conn. are dropped no more winbox session possible to my clients…

I don’t understand, maybe somebody can help me out here?

Oh, all in v.6.33.1 for if it matters…

3

My experience with iptables on bridged interfaces is limited but you may want to move the rule to one of the physical interfaces rather than the bridge.

Also, have you tried playing with “/int bridge settings set use-ip-firewall”?

4

That bridge must have use-ip-firewall enabled, otherwise nothing would go to forward chain and nothing would get filtered (assuming it’s just a simple transparent AP with only one ethernet and one wlan bridged together, i.e. doing no routing at all). But it does not make sense, conntrack works just fine with ip firewall enabled on bridge. And with wireless CPEs, it’s unlikely that it would involve anything special like asymmetric routing. We must be missing some important info.

5

Bridge has ‘Use IP Firewall’ NOT enabled. And also Fast Path is enabled and active.
So in fact the firewall filter would not even work on the bridge. Still connection tracker (which is part of the firewall process?) is tracking all connections and still all traffic in the ‘forward’ chain is counted. And if enabled the drop of the invalid connections throught that forward chain is also dropped.

Basically I could just remove all forward chain filter because I want the AP to be transparent anyway. So all traffic is allowed to pass.
But by accidenteliy putting it on I saw all these strange things happening.

  1. How can the connection tracker still track traffic if actually fast pat is active and firewall for bridge is not enabled?
  2. How can a filter that drop ‘invalid’ traffic drop winbox p8291 traffic? That is actually a new connection or related. So why is it dropping it at initiation?

Code of that AP:

/ip firewall filter
add action=drop chain=forward comment="drop passing through invalid connections and log them" connection-state=invalid disabled=yes log=yes log-prefix="fwd invalid" \
    out-interface=bridge1
add action=jump chain=forward comment="jump to forward allow chain" jump-target=forward-allow
add chain=forward-allow comment="allow new connections" connection-state=new
add chain=forward-allow comment="allow established connections" connection-state=established
add chain=forward-allow comment="allow related connections" connection-state=related
add chain=input comment="accept established connections" connection-state=established
add chain=input comment="accept related connections" connection-state=related
add chain=input comment="allow access to router from known network" src-address-list=safe
add action=drop chain=input comment="drop everything else"
add action=drop chain=output comment="drop invalid outgoing connections and log them" connection-state=invalid log=yes log-prefix="out invalid" out-interface=bridge1

/ip firewall connection tracking
set enabled=auto generic-timeout=10m icmp-timeout=10s tcp-close-timeout=10s tcp-close-wait-timeout=10s tcp-established-timeout=1d tcp-fin-wait-timeout=10s tcp-last-ack-timeout=10s tcp-max-retrans-timeout=5m tcp-syn-received-timeout=5s tcp-syn-sent-timeout=5s tcp-time-wait-timeout=10s tcp-unacked-timeout=5m udp-stream-timeout=3m udp-timeout=10s

/interface bridge
add admin-mac=00:00:00:00:00:00 ageing-time=5m arp=enabled auto-mac=yes disabled=no forward-delay=15s max-message-age=20s mtu=auto name=bridge1 priority=0x8000 protocol-mode=rstp transmit-hold-count=6 
/interface bridge port
add auto-isolate=no bridge=bridge1 disabled=no edge=auto external-fdb=auto horizon=none interface=ether1 path-cost=10 point-to-point=auto priority=0x80
add auto-isolate=no bridge=bridge1 disabled=no edge=auto external-fdb=auto horizon=none interface=wlan1 path-cost=10 point-to-point=auto priority=0x80
/interface bridge settings
set allow-fast-path=yes use-ip-firewall=no use-ip-firewall-for-pppoe=no use-ip-firewall-for-vlan=no
6

I’m not sure about fast path, as I didn’t use that yet, but I think it should not change anything (I might be wrong here).

The main question is, how can it be routing? Is there any other interface, so that it can route your WinBox connection between that and the bridge?

The only other way I can think of, how packets could get into forward chain, is if something used AP’s bridge IP as gateway. That combined with non-working redirects (either AP not sending them or client not accepting them) would throw conntrack off. But I can’t come up with config that would allow connections to work in one direction and not the other. Everything I tried reliably blocked both directions, because that’s what out-interface=bridge1 does, it matches everything going out via bridge, no matter which physical interface is used.

I really like this puzzle and hope that someone finds a solution. :slight_smile:

7

I’m afraid I don’t completely understand your questions.
But on the other hand, I have some part of the puzzle:

Indeed, the bridge also has the dhcp-server issuing the IP’s to the connected clients.
At the same time, this bridge it’s IP is also the default gateway for the connected clients.

If I make a winbox p8291 session, it comes from somewhere of my network with a source IP not part of the AP-CPE network, but with destination of certain CPE. Return traffic from this CPE will now be send to the default gateway, which is the AP-bridge interface.
This AP has a new default gateway sending the return traffic back to its defautl gateway etc. until it reaches a router that still has the original source network as part of its network…

/ip address
add address=172.25.50.65/26 interface=bridge1 network=172.25.50.64
add address=10.50.52.3/27 interface=ether1 network=10.50.52.0
/
ip route
add distance=1 gateway=10.50.52.1

But it still wouldn’t explain to me why the forward chain would filter this traffic if ports are bridged with fast path enabled.
More worrying, why is winbox traffic considered to be ‘invalid’?

8

If AP’s IP is used as gateway by something, it explains why packets go to forward chain. You’re routing between bridge1 and bridge1 (yes, the same interface). Even though you have an address assigned to ether1, router will treat packets to 10.50.52.1 as going out via bridge1. Once the interface is bridged, it no longer behaves as regular interface for routing, bridge takes over.

One thing I don’t understand, why is there a bridge at all? It seems to me that it should work as regular router with 10.50.52.3/27 on ether1 and 172.25.50.65/26 on wlan1, both as independent interfaces, no bridge required. I’m probably still missing something.

On the other hand, I’d expect it to work with bridge too. If CPE gets e.g. 172.25.50.100/26 with gw 172.25.50.65 and router on other side with 10.50.52.1/27 has route to 172.25.50.64/26 via 10.50.52.3, packets in both directions should pass correctly through AP’s routing and conntrack would see proper connections.

So what other interesting things are there?

You can also try to disable fast path, just to test if it changes anything or not. I guest it should not, but as I wrote before, I don’t know much about it.

An example I was thinking about before, that would create invalid connections (in both directions, so not exactly what you have):

GW (main router) <----> AP (transparent bridge) <----> CPE

GW LAN: 192.168.1.1/24
AP bridge IP: 192.168.1.2/24, gateway 192.168.1.1
CPE WAN: 192.168.1.10/24, gateway 192.168.1.2 (instead of proper, directly reachable 192.168.1.1)

CPE tries to connect to e.g. 8.8.8.8. It sends packet to AP, because it has it as gw. AP behaves as router, takes packet from bridge1 and sends it to its own gw, which is again on bridge1. Conntrack sees new connection. When reply packet comes back, GW sends it directly to CPE, because it’s on the same subnet, bypassing AP’s conntrack in the process. As CPE sees it, the connection was established. But when CPE sends another packet to 8.8.8.8, which should be part of that established connection, from AP’s point of view it’s invalid, because AP’s conntract did not see the previous reply from 8.8.8.8 to CPE. It came through AP, but was bridged, not routed. The other direction has exactly the same problem.
Again, it’s not the same thing as you have, but maybe it can give you some idea.

9

You are right, I was expecting your question, there is something else.

Reason for this setup (which is not normal, I agree. Normally I have it set as you explain.) is that this AP gets its power from a switch that at the same time is PoE-inserter. Same Switch (Netonix) has one port going to the local building owner to give him internet. Since I wanted to give his private accespoint (a wifi router) an IP in the same range as the other clients of the AP on top of his building I needed to find a way that switch port and his wifi’s interface is part of the same network as the AP-CPE network. I choose to do it this way. I know, a weird way to make such solution. (Before I used just a vlan between the client side’s interface of AP that runs to the client.)
It also didn’t hurt anything so far since other router in the 10.50.51.0/27 network range are all fixed IP so they will not get any IP from dhcp-server.

What I should do now is to use the extra sfp port of the AP (=Netmetal) and hook that one directly to the client (cable directly from this sfp to its wifi router). Put this sfp interface together with the wlan in one ‘client-bridge’ and put the def-gw for clients and the dhcp-server on this bridge and the original ehternet interface IP plus def. route will take care of the rest.

So yes, the solution is there. Reason why the winbox session are not seen as ‘valid’ but ‘invalid’ instead can indeed be sort of your explanation.

An example I was thinking about before, that would create invalid connections (in both directions, so not exactly what you have):

GW (main router) <----> AP (transparent bridge) <----> CPE

GW LAN: 192.168.1.1/24
AP bridge IP: 192.168.1.2/24, gateway 192.168.1.1
CPE WAN: 192.168.1.10/24, gateway 192.168.1.2 (instead of proper, directly reachable 192.168.1.1)

CPE tries to connect to e.g. 8.8.8.8. It sends packet to AP, because it has it as gw. AP behaves as router, takes packet from bridge1 and sends it to its own gw, which is again on bridge1. Conntrack sees new connection. When reply packet comes back, GW sends it directly to CPE, because it’s on the same subnet, bypassing AP’s conntrack in the process. As CPE sees it, the connection was established. But when CPE sends another packet to 8.8.8.8, which should be part of that established connection, from AP’s point of view it’s invalid, because AP’s conntract did not see the previous reply from 8.8.8.8 to CPE. It came through AP, but was bridged, not routed. The other direction has exactly the same problem.
Again, it’s not the same thing as you have, but maybe it can give you some idea.

I think it could be just reverse in my setup:

  1. PC sends request package with destination a CPE to a router that connects to this Netonix switch with network 10.50.52.0/27
  2. This router sends now directly the package to the CPE. The CPE’s IP is already in this router’s arp table since both the netonix switch and the AP are bridging all traffic.
  3. Traffic hits now the CPE but CPE send return to its def gateway which in fact is the AP bridge.
  4. AP bridge now ‘sees’ this package the first time and it gets registred in the connection tracker. But its a return package from a connection not previously known by this AP connection tracker (since the request passed transparently).

Hence now the ‘invalid’ marker.

This is what I think happens.

I have to put that extra cable and make AP router again instead of bridge.

10

Ok, it does sound likely that it’s somehow caused by your unusual setup. But I’m still not sure about the exact explanation. Specifically about step #2.

Router with just 10.50.52.1/27 should not know about 172.25.50.x CPE. It might be “on the same wire”, it will definitely see ARP requests asking for 172.25.50.x (sent by AP or anything else in 172.25.50.64/26), but switch should not send any ARP reply to router, because it’s not the one asking. And even it switch (more like hub) did send it to router port, router does not (can’t) care about some random ARP reply it didn’t ask for (it would be ARP poisoning). So when router gets a packet for 172.25.50.x CPE, all it can do is to look up the route (172.25.50.64/26 via 10.50.52.3) and send it to MAC address of 10.50.52.3 (AP). AP knows that target MAC is its own, so it should take the packet and route it. AP’s conntrack would know about it.

Even if the previous was wrong and router would be sending packets to CPE directly, it would affect not only connections from your PC to CPE, but also connections from CPE to internet (all reply packets from internet to CPE would still bypass AP’s conntrack, thus breaking the connection). Unless the router would somehow process packets from your PC differently from other packets from internet. Not that I have any plausible idea right now, what exactly it could do and why.