Network Design Questions

[grochowskir]

Hello All,

I am in the process of replacing some of our current Cisco equipment with newer one as well as incorporating additional third party hardware by Sonicwall NSA 5500. I am attaching the preliminary network diagram.

-The SonicWalls are in Active/Standby mode

-The Core 1 switch is the primary HSRP gateway as well as the primary STP root for all Vlans.

-Core switches perform all of the inter-vlan routing

-The uplinks FROM the Core switches TOWARDS the WAN-ACCESS-STACK will be Port-Channels in trunk modes, carrying traffic for VLAN2 (infrastructure Vlan between Cores, Wan-Access-Switches and Sonicwalls), VLAN 254 (Management Vlan which is the same throughout the entire networks), and the Native VLAN 999. 

I have a few questions and would appreciate your input on them:

-I would like to carry the management VLAN all the way to the DMZ-ACCESS-STACK, and ultimately to the  the small DMZ-PUB switches (located on different floors). What is the best/safest method of doing this? Should i or shouldn't i extend the management vlan all the way to the DMZ zone? The DMZ zone doesn't use any directly assigned public IP addresses.

-Should the uplinks FROM the WAN-ACCESS-STACK TOWARDS the Sonicwalls be:

              -each link in access mode (VLAN2)

              -each link in trunk mode (VLAN2, VLAN254, VLAN999)

              -all links combined into one port-channel access mode (VLAN2)

              -all links combined into one port-channel trunk mode (Vlan 2, 254, 999).

** SonicWall does support port-channeling, i have tested it successfully.

Is this design valid? Any suggestions?

Thank you for your input in advance.

[Jon Marshall]

So your firewalls support trunking on their interfaces ?

I'm assuming so as I have never used them so the following is based on that assumption.

Your WAN access stack is terminating on a different interface on the firewalls than the DMZ stack.

If your firewalls are running in L3 mode then you can't extend the management vlan to the DMZ switches. You would have to run a cable(s) direct between the WAN stack and the DMZ stack.

You could do this and create the SVIs on the DMZ switches. If all DMZ switches are L2 then that would do although obviously you would want to lock down access etc.

If any were L3 then you should put the management SVI into it's own VRF.

The alternative is to use a separate vlan/IP subnet for management of the DMZ switches and allow that on the uplinks from the DMZ stack to the firewalls and then route from internal to the DMZ switches.

You wouldn't then need a cable between the DMZ and WAN stacks but your DMZ stack uplinks to the firewalls would need to be trunks.

You only need to allow vlan 2 on the uplinks from the WAN stack regardless of which option you use above.

I would use a port channel whichever you use as it removes any STP considerations although obviously still run it.

Jon

[grochowskir]

Hey Jon,

Thank you for you quick reply. Yes, the Sonicwalls NSA 5600 do support trunking and link aggregation. They also support the creation of sub-interfaces for each VLAN. So if you have a trunk coming from the WAN-ACCESS-STACK with VLANS 2, 254, 999 you can create sub-interfaces on the parent interface on the Sonicwall for each VLAN passed from the WAN-ACCESS-STACK. Not sure if this is the proper or safe design, however, it does work in my lab.

Furthermore, I apologize, however, i should've provided more info on the DMZ zone design. Basically, the WAN-DMZ-STACK is L3 capable and I was planning on creating SVIs for each VLAN and then trunking them towards the Sonicwall. For example:

-VLAN 254 for management

-VLAN 150 for the DMZ Wireless controllers

-VLAN for the smaller PUB-SWitches.

The sonicwall is layer 3 only, however, i can pass vlan tagged traffic from the WAN-ACCESS-STACK all the way to the DMZ zone due to availability of sub-interfaces (which are like SVIs in Sonicwall world) to each network. 

I know what you are thinking, L2 VLAN info doesn't gets filtered by L3, and I therefore, I should be able to use access links in VLAN 2 from WAN-ACCESS-STACK towards the Sonicwall. I just dont know what method is more of a "standard" in network design world.

I hope that i am making sense. Thank you.

[Jon Marshall]

The sonicwall is layer 3 only, however, i can pass vlan tagged traffic from the WAN-ACCESS-STACK all the way to the DMZ zone due to availability of sub-interfaces (which are like SVIs in Sonicwall world) to each network. 

So are the interfacs on the firewall L2 ports and then you have virtual L3 interfaces ? 

I only ask because with Cisco devices if you use subinterfaces then the L3 IP subnet terminates on that interface ie. you can't then pass it through to another L3 interface using the same IP subnet.

If they are L2 interfaces with virtual interfaces, just like SVIs then you could.

Not doubting you, just want to understand exactly how the firewalls work.

Jon

[grochowskir]

Hey Jon, 

