1

I can't find out how to create a fw3 rule which does what I want (block all traffic from 192.168.1.119). I have this in /etc/config/firewall

config rule                                 
        option name 'Block client egress'
        option src 'lan'                   
        option src_ip '192.168.1.119'
        option dest 'vpn'
        option proto 'all'    
        option target 'REJECT'

But that essentially is converted into

iptables -A zone_lan_forward -s 192.168.1.119/32 -j zone_vpn_dest_REJECT

And "vpn" is just the name of a corporate VPN that all WAN traffic is forwarded to. This doesn't work (connections go through and don't get rejected), so I want a fw3 rule that does this (which DOES work):

iptables -I FORWARD -s 192.168.1.119/32 -j REJECT

How do I set up a fw3 rule that turns into that?

Here are the chains btw which I think are causing the problem (because plain FORWARD and REJECT for what I need):

root@OpenWrt:~# iptables -S zone_lan_forward
-N zone_lan_forward
-A zone_lan_forward -m comment --comment "!fw3: Custom lan forwarding rule chain" -j forwarding_lan_rule
-A zone_lan_forward -m comment --comment "!fw3: Zone lan to vpn forwarding policy" -j zone_vpn_dest_ACCEPT
-A zone_lan_forward -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port forwards" -j ACCEPT
-A zone_lan_forward -m comment --comment "!fw3" -j zone_lan_dest_ACCEPT
root@OpenWrt:~# iptables -S zone_vpn_dest_REJECT
-N zone_vpn_dest_REJECT
-A zone_vpn_dest_REJECT -o tun0 -m comment --comment "!fw3" -j reject
root@OpenWrt:~# iptables -S reject
-N reject
-A reject -p tcp -m comment --comment "!fw3" -j REJECT --reject-with tcp-reset
-A reject -m comment --comment "!fw3" -j REJECT --reject-with icmp-port-unreachable

This doesn't work:

config zone
        option name 'deny'
        option subnet '0.0.0.0/0'
        option input 'REJECT'
        option output 'REJECT'
        option forward 'REJECT'

config zone
        option name 'lan'
        list network 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'

config rule
        option name 'Block client egress'
        option src 'lan'
        option src_mac 'MAC ADDR HERE'
        option dest 'deny'
        option proto 'all'
        option target 'REJECT'
