I want to restrict a wired Ethernet printer to my VLAN. I have tried to follow “Assigning a VLAN to a LAN Port.” Modification of the port defaults (with either Trunk or “Access” type, that latter term not being explained anywhere I can find,) to any value other than “Any” causes the WAN to fail a connectivity test, either DHCP or Ping, and the WAN is indeed down until and unless the ports are returned to defaults.
I stumbled on an 11/16 post “Assigning VLAN to LAN port causes loss of internet connection” by ekalter. My f/w version is the same as is the difficulty he reported. It appears a ticket was created but the thread dead-ended. ekalter reported that v7 beta worked.
System>firmware is offering f/w v7.0.2 but the release notes show it unsupported by h/w rev 1 which is what I have, albeit this unit is new, just out of the box from Amazon. I don’t want to brick a brand new router.
Trunk - some device downstream is doing the packet tagging
Access - the packets are tagged on their way in
IF you have another “smart switch” down the line OR the device connected is capable of VLan tagging - then you want to use the Trunk setting and include all possible VLans that could be coming in that port.
More common in the home environment is that there is no other device tagging packets, so you would want to use access (which limits the port to a single VLan only).
I hope this helps and gets you going. Chances are that you set it up to be a trunk for all of your VLans, but there is nothing “down the line” that is tagging the packets. Since the packets don’t have the “tags” on them that the router is expecting – the packets get dropped (which has the same impact as the WAN being down). The WAN is most likely fine, just your connection to the router is broken.
Thanks! That explains why “access” is the appropriate selection, since the printer cannot handle tagging. I tried that first, and expected the printer to receive the VLAN IP via DHCP and process untagged packets.
A laptop used to represent the wired printer for testing connects wirelessly to the AP bound to that VLAN and receives the VLAN IP via DHCP. Disabling the laptop’s WiFi and attempting to use a wired connection, without changing anything else, there is no DHCP. I expected the “access” port and wireless connections to perform similarly.
Neither does it explain why the entire WAN goes down, including the connectivity to all devices served wirelessly until the defaults are restored to all ports.
how many VLans do you have? What are they used for? How are they connected to the Balance router?
Are you sure that the WAN link is disconnecting? Or are you just not able to get to the internet? They are two different things that appear the same to the client.
If you are using a wifi access point to do VLan tagging - they will require a trunk with the appropriate VLans allowed/configured.
Access port - everything coming in will be on the defined VLan and pull DHCP from the respective DHCP pool.
Trunk port - everything coming in is already “tagged” (or untagged). Tagged packets go to the respective VLan, untagged packets go to the “Untagged” VLan.
Its a Surf SOHO router with 6.3.3 build 1068 f/w. I created two VLANS in the Network>Network Settings dialog with inter-VLAN routing disabled and two individual APs. One is intended for wireless IoT devices and the other for wireless guests, the purpose being to isolate either from our WiFi client PCs on the trunk/untagged LAN. The issues (no wired VLAN DHCP and no WAN,) arose when I tried to assign a wired port to the first VLAN and applied to both after I created the second. It persists even if that VLAN is wired only.
The Ethernet WAN port is connected to a LAN port on an AT&T provided Pace/Arris 5031NV residential Gateway, not one of the more infamous ones, but one with ports on its own LAN that shouldn’t be open. The RG’s WiFi is disabled. When the WAN comes up, it provides the SOHO with one of its private IPs in 192.168.1.xxx, although when the new SOHO is fully working, it will be placed in DMZ+ and receive the public IP with the expectation that the SOHO can protect itself from probes and exploits from outside and any potentially corrupted IoT client. It appears it will work that way, but only wirelessly and if only if any wired device is on trunk/any.
When and while any single access port is configured, the WAN fails DNS test or ping, whichever is configured as its health check method and there is no connectivity between the WAN and any of the SOHO’s three APs, the LAN or either VLAN. The defined access port delivers no DHCP and thus no connection; if I unplug from the access port and plug to any of the remaining trunk/any ports, the SOHO delivers an IP in the 192.168.50.xxx range but no WAN connectivity, until and unless the access port is returned to the trunk/any default.
My next step, probably not tomorrow because of other time commitments, will be to try TCPDUMP:DHCP to examine what, if anything, is happening to DHCP requests on that access port, not that I will necessarily be able to do anything about that, nor will it necessarily diagnose the WAN issue.
I’m forever a networking newbie, having troubleshot DHCP problems before, but that was long ago. Thanks for your help.
My problem was resolved by f/w 7.0.2 after browsing other threads lead me to realize I was unlikely to “brick” my new router by upgrading. I’m new to the Pepwave line, so I didn’t recognize that the “unsupported models” reference in the Release Notes refers to an earlier Surf SOLO than the MK3, probably the discontinued MK2. The VLAN configuration now works exactly as I originally expected.
THANK YOU SO MUCH for your assistance! In one of those other threads about VLANs and IoT security, a user suggested that Peplink publish additional user documentation or application note summarizing them. Some of those posts were yours; they taught me a lot and confirmed even more. Thank you again.