You have a good and valid point about whether the SonicWall interfaces are L3 or L2. Since they are assigned an IP address i assume that they are L3, however, what throws me off is the VLAN ID tag field. I am attaching the screenshot of it.

Moreover, what i have decided to do is the following:

1. Created port-channel in trunk mode from Core 1 owards WAN-ACCESS-STACK allowing vlans 2,254,999.

2. Created port-channel in trunk mode from Core 2 towards WAN-ACCESS-STACK allowing vlans 2,254,999.

3. Created 1 port-channel in access mode for VLAN 2 from WAN-ACCESS-STACK towards the Sonicwalls.

Everything seems fine, however, except one thing. I can't ping the SonicWall IP address 10.100.2.254 nor any other address on the Internet such as 8.8.8.8 from the WAN-ACCESS-STACK. as well as the ACCESS-LAYER-SW1 switch that is connected directly to Cores. I have no such problem with pinging from the Core. 

To summarize,

I CAN:

-from WAN-ACCESS-STACK ping my ip default-gateway (vlan 254) 10.100.254.1

-from WAN-ACCESS-STACK ping ACCESS-LAYER-SW1 switch (vlan 254) 10.100.254.15

-from ACCESS-LAYER-SW1 switch ping my ip default-gateway (vlan 254) 10.100.254.1

-from ACESS-LAYER-SW1 ping WAN-ACCESS-STACK switch (vlan 254) 10.100.254.20

-from the CORE switches ping WAN-ACCESS-STACK and ACCESS-LAYER-SW1, along with the SONICWALL LAN IP 10.100.2.254 as well as any address on the Internet such as 8.8.8.8

I CAN'T:

-from WAN-ACCESS-STACK ping the SONICWALL LAN IP 10.100.2.254

-from WAN-ACCESS-STACK ping any Internet address such as 8.8.8.8

-from ACCESS-LAYER-SW1 ping the SONICWALL LAN IP 10.100.2.254

-from ACCESS-LAYER-SW1 ping any Internet address such as 8.8.8.8

When i do the traceroute on the WAN-ACCESS-STACK, the ICMP packets get delivered to the active Core and go nowhere from there. See below:

WAN-ACCESS-STACK#traceroute 8.8.8.8
Type escape sequence to abort.
Tracing the route to 8.8.8.8
VRF info: (vrf in name/id, vrf out name/id)
  1 10.100.254.2 0 msec 0 msec 10 msec
  2  *  *  *
  3  *  *  *
  4  *  *  *
  5  *  *  *
  6  *  *  *
  7  *  *  *
  8  *  *  *
  9  *  *  *
 10  *  *  *

When I ping the Sonicwall i get the same reply:

WAN-ACCESS-STACK#traceroute 10.100.2.254
Type escape sequence to abort.
Tracing the route to 10.100.2.254
VRF info: (vrf in name/id, vrf out name/id)
  1 10.100.254.2 10 msec 0 msec 0 msec
  2  *  *  *
  3  *  *  *
  4  *  *

ACCESS-LAYER-SW1 provides exactly the same output. I am currently confused why the ping works from the Core switches but from the wan stack and the access layer switches. Since the Core is the default gateway it should route this traffic to the appropriate areas of the network. What do you think? Thank you

[Jon Marshall · Accepted solution]

If you are using subinterfaces you need a vlan tag because the traffic would be tagged. But that doesn't mean you can pass L2 vlan traffic through the interface which I suspect you can't because it is a L3 subinterface as I mentioned earlier.

Even if they could though I prefer your solution using just vlan 2 because it means there can be no routing around the firewalls between the DMZs and the internal network.

Does the firewall have a route back to the 10.100.254.x subnet ?

That is the source IP of the WAN stack when you ping.

The core ping is different. It will use it's interface in the 10.100.2.x subnet as the source IP and we know the firewall knows about this subnet.

This would also account for the internet pings as well.

I suspect that is your issue.

Jon

[grochowskir]

Thank you Jon - this makes a lot of sense. I will check the routes on the SonicWall tomorrow. Will keep you posted. Cheers!

[grochowskir]

Hey Jon,

This was it!  Apparently, in Sonicwall OS when "UNASSIGN" an interface which is equivalent to "DEFAULT" in Cisco, it removes any routes used by it. I had created a route over month ago when i was first playing with the equipment and it was probably disabled when I unassigned this interface. 

Moreover, based upon the originally posted network diagram, does it look like a viable solution according to you?

Again, thank you for your help.

[Jon Marshall]

Glad you got it working.

Based on the original design with the modification of only running vlan 2 to the firewalls and having the DMZ switches on a different management subnet yes it looks fine to me.

One other thing, you shouldn't need to allow the native vlan on the trunk between the core and WAN access stack because there should be no traffic in that vlan.

Apart from that it all looks good.

Jon