owrtbro
  • 31
  • 6
  • It seems that the only "fw3-way" of doing it is adding a `zone` with `subnet` being `0.0.0.0/0` and then you use that zone as the `dest` of your `rule`. – Tom Yan Jul 08 '22 at 02:33
  • @TomYan Thank you I will try that. Would that be less of a hack than using `/etc/firewall.user` for it? I used firewall.user also because fw3 doesn't support host names for some reason in `src_ip` whereas iptables does with `-s`. – owrtbro Jul 08 '22 at 02:37
  • Btw, in case you need to match "really any" traffics with source IP `192.168.1.119`, you might try adding another `zone` with `subnet` being the IP and use it as the `src` of your rule (and omit `src_ip`), as `src 'lan'` probably adds an `-i` match. – Tom Yan Jul 08 '22 at 02:44
  • @TomYan What do you mean "really any"? I don't want it to get to `vpn` or `wan` *at all* and not to get to anything else on `lan` by itself (but RELATED,ESTABLISHED is ok, I'll set that up later). – owrtbro Jul 08 '22 at 02:45
  • I mean like when the traffic has the source IP `192.168.1.119` but it's not from `lan`. – Tom Yan Jul 08 '22 at 02:46
  • @TomYan It's only on the lan. I don't know where else it would come from. If it came from `wan` then it would be marked as invalid because it's a private address I'd think. – owrtbro Jul 08 '22 at 02:47
  • Well theoretically it could be from any interface (but pretty much only when it's some kind of malicious activity), and to prevent that kind of traffics, you would probably do it with any other rule anyway (like limiting source address as per the corresponding interface), so it was just a side note. (It's more or less out of the scope of your rule / question here.) – Tom Yan Jul 08 '22 at 02:50
  • @TomYan Ok but if the `192.168.1.119` is malicious then it would still block it. So it would only be a problem if I somehow have to blindly trust .119 and someone else on another interface could spoof it? Anyway what I really want to do is prevent .119 from accessing the internet either through wan directly or the vpn interface. I will later set it up so it can only access it once a week (during a time it needs to) and even then only whitelisted destinations. But that is something I can figure out on my own (I know how to use xt_time) when I get this part working. – owrtbro Jul 08 '22 at 02:53
  • Note that iptables is not *that* "smart". What's malicious is more or less defined by *you*. And there's no such thing as "private IP from WAN -> consider invalid" (conntrack state like invalid isn't quite relevant in this case anyway). And yeah it's just a side note that isn't strictly related to your goal here. – Tom Yan Jul 08 '22 at 02:58
  • @TomYan I tried doing it the "fw3 way" and it's not doing anything. See my edit. Did I do it wrong? – owrtbro Jul 08 '22 at 03:22
  • How do the `iptables -S`s look now? (It would be even better if you could just add a full `iptables-save` dump; or at least also `-S FORWARD`.) – Tom Yan Jul 08 '22 at 03:54
  • @TomYan I think I discovered that I'm having an "XY" problem. The device is plugged in via ethernet directly into the router so I think that the real solution is to use a VLAN which would be so much easier to isolate (once I figure out how to do it on OpenWrt!). And then I can treat the device in fw3 more easily. – owrtbro Jul 08 '22 at 04:20
  • Maybe. But the bottom line is AFAICT, VLAN does not make it any more secure (just like the case of IP and MAC address, if users can freely change those on the host you want to block, they can most likely stop it from tagging as well; certainly you can allow only tagged traffics, which might help a bit because the ID which forwarding is allowed might need to be guessed, but at the same time it's quite a hassle). On the other hand, `subnet` in a `zone` can include multiple IPs / subnets, apparently, so it should still be quite convenient if you use a `subnet` zone for both `src` and `dest`. – Tom Yan Jul 08 '22 at 07:05
  • Btw I wonder if the reason that it didn't work was because your `lan` zone wasn't even properly defined? – Tom Yan Jul 08 '22 at 07:07
  • @TomYan The router is trusted. The device attached is untrusted. When you say "users can freely change those on the host" do you mean a physical user unplugging the cable and putting it into a different port or do you mean the device itself can somehow bypass VLAN? I'm not much of a network guy so I'm still reading about the difference between tagged and untagged ports. – owrtbro Jul 08 '22 at 21:07
  • @TomYan I accomplished what I wanted to do with VLANs. Should I delete my question or leave it open in case someone else has the same problem? – owrtbro Jul 09 '22 at 02:17
  • I don't know the exact capability of your router, but unless it has multiple interface (in which case VLAN may not even be necessary; switch port is not the same thing as interface btw) or if its builtin switch is sort of a managed one that supports "PVID", I assume your VLAN is set up by configuring tagging on the LAN host(s). In that case its no more than an OS configuration, which can be changed by a user or even a program if they have the privileges, just like IP and MAC address can be spoofed / changed. – Tom Yan Jul 09 '22 at 06:03
  • In any case, if you have the time and/or interest, you can write an answer with the solution you adopted and mark this as answered. – Tom Yan Jul 09 '22 at 06:06
  • @TomYan It has three interfaces. One for WAN, one for WLAN, and one for LAN. The LAN one has several ports and is a VLAN capable switch. I just assigned one of them to a seperate VLAN. The router is trusted and of course any process on the router with root could undo the changes and any physical person could just swap the ethernet cable to a different port that is not under the isolated VLAN and that's ok and not a risk in this case. I guess I will write an answer saying how I did it. Thanks for the advice. – owrtbro Jul 09 '22 at 20:45

0 Answers0