What's new

Use LAN port 4 as private network

  • 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!

I would appreciate any feedback on how to troubleshoot this "somewhat working" setup...

I suggest you do not use single digit VLANs, instead use say 10,20,30,40,50 (60 is reserved on my RT-AC68U???) etc. or even 100,200 etc.

Also, can you try the following rules
Code:
ACTION="-I"
$INTERFACE="vlan10"  # Change to your VLAN

iptables $ACTION INPUT -i $INTERFACE -m state --state NEW -j DROP                  # Protect Router Block EVERYTHING!
iptables $ACTION INPUT -i $INTERFACE -p tcp --dport 53 -j ACCEPT                   # Allow VLAN to access DNSSEC?
iptables $ACTION INPUT -i $INTERFACE -p udp -m multiport --dport 53,67 -j ACCEPT   # Allow VLAN to access DNS,DHCP

taken from my script.

NOTE: Since I use multiple VLANs (20,30,40,50 & 200), I leave port 4 'tagged' in VLAN1, and also have port 4 tagged in the custom VLANxx.

Code:
admin@RT-AC68U:/jffs/scripts# robocfg show

Switch: enabled
Port 0:  100FD enabled stp: none vlan: 2 jumbo: off mac: XX:XX:XX:XX:XX:XX
Port 1:   DOWN enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
Port 2:   DOWN enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
Port 3:   DOWN enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
Port 4: 1000FD enabled stp: none vlan: 1 jumbo: off mac: XX:XX:XX:XX:XX:XX
Port 8:   DOWN enabled stp: none vlan: 2 jumbo: off mac: 00:00:00:00:00:00
VLANs: BCM5301x enabled mac_check mac_hash
   1: vlan1: 1 2 3 4t 5t
   2: vlan2: 0 5
  20: vlan20: 4t 5t
  30: vlan30: 4t 5t
  40: vlan40: 4t 5t
  50: vlan50: 4t 5t
<snip>   # Here is the weird VLAN60 that appears along with the other rogue 5x,6x VLANs
  60: vlan60: 0t 2 7t 8t
<snip>
 200: vlan200: 4t 5t

Code:
admin@RT-AC68U:/jffs/scripts# ./VLANSwitch.sh 30 status verbose

 vlan30 Robocfg Status
 =====================
   1: vlan1: 1 2 3 4t 5t
  30: vlan30: 4t 5t

 vlan30 Bridge Status
 ====================
br2  8000.xxxxxxxxxxxx no  wl0.1
                           vlan30

 vlan30 Status
 =============
vlan30    Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX
          inet addr:10.88.30.1  Bcast:10.88.30.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:28991 errors:0 dropped:0 overruns:0 frame:0
          TX packets:30177 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:23092210 (22.0 MiB)  TX bytes:2161594 (2.0 MiB)

 vlan30 Statistics
 =================
vlan30  VID: 30  REORDER_HDR: 1  dev->priv_flags: 8001
         total frames received        28991
          total bytes received     23092210
      Broadcast/Multicast Rcvd            0
      total frames transmitted        30177
       total bytes transmitted      2161594
            total headroom inc         1984
           total encap on xmit        30177
Device: eth0
INGRESS priority mappings: 0:0  1:0  2:0  3:0  4:0  5:0  6:0 7:0
 EGRESS priority mappings:

 br2 ACTIVE devices (ARP only accurate within 60secs?)
 =====================================================
10.88.102.14 xx:xx:xx:xx:xx:xx Hive-Hub (myHivehub.Martineau.lan)


admin@RT-AC68U:/jffs/scripts# ./VLANSwitch.sh 40 status verbose

 vlan40 Robocfg Status
 =====================
   1: vlan1: 1 2 3 4t 5t
  40: vlan40: 4t 5t

 vlan40 Bridge Status
 ====================

 vlan40 Status
 =============
vlan40    Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX
          inet addr:10.88.40.1  Bcast:10.88.40.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:210842 errors:0 dropped:0 overruns:0 frame:0
          TX packets:89068 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:58013081 (55.3 MiB)  TX bytes:20473537 (19.5 MiB)

 vlan40 Statistics
 =================
vlan40  VID: 40  REORDER_HDR: 1  dev->priv_flags: 1
         total frames received       210842
          total bytes received     58013081
      Broadcast/Multicast Rcvd        65103
      total frames transmitted        89068
       total bytes transmitted     20473537
            total headroom inc            0
           total encap on xmit        89068
Device: eth0
INGRESS priority mappings: 0:0  1:0  2:0  310.88.40.15 xx:xx:xx:xx:xx:xx Samsung-TV (?):0  4:0  5:0  6:0 7:0
 EGRESS priority mappings:

 vlan40 ACTIVE devices (ARP only accurate within 60secs?)
 ========================================================
