iptables - don't understand why rules don't work

Post new topic   Reply to topic    DD-WRT Forum Index -> Advanced Networking
Author Message
newsboost
DD-WRT User


Joined: 05 Jul 2018
Posts: 83

PostPosted: Sat Apr 03, 2021 2:16    Post subject: iptables - don't understand why rules don't work Reply with quote
Hi all,

It's been maybe 1-2 years ago, since I last read in this forum so please bear over with me, if the solution/answer to my problem is obvious for you... I've been thinking about this too long and cannot understand it. My problem is that I don't understand why iptables doesn't seem to work, changes seem to have no effect. As an example, it is my impression that these commands would block the internet+LAN access for that device:

Code:
root@Netgear:/jffs/etc/config# iptables -I FORWARD -s 192.168.10.53 -j DROP
root@Netgear:/jffs/etc/config# iptables -I INPUT -s 192.168.10.53 -j DROP
root@Netgear:/jffs/etc/config# iptables -I OUTPUT -s 192.168.10.53 -j DROP

root@Netgear:/jffs/etc/config# iptables -I OUTPUT -d 192.168.10.53 -j DROP
root@Netgear:/jffs/etc/config# iptables -I INPUT -d 192.168.10.53 -j DROP
root@Netgear:/jffs/etc/config# iptables -I FORWARD -d 192.168.10.53 -j DROP


But that doesn't happen - it can still access the internet as usual. My setup:

Netgear R7000, DD-WRT v3.0-r45863 std (02/28/21), from the GUI: "WAN Connection Type" is "Disabled", under "Advanced Routing", "Operating Mode" is set to "router". I have 2 VLANs (192.168.1.0/24 and 192.168.10.0/24):

Code:
brctl show
bridge name   bridge id      STP enabled   interfaces
br0      8000.9c3dcf8b8705   no      eth1
                     eth2
                     vlan1
                     vlan2
br1      8000.9c3dcf8b8705   no      vlan10
                     wl0.1


iptables setup - table nat:

Code:
root@Netgear:/jffs/etc/config# iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 1126 packets, 131K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DNAT       udp  --  wl0.2  *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 to:8.8.8.8
    0     0 DNAT       tcp  --  wl0.2  *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53 to:8.8.8.8

Chain INPUT (policy ACCEPT 321 packets, 20736 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 3 packets, 200 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 3 packets, 200 bytes)
 pkts bytes target     prot opt in     out     source               destination


iptables setup - table default filter:

