Using VLANs for a 2nd Access Point with home & guest wifi

[schmerg]

I've managed to figure out enough to be vaguely dangerous when it comes to VLANs for my personal needs, and making it work with Merlin's ASUS builds, and thought I'd post a note in case anyone's interested, or can see a better way, or suggest improvements of where I've done something stupid (ie more "show and tell" than "authoritative tutorial").

Background: Requirement

So I have an RT-N66U which does me fine for the most part, running both normal and guest wifi SSIDs, but in my new house, I also have a garden studio that the wife uses for teaching classes. The wifi doesn't reach that far, but there's power and a single CAT5 running out there already.

She wants normal wifi out there so she can print and stream in-house music etc but the kids in the classes also want wifi, and I don't want to give them access to the home network, so I want to run both normal and guest wifi out there too.

So I tried a wifi repeater, but it doesn't seem to work too well and drops out, and I dislike the idea of losing half the bandwidth. I run the "home" network on the single CAT5 for the wife into a little AP, but I'd like that AP to broadcast multiple SSIDs and then to split the traffic when it gets back into the house... sounds pretty much like VLANs.

Analysis

The cheap little AP I'm using (TP-LINK TL-WA801ND) does support multiple SSIDs, and can apply a VLAN tag to what it sends back for each SSID. So while my "home" network has no VLAN tags (at the moment) I can have a "home" SSID (with VLAN ID 2) and a "guest" SSID (with VLAN ID 5) as long as I can get the ASUS to handle DHCP etc for both and only allow VLAN 5 to access the internet, whereas VLAN 2 can access the internal network too.

The ASUS UI doesn't offer help with VLANs but there are commands available at the command line to do what I need, if only I could figure it out. This basically will involve

• vconfig to create a new VLAN
• robocfg to configure which physical ports are members of which VLAN, and for each member whether that port should be tagged or untagged with the VLAN ID
• ifconfig to bring the VLAN up
• dnsmasq config to handle DHCP for the VLANs
• iptables to limit the "guest" VLAN to access the internet only

After some experimentation, and working off other postings, I was unable to make this work... hey, I'm a software engineer, not a network engineer.

So falling back on the great software maxim of "introduce another layer" and "re-use what someone else already has working", I've come up with this

My solution

So TP-LINK also do a nice little 5-port managed switch for very cheap (TL-SG105E). I figure if I run the network cable from the studio (running VLANs to split trafffic) into one port of the managed switch, I can then configure this to effectively split the VLANs out to two separate physical ports, which will NOT be VLAN tagged.

I can then plug the "home" output into the RT-N66U, and the "guest" output either directly into my ISP VDSL modem that sits upstream from my RT-N66U, or even better, I can use existing known-to-work scripts to configure physical port 4 of the ASUS to be a "guest network" (implemented with VLANs entirely within the ASUS router).

So lifted from http://www.snbforums.com/threads/use-lan-port-4-as-private-network.14983/ I have the following script to create an internal VLAN 4 of the traffic on physical port 4

/jffs/scripts/nat-start
#!/bin/sh
# Set up VLAN4 on physical port 4
#
robocfg show | grep -i vlan14 > /dev/null 2>&1 || \
(
# 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
#brctl addif br0 vlan4
#
ifconfig vlan4 192.168.4.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 -j ACCEPT
)

And then this to tell dnsmasq to hand out 192.168.4.* addresses on that port (as opposed to my normal 192.168.1.* addresses)

/jffs/configs/dnsmasq.conf.add
#
# Add DHCP custom range for VLAN 4 being the private network on physical port 4
#
interface=vlan4
dhcp-range=vlan4,192.168.4.100,192.168.4.200,255.255.255.0,86400s
dhcp-option=vlan4,3,192.168.4.1
dhcp-option=vlan4,6,192.168.4.1,0.0.0.0

