What's new

"Access Intranet" = disable for 5G guest, not working?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Martin - SNBuser

Regular Contributor
Hi,

I have two "Gst"-wireless SSID's, made by choosing "Guest Network" in the menu to the left. One guest network is 2.4 GHz and the other is 5 GHz. Both places, I disabled "Access Intranet". I then take my Samsung Galaxy S3 phone and first connect to the 2.4 GHz. I use the app "Net Scan" and make a scan to see if it discovers other IP addresses. It finds 192.168.1.1, which is the router (I would like to also hide this, however this is not the most important part now). I'm happy to see that everything else, except the router is not shown.

I then again take my Samsung Galaxy S3 phone and connect to the wireless 5 GHz guest network. Again, I use the same app "Net Scan" - again I have "Access Intranet" = disable. But now I see all my other computers, printers etc...

I don't understand this? I believe with "Access Intranet = disable" in both cases, I should obtain the same behaviour??? A bug? Did I misunderstand anything?

Update: I now followed the instructions here: https://github.com/RMerl/asuswrt-me...dicated-DHCP-options-bind-to-a-specific-SSID?
 
Last edited:
Code:
# cat /jffs/scripts/dnsmasq.postconf
#!/bin/sh
# -------------
CONFIG=$1
source /usr/sbin/helper.sh
logger "dnsmasq-dhcp: Configure wl0.1 to have special DHCP"
ifconfig wl0.1 172.16.0.1 netmask 255.255.255.0
iptables -D INPUT -i wl0.1 -j ACCEPT
iptables -I INPUT -i wl0.1 -j ACCEPT
ebtables -t broute -D BROUTING -i wl0.1 -p ipv4 -j DROP
ebtables -t broute -I BROUTING -i wl0.1 -p ipv4 -j DROP
pc_append "
log-dhcp
interface=wl0.1
dhcp-range=wl0.1,172.16.0.100,172.16.0.200,255.255.255.0,86400s
dhcp-option=wl0.1,3,172.16.0.1
dhcp-option=wl0.1,6,8.8.8.8,8.8.4.4
" /tmp/etc/dnsmasq.conf

Code:
-rwxrwxrwx    1 wrt54g   root           676 Sep 14 23:54 /jffs/scripts/dnsmasq.postconf

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

RC='/opt/etc/init.d/rc.unslung'

i=30
until [ -x "$RC" ] ; do
  i=$(($i-1))
  if [ "$i" -lt 1 ] ; then
    logger "Could not start Entware"
    exit
  fi
  sleep 1
done
$RC start
# ------------------
service restart_dnsmasq

Sorry, I received messages "Sorry you have been blocked" - not sure why... Here's the final part of my message:
Code:
-rwxrwxrwx    1 wrt54g   root           237 Sep 14 23:55 /jffs/scripts/services-start

This correctly gives me the IP-address 172.16.0.161 - but now I cannot access the internet... Anyone, please let me know, what I did wrong. Do I need something, maybe a MASQUERADE command with iptables, maybe?
 
Last edited:
If you add "--ip-dst 172.16.0.0/24" to ebtables broute rule, will it get your Internet back? What's your "ebtables -t filter -L FORWARD" chain?
 
What's your "ebtables -t filter -L FORWARD" chain?
I assume this also answers the question:
Code:
# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 2, policy: ACCEPT
-i wl0.1 -j DROP
-o wl0.1 -j DROP

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
Code:
# ebtables -t broute -L
Bridge table: broute

Bridge chain: BROUTING, entries: 2, policy: ACCEPT
-p IPv4 -i wl0.1 --ip-dst 172.16.0.0/24 -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP
I'm not sure how it's supposed to look like... Does it look ok? It's okay for traffic on 172.16.X.X to see each other, but I don't want 172.16.X.X to be able to reach 192.168.1.0/24... I don't know how to accomplish this, I hope someone can help...

