Allow traffic between specific IP in the Guest WiFi

[bortek]

Hi

How do I allow traffic to-from a specific host located in the Guest Wifi 192.168.102.30 and the regular router network (192.168.2.0/24) or specific IP in that network ? Is this possible?

I know that you can allow/deny all or nothing traffic between Guest and regular net but what I want is to deny all and only allow that specific IP.

 

[L&LD]

The easiest way may be to not use GN 1. Use Guest Network 2 or 3 for that client device (or just put it on the main network).

 

[bortek]

well thats damm smart btw. I could put all those host on that specific network.

But the culprit is that I still want that single host (now moved to NG2) to still be able to talk to other hosts on GN1.

Is this controlled by the iptables? Which chains ? Can I manipulate them to achieve what I want perhaps?

 

[bennor]

If you haven't done so already use the search feature as this question has come up in the past. There are various ways to handle it.

For example using YazFi: https://www.snbforums.com/threads/allowing-access-to-selected-network-devices.80405/#post-784521

 

[bortek]

Thanks for the link. I see that this is exactly what I am trying to achieve. I checked Yazu for some time ago and for some reason (which I don't remember now) it was not an alternative in y setup.

But I wonder if I can add the same iptables rules to e.g. FORWARD chain in the iptables. Is it at all possible to manipulate iptables in the ASUS AX86 with meriln?

 

[drinkingbird]

Thanks for the link. I see that this is exactly what I am trying to achieve. I checked Yazu for some time ago and for some reason (which I don't remember now) it was not an alternative in y setup.

But I wonder if I can add the same iptables rules to e.g. FORWARD chain in the iptables. Is it at all possible to manipulate iptables in the ASUS AX86 with meriln?

Yes you need to modify both ebtables brouting and iptables FORWARD. This only works with guest 1. For guest 2 and 3 you have to modify ebtables and also disable AP isolation and even then it is sort of buggy, so I'd stick with Guest 1 for this purpose. I'm doing it for my Guest 1 to be able to print to main LAN printer for example.

I've posted the configs here in another thread in the firewall-start script.

 

[bortek]

I have tried to add these rules for these 2 hosts to be able to talk to each other. So far no success.


192.168.102.57 is my host on 5Ghz guest net which has wl1.1 interface and should also be using br2 interface for bridging
192.168.2.194 is another host on LAN (and br0)

iptables -I FORWARD -i wl1.1 -o br0 -s 192.168.102.57 -d 192.168.2.194 -j ACCEPT
iptables -I FORWARD -i br0 -o wl1.1 -s 192.168.2.194 -d 192.168.102.57 -j ACCEPT

ebtables -t broute -I BROUTING -p IPV4 -i wl1.1 --ip-dst 192.168.102.57 --ip-proto icmp -j ACCEPT
ebtables -t broute -I BROUTING -p IPV4 -i wl1.1 --ip-dst 192.168.102.57 --ip-proto tcp -j ACCEPT

But something else must be missing.... Any thoughts?

 

[drinkingbird]

I have tried to add these rules for these 2 hosts to be able to talk to each other. So far no success.


192.168.102.57 is my host on 5Ghz guest net which has wl1.1 interface and should also be using br2 interface for bridging
192.168.2.194 is another host on LAN (and br0)

iptables -I FORWARD -i wl1.1 -o br0 -s 192.168.102.57 -d 192.168.2.194 -j ACCEPT
iptables -I FORWARD -i br0 -o wl1.1 -s 192.168.2.194 -d 192.168.102.57 -j ACCEPT

ebtables -t broute -I BROUTING -p IPV4 -i wl1.1 --ip-dst 192.168.102.57 --ip-proto icmp -j ACCEPT
ebtables -t broute -I BROUTING -p IPV4 -i wl1.1 --ip-dst 192.168.102.57 --ip-proto tcp -j ACCEPT

But something else must be missing.... Any thoughts?

Few things wrong. See below. Note that you always want to -D a rule before -I or -A if putting it in a script since the firewall-start script (and others) can get called more than once and you'll end up with duplicate rules. IPTABLES and EBTABLES will just keep creating duplicates.

You're also being a lot more specific than you really need to be. If you're specifying an exact source IP, there isn't really any need to specify an interface. It can't hurt, however in your case you're specifying the wrong interface on IPTABLES (wl instead of br) so that is hurting you. IPTABLES is layer3 so you need to specify the layer 3 interface (BRx). EBTABLES is Layer2 so you need to specify the L2 interface (wl, eth, etc).

Specifying the exact source IP is a bad idea here since you can't set a DHCP reservation on Guest Wireless, unless you also do a dnsmasq.postconf script. So if you want to specify the source IP, you need to do that, otherwise just specify the interface or the whole subnet. Or hope your lease never runs out on that IP.

Your ebtables also is backwards, it needs the 192.168.2.x destination not the 192.168.102. ebtables is only applied inbound from the guest wireless, opposite direction is wide open.

Basically this should work for you:

iptables -D FORWARD -i br2 -o br0 -s 192.168.102.57 -d 192.168.2.194 -j ACCEPT
iptables -I FORWARD -i br2 -o br0 -s 192.168.102.57 -d 192.168.2.194 -j ACCEPT

you can leave off either the interfaces or the IPs, not necessary to have both (or mix and match, I do source interface and destination specific IP)
Note that traffic from main LAN to guest is already allowed (along with replies) in IPTABLES so no need to add a rule for that. Only EBTABLES is blocking the responses which you'll fix below
As I mentioned, if you keep the IP(s) make sure you create a static DHCP reservation for the IPs you use.

ebtables -t broute -D BROUTING -p IPv4 -i wl1.1 --ip-dst 192.168.2.194 -j ACCEPT
ebtables -t broute -I BROUTING -p IPv4 -i wl1.1 --ip-dst 192.168.2.194 -j ACCEPT

no need to specify the protocol since it appears you want to allow everything anway. Also you can replace the source interface with an IP if you want to be specific to match your IPTABLES rules

 

[bortek]

Hi

My apologies for a very very late response. All of your suggestions worked out very well and it worked as I wanted it.

Now of course one wants these rules to be persisted across router reboots. What I have tried is this startup script according to the instructions I found. I placed it in /jffs/script and the file is executable and owned by admin:root , see below output of ll command. But this for some reason does not work. What am I missing?

/jffs/scripts# cat services-start
    #!/bin/sh

    # Adding here my custom fw rules

    # Need to open access between G10 speaker on GN1 (.102 net) and HASS on regular .2 net
    logger "Adding custom fw rules from $0 script"
  
    # Touch a file for testing to see if all this works.
    touch /tmp/test123

    iptables -D FORWARD -i br2 -o br0 -s 192.168.102.57 -d 192.168.2.194 -j ACCEPT
    iptables -I FORWARD -i br2 -o br0 -s 192.168.102.57 -d 192.168.2.194 -j ACCEPT

    ebtables -t broute -D BROUTING -p IPv4 -i wl1.1 --ip-dst 192.168.2.194 -j ACCEPT
    ebtables -t broute -I BROUTING -p IPv4 -i wl1.1 --ip-dst 192.168.2.194 -j ACCEPT

    logger "Custom fw rules have been added"

/jffs/scripts# ll
-rwxrwxrwx    1 admin    root           561 Jul 29 10:15 services-start*

 

[drinkingbird]

Hi

My apologies for a very very late response. All of your suggestions worked out very well and it worked as I wanted it.

Now of course one wants these rules to be persisted across router reboots. What I have tried is this startup script according to the instructions I found. I placed it in /jffs/script and the file is executable and owned by admin:root , see below output of ll command. But this for some reason does not work. What am I missing?

/jffs/scripts# cat services-start
    #!/bin/sh

    # Adding here my custom fw rules

    # Need to open access between G10 speaker on GN1 (.102 net) and HASS on regular .2 net
    logger "Adding custom fw rules from $0 script"
 
    # Touch a file for testing to see if all this works.
    touch /tmp/test123

    iptables -D FORWARD -i br2 -o br0 -s 192.168.102.57 -d 192.168.2.194 -j ACCEPT
    iptables -I FORWARD -i br2 -o br0 -s 192.168.102.57 -d 192.168.2.194 -j ACCEPT

    ebtables -t broute -D BROUTING -p IPv4 -i wl1.1 --ip-dst 192.168.2.194 -j ACCEPT
    ebtables -t broute -I BROUTING -p IPv4 -i wl1.1 --ip-dst 192.168.2.194 -j ACCEPT

    logger "Custom fw rules have been added"

/jffs/scripts# ll
-rwxrwxrwx    1 admin    root           561 Jul 29 10:15 services-start*

Services-start is probably too early. Use firewall-start.

EDIT also a few other things
-No blank lines. Put a # on them. No idea if it is a problem for this kernel but it is for some, and is good hygiene. Can't tell if the indent is part of your script but make sure the first thing on every line is either a # or a command, not blank space or tab.
-I prefer to just create the file with vi directly like "vi firewall-start" without a pre-existing file (I'm old school and like VI, but you can use nano if you prefer). Then paste the script in from notepad so all formatting is gone, then "chmod a+rx /jffs/scripts/*" after saving.

A couple obvious ones but worth mentioning:
-You must be running Merlin
-You must have scripts enabled in the GUI.

I use 3 different scripts for different purposes, below are the properties:
/jffs/scripts# ls -al
-rwxrwxrwx 1 xxxxxx root 189 May 28 00:55 dnsmasq.postconf
-rwxrwxrwx 1 xxxxxx root 3260 May 28 00:55 firewall-start
-rwxrwxrwx 1 xxxxxx root 205 May 28 00:55 services-start

 

[Martinski]

...
EDIT also a few other things
-No blank lines. Put a # on them.

That must be a typo because using a blank line between lines of code is definitely valid in all Linux shell interpreters that I've used in the last 30 years or so, and the language grammar specification certainly allows it. In fact, all coding standards for shell scripting that I've seen & used actually encourage the use of blank lines to separate sections of code into smaller but meaningfully associated groupings in order to improve code readability & maintainability as well as to look for opportunities for refactoring during code reviews.

... No idea if it is a problem for this kernel but it is for some, and is good hygiene.
...

A Linux shell interpreter is part of the OS but not part of the kernel, so whether blank lines are allowed by the shell's grammar should never be a concern (or a problem) for the kernel itself.

 

[drinkingbird]

That must be a typo because using a blank line between lines of code is definitely valid in all Linux shell interpreters that I've used in the last 30 years or so, and the language grammar specification certainly allows it. In fact, all coding standards for shell scripting that I've seen & used actually encourage the use of blank lines to separate sections of code into smaller but meaningfully associated groupings in order to improve code readability & maintainability as well as to look for opportunities for refactoring during code reviews.


A Linux shell interpreter is part of the OS but not part of the kernel, so whether blank lines are allowed by the shell's grammar should never be a concern (or a problem) for the kernel itself.

Not a typo, not a linux expert by any means but I have definitely had issues with blank lines at some point in my experience. May be far enough back to be real unix. Sometimes it depends on what you're doing and how you're doing it, so maybe I'm remembering pasting something in vs running a script.

But regardless blank space might be a line with nothing on it, might be a line with spaces or tabs, etc, personally I've always commented out blank lines as it essentially guarantees no issues regardless of what is after it.

Considering the script isn't running just tossing out things to try. The blank lines may or may not be an issue, no idea.

I'm not saying sectioning code is a bad idea, it is proper coding technique in pretty much any language, but I've always seen those lines commented out (maybe not in real programming like C, I don't remember, last time I did anything in C was like 25 years ago).

 

[Martinski]

Not a typo, not a linux expert by any means but I have definitely had issues with blank lines at some point in my experience. May be far enough back to be real unix. Sometimes it depends on what you're doing and how you're doing it, so maybe I'm remembering pasting something in vs running a script.

But regardless blank space might be a line with nothing on it, might be a line with spaces or tabs, etc, personally I've always commented out blank lines as it essentially guarantees no issues regardless of what is after it.

Considering the script isn't running just tossing out things to try. The blank lines may or may not be an issue, no idea.
...

The only times I have seen people (usually non-programmers) have issues with "blank lines" is because they have somehow ended up with a text file containing a mix of EOL terminators (i.e. DOS-style "CR+LF" vs Linux-style "LF"), and it happens that a blank line was the first line with the DOS-style EOL. So, ultimately, it was not a "blank line" problem, but an "EOL char" problem, which can happen on any line - blank or not.

Also, I've heard anecdotes of people having a problem with a "blank line" which was eventually found to be caused by having non-printable chars embedded within some blank lines (IIRC, I believe they had used UTF-8 encoding when the file was initially written instead of the expected 7-bit ASCII encoding).

So instead of "commenting out blank lines" or deleting them, I'd recommend double-checking that the script file has only the expected Linux-style EOL chars and is in fact 7-bit ASCII encoded.

As mentioned before, all shell script language specifications allow blank lines (either empty blank lines or those containing white space) between actual lines of code, so as long as you're working with a shell interpreter that follows the language specification, "commenting out blank lines" has never been a necessary "thing" to do in my experience working with & around Linux OS platforms.

 

[bortek]

I am running Merlin and had scripts enabled in the GUI
Permission are just like yours

I am too a vi geek, never use nano unless forced

Recopied the contents in notepadd++ to remove all the crap chars. Added # to empty lines (just in case) and made sure no tabs are present. Re-pasted into a new firewall-start file. Chomded it.

Now the fw rules were added during the bootup. But I think what made it work was placing it into firewall-start instead of services-start.

Thanks for all your input guys! Much appreciated.