And then the managed switch, well, the setup is done via the TP-LINK GUI, but basically the port that comes in from the studio is tagged for both VLANs, and each VLAN only has one other member port being untagged and being therefore the physical out port.

Summary

I have an AP that runs two SSIDs and tags traffic from each with a VLAN tag.
I feed that AP into a managed switch which strips the VLAN tag IDs, but physically splits the VLANs out to separate LAN ports.
I then feed the "home" port from that switch into the ASUS router as per normal, and feed the "guest" port from the switch into physical port 4 of the ASUS, which is then configured to internally keep traffic on that port separate (via another VLAN) and only allow it out onto the WAN, but where dnsmasq knows how to handle DHCP requests from that "guest" network too.

If anyone can spot any issues with the above, or suggest how to do it without the managed switch hack, I'm all ears. If the ASUS implemented its guest wifi uses VLANs in the first place (rather than bridge controls) then it might be easier, but while some routers use this technique internally, the ASUS doesn't.

And if anyone has any questions, fire away...

--
Tim

 

[schmerg]

I've managed to figure out enough to be vaguely dangerous when it comes to VLANs for my personal needs, and making it work with Merlin's ASUS builds, and thought I'd post a note in case anyone's interested, or can see a better way, or suggest improvements of where I've done something stupid (ie more "show and tell" than "authoritative tutorial").

Well, for anyone following, the addition of extra switch mostly works, but causes issues when the router restarts as it currently stands.