If you add "--ip-dst 172.16.0.0/24" to ebtables broute rule, will it get your Internet back?
Like this?
Code:
wrt54g@router:/jffs/scripts# cat dnsmasq.postconf
#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
logger "dnsmasq-dhcp: Configure wl0.1 to have special DHCP"
ifconfig wl0.1 172.16.0.2 netmask 255.255.255.0
iptables -D INPUT -i wl0.1 -j ACCEPT
iptables -I INPUT -i wl0.1 -j ACCEPT
ebtables -t broute -D BROUTING -i wl0.1 -p ipv4 -j DROP
ebtables -t broute -I BROUTING -i wl0.1 -p ipv4 --ip-dst 172.16.0.0/24 -j DROP
pc_append "
log-dhcp
interface=wl0.1
dhcp-range=wl0.1,172.16.0.100,172.16.0.200,255.255.255.0,86400s
dhcp-option=wl0.1,3,172.16.0.1
dhcp-option=wl0.1,6,8.8.8.8,8.8.4.4
" /tmp/etc/dnsmasq.conf
Followed by:
Code:
wrt54g@router:/jffs/scripts# service restart_dnsmasq

Done.
? Oh, yes and no (to the question, "does it work?")... I disconnected from the wireless network and tried again - and at least I can now browse the internet. But I noticed, now my IP address on my phone is 192.168.1.241 - instead of 172.16.0.XX ? Can that be right? Did I make a mistake? I do not fully understand the commands, please advice or comment on my configuration... But the good thing is that now my Android phone is on 192.168.1.XX and it can only see the router on 192.168.1.1 and itself... I consider this to be a good security precaution...

I have a small question: When I type e.g: "dhcp-option=wl0.1,3,172.16.0.1" - my router is actually on 192.168.1.1 but I assumed I had to give the router a new IP address on the 172.16.0.XX/24-network... Is this option set correct? And how is it about bridging with wl0.1 and the routers WAN-side? I appreciate any help, thanks.

For the sake of completeness, I show my IPtables-rules (not sure if it means anything):
Code:
wrt54g@router:/jffs/scripts# iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination       
    0     0 ACCEPT     all  --  wl0.1  any     anywhere             anywhere         
   14   590 DROP       icmp --  eth0   any     anywhere             anywhere             icmp echo-request
100K   15M ACCEPT     all  --  any    any     anywhere             anywhere             state RELATED,ESTABLISHED
2840  117K DROP       all  --  any    any     anywhere             anywhere             state INVALID
59517   20M ACCEPT     all  --  br0    any     anywhere             anywhere             state NEW
33319 7713K ACCEPT     all  --  lo     any     anywhere             anywhere             state NEW
  641  212K ACCEPT     udp  --  any    any     anywhere             anywhere             udp spt:bootps dpt:bootpc
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere             icmp !echo-request
1270 78967 DROP       all  --  any    any     anywhere             anywhere         

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination       
63480   22M ACCEPT     all  --  any    any     anywhere             anywhere             state RELATED,ESTABLISHED
   37  2429 DROP       all  --  !br0   eth0    anywhere             anywhere         
    0     0 DROP       all  --  eth0   any     anywhere             anywhere             state INVALID
    0     0 ACCEPT     all  --  br0    br0     anywhere             anywhere         
    0     0 ACCEPT     all  --  any    any     anywhere             anywhere             ctstate DNAT
4146  595K ACCEPT     all  --  br0    any     anywhere             anywhere         

Chain OUTPUT (policy ACCEPT 517 packets, 142K bytes)
pkts bytes target     prot opt in     out     source               destination       

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

Chain PControls (0 references)
pkts bytes target     prot opt in     out     source               destination       
    0     0 ACCEPT     all  --  any    any     anywhere             anywhere         

Chain SECURITY (0 references)
pkts bytes target     prot opt in     out     source               destination       
    0     0 RETURN     tcp  --  any    any     anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 1/sec burst 5
    0     0 DROP       tcp  --  any    any     anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN
    0     0 RETURN     tcp  --  any    any     anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/RST limit: avg 1/sec burst 5
    0     0 DROP       tcp  --  any    any     anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/RST
    0     0 RETURN     icmp --  any    any     anywhere             anywhere             icmp echo-request limit: avg 1/sec burst 5
    0     0 DROP       icmp --  any    any     anywhere             anywhere             icmp echo-request
    0     0 RETURN     all  --  any    any     anywhere             anywhere         

Chain logaccept (0 references)
pkts bytes target     prot opt in     out     source               destination       
    0     0 LOG        all  --  any    any     anywhere             anywhere             state NEW LOG level warning tcp-sequence tcp-options ip-options prefix "ACCEPT "
    0     0 ACCEPT     all  --  any    any     anywhere             anywhere         

Chain logdrop (0 references)
pkts bytes target     prot opt in     out     source               destination       
    0     0 LOG        all  --  any    any     anywhere             anywhere             state NEW LOG level warning tcp-sequence tcp-options ip-options prefix "DROP "
    0     0 DROP       all  --  any    any     anywhere             anywhere
 