10.88.40.10 xx:xx:xx:xx:xx:xx SKYHD-Bedroom (?)
10.88.40.15 xx:xx:xx:xx:xx:xx Samsung-TV (?)
10.88.40.17 xx:xx:xx:xx:xx:xx SKYHD-Lounge (?)
 
Last edited:
Thx for the suggestions, but as it turned out the DNS and dnsmasq were working fine. Well, somewhat: I could load some sites and not others. I tracked it down to the packet fragmentation issue. I am on DSL with MTU=1492 and I never had to deal with MTU on my LAN because everything just worked with all defaults, but in this particular case the clients (Ubuntu 16.04 and PS4) connected to vlan4 port needed MTU set to 1492 (down from the default 1500).
Once I applied the MTU change all issues went away immediately. It would be nice to understand why that was the case, but it is all working now.
 
@Martineau do you mind sharing the your VLANSwitch.sh script? It is helpful to have the ability to list devices in each vlan.
 
...it turned out the DNS and dnsmasq were working fine..

Thanks for the update.

I must admit that I'm paranoid when it comes to explicitly allowing everything from a VLAN to the router:
Code:
iptables -I INPUT -i vlan4 -j ACCEPT

This defeats the attempt to securely isolate the VLAN for say IoT stuff, hence my explicit INPUT rules to ensure that a device on the VLAN can't use SSH or attempt to open the GUI via port 80/8443 to the router.
 
Last edited:
@Martineau That was the next thing I was gonna look at: to make sure the devices on vlan cannot talk to the router. I already have this line below in my script and I still can ssh the router. Do you mind sharing your setup script?

iptables -I INPUT -i vlan4 -j ACCEPT
 
@Martineau That was the next thing I was gonna look at: to make sure the devices on vlan cannot talk to the router. I already have this line below in my script and I still can ssh the router.

iptables -I INPUT -i vlan4 -j ACCEPT

As I said, replace the potentially VERY risky rule above with the three INPUT rules I posted in #41
 
Last edited:
@Martineau do you mind sharing the your VLANSwitch.sh script? It is helpful to have the ability to list devices in each vlan.

The code exceeds the forum posting size limit, so when I have time to perform a code-cleanup (for public ridicule) I'll post the link.

Code:
#!/bin/sh
#===============================================================================Router-on-a-stick v01.01
#
# Use Router switch LAN Port X as VLAN Trunk for VLAN vlanXXX to downstream switch on separate subnet using '/etc/dnsmasq.conf'
#
#
# Usage:    VLANSwitch  [[vlan_id] [switch_port] ] | ['help'|'-h'] ['del'] ['status' ['verbose']] ['vpn'[n]] ['vlanfw'] ['nodnsmasq'] ['autodnsmasq']
#
#           VLANSwitch
#                       Switch port 4 will have vlan200 tagged to it (default)
#           VLANSwitch  del
#                       Switch port 4 will have vlan200 removed
#           VLANSwitch  10 2
#                       Switch port 2 will have vlan10 tagged to it
#           VLANSwitch  status
#                       Show the connected VLAN devices (or Bridge if VLAN is enslaved to one)
#           VLANSwitch  status verbose
#                       Show the vlan configuration and statistics etc.
#           VLANSwitch  20 vpn1
#                       Switch port 4 will have vlan20 tagged to it and will be forced via the VPN Client 1 (on bridge br1)
#           VLANSwitch  20 vpn1 vlanfw
#                       Switch port 4 will have vlan20 tagged to it and will be forced via the VPN Client 1 (on bridge br1)
#                       Firewall rules will explicitly use vlan20 rather than vlan+
#           VLANSwitch  199 nodnsmasq
#                       Switch port 4 will have vlan199 tagged to it, and vlan99 does not need to exist in dnsmasq
#           VLANSwitch  199 autodnsmasq
#                       Switch port 4 will have vlan199 tagged to it, and /jffs/configs/dnsmasq.conf.add will be modified
#                       NOTE: dnsmasq will be bounced.
#
# VLAN convention requires dnsmasq directives for the VLAN subnet to be added for DHCP.
# NOTE: We use 3rd octet when 'autodnsmasq' specified so VLAN range restricted between 3-255 inclusive (excluding 60!!!)
#
# e.g. For VLAN 'vlan200' we define both DHCP and DNS
#
# VLAN=vlan200 uses DHCP pool 10.88.200.2 - 10.88.200.20 and Opendns/Google
#         interface=vlan200
#         dhcp-range=vlan200,10.88.200.2,10.88.200.20,255.255.255.0,86400s
#         dhcp-option=vlan200,3,10.88.200.1
#         dhcp-option=vlan200,6,208.67.220.220,8.8.8.8
 
