Firewall difficulties

Installing and Using OpenWrt
1

HI everybody,

I'm trying to set up redirection rules. I have privacy violating IoT devices for whom I want to cut WAN access, however there is one service that is really needed, but which I can host myself. Using iptables, I would write something like

iptables -t nat -A PREROUTING -p tcp --dport ${wkp} -j DNAT --to-destination ${server_IP}
iptables -t nat -A POSTROUTING -p tcp --dport ${wkp} -j SNAT --to-source ${gateway_IP}

Here, wkp is the service's well known port, server_IP is the node hosting the service, while gateway_IP is the interface of the OpenWRT router that I'm setting up, facing the server. I'd prefer to use the Luci firewall module for maintainability. After some searching around I came to the conclusion that I have to split up the DNAT and SNAT actions: While the former seems to need an entry under the Ports Forwards tab, the latter apparently needs to go to NAT Rules.

My first question is: Is this the correct way to do this?

There is a host on my network that needs to be exempt from these rules. Using iptables, I'd add

! -s ${exempt_IP}

to the matching section of those rules, i.e. an inverted match for the source IP address. The Luci interface seems not to support match inversion?

My second question therefore is: How to set up match inversion using Luci?

Cheers Peter

2

A1 : YES
A2 : Long overdue, also in fw3 you could do one rule exception activity then other rule general activity

What was and what is in

ubus call system board
3

A2 : Long overdue, also in fw3 you could do one rule exception activity then other rule general activity

Ah, one of those small things that were quick to fix but not sexy enough and therefore take a long time ...
I understand. Thanks.

What was and what is in

Why is that relevant?

Cheers Peter

# ubus call system board
{
	"kernel": "6.6.73",
	"hostname": "edge",
	"system": "AMD GX-412TC SOC",
	"model": "PC Engines apu6",
	"board_name": "pc-engines-apu6",
	"rootfs_type": "ext4",
	"release": {
		"distribution": "OpenWrt",
		"version": "24.10.0",
		"revision": "r28427-6df0e3d02a",
		"target": "x86/64",
		"description": "OpenWrt 24.10.0 r28427-6df0e3d02a",
		"builddate": "1738624177"
	}
}
1 Like
4

I dont understand the reason to ask for the hardware platform when the issue is linked to a software component

5

Just the ages we must skip.

6

Ok, i just wanted to know how old it was. If you had even approximate numbers in OP id be happy.
Also knockof 0p3nWr1 would add some adjustmentsm

Do you have old iptables-save at hand? More custom rules? Any /etc/config/firewall section rejected? "nft list ruleset | grep xt" ? nft list tables - anything beside table inet fw4?

7

Also knockof 0p3nWr1 would add some adjustmentsm

Do you have old iptables-save at hand? More custom rules? Any /etc/config/firewall section rejected? >"nft list ruleset | grep xt" ? nft list tables - anything beside table inet fw4?

I do not understand what you want. I'm confused. You already did answer my question.

Essentially I cannot do directly as I wanted, so I'll set up an acceptance rule for my exempted host first, and then set up the NATting rules.

A question remains though. The three rules go into three different tabs in the firewall GUI in Luci, so I cannot control the sequence. While this is harmless for the NATting rules, the acceptance rule has to come first. So, how do I make sure the acceptance rule, which would go to the Traffic Rules tab, takes precedence over the NATting rules?

8

Then cross check with "nft list ruleset"

Maybe simpler - one can trace the rule order

I am asking to identify partially migrated rules eg relying on nf-xt bridge

9

Are the IoT devices located in a separate firewall zone/IP subnet?

Are the server and the IoT devices on the same IP subnet? If not, you do not need SNAT rules.

Not quite true.

image
image510×252 6.28 KB

10

Ok, so there is some wrong information here.

I have messed around a bit with the firewall GUI, and found that

A2 : Long overdue, ...

is not correct. The GUI does support match inversion.

When creating an entry in the 'Port Forwards' tab, after filling in the fields in the 'General Settings' section I move on to the 'Advanced Settings'. There is an entry labeled 'Source IP address', a combo box. When clicked, it offers the addresses of all hosts the system knows about, plus one '-- custom --' field at the bottom. Entering '!' there, a popup tells me "Expected: Negation of potential: ...". Adding the IP address and '/32' does the job.

Saving and applying, the ruleset contains a new line (replaced the values by the meaning in pointed brackets):

   ip saddr != <exempt_IP> udp dport <wkp> counter packets 0 bytes 0 dnat ip to <server_IP>:<wkp> comment "!fw4: Redirect"

So everything points to the match inversion being set up properly.

Therefore, the question of precedence appears to be moot.

Having said that, it appears peculiar that the GUI would list this entry as "Incoming IPv4 protocol ... To this device". I'd interpret that as being hooked in the Input Hook, rather than the Prerouting Hook, which would defeat the purpose. With iptables, DNAT could only be done in the PREROUTING chain, but I do not know how netfilter handles this. Classically, indeed the term 'Port Forwarding' only refers to forwarding connectings coming into the device, rather than those going through it. So it may not work. But where else would I configure DNATting? Under 'Port Forwards' I cannot see how I make the entry not to display "... To this device".

I am asking to identify partially migrated rules eg relying on nf-xt bridge

Got you. Well, it's a brand new installation with - as far as the firewall is concerned - a brand new setup. No legacy data migrated. Correspondingly, grep xt does not display anything.

11

Not at the moment, but will be.

Yes, I do. Without the SNAT it does not work, and it is very clear, why: The IoT device initiates a connection which is DNATted and therefore reaches the server. The server does not know about the deflection and sends the reply directly to the IoT device, which discards it because it does no have the correct source IP address. The SNAT is needed to have the reply go back the same way.

Yes, I found out by myself, meanwhile.

12

So we need to guess how exactly you restrict IoT devices' access to the internet, by MAC, IP or whatever...

Believe it or not, I am very aware of when the SNAT rule is needed.

You obviously found all the answers yourself, so you should close this thread.

1 Like
13

No, you don't, that part is off-topic here. I only included that information to give a more complete picture of what I'm doing. What I was asking was in two precisely phrased questions in the top posting.

If that is so, then I'm sure you can explain two things:

  1. what's wrong with the reasoning I put forward in my first reply to you?
  2. why it didn't work, when during experimenting I DNATted only, and started working when I added SNAT?

You obviously read only a small part of what I wrote. How about you comment on this:

If it is true what I fear there, then I'm back at square zero: I do not know how to set up DNAT with the firewall setup GUI.