| VLAN routing help needed (USG50) This seems like something that I'm just missing.
Basically I have this:
USG50
NWA3560-N
NWA3560-N plugged directly into the USG50 (lan1)
lan1: 192.168.66.1 / DHCP Works great
NWA3560-N has an SSID which uses lan1 - works great.
I'm trying to setup a secondary SSID which will use a VLAN and so far I seem to have it working except that it does route beyond the VLAN router.
The VLAN (vlan:33) is setup as:
192.168.33.1 w/DHCP and it resolves DNS appropriately (shows 192.168.33.1 as the DNS and names are resolved correctly), and shows the gateway as 192.168.33.1. I can't seem to get out to the internet. If I use traceroute to say my ISP's gateway I can see it hit 192.168.33.1 and then it just stops.
I have Google'd, searched this forum, and searched Zyxel trying to figure this out (also RTFM) and I'm just not seeing why the USG50 doesn't just route out automatically from 192.168.33.1. There are no firewall rules blocking it.
This seems like it should be dead-easy to do but I'm missing something crucial in getting this to work.
Can someone fill me in on what I'm missing? |
|
| Port based vlan or 802.1Q tagged vlan? |
|
| Its port based (lan1). I assumed that it was doing the 802.1Q magic under the covers. |
|
 AnavSarcastic Llama? Naw, Just AcerbicPremium