As I said, replace the potentially VERY risky rule above with the three INPUT rules I posted in #41

Right, my apologies for missing that. I actually went ahead with static IPs and disabled port 67/DHCP on vlan4. Thank you for the suggestions.

Speaking of security, why not use external DNS and then all access to the router can be blocked?
 
Right, my apologies for missing that. I actually went ahead with static IPs and disabled port 67/DHCP on vlan4. Thank you for the suggestions.

Speaking of security, why not use external DNS and then all access to the router can be blocked?

Because they can still explicitly try 192.168.1.1 !!!!!!

NOTE: P.S. You are correct, using an external DNS, router.asus.com will resolve to a non-local address
 
Because they can still explicitly try 192.168.1.1 !!!!!!

NOTE: P.S. You are correct, using an external DNS, router.asus.com will resolve to a non-local address

That is what I was hoping for: I would only keep the first rule out of your three rules above on this page and configure static IP clients to use OpenDNS servers. I will try that later. If that works, the router is protected.
 
That is what I was hoping for: I would only keep the first rule out of your three rules above on this page and configure static IP clients to use OpenDNS servers. I will try that later. If that works, the router is protected.

Errm, still confused by your reply. o_O

DNS by itself will not protect the router. Security by obfuscation never works!

e.g. see my post #47. VLAN200 is configured to use external DNS 208.67.220.220,8.8.8.8, but without my
Code:
iptables $ACTION INPUT -i $INTERFACE -m state --state NEW -j DROP

rule, the router is still exposed.
 
Errm, still confused by your reply. o_O

DNS by itself will not protect the router. Security by obfuscation never works!

e.g. see my post #47. VLAN200 is configured to use external DNS 208.67.220.220,8.8.8.8, but without my
Code:
iptables $ACTION INPUT -i $INTERFACE -m state --state NEW -j DROP

rule, the router is still exposed.

Here is what my nat-start script looks like now:
Code:
# lan ports 1-3 assigned to vlan1
robocfg vlan 1 ports "1 2 3 8t"
# port 4 to vlan4
robocfg vlan 4 ports "4 8t"
#
vconfig add eth0 4
#
ifconfig vlan4 192.168.85.1 netmask 255.255.255.0 up
#
iptables -I FORWARD -i vlan4 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i vlan4 -o br0 -m state --state NEW -j DROP
iptables -I FORWARD -i br0 -o vlan4 -m state --state NEW -j DROP
iptables -I INPUT -i vlan4 -m state --state NEW -j DROP                  # Protect Router Block EVERYTHING!

I think that covers everything and router.asus.com is resolved to an external IP and I am not exposing the dnsmasq running on the router.
And if I use static IPs and external DNS servers then I do not need /jffs/configs/dnsmasq.conf.add file mentioned in the instructions in the very first post. For the benefit of DSL users I had to set MTU=1492 on the vlan4 clients.

Now I wonder if there is a way to prevent vlan4 devices from talking to each other...
 
Hi, I followed the instruction in the first post verbatim and everything worked the first time except DNS. The client computer cannot finish loading pages or just says that the name cannot be resolved. I am obviously missing something here. Can anyone suggest what I should look into to make DNS work on vlan4 devices?
I just double-checked the files in jffs:
/jffs/scripts/nat-start
&
/jffs/configs/dnsmasq.conf.add
And indeed, I made no changes from the OP to get it working. After multiple initial reboots it hit WAN and now has survived additional boots and has been up since November of last year. I wish I had an answer with some real data behind it, because I wasn't very comfortable just rebooting until it worked, but that's all I've got - except...