The managed switch has 2 connections to the router, and if they're both connected when the router starts (and before the physical port 4 is remapped above) then the ASUS goes into an unresponsive loop, logging repeated messages about receiving a packet with it's own address as source address but refusing all network traffic etc seemingly indefinitely.
If I unplug one connection, it comes back, and then once the user script gets a chance to run, then everything is fine (that's when I can then view the log).

But this means that at any reboot, I have to physically intervene. I'm guessing the problem is something like when a client makes a DHCP request (broadcast UDP with source 0.0.0.0, its own MAC address in the payload) then the DHCP server UDP broadcasts a reply with itself as UDP source, quoting the same MAC address in the payload and where it also specifies details such as the IP for the client. But as this is a broadcast UDP packet, it gets sent along both connections to the switch (port 4 has not yet been isolated) and each of those packets is then broadcast back up the other connection, so the router sees the broadcast packets with its own source address. And rather than simply ignoring it, this triggers a not so useful response.

This is just a hypothesis, but I understand dnsmasq pings an address before assigning it (to check its not about to hand out an address in use) so it could be this ping that's echoing back before one of the connections is isolated.

So I tried moving the user script to run earlier than nat-start, such as running at init-start, but that seems too early as some of the network is still coming up.

In the absence of better ideas, it looks like I'll have to revert to what I tried once before - handling the VLAN tagged packets from the AP natively in the router (I can find another use for the managed switch), so any packets that are tagged with VLAN 5 get their own IP range and are only otherwise allowed access to the WAN, whereas any other VLAN tagged packets are treated as normal.

I'll post a follow up if I get any further with this, until then, any advice on how to do this will be welcome. I had a look last time at how port 8 and port 0 and vlan 2 work ... I'll just see if I can figure out the right bits and pieces of scripts to do what I need.

--
Tim

 

[schmerg]

In the absence of better ideas, it looks like I'll have to revert to what I tried once before - handling the VLAN tagged packets from the AP natively in the router (I can find another use for the managed switch), so any packets that are tagged with VLAN 5 get their own IP range and are only otherwise allowed access to the WAN, whereas any other VLAN tagged packets are treated as normal.

And it's working.. VLAN tagging wasn't quite as tricky as it seemed last time I tried (hints about what I maybe got stuck on last time around below).
So now my AP is plugged directly into the router (via a very long cable) and is running two SSIDs, one (the "home" wifi) is tagged as VLAN 1 , the default VLAN, and the other (the "guest" wifi) is tagged as VLAN 4.
On the router, VLAN1 is fine if tagged... untagged packets are assumed to be VLAN1 when read from a port so the home wifi works just fine.
But VLAN4 needs configuring to tell the router what to do ... namely
- tell the router that not only can all the physical ports carry the default VLAN1 (tagged or untagged - VLAN1 doesn't mind), but that all the physical ports are also allowed to carry VLAN 4 if tagged appropriately
- create VLAN4
- bring VLAN4 up (I put this on it's own subnet but that's not strictly needed I think)
- iptables rules to allow VLAN4 packets out on the WAN
- configure dnsmasq to handle DHCP requests on VLAN4

So the last one first, is just the user config file described above

/jffs/configs/dnsmasq.conf.add
# Add DHCP custom range for VLAN 4 being a private network
#
interface=vlan4
dhcp-range=vlan4,192.168.4.10,192.168.4.200,255.255.255.0,86400s
dhcp-option=vlan4,3,192.168.4.1
dhcp-option=vlan4,6,192.168.4.1,0.0.0.0

The rest can be done with an nat-start script

/jffs/scripts/nat-start
#!/bin/sh
#
/usr/bin/logger "================== NAT START ==================="
robocfg show | grep -i vlan4 > /dev/null 2>&1 || \
(
/usr/bin/logger "========= ROBOCFG"
# lan ports 1-4 assigned to vlan1 when untagged, port 8 is the CPU
robocfg vlan 1 ports "1 2 3 4 8t"
# or all the ports can carry vlan4 if tagged as such
robocfg vlan 4 ports "1t 2t 3t 4t 8t"

/usr/bin/logger "====== VCONFIG"
# Create VLAN4
vconfig add eth0 4 || /usr/bin/logger "VLAN 4 already exists"

/usr/bin/logger "====== IFCONFIG"
# Bring VLAN4 up (note that dnsmasq has already been configured for this address)
ifconfig vlan4 192.168.4.1 netmask 255.255.255.0 up

/usr/bin/logger "======= IPTABLES"
# And set iptables rules for VLAN4 to access the WAN only
# Seems a slight delay here is handy....
sleep 5
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 -j ACCEPT
)
/usr/bin/logger "=================== NAT DONE ==================="

The "logger" lines write messages to the system log and help when you're trying to spot stuff.

Now the only gotcha I found is that without the pause before the iptables commands, VLAN4 didn't work... DHCP requests went unanswered and static IPs didn't work either.

I think, and again I'm making wild guesses only, that while we've brought up VLAN4, it takes a while to settle/initialise, and without the sleep, then the iptables rules are ignored and so VLAN4 packets are dropped as there are no rules for what to do with them.

DHCP seemed to be an issue last time I tried, so perhaps just this "sleep" is all that was needed then.

Anyway, my AP now broadcasts 2 SSIDs, one of which has full access to the internal network, and the other of which hands out a different IP subnet and can only access the WAN, and this AP can now be connected via a cable to service far parts of property.

Hope it helps someone trying to do the same... the forums do seem to have a number of questions about VLANs but not too many success stories.

Now... wonder what else I can use this small managed switch for....

--
Tim

 

[jamestx10]

You sir are awesome. THANKS for documenting what you did. This is EXACTLY what I needed. Cut, change some IPs to match my network, Paste to the router and reboot. BAM first time success.

 

[schmerg]

You sir are awesome. THANKS for documenting what you did. This is EXACTLY what I needed. Cut, change some IPs to match my network, Paste to the router and reboot. BAM first time success.

You're very welcome - happy it was of use.

--
Tim

 

[bayern1975]

hello, @schmerg, i need to get new VLAN too....i have data and iptv signal over one cable....so, router can`t see video signal in that case....i need to add new vlan 3999 for iptv and vlan 1 for internet....do you have a solution in my case? thanks
this is my robocfg...

admin@RT-AC3200-0000:/tmp/home/root# robocfg show
Switch: enabled
Port 0: 1000FD enabled stp: none vlan: 2 jumbo: off mac: 00:30:88:19:c5:61
Port 1:  100FD enabled stp: none vlan: 1 jumbo: off mac: 00:e1:01:45:10:05
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:  100FD enabled stp: none vlan: 1 jumbo: off mac: 78:24:af:cb:18:1e
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 4 5t
   2: vlan2: 0 5
1045: vlan1045: 2 3 8u
1046: vlan1046: 0t 1t 2t 3 4t 5t 7t 8u
1047: vlan1047: 1 2t 5t
1099: vlan1099: 1t 2 3t 7 8t
1100: vlan1100: 1t 3 7t 8t
1101: vlan1101: 2t 3t 5 7
1102: vlan1102: 1 2 4 5 7 8t
1103: vlan1103: 1 5 7t 8t

 

[schmerg]

hello, @schmerg, i need to get new VLAN too....i have data and iptv signal over one cable....so, router can`t see video signal in that case....i need to add new vlan 3999 for iptv and vlan 1 for internet....do you have a solution in my case? thanks
this is my robocfg...

Sorry but iptv is one of those things I hear about in these forums but doesn't exist AFAIK here in the UK, and so I'm not really qualified to know what it is or how to work with it without breaking stuff.

Apologies, but I'm not really a networking guy, but just a software guy who was foolish enough to dabble with his own kit.

Regards

--
Tim

 

[jamestx10]

I am having some issues that I need help figuring out how to troubleshoot. After some time my VLAN4 can no longer access the internet. What I have found is that I can manually add the iptables section of the Nat-Start script via SSH and then it starts working again for a while. Is there something on the router side that would remove, change or close that connection? Can I display my iptables before I modify it again via SSH to see what is up?

 

[Jack Yaz]

Going to give this a go on my 87U, did you ever sort the sleep command being needed? My guess is that the iptables rules at the end of nat should perhaps go into firewall-start? Are you able to give it a test on your setup - I don't have the AP just yet!

 

[jamestx10]

My guess is that the iptables rules at the end of nat should perhaps go into firewall-start? Are you able to give it a test on your setup - I don't have the AP just yet!

Over all it is working as expected. My AP is tagging the guest SSD as VLAN4 and users there are getting the correct IPs as configured. My only issue is that internet access drops after some time and seems to be related to the iptable entries as I can manually run them in SSH on the router and internet access on VLAN4 starts working again. Is my FW restarting maybe and not adding those commands back since they are not in firewall-start? Any ideas on how to troubleshoot this?

 

[Jack Yaz]

Check the SysLog after it stops working and post the output

 

[jamestx10]

There is nothing in the syslog at the time of the failure. I ran the iptables commands and internet access was restored. I checked the syslog again and it shows:

May  4 10:16:58 dnsmasq-dhcp[246]: DHCPREQUEST(vlan4) 10.10.11.20
May  4 10:16:58 dnsmasq-dhcp[246]: DHCPACK(vlan4) 10.10.11.20

That is the device I am testing from. During this time running ipconfig on the client shows that it has that IP.

I will check the next time it goes down and see if there is DHCP action then as well.

 

[Jack Yaz]

Can you also post contents of

/jffs/configs/dnsmasq.conf.add

/jffs/scripts/nat-start

 

[jamestx10]

dnsmasq.conf.add

# Add DHCP custom range for VLAN 4 being a private network
#
interface=vlan4
dhcp-range=vlan4,10.10.11.10,10.10.11.250,255.255.255.0,86400s
dhcp-option=vlan4,15,NULEAFGUEST
dhcp-option=vlan4,3,10.10.11.1
dhcp-option=vlan4,6,10.10.11.1,0.0.0.0

nat-start

#!/bin/sh

/usr/bin/logger "================== NAT START ==================="
robocfg show | grep -i vlan4 > /dev/null 2>&1 || \
(
/usr/bin/logger "========= ROBOCFG"
# lan ports 1-4 assigned to vlan1 when untagged, port 8 is the CPU
robocfg vlan 1 ports "1 2 3 4 8t"
# or all the ports can carry vlan4 if tagged as such
robocfg vlan 4 ports "1t 2t 3t 4t 8t"

/usr/bin/logger "====== VCONFIG"
# Create VLAN4
vconfig add eth0 4 || /usr/bin/logger "VLAN 4 already exists"

/usr/bin/logger "====== IFCONFIG"
# Bring VLAN4 up (note that dnsmasq has already been configured for this address)
ifconfig vlan4 10.10.11.1 netmask 255.255.255.0 up

/usr/bin/logger "======= IPTABLES"
# And set iptables rules for VLAN4 to access the WAN only
# Seems a slight delay here is handy....
sleep 5
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 -j ACCEPT
)
/usr/bin/logger "=================== NAT DONE ==================="

 

[Jack Yaz]

can you run iptables -S and post that when internet connectivity stops please? Do you have any other jffs scripts in place?

 

[jamestx10]

iptables v1.3.8: Unknown arg `-S'
Try `iptables -h' or 'iptables --help' for more information.

Did not like that command.

Internet dropped again and this time I did not do anything and it started working again. Syslog shows the same DHCP action when the internet came back up. So it seems that for some reason the client is requesting a new IP and that is taking a little while to happen and there is no connection in the mean time.
dhcp-range=vlan4,10.10.11.10,10.10.11.250,255.255.255.0,86400s
Means the lease should be good for a day and the client shows the lease expiring tomorrow.

 

[Jack Yaz]

iptables v1.3.8: Unknown arg `-S'
Try `iptables -h' or 'iptables --help' for more information.

Did not like that command.

Internet dropped again and this time I did not do anything and it started working again. Syslog shows the same DHCP action when the internet came back up. So it seems that for some reason the client is requesting a new IP and that is taking a little while to happen and there is no connection in the mean time.
dhcp-range=vlan4,10.10.11.10,10.10.11.250,255.255.255.0,86400s
Means the lease should be good for a day and the client shows the lease expiring tomorrow.

Might be -L sorry, I forget which box i ssh into supports what!

 

[jamestx10]

That works. Here is the output with internet working on the guest network:

RT-N66U:/tmp/home/root# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:5228
ACCEPT     all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:1195
ACCEPT     all  --  anywhere             anywhere
DROP       icmp --  anywhere             anywhere            icmp echo-request
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
DROP       all  --  anywhere             anywhere            state INVALID
ACCEPT     all  --  anywhere             anywhere            state NEW
ACCEPT     all  --  anywhere             anywhere            state NEW
ACCEPT     udp  --  anywhere             anywhere            udp spt:bootps dpt:bootpc
ACCEPT     icmp --  anywhere             anywhere            icmp !echo-request
DROP       all  --  anywhere             anywhere

Chain FORWARD (policy DROP)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere            state NEW
DROP       all  --  anywhere             anywhere            state NEW
ACCEPT     all  --  anywhere             anywhere            state NEW
DROP       all  --  anywhere             anywhere            state NEW
DROP       all  --  anywhere             anywhere            state NEW
ACCEPT     all  --  anywhere             anywhere            state NEW
DROP       all  --  anywhere             anywhere            state NEW
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
DROP       all  --  anywhere             anywhere            state NEW
ACCEPT     all  --  anywhere             anywhere            state NEW
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
DROP       all  --  anywhere             anywhere
DROP       all  --  anywhere             anywhere            state INVALID
ACCEPT     all  --  anywhere             anywhere
NSFW       all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere            ctstate DNAT
ACCEPT     all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain FUPNP (0 references)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             JDELMUL-PC.NULEAF   tcp dpt:8096
ACCEPT     tcp  --  anywhere             JDELMUL-PC.NULEAF   tcp dpt:8920
ACCEPT     udp  --  anywhere             LivingRoom-PC.NULEAF udp dpt:57995
ACCEPT     tcp  --  anywhere             JDELMUL-PC.NULEAF   tcp dpt:22000
ACCEPT     tcp  --  anywhere             JDELMUL-PC.NULEAF   tcp dpt:22000
ACCEPT     udp  --  anywhere             JDELMUL-PC.NULEAF   udp dpt:16513
ACCEPT     tcp  --  anywhere             JDELMUL-PC.NULEAF   tcp dpt:16513

Chain NSFW (1 references)
target     prot opt source               destination

Chain PControls (0 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere

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

Chain logaccept (0 references)
target     prot opt source               destination
LOG        all  --  anywhere             anywhere            state NEW LOG level warning tcp-sequence tcp-options ip-options prefix `ACCEPT '
ACCEPT     all  --  anywhere             anywhere

Chain logdrop (0 references)
target     prot opt source               destination
LOG        all  --  anywhere             anywhere            state NEW LOG level warning tcp-sequence tcp-options ip-options prefix `DROP '
DROP       all  --  anywhere             anywhere
RT-N66U:/tmp/home/root#

 

[jamestx10]

The DHCP request seems to be the key now. Same thing happened again. Client lost internet for a while and when it came back the syslog shows the DHCP request.

May  4 10:16:58 dnsmasq-dhcp[246]: DHCPREQUEST(vlan4) 10.10.11.20
May  4 10:16:58 dnsmasq-dhcp[246]: DHCPACK(vlan4) 10.10.11.20
May  4 11:16:55 dnsmasq-dhcp[246]: DHCPREQUEST(vlan4) 10.10.11.20
May  4 11:16:55 dnsmasq-dhcp[246]: DHCPACK(vlan4) 10.10.11.20
May  4 11:38:32 dnsmasq-dhcp[246]: DHCPREQUEST(vlan4) 10.10.11.20
May  4 11:38:32 dnsmasq-dhcp[246]: DHCPACK(vlan4) 10.10.11.20
May  4 11:56:25 dnsmasq-dhcp[246]: DHCPREQUEST(vlan4) 10.10.11.20 
May  4 11:56:25 dnsmasq-dhcp[246]: DHCPACK(vlan4) 10.10.11.20

 

[schmerg]

The DHCP request seems to be the key now. Same thing happened again. Client lost internet for a while and when it came back the syslog shows the DHCP request.

May  4 10:16:58 dnsmasq-dhcp[246]: DHCPREQUEST(vlan4) 10.10.11.20
May  4 10:16:58 dnsmasq-dhcp[246]: DHCPACK(vlan4) 10.10.11.20
May  4 11:16:55 dnsmasq-dhcp[246]: DHCPREQUEST(vlan4) 10.10.11.20
May  4 11:16:55 dnsmasq-dhcp[246]: DHCPACK(vlan4) 10.10.11.20
May  4 11:38:32 dnsmasq-dhcp[246]: DHCPREQUEST(vlan4) 10.10.11.20
May  4 11:38:32 dnsmasq-dhcp[246]: DHCPACK(vlan4) 10.10.11.20
May  4 11:56:25 dnsmasq-dhcp[246]: DHCPREQUEST(vlan4) 10.10.11.20
May  4 11:56:25 dnsmasq-dhcp[246]: DHCPACK(vlan4) 10.10.11.20

Ah - I see you guys are looking at this, but clients who join my guest wifi only join for a short time (an hour or two) and then leave for a week or so.
So it could maybe be something so dumb as my original setup not allowing for clients asking to refresh their DHCP (as opposed to starting a new session altogether).

If I get a chance on the weekend I'll have a look, but again iptables etc is something I cargo-cult rather than regularly use - my apologies for any "schoolboy" style errors in my original notes.

Cheers

--
Tim