Last edited:
now my IP address on my phone is 192.168.1.241 - instead of 172.16.0.XX ?

The Ebtables BROUTING rules use DROP to change the apparent interface of the frame from (br0) to (wl0.1). Then, the Ebtables FORWARD chain will actually DROP it.
Code:
Ebtables Bridge chain: BROUTING, entries: 2, policy: ACCEPT
-p IPv4 -i wl0.1 --ip-src 192.168.1.0/24 --ip-dst 172.16.0.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP

In your Ebtables FORWARD chain, you already have rules that block devices from seeing each other. If the BROUTING chain previously un-bridged the frame, it gets DROP'ed here.
Code:
Ebtables Bridge chain: FORWARD, entries: 2, policy: ACCEPT
-i wl0.1 -j DROP
-o wl0.1 -j DROP

Normally, all the frames stay bridged (br0), but when you tell Ebtables BROUTING chain to DROP, it "unbridges" the frame to (wl0.1), so now you can write rules on subsequent chains that discriminate between the packets on different interfaces (wl0.1, wl1.1, etc.). Otherwise, all the packets appears on (br0) and there's no way to know the physical interface where the packet originated. Frames entering the bridge interface (br0), must first traverse the Ebtables BROUTING chain, where DROP means to un-bridge the frame, and ACCEPT means to stay bridged.
 
The Ebtables BROUTING rules use DROP to change the apparent interface of the frame from (br0) to (wl0.1). Then, the Ebtables FORWARD chain will actually DROP it.
Code:
Ebtables Bridge chain: BROUTING, entries: 2, policy: ACCEPT
-p IPv4 -i wl0.1 --ip-src 192.168.1.0/24 --ip-dst 172.16.0.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP

In your Ebtables FORWARD chain, you already have rules that block devices from seeing each other. If the BROUTING chain previously un-bridged the frame, it gets DROP'ed here.
Code:
Ebtables Bridge chain: FORWARD, entries: 2, policy: ACCEPT
-i wl0.1 -j DROP
-o wl0.1 -j DROP
Yes, correct. I discovered that "Access Intranet = Off" is responsible for creating what is similar to the two lines: "ebtables -A FORWARD -i wl0.1 -j DROP" and "ebtables -A FORWARD -o wl0.1 -j DROP")... Thanks. So this is responsible for the "isolation". Now: But, sorry, I don't understand why I now am bypassing the dnsmasq DHCP-server setting (I wanted clients on the wl0.1-interface to have IP-address 172.16.0.XXX but now it's back to 192.168.0.XXX)... You wrote "BROUTING rules use DROP to change the apparent interface of the frame from (br0) to (wl0.1)". I have this:
Code:
wrt54g@router:/jffs/scripts# brctl show
bridge name    bridge id        STP enabled    interfaces
br0        8000.14dda9cb4040    yes        vlan1
                            eth1
                            wl0.1
