Recommended Posts

I'm new to the whole managed switches thing, so I am completely lost right now. I have two buildings that are right next to each other, they are connected by fiber. The fiber terminates into unmanaged switches on both ends. This keeps the workstations/servers in both buildings connected to each other. Internet comes into one building, and we use an NSA 240 as our router/firewall. We have one SonicPoint connected directly to the NSA to provide wireless, there are two SSIDs (corporate and guest) broadcasting from the SonicPoint. Now we need to put two SonicPoints in the other building. I purchased two Dell PowerConnect 5524 switches thinking that we could use VLANs to connect the two new SonicPoints to the NSA. The SonicPoints need to be directly connected to a port on the NSA, I am thinking I could use VLAN's to trick the SonicPoints into thinking they are directly connected to the NSA. I figured I'd put one 5524 into each building, plug the fiber into each to connect the building, and then set up VLANs for workstation traffic and SonicPoint traffic. Problem is, I have no idea where to start. I've looked over the documentation multiple times, but I'm confused about access vs general vs trunk and native VLANs and PVIDs and everything else. Can someone please point me in the right direction? Thanks!

The sonicpoints need to be connected to the wlan port (which could by any port!), at this point if you want to allow wlan traffic to the lan, you have to bridge the two ports, and have ALL of your sonicpoints connected to a switch which connects to the wlan. You cannot and will not be able to use ANY sonicpoint on the LAN segment. A firmware update I believe will make the sonicpoints in the future become regular APs and be use on the LAN segment, but until then you have to use them on the wlan segment.

Not sure why you think you needed to introduce vlans for?

from the sonicpoint deployment guide

Layer 2 and Layer 3 considerations for SonicPoints

SonicWALL uses two proprietary protocols (SDP and SSPP) and both *cannot* be routed across any layer 3 device. Any SonicPoint that will be deployed must have an Ethernet connection back to the provisioning SonicWALL UTM appliance, in the same broadcast domain/network.

SonicWALL UTM appliance must have interface or sub-interface in same VLAN/broadcast domain as SonicPoint.

SonicPoints must be able to reach the DHCP scope on the SonicWALL; make sure other DHCP servers are not present on VLAN/broadcast domain.

Sharing SSIDs across SonicPoints attached to multiple interfaces may case connectivity issues as wireless client roams to different SonicPoint subnet.

From how you have described your network, your devices are all on the same broadcast domain. You should be able to plug your new sonicpoints into any port on the switch(es) in the other building without issue.

You do not need to use vlans from what I can see.

The sonicpoints need to be connected to the wlan port (which could by any port!), at this point if you want to allow wlan traffic to the lan, you have to bridge the two ports, and have ALL of your sonicpoints connected to a switch which connects to the wlan. You cannot and will not be able to use ANY sonicpoint on the LAN segment. A firmware update I believe will make the sonicpoints in the future become regular APs and be use on the LAN segment, but until then you have to use them on the wlan segment.

Currently the one SonicPoint is connected to the WLAN port, and we've bridged it to the LAN port so people on the corporate SSID can access servers/etc. But now I need to connect two more SonicPoints in the building across the street. Because I cannot physically plug the two SonicPoints into the back of the NSA, I need to find a way fool them into thinking they are.

Not sure why you think you needed to introduce vlans for?

from the sonicpoint deployment guide

Layer 2 and Layer 3 considerations for SonicPoints

SonicWALL uses two proprietary protocols (SDP and SSPP) and both *cannot* be routed across any layer 3 device. Any SonicPoint that will be deployed must have an Ethernet connection back to the provisioning SonicWALL UTM appliance, in the same broadcast domain/network.

SonicWALL UTM appliance must have interface or sub-interface in same VLAN/broadcast domain as SonicPoint.

SonicPoints must be able to reach the DHCP scope on the SonicWALL; make sure other DHCP servers are not present on VLAN/broadcast domain.

Sharing SSIDs across SonicPoints attached to multiple interfaces may case connectivity issues as wireless client roams to different SonicPoint subnet.

From how you have described your network, your devices are all on the same broadcast domain. You should be able to plug your new sonicpoints into any port on the switch(es) in the other building without issue.

You do not need to use vlans from what I can see.

I think this isn't working for us because we've bridged the wireless and lan ports on the NSA unit.

If you have bridged the wlan to lan, then you can plug into any lan port. If you connect to other dumb switches, you could connect to any of them. Your on one big dumb broadcast domain. So you can plug in anything anywhere and get anywhere that is plugged into any other port on any of the switches, etc.

So again I am no seeing where you need to setup vlans, or what this is going to do - since you don't have any setup now.

No where in the guide does it say you have to be directly connected to anything, nor does setting up a vlan accomplish that even if did.

I am looking at the picture of the nsa 240 -- where is this WLAN port you talk about? Says it can support up to 16 sonicpoints - it clearly does not have 16 ports ;) So not sure what you are talking about with a WLAN port

post-14624-0-65038600-1343825172.png

The individual ports are "programmable", so you can define a port as WAN, LAN, WLAN, etc. In our case, port X6 is the WLAN port, it's bridged to X0 (the LAN port). Port X6 also has a VLAN so we can have two SSIDs running off one SonicPoint.

Capture.jpg

Just wanted to come back and let everyone know that I got this to work. I had to set up the same VLAN's on the switches that were created in the Sonicwall, and then trunk the switch to the Sonicwall. Created access ports for the SonicPoints and was good to go. Thanks for the help everyone!

  • 1 year later...

I'm trying to configure pretty much the same setup. Can you give me more information on how you connected the Sonicwall to your network switches?  Di you plug X0 and X2 into the same switch?  If so, how were they provisioned?  Did you set them up as an aggregate/trunk?

 

If I plug a SonicPoint into X2 it works just the way I want. I'm not sure how to "extend" that XO port to my switches?  I have tried a few ways but each time I lose DHCP on the Geast WLAN.

 

Thanks

  • 2 months later...

I'm trying to configure pretty much the same setup. Can you give me more information on how you connected the Sonicwall to your network switches?  Di you plug X0 and X2 into the same switch?  If so, how were they provisioned?  Did you set them up as an aggregate/trunk?

 

If I plug a SonicPoint into X2 it works just the way I want. I'm not sure how to "extend" that XO port to my switches?  I have tried a few ways but each time I lose DHCP on the Geast WLAN.

 

Thanks

Hello, 

 

I recently completed a 25 Sonicpoint deployment for a school.  My recommendation for a secure and stable installation.  You should get a POE switch or switches to provide power and data to your access points.  Not sure how many access points you are delpoying, but get a POE switch to handle the  number of access points.  We used Cisco Small Business gigabit POE managed switch, which works great.

 

I strongly recommed using VLANs on the Sonicwall and the POE switch.  If you create VLANs you setup will be easy and manageble.  As an example we created 3 VLANs and created those sub-interfaces  (50, 60, and 70) on the WLAN (X4).  50 was for Corp users, 60 for guest users, and 70 is for another function, but readily available.    On your POE switch(s) create VLANs as well.  Be sure to assign each port that will host a Sonic access point to VLANs 50 and 60 respectively.

 

I hope this helps.

This topic is now closed to further replies.
  • Posts

    • Very fitting name since AI users have air where there brains should be.
    • Yes, it was amusing at the time because even then dbrand was well known for stealing the designs of products from other companies. That’s what they do.
    • Didn’t Dbrand once complain that Casetify was ripping off their designs a well? seems pretty bad of them to try and get around Valve’s copyright this way with that in mind.
    • Dbrand thought they could get away with this Steam Machine case, Valve disagreed by David Uzondu Image via Dbrand Dbrand has cancelled its highly anticipated Companion Cube enclosure for the Valve Steam Machine, which it teased back in November of last year with a concept render and sign-up page, because it did not ask Valve for permission first before manufacturing the case. According to Dbrand, it took the "backwards approach" of building the product first before asking for permission from the copyright holder. Seven months of work went into the project, requiring over a thousand engineering hours from the design team. Workers developed forty-four sets of injection molding tools, making a unique mold for each sub-component of the crate. When the Companion Cube went live on Monday last week, it, according to Dbrand, quickly became the second-fastest-selling product in the company's fifteen-year history, racking up orders for hundreds of thousands of units. Customers eagerly bought the $129.95 deluxe edition or the bare-bones $99.95 version, which the manufacturer cheekily branded as the "Poverty Cube". It was around this time that the legal eagles at Valve descended on the accessory maker with a formal demand. The developer pointed out that the iconic block design remains protected intellectual property from the game Portal, so unlicensed sales had to stop. Dbrand said that all its pleas to salvage the project with the Valve team, including proposals to run a properly licensed release under official terms "with their blessing", fell on deaf ears, so it had no choice but to obey and remove every trace of the product from the internet. If you bought the enclosure, the company said that banks will process your refund by the end of this week, but if it still hasn't arrived in your account by then, you should not hesitate to contact support. The Steam Machine itself is a high-performance console that Valve designed directly to bring PC gaming into the living room. It was announced on 12th November 2025 (the same day Dbrand announced the Cube) and runs on the Linux-based SteamOS, the same OS that powers the Steam Deck. As for the price, due to the shortage of memory and storage chips, the hardware cost landed much higher than people were expecting, starting at $1,049 for the 512 model (without a controller) or $1,128 with the new gamepad. The premium 2 TB model pushes those prices even higher, selling at $1,349 for the standalone console and hitting $1,428 if you want the bundle.
  • Recent Achievements

    • Rookie
      Almohandis went up a rank
      Rookie
    • Apprentice
      jahara21 went up a rank
      Apprentice
    • Reacting Well
      NovaEdgeX earned a badge
      Reacting Well
    • Week One Done
      NovaEdgeX earned a badge
      Week One Done
    • One Year In
      BA the Curmudgeon earned a badge
      One Year In
  • Popular Contributors

    1. 1
      +primortal
      532
    2. 2
      +Edouard
      266
    3. 3
      PsYcHoKiLLa
      148
    4. 4
      Steven P.
      97
    5. 5
      macoman
      57
  • Tell a friend

    Love Neowin? Tell a friend!