Designed with a wealth of functionality and convenience, ATEN's new Thunderbolt™ 2 Sharing Switch takes your Thunderbolt setup to the next level. Now through September 15, 2017, Experts Exchange members get 30% off the US7220 on the ATEN USA eShop using promo code EXPERTS30.
COURSE of the MONTH
12 days, left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
Solved
Routing question between wifi / firewall and switch
Posted on 2016-07-16
WiFi Controller has setup a Radius server 10.0.1.120 behind Sonicwall.
Wifi client assigned with VLAN30 need to authenticated through Radius 10.0.1.120.
For WiFi controller routing to network 10.0.1.0, it need to route through Fortigate and then to Sonicwall.
DHCP server on LAN 10.0.1.0 will subnet 10.0.99.0 will start DHCP negoitation with the wifi client,
through the trunk -> PoE Switch -> WiFi Controller -> Wifi client.
After DHCP negotiation, the PoE switch should have the MAC address Wifi client and the correct port (ie the port connecting to the controller) . Am I corect ?
When wifi client access any servers 10.0.1.0 behind Sonicwall, it will go through
wifi client -> Wifi Controller -> PoE Switch -> Fortigate -> PoE Switch Sonicwall, correct ?
How does server in network 10.0.1.0 return to the Wifi client (10.0.99.0) ? How does Sonicwall know that the client is behind the Controller ?
Thx
Diagram.png
Wifi client assigned with VLAN30 need to authenticated through Radius 10.0.1.120.
For WiFi controller routing to network 10.0.1.0, it need to route through Fortigate and then to Sonicwall.
DHCP server on LAN 10.0.1.0 will subnet 10.0.99.0 will start DHCP negoitation with the wifi client,
through the trunk -> PoE Switch -> WiFi Controller -> Wifi client.
After DHCP negotiation, the PoE switch should have the MAC address Wifi client and the correct port (ie the port connecting to the controller) . Am I corect ?
When wifi client access any servers 10.0.1.0 behind Sonicwall, it will go through
wifi client -> Wifi Controller -> PoE Switch -> Fortigate -> PoE Switch Sonicwall, correct ?
How does server in network 10.0.1.0 return to the Wifi client (10.0.99.0) ? How does Sonicwall know that the client is behind the Controller ?
Thx
Diagram.png
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
-
5
4
2
11 Comments
Active today
Your diagram is pretty helpful. In that regard, I presume that T10 on the Fortigate is intended to be the connection to the WiFi controller? That's not explicit (as T10 and T30 on the WiFi controller could be independent.... perhaps).
I'm not clear what this means:
Whether the WiFi Controller has a DHCP server running is unclear. I suspect NOT, eh?
I may be missing something in the motivation here that leads to this architecture. It appears you're trying to provide wireless access to both 172.16.172.0 AND 10.0.99.0. Is that right?
I can understand that maybe you want the wireless clients to be isolated but then you don't seem to be intending to do that.
Tell us what the big picture objectives are and perhaps there can be a suggestion.
I'm not clear what this means:
DHCP server on LAN 10.0.1.0 will subnet 10.0.99.0 will start DHCP negoitation with the wifi client,Does this mean:DHCP server on the Sonicwall / LAN 10.0.10.0 WITH subnet 10.0.99.0 ???? Well one might *presume* /24 but you don't say so maybe it's 10.0.9.0???
through the trunk -> PoE Switch -> WiFi Controller -> Wifi client.
Whether the WiFi Controller has a DHCP server running is unclear. I suspect NOT, eh?
After DHCP negotiation, the PoE switch should have the MAC address Wifi client and the correct port (ie the port connecting to the controller) . Am I corect ?Yes. That sounds correct.
When wifi client access any servers 10.0.1.0 behind Sonicwall, it will go throughYes. That sounds correct.
wifi client -> Wifi Controller -> PoE Switch -> Fortigate -> PoE Switch Sonicwall, correct ?
How does server in network 10.0.1.0 return to the Wifi client (10.0.99.0) ? How does Sonicwall know that the client is behind the Controller ?Since the 10.0.99.0 subnet is also on the Sonicwall, it seems that a route on the Sonicwall from 10.0.1.0 to 10.0.99.0 would do it. Imagine if there were wired clients on the Sonicwall on VLAN30 with subnet 10.0.99.0. And, imagine if you wanted them to talk to clients on 10.0.1.0? There would be a route between those two VLANs.
I may be missing something in the motivation here that leads to this architecture. It appears you're trying to provide wireless access to both 172.16.172.0 AND 10.0.99.0. Is that right?
I can understand that maybe you want the wireless clients to be isolated but then you don't seem to be intending to do that.
Tell us what the big picture objectives are and perhaps there can be a suggestion.
Active today
The Window DHCP server on LAN subnet 10.0.1.0 can also provide IP leasing for 10.0.99.0. The intention of the design is to allow wifi client to access the LAN server through wireless network.
Sonicwall has defined 10.0.99.1 on X2 (VLAN 30). The return packet from server to wifi client will go to Sonicwall. Sonicwall know 10.0.99.0 subnet is connected to X2 and it will route the packet to the PoE switch. The PoE switch should have wif client mac address , which is the port connecting to the Wifi controller. Hence the MAC address table of PoE switch provide the information to route the packet from Sonicwall back to the Wifi controller and finally returns to the wifi client.
Am I correct ?
Thx
Sonicwall01.png
Sonicwall has defined 10.0.99.1 on X2 (VLAN 30). The return packet from server to wifi client will go to Sonicwall. Sonicwall know 10.0.99.0 subnet is connected to X2 and it will route the packet to the PoE switch. The PoE switch should have wif client mac address , which is the port connecting to the Wifi controller. Hence the MAC address table of PoE switch provide the information to route the packet from Sonicwall back to the Wifi controller and finally returns to the wifi client.
Am I correct ?
Thx
Sonicwall01.png
Active today
Well, "POE" isn't exactly the switch description one would be looking for. "Level 2" or "Level 3" would be more like it. I've been assuming that it's a Level 2 switch. But your description suggests maybe Level 3.
"The Sonicwall serving LAN subnet 10.0.1.0 also serves VLAN on subnet 10.0.99.0 and provides DHCP for each subnet." Is that correct?
First, a smart switch will know MAC addresses and associate them with ports but a Level 2 switch won't know anything about IP addresses and subnets. VLANs are just what they are called "Virtual LANs" and LANs are physical things (as in "wires") with no affiliation to IP addresses or MAC addresses. Not to be confused with subnets then.... even though they often are matched up in their use. So, it's not about MAC addresses here I shouldn't think.
I remain confused. Do you really mean X2: 172.16.172.0 AND X2:10.0.99.0 (i.e. both X2?).
Something here just isn't making sense for me.
I don't see a trunk to the WiFi Controller nor might I expect one. So that needs clarification.
Let's try this:
A WiFi client has an IP address 10.0.99.22 and connects via the WiFi Controller.
A packet is launched to the Server on 10.0.1.0/24.
The packet is sent out the WiFi controller wire destined for 172.16.172.30.
The packet arrives at the switch and is directed to the port connected to the Sonicwall.
The packet arrives at the Sonicwall 172.16.172.30.
The Sonicwall has a subnet 10.0.1.0/24 where the server resides.
The Sonicwall puts the packet out on the 10.0.1.0/24 subnet and it reaches the Server.
The Server sends a return packet destined for 10.0.99.22
Since this packet destination is not on the local subnet, it is directed to the gateway (the Sonicwall) at let's say 10.0.10.1.
The Sonicwall has a VLAN using subnet 10.0.99.0/24 it appears.
So now either:
- 1) the packet will be directed to the local 10.0.99.0/24 subnet VLAN
OR
- 2) the packet will be directed to the "internet" gateway (the Fortigate)
OR
- 3) if the switch is Level 3 then maybe it will be directed to the switch.
If it's #1 then that doesn't seem useful as there are no wireless clients on the local subnet/VLAN.
If it's #2 then the Fortigate must have a route for 10.0.99.0/24 pointing to 172.16.172.2 (the WiFi Controller)
If its' #3 then the switch must have a route for 10.0.99.0/24 pointing to 172.16.172.2 (the WiFi Controller).
I have no idea how 10.0.99.0 is associated with both the WiFi controller AND the Sonicwall at the same time. There may be two separate LANs with the same subnet and I see no way to fix that other than changing one of them. I must be missing something perhaps buried in the VLAN setups and operation.
I'm not a Sonicwall expert as such. Does this have anything to do with how your Sonicwall is configured:
https://support.software.dell.com/kb/sw7081
The Window DHCP server on LAN subnet 10.0.1.0 can also provide IP leasing for 10.0.99.0. The intention of the design is to allow wifi client to access the LAN server through wireless networkI might paraphrase this to make sure I understand:
"The Sonicwall serving LAN subnet 10.0.1.0 also serves VLAN on subnet 10.0.99.0 and provides DHCP for each subnet." Is that correct?
Sonicwall has defined 10.0.99.1 on X2 (VLAN 30). The return packet from server to wifi client will go to Sonicwall. Sonicwall know 10.0.99.0 subnet is connected to X2 and it will route the packet to the PoE switch. The PoE switch should have wif client mac address , which is the port connecting to the Wifi controller. Hence the MAC address table of PoE switch provide the information to route the packet from Sonicwall back to the Wifi controller and finally returns to the wifi client.Maybe. But you wouldn't be asking if it were working, eh?
Am I correct ?
First, a smart switch will know MAC addresses and associate them with ports but a Level 2 switch won't know anything about IP addresses and subnets. VLANs are just what they are called "Virtual LANs" and LANs are physical things (as in "wires") with no affiliation to IP addresses or MAC addresses. Not to be confused with subnets then.... even though they often are matched up in their use. So, it's not about MAC addresses here I shouldn't think.
I remain confused. Do you really mean X2: 172.16.172.0 AND X2:10.0.99.0 (i.e. both X2?).
Something here just isn't making sense for me.
I don't see a trunk to the WiFi Controller nor might I expect one. So that needs clarification.
Let's try this:
A WiFi client has an IP address 10.0.99.22 and connects via the WiFi Controller.
A packet is launched to the Server on 10.0.1.0/24.
The packet is sent out the WiFi controller wire destined for 172.16.172.30.
The packet arrives at the switch and is directed to the port connected to the Sonicwall.
The packet arrives at the Sonicwall 172.16.172.30.
The Sonicwall has a subnet 10.0.1.0/24 where the server resides.
The Sonicwall puts the packet out on the 10.0.1.0/24 subnet and it reaches the Server.
The Server sends a return packet destined for 10.0.99.22
Since this packet destination is not on the local subnet, it is directed to the gateway (the Sonicwall) at let's say 10.0.10.1.
The Sonicwall has a VLAN using subnet 10.0.99.0/24 it appears.
So now either:
- 1) the packet will be directed to the local 10.0.99.0/24 subnet VLAN
OR
- 2) the packet will be directed to the "internet" gateway (the Fortigate)
OR
- 3) if the switch is Level 3 then maybe it will be directed to the switch.
If it's #1 then that doesn't seem useful as there are no wireless clients on the local subnet/VLAN.
If it's #2 then the Fortigate must have a route for 10.0.99.0/24 pointing to 172.16.172.2 (the WiFi Controller)
If its' #3 then the switch must have a route for 10.0.99.0/24 pointing to 172.16.172.2 (the WiFi Controller).
I have no idea how 10.0.99.0 is associated with both the WiFi controller AND the Sonicwall at the same time. There may be two separate LANs with the same subnet and I see no way to fix that other than changing one of them. I must be missing something perhaps buried in the VLAN setups and operation.
I'm not a Sonicwall expert as such. Does this have anything to do with how your Sonicwall is configured:
https://support.software.dell.com/kb/sw7081
Active today
I have checked the route
1. Fortigate don't have any route for 10.0.99.0 subnet
2. In Sonicwall, there is no a route for 10.0.99.0 which is point to interface X2:30, which is connect the Sonicwall back to PoE Switch.
So, can I say that return packet is based on the PoE switch using the MAC-address table. I can see the MAC address of the wifi client (of course, not the IP address)..
Thx
1. Fortigate don't have any route for 10.0.99.0 subnet
2. In Sonicwall, there is no a route for 10.0.99.0 which is point to interface X2:30, which is connect the Sonicwall back to PoE Switch.
So, can I say that return packet is based on the PoE switch using the MAC-address table. I can see the MAC address of the wifi client (of course, not the IP address)..
Thx
Hi There,
Could you place the output of the below:
i)
#Sh ip route from the PoE switch
ii)
Routing table of the sonicwall and the fortigate
iii)
Trace from the client to Shoretel server and Vice versa.
Also confirm the significance of 10.0.99.x subnet.
Could you place the output of the below:
i)
#Sh ip route from the PoE switch
ii)
Routing table of the sonicwall and the fortigate
iii)
Trace from the client to Shoretel server and Vice versa.
Also confirm the significance of 10.0.99.x subnet.
Active today
There seems to be some misunderstanding. As I see things now (albeit with imperfect information):
1. Fortigate don't have any route for 10.0.99.0 subnetThat may be unfortunate. I don't see that it can hurt anything; so why not?
2. In Sonicwall, there is no a route for 10.0.99.0 which is point to interface X2:30, which is connect the Sonicwall back to PoE Switch.So the trunk VLAN 1,30 is on X2. Is that right? At any rate, if 10.0.99.0 is "known" by the Sonicwall then it must have a route. If all the route does is go to the gateway (via 0.0.0.0 the default route) . Is the gateway for the Sonicwall the Fortigate or the PoE Switch? You have still not said if the switch is Level2 or Level3 mode.... Once more, if there's no route in the Sonicwall for 10.0.99.0 AND no route in the gateway then there's no path and packets will be dropped. The MAC address instance in the switch is normal but won't help.
So, can I say that return packet is based on the PoE switch using the MAC-address table. I can see the MAC address of the wifi client (of course, not the IP address)..No.
Active today
The switch is C2960X, guessing it is a L2. 172.16.172.254 is Fortigate IP.
POES1#sh ip route
Default gateway is 172.16.172.254
Host Gateway Last Use Total Uses Interface
ICMP redirect cache is empty
Y5POES1#
POES1#sh ip route
Default gateway is 172.16.172.254
Host Gateway Last Use Total Uses Interface
ICMP redirect cache is empty
Y5POES1#
Active today
The fact that the switch has a gateway entry may be fairly meaningless in this discussion if it's a Layer 2 switch. It's likely there to support things like firmware updates, etc.
Kindly share the outputs as requested by Ian Arakel.
Kindly share the outputs as requested by Ian Arakel.
Active today
10.0.99.0 is the subnet for wifi client connecting to internal LAN server through Radius authentication, Thx
Dump1.txt
Dump2-Sonicwall.png
Dump3-Fortigate.png
dump4-tracert-to-Radius.txt
Dump1.txt
Dump2-Sonicwall.png
Dump3-Fortigate.png
dump4-tracert-to-Radius.txt
Featured Post
Look no further than WatchGuard's Total Security Suite, providing defense in depth against today's most headlining attacks like Petya 2.0 and WannaCry. Keep your organization out of the news with protection from known and unknown threats.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
I found an issue or “bug” in the SonicOS platform (the firmware controlling SonicWALL security appliances) that has to do with renaming Default Service Objects, which then causes a portion of the system to become uncontrollable and unstable.
BACK…
Quality of Service (QoS) options are nearly endless when it comes to networks today. This article is merely one example of how it can be handled in a hub-n-spoke design using a 3-tier configuration.
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
Suggested Courses
Course of the Month12 days, left to enroll
752 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.