So my understanding is that traffic comes in at wl0.1. And then traffic is passed through ebtables brouting, is that right? Later you wrote "Frames entering the bridge interface (br0), must first traverse the Ebtables BROUTING chain, where DROP means to un-bridge the frame, and ACCEPT means to stay bridged." - so ok, I'm thinking: Is it correct to say/believe that my traffic comes into br0 and it sees Ebtables BROUTING-chain. Drop means before the traffic sees iptables, the data is moved out of the bridge (br0) and into wl0.1, while accept means the package is on br0, when iptables rules are processed? I think this what I've understood now (but I still don't fully understand why I don't have internet connection and why my phone doesn't have IP address 172.16.0.XXX as I wanted to instruct dnsmasq DHCP-server to do)...

Normally, all the frames stay bridged (br0), but when you tell Ebtables BROUTING chain to DROP, it "unbridges" the frame to (wl0.1), so now you can write rules on subsequent chains that discriminate between the packets on different interfaces (wl0.1, wl1.1, etc.). Otherwise, all the packets appears on (br0) and there's no way to know the physical interface where the packet originated. Frames entering the bridge interface (br0), must first traverse the Ebtables BROUTING chain, where DROP means to un-bridge the frame, and ACCEPT means to stay bridged.
It's great, I think I understand more now... But what do I need to change, if I want my phone (Samsung Galaxy) to DHCP-lease IP-address 172.16.0.XXX and also be able to connect to the internet?

By the way, I read that (I think it was on open-wrt-forum) when using open-wrt or dd-wrt or similar, to accomplish what I try to do now, a forum post suggested to create a new bridge, br1. And this br1 should consist of eth1 (WAN) and wl0.1 (wireless)... And then br1 would be isolated from br0, which is the wired LAN... The approach with ebtables seems a little different? Anyway, I appreciate ideas/comments a lot, I feel I'm learning something useful here, thanks!
 
By the way, I read that (I think it was on open-wrt-forum) when using open-wrt or dd-wrt or similar, to accomplish what I try to do now, a forum post suggested to create a new bridge, br1. And this br1 should consist of eth1 (WAN) and wl0.1 (wireless)... And then br1 would be isolated from br0, which is the wired LAN... The approach with ebtables seems a little different? Anyway, I appreciate ideas/comments a lot, I feel I'm learning something useful here, thanks!
I don't think that works on Asus routers because Broadcom's hardware acceleration bypasses the CPU, for performance reasons, causing Iptables rules and some Ebtables rules to not be enforced??

I installed DD-WRT v3.0 on my RT-AC56U... Linux kernel 4.4.19... WOW!!!
Code:
Router Model      Asus RT-AC56U
Firmware Version  DD-WRT v3.0-r30534 std (09/01/16)
Kernel Version    Linux 4.4.19 #1320 SMP Wed Aug 31 15:35:47 CEST 2016 armv7l
Compiler Version  gcc version 6.1.0 (LEDE GCC 6.1.0 r1009)
CPU Model         Broadcom BCM4708
CPU Cores         2
CPU Clock         1200 MHz
RAM               256 MB
NVRAM             38 KB / 64 KB
JFFS              6,676.00 KB / 96.00 MB
Flash             64 MB
 
I don't think that works on Asus routers because Broadcom's hardware acceleration bypasses the CPU, for performance reasons, causing Iptables rules and some Ebtables rules to not be enforced??
Ok, thanks... Understood...
I installed DD-WRT v3.0 on my RT-AC56U... Linux kernel 4.4.19... WOW!!!
Code:
Router Model      Asus RT-AC56U
Firmware Version  DD-WRT v3.0-r30534 std (09/01/16)
Kernel Version    Linux 4.4.19 #1320 SMP Wed Aug 31 15:35:47 CEST 2016 armv7l
Compiler Version  gcc version 6.1.0 (LEDE GCC 6.1.0 r1009)
CPU Model         Broadcom BCM4708
CPU Cores         2
CPU Clock         1200 MHz
RAM               256 MB
NVRAM             38 KB / 64 KB
JFFS              6,676.00 KB / 96.00 MB
Flash             64 MB
I had DD-WRT on my older router, but read that Asus-Merlin firmware is best because of hardware acceleration and performance... Hmm.... Ok, so I have wl0.1 together with eth1 (WAN-side) together in a bridge "br0". Either ebtables or iptables settings must be wrong, as I cannot connect to the internet from my guest wireless interface (wl0.1)...

If I want to log all dropped packets using both iptables and ebtables, what should I change (so maybe I understand, what rule I need to change - something must be dropping HTTP-traffic to/from either wl0.1 or br0 before it reaches eth1)?
 
These commands show the packet and byte counts for matched frames or packets. Sometimes the hardware acceleration affects the counts.
Code:
/usr/sbin/ebtables -t broute -L --Lmac2 --Lc --Ln
/usr/sbin/ebtables -t filter -L --Lmac2 --Lc --Ln

/usr/sbin/iptables -t filter -L -v -n --line-numbers
/usr/sbin/iptables -t nat -L -v -n --line-numbers
/usr/sbin/iptables -t mangle -L -v -n --line-numbers
 
These commands show the packet and byte counts for matched frames or packets. Sometimes the hardware acceleration affects the counts.
Code:
/usr/sbin/ebtables -t broute -L --Lmac2 --Lc --Ln
/usr/sbin/ebtables -t filter -L --Lmac2 --Lc --Ln

/usr/sbin/iptables -t filter -L -v -n --line-numbers
/usr/sbin/iptables -t nat -L -v -n --line-numbers
/usr/sbin/iptables -t mangle -L -v -n --line-numbers
Thanks, I'll try to investigate more in the weekend to see if I can understand, why there's no http-access for my phone on wl0.1... I'm doing something wrong, but don't understand it... Thanks...
 
Hi Fitz Mutch (or anyone interested),

I've been digging into it and found some interesting things... First, it's a little strange... After reboot, I can see the "broute" is ok, but iptables does not have any "wl0.1"-rules in it despite that I have "service restart_dnsmasq" in the bottom of my /jffs/scripts/services-start... But I can manually run "service restart_dnsmasq" and I now do that, after reboot until I have a solution. My script, now looks something like this (I think this is very nice):
Code:
wrt54g@router:/jffs/scripts# cat dnsmasq.postconf
#!/bin/sh
# -------------
WRLSS_IF=wl0.1                   # Name of the wireless interface that will be used.
WRLSS_IF_NETMASK=255.255.255.0   # Netmask of the wireless network to be added.
WRLSS_IF_NTWK_ADDR=172.16.0.2    # Network address that the wireless interface will be on.
WRLSS_IF_INET_ADDR=172.16.0.1    # IP address that will be assigned to the wireless interface.
LS_START=172.16.0.100           # Start address of leases. This needs to be within the same network as above.
LS_END=172.16.0.250             # End address of leases. This needs to be within the same network as above.
DHCP_OPT1=3                      # dnsmasq option to specify router.
LS_TIME=86400s                   # Duration of the dhcp leases.

# -------------
CONFIG=$1
source /usr/sbin/helper.sh
logger "dnsmasq-dhcp: Configure $WRLSS_IF to have special DHCP"
ifconfig $WRLSS_IF $WRLSS_IF_INET_ADDR netmask $WRLSS_IF_NETMASK
IPT_RULE1="-I INPUT -i $WRLSS_IF -j ACCEPT"
if [ -n "$IPT_RULE1" ] && [ `iptables-save | grep -ice "$WRLSS_IF"` == 0 ]; then
  iptables $IPT_RULE1
fi
# ============================================
EBT_RULE1="-p IPv4 -i $WRLSS_IF -j DROP"
if [ -n "$EBT_RULE1" ] && [ `ebtables -t broute -L | grep -ice "$EBT_RULE1"` != 1 ]; then
  ebtables -t broute -I BROUTING $EBT_RULE1
fi
# ----------------
pc_append "
log-dhcp
log-queries
interface=$WRLSS_IF
dhcp-range=$WRLSS_IF,$LS_START,$LS_END,$WRLSS_IF_NETMASK,$LS_TIME
dhcp-option=$WRLSS_IF,$DHCP_OPT1,$WRLSS_IF_INET_ADDR
dhcp-option=$WRLSS_IF,6,8.8.8.8,8.8.4.4
log-async=5
" /tmp/etc/dnsmasq.conf
I'm 100% sure now, that something is wrong with my ARP-packages - and I think I need a little help, interpreting the below and fixing my script (maybe it's something with broute, I think so), please read my findings and explanation: From wireshark, I notice the below behaviour, by comparing what happens when I take my (Samsung)-phone and connect to a non-guest SSID (this works) and later to the guest SSID (this doesn't work, this is where I'm tryint to make my script work):