join:2001-07-16
Dartmouth, NS
kudos:3 | what managed switch are you using?
I am under the impression that the router can not assign vlan tags but can read them and route them appropriately according to the VLAN rules you have setup. You need a managed switch to either conduct port based vlan ( a simple matrix of rules) or vlan tagging more time consuming but more flexible control). |
|
1 edit | I've plugged the NWA3560-N directly into the router.
The VLAN itself seems to work appropriately. I can connect, via WiFi to my SSID which is associated to the VLAN and then I'll be assigned a DHCP address from the VLAN settings in the router.
I can even access the router at the VLAN's address that I gave it of 192.168.33.1.
The problem is that the router isn't routing from the VLAN out to the internet and I'm not seeing any clear way to say, "Oh, this needs to be turned on/off"
There is a 'gateway' (optional) setting for the VLAN but it's only to be used if the router can figure out how to route the traffic. It really should be able to do it by default (shouldn't be any different than lan1 or lan2 or even dmz, for that matter). It just doesn't seem to be clicking.
I have tried to put in:
192.168.66.1 (the gateway for my regular network, which currently can be seen from 192.168.33.*)
I've also tried to put in the gateway for one of my ISPs.
In both cases it doesn't help.
It looks to me like this is the 'gateway' setting that you'd use if you were doing the VLAN across the WAN or had some other kind of configuration. All I'm trying to do is to setup multiple SSIDs on the WAP and allow each of them to connect to a VLAN and get out to the internet.
The VLAN itself does seem to be functioning properly it's just the routing out through the WAN that's giving me issues. |
|
| reply to Brad Bishop
The physical port you have connected to the AP got port based VLAN 33. Now any other port that you want to talk to, also need to be a member of VLAN 33. So unless the WAN port also is a member of VLAN 33, then the traffic will not go out on that port.
--
"Perl is executable line noise, Python is executable pseudo-code."
|
|
| BTW - the help is greatly appreciated.
@dslpartner - what you're saying does sort of make sense except:
I need to have the VLAN associated with lan1 and you can only associate the VLAN with one port.
To clarify: This VLAN is to remain entirely on my LAN. All I need is to get it to allow 192.168.33.1 to act as a router and route traffic to the WAN (not saying you're disputing this - half thinking out loud and half just making sure).
So it seems like you ought to be able to, somehow, tell the router: For VLAN33, this is your gateway: 192.168.33.1 and route the traffic to the WAN.
I'm not seeing anything that says: For the Trunk, also allow it to be used on the VLAN.
Nor am I seeing anything on the VLAN Interface that says: Use the WAN (Trunk).
It seems to me that if I put the VLAN on the wan1 or wan2 port then the VLAN is on the other side of my router and it kills it being used on my LAN. |
|
|
|
| reply to Brad Bishop
I do not have a USG, so what options you have to configure it, I do not know.
But I am getting confused here, you only want it to be on your lan and you want it to access the internet?
192.168.33.1 is your USG VLAN 33 LAN IP right? So you are able to communicate with your USG from theVLAN. Now since traffic belongs to VLAN33 it will stay in VLAN 33, unless you have router instance that allows you to route between vlans.
Your WAN port probably got PVID that is set to 1, if you change that to 33 only VLAN 33 will reach the internet. So you need the WAN port to a member of both VLAN 33 and VLAN 1.
If you both want VLAN 1 and VLAN 33 to access the internet this is a solution, they will still not be able to talk to each other, since you are using RFC1918 IP's and the traffic from VLAN 33 must hit your upstream GW before it gets routed back to you. And then you will only be able to access the other VLAN if you allow it in your firewall (NAT) settings like any other traffic from the WAN.
As mentioned I do not have an USG and this is based on general terms, not USG specific. Also 802.1Q is much better than Port based, just do untag on the ports.
--
"Perl is executable line noise, Python is executable pseudo-code."
|
|
| I was a bit confused before:
From this page:
»www.zyxel.com/support/knowledge_···92.shtml
I see that this isn't port-based although when you set it up it says 'choose a port' - but you're really choosing a virtual port. The USG is adding/removing the tags as needed.
To get a better idea of what I'm going for:
Imagine you have a restaurant. You want to have a private/office LAN/SSID and a public LAN/SSID for your patrons. You want to just use the same WAP to do this. They both need to be able to get out to the internet.
A VLAN seems perfect in this situation in that I can piggy-back the public LAN across the same bit of wire/WAP as the private LAN.
I don't need the VLAN to stretch beyond the USG. It just needs to communicate with the outside world. |
|
| If you want to use the same AP, but with different ESSID, then you need the AP to also support 802.1Q VLAN AND you have to use 802.1Q with tags. IMHO.
--
"Perl is executable line noise, Python is executable pseudo-code."
|
|
| Yes - I believe that is what is happening.
The AP happily handles the regular LAN and the VLAN and communicates with the USG correctly.
It's just this last piece of trying to get the VLAN on the USG to correctly handle the WAN trunk that I'm having a problem with.
From everything I've read it ought to 'just work'. You brought up an interesting point with having the WAN on the same VLAN but the VLAN should be able to say, "Ok, I use the WAN to get to the outside world." It doesn't seem like it should be any different than setting up a normal (non VLAN) network. |
|
1 edit | said by Brad Bishop:From everything I've read it ought to 'just work'. You brought up an interesting point with having the WAN on the same VLAN but the VLAN should be able to say, "Ok, I use the WAN to get to the outside world." It doesn't seem like it should be any different than setting up a normal (non VLAN) network.
But it is, VLANs are used to make virtual lans in your lan. Ie we need explicitly tell the devices what where and when where they can send traffic and not. In general if a port is not a member of a vlan, then it will not get traffic from that vlan.
So if you make a vlan, you usually include all the ports that needs to be part of it. Ie you include port 9 and 10 in vlan 1337 then devices that are members of vlan 1337 will talk to each regardless if they are connected to port 9 or 10. Now even if a device claims its a member and connected to port 13 and port 13 is not a member it will not be able to talk to devices connected to port 9 and 10.
Same thing happens with WAN port,it is not a member of the vlan ie traffic will never be forwarded to the WAN port.
Now you can make router instances that will route across vlans, but that usually means you need to a virtual router per vlan. I do not know if the USG supports this or if it does this automagically.
But have you tried calling ZyXEL support?
I got the same setup running in my office,
--
"Perl is executable line noise, Python is executable pseudo-code."
|
|
| reply to Brad Bishop
Sorry that I had to read this thread in haste, and also that I don't have time right now to delve into my USG50 for the particular settings I use for the first VLAN I've set up. Also, in my firewall this VLAN is prohibited from Internet connectivity, so an inverse rule would be needed for deliberate connectivity. In any case, I didn't see any reference above to three points.
First, the smart or semi-smart switch that you have to use to establish the correspondence between ports and VLANs should allow other VLANs (like no. 1, say) to have access to a given VLAN. This is an optional setting but can simplify the pathway for workstations to communicate with printers on another VLAN.
Second, the connection between the switch and the router has to be configured as a trunk (accepts both VLAN tagged and untagged messages).
Third, even if the router is configured to allow VLAN stuff out to the Internet, when a message comes back and the state table changes the IP address back to 192.168.33.7, say, the USG has to know that the way to that VLAN is through the switch at whatever IP address the switch trunk connection is on, say 192.168.1.2. I forget right now where that routing is set, which is why I'll have to delve into it later. If the router doesn't know, it will send the packet to the Great Bit Bucket in the Sky, and it will appear that there is no Internet connectivity.
This third point is addressed in some detail in a Cisco switch forum reply of a few months ago.
kirby |
|
AnavSarcastic Llama? Naw, Just AcerbicPremium
join:2001-07-16
Dartmouth, NS
kudos:3 | reply to JPedroT
The only time a router should get involved in VLAN traffic is to when vlan traffic is routed to or from the internet. (or when VLANs span multiple switches connected to the router (and in this case some traffic will pass thru the router).
THe purpose of vlans is to maximize intravlan traffic (fast and secure). If you can manage this vlan traffic all behind one switch all the better. The router needs to ensure internet traffic gets routed back to the correct device and thus needs to be able to a. recognize/read vlan traffic b. execute admin assigned rules to that vlan traffic. The router does not have the ability to tag data with vlan tags.
THe router will not be able to apply rules to traffic based on port based vlans as assigned by the switch other than identifying traffic as having come from that port should go back to that port (in the case of internet traffic) .
The big mystery for me in the above setup is which unit is assigning the vlan tags?? Be advised this is my simpletion view of how these things work. I cannot with any certainty say this is fact....... Hopefully some more astute actual IT pros can comment (im always learning).
--
Ain't nuthin but the blues! "Albert Collins".
Leave your troubles at the door! "Pepe Peregil" De Sevilla. Just Don't Wifi without WPA, "Yul Brenner"
LlamaWorks Equipment |
|
| said by Anav:The only time a router should get involved in VLAN traffic is to when vlan traffic is routed to or from the internet. (or when VLANs span multiple switches connected to the router (and in this case some traffic will pass thru the router).
A bit narrow, but sure, the thing is VLAN is VLAN wether its deployed in your LAN or in the metro net. So routers often get into the mix, depending on your design. said by Anav:THe purpose of vlans is to maximize intravlan traffic (fast and secure). If you can manage this vlan traffic all behind one switch all the better. The router needs to ensure internet traffic gets routed back to the correct device and thus needs to be able to a. recognize/read vlan traffic b. execute admin assigned rules to that vlan traffic. The router does not have the ability to tag data with vlan tags.
THe router will not be able to apply rules to traffic based on port based vlans as assigned by the switch other than identifying traffic as having come from that port should go back to that port (in the case of internet traffic) .
Not quite, one switch and have one vlan is like putting a porche engine in vw beetle, yes its fun, but overkill. Routers have abilities to tag and untag it just depends on your router, my little Prestige 2812 can do it and I use the feature. said by Anav:The big mystery for me in the above setup is which unit is assigning the vlan tags?? Be advised this is my simpletion view of how these things work. I cannot with any certainty say this is fact....... Hopefully some more astute actual IT pros can comment (im always learning).
You tag on the edge of your network, so in your home setup,traffic from the internet is tagged by you router when it egresses into your LAN. Then your switch untags the frames when the frames egress the switch down to your PC. For traffic from your PC the switch tags on ingress and the WAN router untags it on the to your ISPs internet gateway. All devices in between must be vlan tag aware to have use of the feature and they can remove or add depending on your policy/rules. A setup I work with, the frames are actually tagged from the ISP and each Router WAN port is a member of 3 VLANs. 1. IPTV bridge node 2. Internet date node 3. Management node 1. Arrives tagged and is untagged on switch port 1-3 which is connected to IPTV STBs. 2. Arrives tagged and is untagged on switch port 1 and WLAN, which is connected to PC's that connects to the Internet. 3. Arrives tagged and is just for access to the UI of the router. There are multiude of possibilities, now add double tags, mac in mac and other fun stuff and we can build a decent metro network. --
"Perl is executable line noise, Python is executable pseudo-code."
|
|
| reply to Anav
I really think that this is an issue inside the router and I'm just missing the bit on how to tell VLAN's gateway (192.168.33.1 as defined in the router) to use the WAN trunk.
Given this:
Imagine you have a restaurant. You want to have a private/office LAN/SSID and a public LAN/SSID for your patrons. You want to just use the same WAP to do this. They both need to be able to get out to the internet.
I have:
- USG 50
- NWA3560-N
- various unmanaged switches - no managed switches are involved here save for the fact that the NWA3560 acts as a managed switch.
The USG 50 has:
- wan (wan1 & wan2)
- lan1 (interface: 192.168.66.1 w/ DHCP)
- lan2
- dmz
- vlan33 (piggybacks on lan1) (interface: 192.168.33.1 w/ DHCP; Zone: LAN1)
vlan33 being in Zone LAN1 should allow it all the privileges of LAN1 (which is shown to work correctly under lan1).
the 4 physical LAN ports on the front of the USG are assigned/connected to:
- lan1 (vlan33) - connected to various unmanaged switches
- lan1 (vlan33) - connected to the NWA3560-N
- lan1 (vlan33) - empty
- lan2 (ignore) - empty
The NWA3560-N is 'VLAN aware'. Let's say I've assigned it these two SSIDs:
- ABC123 - default - part of lan1. It happily connects and assigns 192.168.66.* IPs from the DHCP
- DEF456 - VLAN33 - The AP knows that this SSID is part of VLAN33 and assigns the ethernet tags appropriately. If you connect to DEF456 you will get a DHCP assigned address of 192.168.33.* which is correct. This tells me that, essentially, I have a working VLAN.
So at this point I have:
- lan1 (192.168.66.1) which will allow wired or wireless connections and functions correctly. It also routes traffic as you would expect through the wan
- vlan33 (192.168.33.1) which will allow you to connect wirelessly (no wired as there are no managed switches - it's all handled in the NWA3560-N). You can connect, get a correctly assigned IP (192.168.33.*) and you can actually hit other things on the network (192.168.66.1) which doesn't really matter at this point. I can setup rules/zones to stop that later.
192.168.33.1 is setup in the USG under the VLAN Interfaces. It gets assigned as the gateway from the DHCP server on the VLAN. If you were to connect to 192.168.33.1 you get the normal USG (either by http or by something like ssh). It's the gateway.
I think some are getting hung up on the ports / vlan / tagging and missing the part I need: I don't see how to tell the VLAN's gateway (192.168.33.1) to use the WAN (trunk).
(not a criticism, just trying to clarify, keep on track)
So, it's been brought up that I need to tell the WAN that it needs to be accessed by VLAN33 but shouldn't this be a function of the gateway, anyway? In my head the VLAN should be self-contained and the gateway (192.168.33.1) should be the bit that bridges one LAN with another. The gateway should say: "Ok, I'm here at 192.168.33.1 and I know there's this wan trunk I'm supposed to send traffic to." It doesn't seem like the VLAN should be extended beyond that.
Now, that being said, there's obviously a bit missing and I am new to this - just trying to reason it out in my head.
I've tried playing with the ZONEs to see if there's something there. No luck.
I've tried to understand the Virtual Interfaces (maybe this is the key) but I don't get them, yet. Basically you can highlight vlan33 (or lan1 for that matter) and 'Create Virtual Interface' and then you can give it: an IP, Netmask, and (optional) gateway. - I don't see the point. It's like you can create a virtual IP on your network with no real point (I'm sure there's a point but it's not obvious to me, yet). |
|
| reply to Brad Bishop
To all:
I REALLY appreciate the input with this. Thank you.
When I do figure it out (from another thread I think Kirby may actually be able to tell me once he reads through it) I'll post here as I can't be the only one thinking of using VLANs in this way. To me this should be the simplest case for a VLAN (good test case in my mind). |
|
AnavSarcastic Llama? Naw, Just AcerbicPremium
join:2001-07-16
Dartmouth, NS
kudos:3 | reply to JPedroT
THanks dslpartner, narrow of course as is my experience.
I do not think the USG series is capable of tagging or untagging but simply recogning vlan tagging and thus routing them appropriately as per admin setup. That is alsow why I am assuming a switch needs to be in the mix. Of course I would assume multiple Vlans could be on a switch which is the true power of vlan tagging (users or devices can overlap into diff vlans) over the more one dimension of port based vlan. Again, assuming that I may be accurate in my thinking but not necessarily
--
Ain't nuthin but the blues! "Albert Collins".
Leave your troubles at the door! "Pepe Peregil" De Sevilla. Just Don't Wifi without WPA, "Yul Brenner"
LlamaWorks Equipment |
|
| From the manual the USG adds/removes the tags as needed and (supposedly) routes traffic as needed.
I'm starting to wonder if it's just a bug I've found. I'm hoping it's just some setting I've missed.
From the manual:
"• VLAN interfaces recognize tagged frames. The ZyWALL automatically adds or removes the tags as needed. Each VLAN can only be associated with one Ethernet interface."
"VLAN Interfaces Overview
In the ZyWALL, each VLAN is called a VLAN interface. As a router, the ZyWALL routes traffic between VLAN interfaces, but it does not route traffic within a VLAN interface. All traffic for each VLAN interface can go through only one Ethernet interface, though each Ethernet interface can have one or more VLAN interfaces.
Note: Each VLAN interface is created on top of only one Ethernet interface.
Otherwise, VLAN interfaces are similar to other interfaces in many ways. They have an IP address, subnet mask, and gateway used to make routing decisions. They restrict bandwidth and packet size. They can provide DHCP services, and they can verify the gateway is available." |
|
| reply to Brad Bishop
I don't think of the USG50 as creating VLANs; the VLAN menu presented to the browser allows the admin to make the router aware of VLANs created in the connected smart switch. The router can perform DHCP for the VLANs that are listed, or the IP addresses of connections to VLANs can be established elsewhere.
I am certain that the "gateway" fill-in block in the USG50 VLAN menu should have the IP address of the switch that is connected to the USG50 that is establishing the VLANs. (I am reasonably sure that if two smart switches were connected, one to LAN1 and the other to LAN2, then the gateway address for each VLAN would be the IP address of the relevant switch that created that VLAN. I have no way to test this.)
At least in the case of my USG50 router and Cisco SG200-26 switch, the router communicates to the switch by routing all allowed incoming WAN traffic to 192.168.1.2, the DHCP established LAN1 IP address for the switch. The switch recognizes the router gateway as 192.168.1.1 (default for LAN1) for all outgoing trunk traffic to the router. Traffic passing between VLANs is routed to the router and then back to the switch. Broadcast traffic does not get out of the switch.
All traffic from router to switch is tagged or not by the router as applicable and routed to 192.168.1.2. The switch then puts the VLAN30 tagged messages into "contact" with the appropriate port designated to be part of VLAN30 (and strips the tags). Untagged messages are assumed to be destined for VLAN1 and the switch sends them to the appropriate ports designated to be within VLAN1.
Note that the router cannot route to a hoped-for VLAN that is conceived to be established on two switches at the same level, one switch VLAN-aware and one not. There can be only one gateway that the router associates with a given VLAN. With some study, one may see that this allows an enormous tree of switches fanning out from the router where the computers and printers are the leaves on the branches, each unaware of the architecture, and unaware of devices on other VLANs. Nonetheless, communication across VLANs can occur at the router if the firewall allows.
kirby |
|