Are you sure you made the dnsmasq.conf.add executable as in the OP:
Code:
chmod a+rx /jffs/scripts/*
 
If I set up new vlan on port 4, as described in first post, will Port Forwarding work to the new vlan if a specified a ip address on that lan? Can i use the web interface to config it as usual?

Using RT-N66U Asus-Merlin Firmware:380.65_2
 
If I set up new vlan on port 4, as described in first post, will Port Forwarding work to the new vlan if a specified a ip address on that lan? Can i use the web interface to config it as usual?

Using RT-N66U Asus-Merlin Firmware:380.65_2

The vlan IPs are pingable from the router, so it should work.
 
Hi guys, thanks to this thread I got my RT-AC87U with Asuswrt-Merlin 380.68.4 sharing a multiple vlan link on LAN4 with a Netgear managed switch GS105E. Here's the config I used, with an example VLAN 100.

/jffs/scripts/firewall-start

Code:
#!/bin/sh
robocfg vlan 100 ports "1t 8t"
vconfig add eth0 100
ifconfig vlan100 192.168.100.1 netmask 255.255.255.0 up
iptables -I FORWARD -i vlan100 -m state --state NEW -j ACCEPT
iptables -I FORWARD -i vlan100 -o br0 -m state --state NEW -j DROP
iptables -I FORWARD -i br0 -o vlan100 -m state --state NEW -j DROP
iptables -I INPUT -i vlan100 -m state --state NEW -j DROP

It's all working great apart from one thing: devices on vlan 100 can still access the router's SMB shares (while correctly they can't telnet or http to it).

Code:
admin@router:/jffs/scripts# netstat | grep 192
tcp        0      0 router.:445             192.168.100.2:59960     ESTABLISHED
admin@router:/jffs/scripts#

192.168.100.2 is an Ubuntu machine on vlan100 accessing SMB through Nautilus.

Anyone knows why that is? I thought the INPUT rule would have dropped it.

I've also tried adding a specific rule dropping SMB's ports from vlan 100 both on the INPUT and the FORWARD chains and still it can be accessed. It seems the router is accepting SMB no matter what.

The router SMb configuration is guest login off, SMB2 on, WINS server off.
 
Thx for the suggestions, but as it turned out the DNS and dnsmasq were working fine. Well, somewhat: I could load some sites and not others. I tracked it down to the packet fragmentation issue. I am on DSL with MTU=1492 and I never had to deal with MTU on my LAN because everything just worked with all defaults, but in this particular case the clients (Ubuntu 16.04 and PS4) connected to vlan4 port needed MTU set to 1492 (down from the default 1500).
Once I applied the MTU change all issues went away immediately. It would be nice to understand why that was the case, but it is all working now.

Hi Fantom - I just set this up on an Asus RT-AC68U - running Merlin 380.68_4. I had the same MTU issue you did. I was able to ping, but couldn't load web pages, or they loaded very slowly.

I'm on Comcast, with a WAN MTU of 1500. I was able to test the threshold for MTU that was getting through by using this command:
ping www.google.com -f -l 1472
If I pinged with a larger size, (1473 or bigger) I would get an error back saying "Packet needs to be fragmented but DF set". So it appears that for some reason 28 bytes are getting added to the packets as they traverse the VLAN.

One guess I have is that the VLAN tag header is being applied upon ingress to the bridge, but not being removed correctly or something. No idea yet. I can make a machine work on that guest VLAN if I lower the MTU, but I'm not happy with that - still trying to figure out if a change in the config will work around this MTU issue.

I tried disabling NAT acceleration under LAN / Switch Control - which changes the CPU port from 8t to 5t, but it still doesn't fix the MTU issue.

Anyone else have an ideas how to make this work without changing the Windows / Mac default MTU values on the guest VLAN on an AC68U?
 
Last edited:
I'm on Comcast, with a WAN MTU of 1500. I was able to test the threshold for MTU that was getting through by using this command:
ping www.google.com -f -l 1472
If I pinged with a larger size, (1473 or bigger) I would get an error back saying "Packet needs to be fragmented but DF set". So it appears that for some reason 28 bytes are getting added to the packets as they traverse the VLAN.
That indicates that the MTU is 1500 because there is a 28 byte overhead that needs to be added to 1472.
 
That indicates that the MTU is 1500 because there is a 28 byte overhead that needs to be added to 1472.
Ah, interesting, thanks for that link. I just tried the same ping on my production network, and got the same threshold. I guess this throws the MTU theory for why pings work but websites load slowly or don't load at all out the window.

However, I power cycled the router - and it works fine now when loading from the nat-start script upon boot up instead of being manually fed in. So this only seems to happen when manually feeding in the robocfg and iptables. So case closed for now, but something is odd -- not sure why a power cycle is required.
 
There was a previous post about how to reach a Synology box from the guest VLAN. The tip didn't work. I was thinking more of a shared printer scenario - where people / devices on the guest VLAN (in my case 20) need to reach a shared printer / scanner (for example at 192.168.1.121) that is on the internal secure VLAN1, but this could also work for a Synology box or something else. Here is the addition to the iptables rules that worked for me:

Code:
# allows anyone on vlan20 to reach 192.168.1.121
iptables -I FORWARD -i vlan20 -o br0 -d 192.168.1.121 -j ACCEPT

# allows anyone on br0 to reach anyone on the guest VLAN if initiated from the home/secure LAN side - not necessary, but might be useful if initiating a scan from the scan button on the scanner
iptables -I FORWARD -i br0 -o vlan20 -d 192.168.85.0/24 -j ACCEPT
 

Similar threads

Sign Up For SNBForums Daily Digest

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