Code:
root@Netgear:/jffs/etc/config# iptables -nvL
Chain INPUT (policy ACCEPT 340 packets, 37354 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  *      *       192.168.10.53        0.0.0.0/0           
    0     0 DROP       all  --  *      *       0.0.0.0/0            192.168.10.53       
    0     0 DROP       all  --  *      *       0.0.0.0/0            192.168.10.42       
    0     0 DROP       all  --  *      *       192.168.10.42        0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  *      *       192.168.10.53        0.0.0.0/0           
    0     0 DROP       all  --  *      *       0.0.0.0/0            192.168.10.53       
    0     0 DROP       all  --  *      *       0.0.0.0/0            192.168.10.42       
    0     0 ACCEPT     tcp  --  *      *       192.168.10.0/24      192.168.1.3         
    0     0 DROP       all  --  br1    *       0.0.0.0/0            192.168.1.1         
    0     0 DROP       all  --  *      *       192.168.10.0/24      192.168.1.0/24     

Chain OUTPUT (policy ACCEPT 301 packets, 41148 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  *      *       192.168.10.53        0.0.0.0/0           
    0     0 DROP       all  --  *      *       0.0.0.0/0            192.168.10.53       
    0     0 DROP       all  --  *      *       0.0.0.0/0            192.168.10.42       
    0     0 DROP       all  --  *      *       192.168.10.0/24      192.168.1.0/24     

Chain advgrp_1 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain advgrp_10 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain advgrp_11 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain advgrp_12 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain advgrp_13 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain advgrp_14 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain advgrp_15 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain advgrp_16 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain advgrp_17 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain advgrp_18 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain advgrp_19 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain advgrp_2 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain advgrp_20 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain advgrp_3 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain advgrp_4 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain advgrp_5 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain advgrp_6 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain advgrp_7 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain advgrp_8 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain advgrp_9 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain grp_1 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain grp_10 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain grp_11 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain grp_12 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain grp_13 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain grp_14 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain grp_15 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain grp_16 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain grp_17 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain grp_18 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain grp_19 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain grp_2 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain grp_20 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain grp_3 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain grp_4 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain grp_5 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain grp_6 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain grp_7 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain grp_8 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain grp_9 (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain lan2wan (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain logaccept (0 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain logdrop (0 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain logreject (0 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with tcp-reset

Chain trigger_out (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain upnp (0 references)
 pkts bytes target     prot opt in     out     source               destination


I don't understand this behaviour - shouldn't the first posted lines block at least the internet connection for 192.168.10.53 (also LAN)? I login via SSH and type the iptables commands... I think this used to work a long time ago, but now I want real segmentation instead of having "mixed VLAN 1 and VLAN 10"... A long time ago I also once remember I had two different "iptables" executables, one from the "default" build and one from ipkg/opkg, but right now neither of ipkg/opkg works so I think that isn't the problem... Anyone have any ideas why it doesn't work, shouldn't it work right away from the SSH prompt?
Sponsor
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12917
Location: Netherlands

PostPosted: Sat Apr 03, 2021 6:07    Post subject: Reply with quote
I will transfer this to the appropriate forum (Advanced Networking)

If this router is setup as a WAP ( https://wiki.dd-wrt.com/wiki/index.php/Wireless_Access_Point ) the traffic just passes the router and the blocking should be done on the primary router.

Exceptions are unbridged interfaces on the WAP those go through the router and can be handled by the firewall of the WAP (unless you use trunking to connect this unbridged interface with a trunk port to the primary router in that case the blocking should also be done on the primary router, this might be the case in your setup?)

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
newsboost
DD-WRT User


Joined: 05 Jul 2018
Posts: 83

PostPosted: Sat Apr 03, 2021 15:46    Post subject: Reply with quote
egc wrote:
I will transfer this to the appropriate forum (Advanced Networking)
Thanks, sorry that makes completely sense.
egc wrote:
If this router is setup as a WAP ( https://wiki.dd-wrt.com/wiki/index.php/Wireless_Access_Point ) the traffic just passes the router and the blocking should be done on the primary router.
Right, I think I forgot to add a few words about that: My primary router (Asus AT-RC87U) is currently the only DHCP-server, so I'm trying to apply iptables rules on the secondary router, which is the only router that directly connects clients to VLAN 10 (my IOT-network) - I tried to make iptables rules that restricts VLAN 10-clients from talking to VLAN 1-clients (on the secondary, DD-WRT router). So under "Basic Setup", the "DHCP Server"-setting is set to "disable" using the DD-WRT-gui. Also I have "Assign WAN Port to Switch", while that port is the trunk port for VLAN 1+10, going to the main router (via a managed VLAN-capable switch). Vlan 1 is 192.168.1.0/24 and Vlan 10 is 192.168.10.0/24. Local IP address of the secondary router is 192.168.1.3.

I'm not 100% sure if my setup matches the wiki-description of a WAP primarily because I have VLAN's. But: I think this is a WAP (primarily because the two routers are connected via a trunk cable), but I don't didn't exactly think my setup completely matched either the https://wiki.dd-wrt.com/wiki/index.php/Wireless_Access_Point#Secondary_Router_on_a_Separate_Subnet (same subnet), nor the "Secondary Router on a Separate Subnet", but maybe I'm just getting confused because that page doesn't talk about VLANs?

Does my setup fit to the definition of a WAP? I think it is - but I didn't see the wiki explain that iptables doesn't work for WAPs, how is that so (I think I once had something working with iptables, with a similar setup as now, but that doesn't work longer, maybe I changed something slightly and cannot remember what it is)? But it would definately make sense, if this is the explanation - as I don't understand why iptables have no effect...

egc wrote:
Exceptions are unbridged interfaces on the WAP those go through the router and can be handled by the firewall of the WAP...
I think my VLAN 10-devices are bridged via br1 like so, because I wanted both wifi+ethernet VLAN 10 clients to be able to talk together:
Code:
br1      8000.9c3dcf8b8705   no      vlan10
                     wl0.1
Sorry, I don't understand why iptables should work for unbridged interfaces and not for bridged interfaces? Under http://192.168.1.3/Firewall.asp I have "SPI Firewall" set to "Disable" - is that wrong (because it's being protected by the main router's firewall, on the WAN-side of the primary router)?

egc wrote:
... (unless you use trunking to connect this unbridged interface with a trunk port to the primary router in that case the blocking should also be done on the primary router, this might be the case in your setup?)
Getting a bit confused here, but: In the http://192.168.1.3/Vlan.asp setting I have the physical WAN-port (WAN-port is disabled in the DD-WRT-GUI, so it's an extra LAN-port) acting as trunk for VLAN 1+10 (furthermore, physical ports 1-3 are VLAN 10 ports while port 4 is a VLAN 1-port). But vlan 10 is software-wise contained in br1, thus I don't think your last comment applies to me?

As I understand you (*if* I understand you correctly), iptables doesn't work because (I think) my secondary router works as a WAP and the VLAN-10-clients are bridged to br1. I didn't know that, I thought iptables always worked? Why isn't there any iptables forwarding of packets going on in this case and why would there be, if VLAN 10 used an unbridged interface? Sorry for (maybe) stupid questions - but I can see that the solution is probably that I have to apply iptables-rules on the main router (which I also think I can, I'm just confused because I think I earlier had a setup working with a secondary router pretty similar to now, where iptables-rules worked, hmmmm?)... Thanks for kind help, also, I'm having a really hard problem googling for an exact answer to this (I find many irrelevant links/sources)!
Per Yngve Berg
DD-WRT Guru


Joined: 13 Aug 2013
Posts: 6870
Location: Romerike, Norway

PostPosted: Sat Apr 03, 2021 16:16    Post subject: Reply with quote
Iptables only is executed when packets are routed on the IP Layer (Layer 3 in the OSI model).

In your case wl0.1->br1->vlan10->Router1 on the MAC layer (Layer 2), where it's received by the IP address on vlan10 on router1 (same sub-net).
newsboost
DD-WRT User


Joined: 05 Jul 2018
Posts: 83

PostPosted: Sat Apr 03, 2021 17:00    Post subject: Reply with quote
Per Yngve Berg wrote:
Iptables only is executed when packets are routed on the IP Layer (Layer 3 in the OSI model).
Ok, sorry there's clearly a big hole in my knowledge here. I've seen MAC address-stuff is layer 2 and IP address stuff is layer3... Why is there a difference between bridged and unbridged interfaces? Are you saying unbridged data are on layer 3? And bridged interface-data - is that layer 2?

Per Yngve Berg wrote:
In your case wl0.1->br1->vlan10->Router1 on the MAC layer (Layer 2), where it's received by the IP address on vlan10 on router1 (same sub-net).
Router 1=primary router and router 2=secondary router, right? The wl0.1 and everything I showed previosly were output from the secondary router (router 2) and that is where vlan 10-clients connects to first...

I think I'm confused because I'm just thinking like a layman here: So data is entering router 2 (secondary router) on VLAN 10. Me as a layman thinks: Then the router must forward that data to router 1 (primary router), because that won't happen by itself. Again as layman I'm thinking: So traffic passes the router, hence the router must be forwarding something, hence iptables should be in effect... That way of thinking is clearly wrong.

I googled a bit and found: "As the linked ebtables documentation says (possibly on a different page), you need an ebtables DROP target in BROUTING table to make the packets go through iptables" - I assume that is also the case here, unless I just do the iptables-rules on the primary (#1)-router? So with ebtables I can DROP to get packets to from layer 2 to layer 3, is that correct?
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 9157

PostPosted: Sat Apr 03, 2021 17:57    Post subject: Reply with quote
Ultimately, all devices communicate at the ethernet layer based on their MAC addresses. When those devices are all sharing the same ethernet segment (and by extension, the same IP network, e.g., 192.168.1.x), they are considered *bridged*. There is no need for routing. In fact, a simple switch is sufficient. And if you want to firewall access between those devices, you would either have to use personal firewalls, or a layer 2 ethernet firewall (e.g., ebtables).

Routing is required when you need to jump from one ethernet segment to a *different* ethernet segment, and where each ethernet segment is using a different IP network (e.g., 192.168.1.x and 192.168.2.x). NOW you need to route between those two different networks using a router. A switch is NOT sufficient. And the router's layer 3 IP firewall (iptables) now comes into play.

_________________
ddwrt-ovpn-split-basic.sh (UPDATED!) * ddwrt-ovpn-split-advanced.sh (UPDATED!) * ddwrt-ovpn-client-killswitch.sh * ddwrt-ovpn-client-watchdog.sh * ddwrt-ovpn-remote-access.sh * ddwrt-ovpn-client-backup.sh * ddwrt-mount-usb-drives.sh * ddwrt-blacklist-domains.sh * ddwrt-wol-port-forward.sh * ddwrt-dns-monitor.sh (NEW!)
newsboost
DD-WRT User


Joined: 05 Jul 2018
Posts: 83

PostPosted: Sat Apr 03, 2021 20:40    Post subject: Reply with quote
eibgrad wrote:
Ultimately, all devices communicate at the ethernet layer based on their MAC addresses. When those devices are all sharing the same ethernet segment (and by extension, the same IP network, e.g., 192.168.1.x), they are considered *bridged*. There is no need for routing. In fact, a simple switch is sufficient. And if you want to firewall access between those devices, you would either have to use personal firewalls, or a layer 2 ethernet firewall (e.g., ebtables).

Routing is required when you need to jump from one ethernet segment to a *different* ethernet segment, and where each ethernet segment is using a different IP network (e.g., 192.168.1.x and 192.168.2.x). NOW you need to route between those two different networks using a router. A switch is NOT sufficient. And the router's layer 3 IP firewall (iptables) now comes into play.
Ok, that's a good explanation. But I still thought the secondary router had to forward traffic/data packets from each of it's ports/clients to the primary router - and when router #2 receives something from router #1 it still has to distribute that and as it "forwards" data, I always imagined that went through iptables... Gotta stop thinking like that... It's a good comparison, that it would then work as a simple switch where no routing takes places, I'll try to remember that, very useful... Thanks!

I basically solved (most of) my iptables-problem(s) by moving the commands from the secondary router to the first - I have some issues regarding exceptions to the iptables-rules but I think I will maybe make a new thread for that purpose, instead of continuing here - thanks, eibgrad, egc and Per Y Berg, for great help, very much appreciated!
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 9157

PostPosted: Sat Apr 03, 2021 21:11    Post subject: Reply with quote
newsboost wrote:
Ok, that's a good explanation. But I still thought the secondary router had to forward traffic/data packets from each of it's ports/clients to the primary router - and when router #2 receives something from router #1 it still has to distribute that and as it "forwards" data, I always imagined that went through iptables.."


I think part of the confusion here is the term "forward". Yes, a switch will forward traffic to another switch, but at the ethernet level. It's NOT forwarding as in "routing" from one to the other. We sometimes use the terms "forward" and "route" interchangeably (such as the port forwarding page of the GUI). Even iptables uses the FORWARD chain of the filter table. All of which contribute to the confusion.

IOW, both switches and routers can legitimately use the term "forward", but it has a different meaning in each case.

_________________
ddwrt-ovpn-split-basic.sh (UPDATED!) * ddwrt-ovpn-split-advanced.sh (UPDATED!) * ddwrt-ovpn-client-killswitch.sh * ddwrt-ovpn-client-watchdog.sh * ddwrt-ovpn-remote-access.sh * ddwrt-ovpn-client-backup.sh * ddwrt-mount-usb-drives.sh * ddwrt-blacklist-domains.sh * ddwrt-wol-port-forward.sh * ddwrt-dns-monitor.sh (NEW!)
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1447
Location: Appalachian mountains, USA

PostPosted: Sat Apr 03, 2021 21:31    Post subject: Reply with quote
Plus your iptables commands install rules into the firewall, but you disable the firewall ("SPI Firewall"), so those rules areof course ignored.
_________________
2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
newsboost
DD-WRT User


Joined: 05 Jul 2018
Posts: 83

PostPosted: Sat Apr 03, 2021 21:53    Post subject: Reply with quote
eibgrad wrote:
We sometimes use the terms "forward" and "route" interchangeably (such as the port forwarding page of the GUI). Even iptables uses the FORWARD chain of the filter table. All of which contribute to the confusion.

IOW, both switches and routers can legitimately use the term "forward", but it has a different meaning in each case.
Right, I hope my learned my lesson and that I won't forget it too soon. I've got so many things I wish I had more sparetime to dig into and iptables/networking is one of these things Smile Well, as long as I remember that when something is on the same subnet, there's no need for "routing", only "forwarding like a simple switch" would do it (hence no iptables are in effect) Smile
newsboost
DD-WRT User


Joined: 05 Jul 2018
Posts: 83

PostPosted: Sat Apr 03, 2021 21:55    Post subject: Reply with quote
SurprisedItWorks wrote:
Plus your iptables commands install rules into the firewall, but you disable the firewall ("SPI Firewall"), so those rules areof course ignored.
Oh, damn, now I'm getting confused again: I didn't test it yet, but are you saying that iptables-rules would be in effect if I enabled that SPI firewall?
UPDATE: I tested it (enabling the SPI firewall via the GUI, without saving, just hitting "Apply Settings") - it makes no difference? Still a bit weird, I think - but this tells me that it's correct that it's just acting as a "dumb switch", not processing any iptables rules even if SPI firewall is enabled... Smile
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1447
Location: Appalachian mountains, USA

PostPosted: Sat Apr 03, 2021 23:51    Post subject: Reply with quote
I'm not sure the firewall is ever enabled in Router mode. I'm not an expert on that point. But if you get back to the more common Gateway mode, use the WAN port as a WAN port, enable the SPI Firewall, execute some iptables commands, and inspect the firewall (for example "iptables -vnL FORWARD" in the CLI to look at the FORWARD chain), you should see your rules and, on the left , how many times each has executed its action.

Of note also is that your rules have issues. The INPUT and OUTPUT chain refer to traffic to and from the router's own internal processes, at whatever IP you have assigned it. Traffic to and from the admin GUI, for example, goes through those two chains.

But the other guys commenting in this thread know way more about 100% of all of this than I do. They are experts. I'm just an advanced beginner, if perhaps one with verbose tendencies in the forum! So listen to them re your specific situation re Router mode, etc.

_________________
2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
newsboost
DD-WRT User


Joined: 05 Jul 2018
Posts: 83

PostPosted: Sun Apr 04, 2021 0:22    Post subject: Reply with quote
SurprisedItWorks wrote:
I'm not sure the firewall is ever enabled in Router mode. I'm not an expert on that point. But if you get back to the more common Gateway mode, use the WAN port as a WAN port, enable the SPI Firewall, execute some iptables commands, and inspect the firewall (for example "iptables -vnL FORWARD" in the CLI to look at the FORWARD chain), you should see your rules and, on the left , how many times each has executed its action.
Oh, so that explains it: Maybe that's why I believe it has worked for me before on that router, i.e. maybe I had the router in Gateway mode instead of like now in router mode... That makes very much sense, thanks a lot for that comment, I believe you're right...
SurprisedItWorks wrote:
Of note also is that your rules have issues. The INPUT and OUTPUT chain refer to traffic to and from the router's own internal processes, at whatever IP you have assigned it. Traffic to and from the admin GUI, for example, goes through those two chains.
I understand that. But the rules I posted were just some experimenting, where I attempted to give specific access to the webUI from a few individual IP addresses, there are no rules there now (as they didn't have any effect at all). I haven't posted the final rules, I'm guessing they're not really that interesting for the sake of the discussion as there's nothing left "to solve"... I'm getting better at experimenting with and learning about iptables and I really enjoy this "affordable" open-source stuff, instead of having to buy expensive stuff proprietary (I think Cisco is in that category) for my private home, I'm pretty sure my next router should also be a DD-WRT-router, at least based on opensource linux Smile

SurprisedItWorks wrote:
But the other guys commenting in this thread know way more about 100% of all of this than I do. They are experts. I'm just an advanced beginner, if perhaps one with verbose tendencies in the forum! So listen to them re your specific situation re Router mode, etc.
Right, but I never completely understood why iptables didn't have an effect - I think it was very valuable that you suggested it was because it wasn't/isn't in gateway mode... I don't want to make that experiment now, but maybe another day I could experiment with this - on the other hand, it works now fully (just figured out the last rules, after some initial struggling), so I might also just leave it. In the future I hope to learn more about ebtables but also more about iptables-setups, I think I'll follow this forum for a while, it's sometimes a bit difficult with limited sparetime but I think networking is really interesting so I ought to spend a bit more time here, reading from other people's experiences Smile
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Index -> Advanced Networking All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum