SonicWALL-on-a-Stick

| Saturday, September 10th, 2011 | 19 Comments »

SonicWALL on a Stick, SonicWALL-on-a-Stick

SonicWALL’s never tasted so good!

I touched up on this subject in my last blog titled, “Solutions to your SonicPoint WLAN Woes!”

What I want to do here is go over what is traditionally known as “Router-on-a-Stick” or “ROAS”. In this case, “SonicWALL-on-a-Stick” or “SOAS”.

The concept behind “ROAS” is that instead of taking a router and assigning multiple ports to it belonging to different network segments, you consolidate by utilizing 802.1Q trunking on a port which will then carry all VLAN’s over that port. This greatly increases scalability, just imagine if you had ten different network segments, do you have ten available physical ports you would want to dedicate to each network? It would not scale very well!

In the above scenario, each switch is dedicated to a port. It may not seem so bad now, but you can see how fast the ports can run out if you need more network segments. It just isn’t scalable!

Here is your classic “router-on-a-stick”. What you’re doing now is utilizing 802.1Q trunking to carry the VLAN’s to your switch. The key contributing factors are:

  1. Your firewall or router needs to support 802.1Q
  2. Your switch needs to support 802.1Q

At this point, you can now individually assign specific ports to each network! For example:

  • Network 192.168.1.0/24 can be assigned ports 1-5.
  • Network 192.168.2.0/24 can be assigned ports 6-10.
  • Network 192.168.3.0/24 can be assigned ports 11-15.

Not only have you cleaned up additional messy wires and cabling, but you are also reducing power consumption by using less switches!

Below I show you how you can setup your SonicWALL TZ 210 running SonicOS 5.8 to utilize trunking off the LAN(Xo) port and creating VLAN’s. You’re going to be creating sub-interfaces!

Go to Network–>Interfaces and create your VLAN’s. It’s very important that your VLAN Tag ID’s are consistent with the same ID’s that will be created on your switch.

BrandonTek SonicWALL create VLAN

Now you will see on the main interfaces page, that the sub interfaces have been created!

BrandonTek Sonicwall Show VLAN

The main piece of configuring your SonicWALL with sub interfaces is now complete! The next section covers configuring a Cisco switch to support trunking and assigning specific ports to those VLAN’s. Please refer to your vendor equipment for the proper way to configure your own switch.

BrandonTek SonicWALL create trunk

Create a trunk port on port 24

BrandonTek SonicWALL assign ports to VLAN

Assigning ports to VLAN

With Cisco, if the VLAN doesn’t already exist, it will create it as you can see from the error above. This saves me the extra step of having to create the VLAN ahead of time.

Now that we have our trunk port and ports assigned to proper VLAN’s, we now verify connectivity by plugging a PC into each VLAN and pinging each other!

BrandonTek SonicWALL PC pings Gateway

PC1(VLAN1) pings gateway

PC1 being on VLAN1 is able to successfully ping its own gateway. This should work whether we have trunking/sub-interfaces or not, and it’s verified working.

BrandonTek SonicWALL PC1 pings gateway 2 and 3

PC1 on VLAN1 pings gateway for VLAN 2 and VLAN3

We now ping the default gateways for VLAN 2 and VLAN 3 from PC1. As you can see, we have connectivity! This shows that the trunk is working as expected.

BrandonTek SonicWALL pc1 pings pc2

PC1 on VLAN1 now pings across to PC2 on VLAN2

Here we can confirm that you have reach ability beyond just the default gateway, but to actually reach out across the VLAN’s and access another PC on VLAN2. We ping PC2(VLAN2) from PC1 on VLAN1.

BrandonTek SonicWALL PC3 pings PC2

PC3 on VLAN3 pings PC2 on VLAN2

Just so that PC3 on VLAN3 doesn’t feel left out. Here we show that PC3 has connectivity to its own default gateway, it can ping itself(which I always like to test for localhost TCP/IP verification) and it can ping PC2 on VLAN2.

That’s about it! I hope you can now think about how a SonicWALL-on-a-Stick can help simplify your network setup!

Share

Tags: , , , , , , , , , , , , ,
Posted in Labs, Networking, Sonicwall

  • Pingback: Internets of Interest:14 Sep 2011 — My Etherealmind

  • Jad Callahan

    Don’t forget the command “switchport mode access” on all of the access ports.  This command is critical because it prevents the port from trying to dynamically trunk to another device.

    See additional discussion here: https://learningnetwork.cisco.com/message/97604

    James McKinzie’s post is a great summary of the discussion, “the reason to use the access command is to make sure someone does not plug anothor switch into that port and get access to the network. If you do not use switchport mode access then if someone plugs in a switch into that port then it will become a trunking port. For security of the network it is best pratice to use the switchport mode access to prevent it from going into trunking mode.For a shortcut in that area try “switchport host”, it will add a few more extra items that will make it more secure to prevent another switch from being plugged into it.”

  • http://twitter.com/brandontek Brandon Kim

    Thanks Jad,

    Although I left out these commands since it wasn’t a “security” related blog, you are correct and that is best practice that should be followed. From a Cisco POV that would work, and as I mentioned, if you’re not using a Cisco switch, you will have to look at your own vendor for locking down your switch.

    “Switchport host” is a great command…..

  • Joseph Voldeck

    Do you have a tutorial on how to trunk for two ethernet cables to create a LAG for bandwidth to the switch?

    Thanks in advance.

  • Anonymous

    Hi Joseph,

    If I read your question correctly. It sounds like you are looking to do etherchannel. If you check out my HSRP/Etherchannel article, you’ll see how to create one. It’s basically creating a port interface and then applying your physical ports to it.

    http://www.brandontek.com/cisco/hsrpetherchannel-and-trunks/

    If you’re looking to aggregate two ports into a SonicWALL, I don’t think the SonicWALL’s support that. The higher end E-Class models may support port aggregation. I’d have to look into that though.

  • Anonymous

    Hello,

    I have been trying to configure a setup almost identical to this tutorial creating a trunk interface on Cisco switch to x0 on Sonicwall TZ 210.  Have not been able to get the trunk working at all. As soon as the port is set to trunk all Internet connectivity is lost but local LAN traffic still works.  I have IP addresses assigned to each switch vlan SVI and use that as the respective default gateway for hosts in each vlan (ex vlan 2 IP 172.16.2.1 255.255.255.0, host 172.16.2.70 uses 172.16.2.1 as default gateway). It doesn’t look like based on the steps in the tutorial that IPs were set on the switch SVIs.  Just wondering if that is not a requirement and the hosts use the sonicwall as default gateway?

    Any help would be greatly appreciated,

    Pete

  • http://twitter.com/brandontek Brandon Kim

     Hi Pete,

    Sorry for the delay as I’ve had a pretty hectic schedule as of late. Did you ever get to resolve this issue? I don’t know how exactly your Cisco is configured so it would be a little challenge to guide you in the right direction.

    However, eventhough you’re Cisco switch is L3 capable, it is not necessary to use. You can use the FW as the gateway for all your VLAN’s. So in your post regarding host 172.16.2.70, it “could” use 172.16.2.1 on the Sonicwall as a sub-interface instead of that being an SVI on your Cisco!!

  • Anonymous

    Hi Brandon,

    I was able to resolve this issue with some help from Sonicwall support.  The solution was to change the trunk interface on my switch to a L3 routed interface on a separate subnet from other vlans on the switch.  L3 interface and Sonicwall are both in the same subnet.  On the Sonicwall we removed the vlan sub-interfaces and created network address objects for each subnet and a host address object for the switch IP. Also we had to create a group address object and add all the network address objects to the group. Then a route policy was needed with the destination set to the group address object and the gateway set to the switch L3 IP.  Esentially had to tell the Sonicwall about the subnets on the LAN and how to get there.  I preferred to keep using the switch for inter-vlan routing so that LAN traffic would not have to go out to Sonicwall and then back to the switch.

    Thanks for the response,

    Pete

  • http://twitter.com/brandontek Brandon Kim

     Thanks for the update Pete and glad it worked out for you. What you just did does work, “obviously”. So basically you created a point to point between the firewall and switch.

    It is true my method would have turned the firewall into basically a core router/switch. So depending on your traffic, it may be good to keep them all within your switch.

    Good job and please let me know if I can assist in any other issues you may come across!

  • Dave Rasmussen

    Pete, 
    I’m trying to do the same thing. This is what I basically came up with on my own and it works for routing just fine. I’m also needing the sonicwall to do dhcp for each of the subnets for the vLans. Did you do this and if so how did you accomplish it?

    Thanks,
    Dave

  • petedachelet

    Hi Dave,
    I didn’t use the sonicwall for dhcp, we have dhcp setup on a domain controller on one of the vlans.  What I needed to do which is most likely what you’ll need to do as well is add an ip-helper address on each vlan to point to the IP address of the dhcp server in your case the IP of your sonicwall.  

    Here is what it looks like on my switch for one vlan:

    interface Vlan6
     ip address 172.16.6.1 255.255.255.0
     ip helper-address 172.16.2.2   <— Pointing to Remote DHCP Server

    You'll need to add the ip helper for each interface/ subnet that requires the dhcp service.  The reason for this is that dhcp uses broadcast packets which do not travel outside the subnet.

    Hope this helps,
    Pete

  • Dave Rasmussen

    Pete, thank you for your quick response. I have tried to find a way to do this on my cisco sge2010 switch but I have not found an option in the Web GUI to do this and I’m not aware of a way to do  CLI commands on this switch. Am I missing something?

  • Dave Rasmussen

    Pete, one other difference in my configuration is I have a main lan configured on X0, my vlans come in on a trunk I have connected to X5; with all of my vlans defined as sub-interfaces off of X5. My main Lan and all vLans need to communicate with each other, and I need the sonicwall to provide DHCP for the vlans. In your opinion, is this the best approach, using the ROAS on X5 as in your example? Thanks again  

  • petedachelet

    Dave,

    I don’t have any experience with the sge2010 switches but I was able to find some info on a lightweight cli mode that might be available to you. I wonder if the ip-helper command would be available in that mode? Check out this link:

    http://homecommunity.cisco.com/t5/Switches/SRW-series-super-secret-CLI-mode/mp/109959

    Is there a dhcp relay option in the web gui?

    Pete

  • petedachelet

    Hi Dave,

    I don’t have any experience with the sge2010 switches but found a link that shows a way to get into a lightweight CLI mode.  Not sure if the IP helper command will be available but check out this link:

    http://homecommunity.cisco.com/t5/Switches/SRW-series-super-secret-CLI-mode/m-p/109959

    Is there a DHCP relay option in the web GUI?

    Pete

  • petedachelet

    I used a Layer 3 interface to connect my switch to the Sonicwall instead of using ROAS method. Are you attempting to use the ROAS method?  The reason I didn’t go with ROAS is that I wanted to keep my local LAN traffic on the switch and not have to go back and forth between Sonicwall and switch unless it is Internet traffic.

  • petedachelet

    Just another thought…I think there is a setting for ip helper in the Sonicwall config GUI. You may need to point your ip helper for x5 interface to x0 or something along those lines to provide dhcp to your vlans.

  • http://www.facebook.com/Selfaware Avram Berman

    I have a tz 205 and I’m trying to connect my new web server which has two nic connections which are teamed on 2008r2.
    I was planning on creating, e.g., vlan2 (on my netgear switch) which would consist of 3 ports: 46 for my upload to dmz configured port on sonicwall and 47 and 48 which are lagged for my two nic connections coming from my web server – is this correct?  I never knew you could create sub interfaces.

  • http://twitter.com/brandontek Brandon Kim

    Hi Avram,

    You can build sub-interfaces but you will have to see if your model will support that. It is a combination of model and firmware. So make sure you are on the latest SonicOS 5.8+ firwmware and then see if you can create sub-interfaces.

    In terms of NIC teaming, that would be between your server and Netgear switch so those functions would be transparent to the SonicWALL.

    Just make sure that if you are creating VLANs on the switch, that the SonicWALL is aware of those VLANs as well if you are connecting any physical ports from the SonicWALL to the Netgear switch using those VLANs.