The non-guest SSID-capture...
1. On the working (=non-guest) SSID, first two DHCP (Discover followed by Request) packets are send: source address is 0.0.0.0 and destination is 255.255.255.255.
2. Then wireshark doesn't show source 0.0.0.0 anymore, this time it sends an ARP-broadcast package and source is SamsungE_(last 3 bytes of MAC-address), destination is "Broadcast". In the info field it says: "Who has 192.168.1.1? Tell 192.168.1.241, and the latter is from later on the assigned IP address.
3. Then the Samsung phone sends out 5-6 packages using MDNS protocol (I have no idea what it's doing).
4. Then the Samsung phone sends out a few SSDP packages (still, I don't know what this is).
5. There's also something called "Router Solicitation" using ICMPv6-protocol (I don't know what this is, probably it's normal, I guess).
6. I can browse the internet from the Samsung-phone - everything is ok, so no need to include more capture-info...

Now, compare this with the guest SSID-capture:
1. On the guest SSID, again first two DHCP (Request followed by ACK) packets are send: Source address is 0.0.0.0 and destination is again 255.255.255.255.
2. As above, after the ARP-broadcast package, source is SamsungE_(last 3 bytes of MAC-address), destination is "Broadcast". In the info field it says: "Who has 172.16.0.1? Tell 172.16.0.119, and the latter is from later on the assigned IP address.
3. As (3) above, but it only sends out 3 MDNS-packages.
4a. The ARP-messages are interesting I think: My package 31 says the Samsung phone says: "Who has 172.16.0.1? Tell 172.16.0.119" - so it's looking for the router MAC address, right (172.16.0.1)?
4b. Then in package 33, AsustekC_cb:40:41 (router, I guess, this matches below HWaddr from ifconfig) says: Who has 172.16.0.119? Tell 172.16.0.1.

wl0.1 Link encap:Ethernet HWaddr XX:XX:XX:CB:40:41
inet addr:172.16.0.1 Bcast:172.16.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:4241 errors:0 dropped:0 overruns:0 frame:203446
TX packets:2410 errors:3 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:196616 (192.0 KiB) TX bytes:195658 (191.0 KiB)


4c. In package 34, Samsung-phone sends ARP-broadcast: "Who has 172.16.0.1? Tell 172.16.0.119".
4d. In package 38, AsustekC-router sends ARP: "Who has 17216.0.119? Tell 172.16.0.1".
4e. In package 39, Samsung sends ARP: "172.16.0.119 is at ....:3f" - the MAC-address.
4f. in package 40, Samsung sends ARP: "Who has 172.16.0.1? Tell 172.16.0.119" - Samsung phone is looking for the router MAC-address, right?
4g. Then I have 2 MDNS, 1 ICMPv6 and 1 SSDP-packages, I think these can be ignored.
4h. In package 45, AsustekC-router sends ARP: "Who has 172.16.0.119? Tell 172.16.0.1"?
4i. In package 46, Samsung sends ARP: "172.16.0.119 is at ..... MAC-address" - completely as package 39 - so packages must have been lost, right?
4j. In package 52, Samsung sends ARP, completely as package 40 - so packages must have been lost, right?
4k. In package 55, 57, 63, 65, 67 and 73: All are completely as package 52 and 40, i.e: Samsung sends ARP: "Who has 172.16.0.1? Tell 172.16.0.119" - Samsung phone is looking for the router MAC-address, right? But it doesn't receive any answer (I'm guessing), right or not?
...

So - something is wrong with my ARP-packages, it's like they're not correctly being send to the router? I also need to ask you experts, when I use dnsmasq for this, is it correct that the router on the new "guest-LAN" should see my router on 172.16.0.1 which is the address for interface wl0.1 ? Or do I need to broute DROP or something (to take ARP-packages from wl0.1 to the bridge-interface) or maybe use my router address 192.168.1.1 in this config-file, somewhere? Also, please notice that I got errors from ifconfig and wl0.1, i.e. "TX packets:2410 errors:3 dropped:0 overruns:0 carrier:0" - so something is clearly wrong... I just don't know exactly what is wrong... Please help with ideas/suggestions, thanks!
 
I think the issue is with your Ebtables BROUTING chain. I think you are un-bridging all IPv4 on (wl0.1)? Then it gets dropped in Ebtales FORWARD chain? Is this your intent? I think you're missing some Ebtables BROUTING rule parameters, like the ones I suggested in a previous post. I would start over from scratch, go back to the Asus' rules for the Guest Network. Make incremental changes to the Asus' Ebtables rules and try not to think about ARP. ARP isn't going to lie to the network and get you in trouble. Once you get your phone working on the Guest Network, then go back and mess with ARP.
 
I think the issue is with your Ebtables BROUTING chain. I think you are un-bridging all IPv4 on (wl0.1)? Then it gets dropped in Ebtales FORWARD chain? Is this your intent? I think you're missing some Ebtables BROUTING rule parameters, like the ones I suggested in a previous post. I would start over from scratch, go back to the Asus' rules for the Guest Network. Make incremental changes to the Asus' Ebtables rules and try not to think about ARP. ARP isn't going to lie to the network and get you in trouble. Once you get your phone working on the Guest Network, then go back and mess with ARP.
Sorry, long post from my side now, I'll try to see if I can answer everything completely:

About "I think you are un-bridging all IPv4 on (wl0.1)?" - I'm not really sure what I'm doing, I think I've tried many combinations... Changes in ebtables, ebroute and iptables, takes effect immediately, right? I don't need to disconnect my phone from the WIFI-connection and obtain a new IP-address again (turning off WIFI and turning it back on again, on my Samsung phone), right? Changes are immediate, correct? I think they are...

You also asked "Then it gets dropped in Ebtables FORWARD chain? Is this your intent?": Answer: My ebtables FORWARD chain has almost always been completely empty, after I discovered the meaning of the two lines: "-i wl0.1 -j DROP" and "-o wl0.1 -j DROP": The packages are being dropped and I remember you gave a good explanation, so these packages are removed from the bridge (they're unbridged) and arriving on the wl0.1-interface. I'm not so concerned if they're bridged or not. No matter if I keep these two rules in my Ebtables / forward chain or not, I don't get internet access on the 172.16.... network (something with ARP-packages, I think - I wrote about my wireshark-capture the other day, it's like something is blocking the packages, I'm not sure how/why or what's happening, I'm confused) :)

You wrote: "like the ones I suggested in a previous post": Yes, you're right - these WILL give me internet access - but the phone gets an IP address in the 192.168-domain instead of 172.16-domain... But you're right - these lines DO help... About: "I would start over from scratch, go back to the Asus' rules for the Guest Network" - I think I've tried to start over from scratch some times, but I'm confusing myself now... What do you mean "Asus' rules for the Guest Network?" - it's weird, because I also followed the recipe about "How-to-have-dedicated-DHCP-options-bind-to-a-specific-SSID?" and I don't see it works on my RT-AC87U-router... Unless ofcourse I made something really really stupid... Therefore I also improved my script, to use variables (to minimize the possibility of entering wrong values, different places). About: "Once you get your phone working on the Guest Network, then go back and mess with ARP" - you're completely right, I agree... But I CAN get an 172.16- ("guest network") IP address... But then no internet connection (refer to my wirepost-writings). I don't know exactly how to change my ebtables-rules to make ARP-work correctly... A little later this week, however, I'll try some more wireshark and I also googled and maybe found a little extra (however, mostly for virtual machines, bridged network interfaces - maybe I can learn from it, I'll read more later and see if I can understand more).

