Determination of the kind of a paquet to block it with a Firewall

Where can I find a kind of generic example or a pattern for the iptables rules ?
Does the position of the options like for example -p udp matters in the command ?

https://linux.die.net/man/8/iptables

...but I'd advise using UCI syntax instead - to add these rules to the configs properly.

2 Likes

This looks interesting. It's looks also very low-machine level. From what I understand I can use multiple config rule ?

I made a new diagram which can help helpers (and myself) understand better the problem :

Could you give me an example of blocking the UDP 53 for example ?
I tried every example and no one has worked since :frowning:

thank you

1 Like
  • Blocking UDP/53 in general, or for/from an interface, IP, or subnet???
  • For input, output or forward?

Your request is somewhat vague.

# to block forwarding

config rule
	option name 'Example-Block-UDP-DNS'
	option family 'ipv4'
	option target 'DROP'
	option proto 'udp'
	option dest_port '53'
	option src '*'
	option dest '*'
1 Like

Blocking the UDP/53 for the subnet 192.168.179.0/24

I want no access for this subnet at all to the UDP/53. Incoming and outgoing traffic so I guess OUTPUT and INPUT.

  • What you wrote is not the proper syntax/notation to describe neither an IP nor a subnet
  • I assume you mean the subnet 192.168.179.0/24

You should be able to amend the rule above, you must begin to learn the syntax...one more example...

config rule
	option name 'Example-Block-UDP-DNS'
	option family 'ipv4'
	option target 'DROP'
	option proto 'udp'
	option src_port '53'
	option src '*'
	option dest '192.168.179.0/24'
  • This means that any UDP replies coming to this subnet from another zone will be dropped.
  • It makes more scene to explain what about DNS you're trying to block on this subnet instead - so we can better help you with your use case.
  • If you want to block INPUT to the router, that's another rule

@lleachii, there's no point to allow query forwarding if you don't want to receive replies.

  • I know, but I also don't want to get keep writing all these rules, especially without knowing the use case.
  • The OP also didn't say if they wanted to block DNS requests to the router itself, I didn't want to write a rule that may mess up those replies.

You want to block on the FORWARD chain, but keep in mind that DNS advertised from DHCP is the Openwrt itself.
Took us 23 posts to have an idea of the flows that explain the problem...

@4lexO, DNS is not limited to 53/UDP, there are also:

  • DNS over TCP
  • DNS over HTTPS
  • DNS over TLS
  • DNS over VPN
  • DNSCrypt
  • etc.

And repeat for IPv6.

1 Like

I messed up with the syntax, I tried to talk about the subnet 192.168.178.0/24 but in particular the device with the 192.168.178.194 IP address using a bad shortcut idea(194), let me apologize for it :slight_smile:.

I want to see the behavior when something is blocked on the network. In light of that I can determine regarding the behavior what is wrong because I already tested it and it match the same behavior. Then I will make a tool to make automatic the diagnostic and report it.

Easy. Make a rule for 1 IP, completely blocking forward to WAN. You'll see what you desire.

You can also block it by MAC, then it won't even get an IP from the router.

Blocking replies is ineffective due to this:

iptables-save | grep -e RELATED

So, you need to block queries not replies.

1 Like

This non-limitation explain why when I block one it still can communicate.
Maybe the best it to setup a blacklisted environment by isolating it and then open thing one by one ?

See the answer for "related" -

1 Like

You can, but there's almost no point to do it in home or SOHO network, except for educational purpose.

Most of the time the network configuration I set the device in is a blacklisted one then they only open the ports and whitelist the domain wanted. I have been looking for couple of weeks but didn't have a configurable router, now I have.

I was thinking about making a DROP by default on the LAN interface and then ACCEPT only what is needed. is this corrrect ?

It is feasible, although target DROP is tricky and the whole reasoning is questionable.

May you give more details about it please ? :slight_smile:

openwrt is not the environment to do that...

get a virtualbox running debian and go nuts.... you'll learn 10x faster....

i do not understand the openwrt way.

what you have to factor in is;

a) interface > "zone" translations
b) target default policies and their interaction with the above ( -P FORWARD DROP etc. )

it is a very specific and abstracted way to try to get and understanding.

if you wish to go further.... stick with a single CHAIN..... and work within the default policies.

zone_wan_forward
and
zone_wan_input

are a good place to start.....

  1. make some changes...... in /etc/config/firewall
  2. check what happened in iptables-save

trust me ...... debian virtualbox..... route everything through it if you need something functional.

if your serious about learning..... these are the way to go..... practical feedback will make you practically proficient.