Link to home
Start Free TrialLog in
Avatar of Jason Zondag
Jason ZondagFlag for Canada

asked on

SonicWALL / Cisco Inter VLAN routing - DHCP - SSL VPN

I have a routing puzzle that I just can't figure out.

Here's my network:

SonicWALL TZ210
X0 interface:  192.168.0.2
- no DHCP, no VLAN
- two custom routing rules
Source    Destination                  Service   TOS/Mask     Gateway    Interface    Metric
Any          Partner fiber LAN1     Any         Any                 C3560        X0                1
Any          Partner fiber LAN2     Any         Any                 C3560        X0                1

Cisco C3560CX 8 port Catalyst Switch  <---- core switch used for internal routing
interface GigabitEthernet0/1           <-- this interface is plugged into the nearest SG300 series Cisco Switch
 description gvf-alt-lan
 switchport mode trunk
 speed 1000
 duplex full
 macro description cisco-desktop
 spanning-tree bpdufilter disable
 spanning-tree bpduguard disable

interface GigabitEthernet0/3   <--- this port is plugged into the SonicWALL X0 Interface
 switchport mode access

interface GigabitEthernet0/10  <--- my fiber uplink to partner company
 description FIBER CORE 3650 SWITCH
 no switchport
 ip address 172.31.1.2 255.255.255.248
 speed 10
 duplex full

Routing on gateway switch:
interface Vlan1
 ip address 192.168.0.1 255.255.255.0
!
interface Vlan140
 ip address 192.168.210.1 255.255.255.0
!
interface Vlan150
 ip address 192.168.220.1 255.255.255.0
!
interface Vlan160
 ip address 192.168.230.1 255.255.255.0

ip default-gateway 192.168.0.2
ip route 0.0.0.0 0.0.0.0 192.168.0.2

I have 7 switches for internal networking.

192.168.0.0/24  - no VLAN - base wired network
192.168.210.0/24 - VLAN 140 - wired network with Cambium WAP's connected (static assigned IP's)
192.168.220.0/24 - VLAN 150 - wireless network (Production Wireless)
192.168.230.0/24 - VLAN 160 - wireless network (Guest Wireless)

On my SG300 switches, I assigned each a static iP on 192.168.0.0 using VLAN1 (default).  They all show up.
All ports/interfaces on the SG300's are configured for TRUNK
All switches have VLAN 140/150/160 added

What works:

192.168.0.0/24 functions fine.  DHCP from a local server works,
DHCP from the SonicWALL works.  I am using a local windows server (192.168.0.201) for DHCP.  
Internet works.

What doesn't work:
Some of my SG300 switches have multiple IP's assigned to it.  One is 192.168.220.98.  From 192.168.0.0 I cannot ping this device.  Traceroute dies at 192.168.0.1.
DHCP for any of the VLAN's does not work either from the C3560 or from the local Windows Server.
- however, I set port 5 on the C3560 to VLAN 150 and it did successfully pull an IP from the Cisco Switch

I can statically assign an IP for 192.168.220.70 (as an example) to my notebook on the wireless network.  It's totally dead. Unroutable. It can ping the switches with static IP's on that subnet (192.168.220.98 and 192.168.220.99) but cannot get to the gateway 192.168.220.1.

Please note - this configuration is a new design and it is necessary.  The goal was to expand the existing LAN with a building-wide wireless mesh network.  Because of my fiber uplink and lack of room on my existing LAN (192.168.0.0/24) I was forced to introduce new subnets for WLAN and WLAN management.

192.168.210.0/24 VLAN 140 WLAN MGMT network (Cambium WAP's configured with static IP's on this network)
192.168.220.0/24 VLAN 150 WLAN Production network
192.168.230.0/24 VLAN 160 WLAN Guest network

I'm really stuck.  It's been suggested the problem is with my SonicWall Router but when I had my X4 interface set up with all three VLAN's and DHCP pools, and the SonicWALL was the gateway device, DHCP functioned, Internet functioned, and most things worked.  The only thing that didn't work, which is key and why I changed it all, is EIGRP is not supported by SonicWALL and it is mission critical that the LAN's on my side of the fiber are advertised on the remote side.

Another issue that cropped up and my be an indicator of where the issues lie, I have the SonicWALL set up for SSL VPN using RADIUS to authenticate AD users. Before the change, it worked fine.  Now, RADIUS times out.  I updated NPS on the server to use the new SonicWALL IP (changed form 192.168.0.1 to 192.168.0.2) but it didn't make any difference.

Any help would be appreciated.
ASKER CERTIFIED SOLUTION
Avatar of Benjamin Van Ditmars
Benjamin Van Ditmars
Flag of Netherlands image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Jason Zondag

ASKER

Benjamin,

The only routing rules I have created in the SonicWALL are as follows:

- two custom routing rules
Source    Destination                  Service   TOS/Mask     Gateway    Interface    Metric
Any          Partner fiber LAN1     Any         Any                 C3560        X0                1
Any          Partner fiber LAN2     Any         Any                 C3560        X0                1

I looked at these again but I don't see how to make a SonicWALL aware of the various subnets.  All rules are based on Interface, so if the Interface IP is 192.168.0.2 it knows about 192.168.0.0/24, but it doesn't know anything about the other subnets (192.168.210.0/24 192.168.220.0/24 192.168.230/24).  I considered adding sub-interfaces to the X0 interface - would that work?  I'm finding the SonicWALL a bit limited in this capacity.
Ok, following your suggestion I have created the following rule:

Source    Destination                  Service   TOS/Mask     Gateway    Interface    Metric
Any          Hidden Internal          Any         Any                 C3560        X0                20

Hidden Internal is an address object group consisting of the following networks:
192.168.210.0/24
192.168.220.0/24
192.168.230.0/24

This does appear to have had some effect.  On the 192.168.210.0/24 network are 25 Cambium Wireless Access Points, all with static IP addresses, all that check in with a Cloud Management Portal.  Immediately after adding that rule I checked to see if they were checking in.  After about 10 minutes all were checking in, suggesting that they must now have Internet access.

I also solved the problem with DHCP not broadcasting to the VLANs.  I discovered that SG300 series switches do not trunk in the same way as catalyst switches.  On a catalyst switch, just setting to trunk permits all VLAN traffic through, regardless of the VLAN, provided the VLAN is identified in the switch configuration.  On the SG300 series switches, I had to manually add all of the VLANs to the uplink ports, which now show 1U, 140T, 150T, 160T.  Almost instantaneously DHCP provided my phone with an IP address.

I'm no longer onsite so I cannot confirm if the static route is actually working for traffic in both directions.  I'm not finding it easy to tell on the SonicWALL if traffic traffic is actually flowing in both directions.  I'll go back onsite tomorrow for further testing.
Another update - the SSL VPN issue was my own stupidity.  I forgot to update the NPS RADIUS Client on the Windows Server to the new IP of the SonicWALL.  As soon as I updated it the SSL VPN Connection authentication started working.
Remember routing is a 2-way process, always think about how the  traffic get's back.
for the 2 partnet networks, are they aware of the 192.168.0.0/24 subnet ?

When they also do some routing. they also have to add a route the this network with as gateway the IP Address of youre layer 3.

when you need more help just send me a message.
The return routing was the solution. I got confirmation that wireless is now up and fully functional. Just took me a bit to figure out how to make the sonicwall aware of the subnets that weren’t configured on the sonicwall to the X0 interface. Creating an address group object consisting of all the subnets and directing the traffic through the core switch accomplished what I needed.

Thank you very much for your quick response and pointing me in the right direction.