It's really really strange... I mean... Whenever I do get internet connection to work (I do this, using your advice: "--ip-dst 172.16.0.0/24 --ip-proto tcp -j DROP", thanks!) the phone gets the IP address 192.168.1.XXX (/24) but I thought the whole intention behind doing the DNSmasq-stuff - as described in my original post and here: https://github.com/RMerl/asuswrt-merlin/wiki/How-to-have-dedicated-DHCP-options-bind-to-a-specific-SSID? - was to obtain another network subdomain address, e.g. 172.16.0.0/24... Whatever I do (I've tried many combinations of these lines:
Code:
Ebtables Bridge chain: BROUTING, entries: 2, policy: ACCEPT
-p IPv4 -i wl0.1 --ip-src 192.168.1.0/24 --ip-dst 172.16.0.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl0.1 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP
But it's still the same: Without these lines, my phone catches the IP-address as described by the dnsmasq-stuff (172.16....) and the internet does not work - on the other hand, I've achieved the isolation I wanted and the phone doesn't see any 192.168-devices. If I include these lines (the top line is enough, I think), then the phone gets the IP-address 192.168.... and the phone can see the other devices on the 192.168...-network. It's strange... I don't get it... I'm not currently investigating these lines:
Code:
Ebtables Bridge chain: FORWARD, entries: 2, policy: ACCEPT
-i wl0.1 -j DROP
-o wl0.1 -j DROP
(so I don't run them at the moment - I understand they're responsible for isolation but my Samsung phone is getting the wrong 192.168.... address when internet works and 172.16.... according to dnsmasq-config-file... I would really like to see if my phone can get the 172.16....-address, but then something with ARP-happens I think... Even with clean ebroute-table (both BROUTING and FORWARD is empty).

To wrap it up: I suspect I need to do something with broute and BROUTING or maybe broute / FORWARD - something with ARP, I think... hmm.... Maybe I'll give up... I'm reading a book about iptables, at the moment... Maybe after some weeks, I'll understand much better, what I need to do, to make it work... Thanks for everything so far, you've been a great help... I'm learning a lot about iptables/ebtables, at the moment...
 
What do you mean "Asus' rules for the Guest Network?"
It takes Ebtables two steps to drop a frame (or a packet, if you like) when we want to match on the physical interface (wl0.1). Because the Asuswrt Linux kernel does not enable the Physdev matching module for Iptables to make it easy. The Ebtables method is the next best alternative.

Now, here's how Asus does device isolation for the Guest Network when you choose "Access Intranet = off". It's why devices on the Guest Network cannot see each other.

EXAMPLE: Asus device isolation for 2.4 GHz Guest Network #1

STEP #1
Un-bridge the frame in Ebtables BROUTING chain. When the frame enters the bridge interface (br0), we can check to see that the physical interface is (wl0.1). If we intend to drop this frame, then we must un-bridge it immediately because this is the only opportunity we'll have to be able to see that the physical interface is (wl0.1). After this chain, the frame's apparent interface will be (br0) if we do not un-bridge the frame now. This why it's so important that you understand what's going on in this first step. It's not possible to actually drop the frame here. All we do is either un-bridge it, or allow it to stay bridged. This rule says to un-bridge the frame when the IPv4 protocol is TCP, the source interface is 2.4 GHz Guest Network #1, and the destination IP address is your local area network.
Code:
# /usr/sbin/ebtables -t broute -L
Bridge table: broute
Bridge chain: BROUTING, entries: 26, policy: ACCEPT
-p IPv4 -i wl0.1 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP

STEP #2
Drop all un-bridged frames in Ebtables FORWARD chain. When the frame stays bridged, the apparent interface is (br0), there is no rule match and the frame is not dropped. When the frame is un-bridged, the apparent interface is (wl0.1), the rule matches and the frame gets dropped here.
Code:
# /usr/sbin/ebtables -t filter -L
Bridge table: filter
Bridge chain: FORWARD, entries: 27, policy: ACCEPT
-i wl0.1 -j DROP
-o wl0.1 -j DROP


What you're looking at is really just one logical rule, programmed into the Ethernet switch in two pieces.
 
Last edited:
It takes Ebtables two steps to drop a frame (or a packet, if you like) when we want to match on the physical interface (wl0.1). Because the Asuswrt Linux kernel does not enable the Physdev matching module for Iptables to make it easy. The Ebtables method is the next best alternative.

Now, here's how Asus does device isolation for the Guest Network when you choose "Access Intranet = off". It's why devices on the Guest Network cannot see each other..................What you're looking at is really just one logical rule, programmed into the Ethernet switch in two pieces.
Hi Fitz Mutch, sorry, for the late reply, I've had a hell of a long day, just want to write to you before going to bed for a few hours... Your explanation is REALLY REALLY good, I highly appreciate it... However I think I understood most of it (well, this time, the explanation was really really good, so I understand some details)...

From earlier, you helped me understand that STEP 2 is "only" responsible for the isolation - not anything with internet or ARP... So I understood this... Nevertheless, even if I do exactly as you wrote, I don't have internet access on my Samsung phone... I think I'll also soon try to see which packet counters increase, using the "iptables -L -v -n"-view (to maybe see where something gets DROP'ed). It's a shame that until a few minutes ago, I thought ebtables was harder to debug, because I thought there were no packet counter... But then I discovered I had to use "-L --Lc", e.g:
Code:
# ebtables -t broute -L --Lc
Bridge table: broute

Bridge chain: BROUTING, entries: 1, policy: ACCEPT
-p IPv4 -i wl0.1 -j redirect  --redirect-target DROP, pcnt = 20 -- bcnt = 2576
Tomorrow I have more time... Then I want to change rules and follow the packet counters, maybe also use wireshark more, to see which rules gets hit - and what happens to these ARP-messages? Like frames are going in one direction, but not the other direction...

These things should definately increase my understanding and maybe help me solve this (wireshark + packet counters, I'll keep an extra eye for these, the next days)... I've been digging a lot - also tried to change some of my "-j DROP" into "j redirect --redirect-target DROP" - I thought maybe that would help... But still no luck... I believe/think (from my wireshark-capture) that I need to do something and if the ARP-frames work, then I think everything will work...

I mean: What I'm trying to do now, is taking one step back: I say, I'll forget about guest isolation, just for a while, until internet access is working. I need wireless clients to be able to access the internet, from the 172.16... (I'm stubborn, I suppose I could use 192.168.X.X like my other clients - on the wired LAN - but I thought the router could also handle 192.168.1.XX as well as 172.168.1.XX on wl.0.1, at the same time?).

I suppose technically speaking, I need to pass frames from either wl0.1 to eth0 (maybe they need to pass through br0, which I consider to the the LAN- or wired clients-network). When frames come back from the internet / WAN on eth0, they should end up back in wl0.1 (maybe first br0, I'm not completely sure about all this routing-stuff, need to google and read and try some things out)... Appreciate any ideas, otherwise I'm on my own... I really hope I can solve this... If I do, I'll sure to write back here...
 
Last edited:

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top