TZ 470 Configuration with Layer 3 Switch and on prem Phone Server
Hello wonderful people, I hope you are all well! We have recently taken on a client with an existing network setup, they have a layer 3 switch in the mix that appears to be routing traffic back to the router. The phones are on a VLAN defined by the switch, we have already been onsite to install our TZ470 after configuring it but it seems something was off on our setup as the phones were not getting out to the internet. The computers had internet just not the phones. We need the phones on our 192.168.2.0/24 subnet to be able to get out to the internet, any assistance would be appreciated. Please see below for further information, don't hesitate to ask any questions, thanks in advance!
Switch IP 192.168.0.1
VLAN1 192.168.0.1 255.255.255.0
VLAN2 192.168.2.1 255.255.255.0
0.0.0.0 0 Default 192.168.0.254 Default 1 1 VLAN 1
192.168.0.0 24 Local Directly Connected VLAN 1
192.168.2.0 24 Local Directly Connected VLAN 2
Default Gateway 192.168.0.254
Current Firewall Info (Watchguard)
Eth0 - Comcast
Eth1 - Data 192.168.0.0/24 / VOIP 192.168.2.0/24 (seems you can link vlans to the physical interface)
Eth2 - AllWORX 192.168.20.1
Firewall IP 192.168.0.254
DNS Server 192.168.0.17 (AD Server which is also doing DHCP for the 192.168.0.0/24 subnet)
ALLWORX Phone Server Info - 192.168.2.254
Default Gateway 192.168.20.1
ETH0/untagged | Local Phones
Current IP Address: 192.168.2.254
Current IP Mask: 255.255.255.0
ETH1/untagged | WAN
Current IP Address: 192.168.20.254
Current IP Mask: 255.255.255.0
Public Interface IP 192.168.20.254
Destination Netmask Gateway External IP
192.168.0.0 255.255.255.0 192.168.2.1
192.168.113.0 255.255.255.0 192.168.2.2
DHCP ENABLED - 192.168.2.0 /24 subnet
You haven't given us the config rundown of your Sonicwall.
I have seen this exact setup before and honestly these setups are terrible. Watchguards make no sense with their VLANs, how can they have an interface on a VLAN but also have a route to the VLAN thats not the interface? How does that make sense?
What I have done in these instances is takeover gateway functionality from the switch and have the Sonicwall do it all.
If you still want to try mimicing the original setup let's see how the Sonicwall is configured.
Thank you for the response, I agree on the Watchguard portion.
We would prefer to move everything to the SonicWALL but didn't want to break anything in the process. Currently this is what we have setup on the SonicWALL
X0 LAN 192.168.0.254 <- SonicWALL IP , didn't think we needed to define a VLAN for the primary subnet of 192.168.0.0/24 as everything was working fine on our last attempt for the data subnet
X0:V2 LAN 192.168.2.3 <- VLAN for phone subnet
X1WAN 96.72.X.X <- Comcast Primary Internet
X2WAN 192.119.X.X <- Secondary ISP
X3DMZ 192.168.20.1 <-- We created a DMZ for the Phone Server
Any direction on moving to setup everything on the SonicWALL itself would be appreciated, thank you!
No offense but I'm not going to do your job for you. You have to break things in order to fix them.
Think about your goal and how to accomplish it step by step. Ask specific questions and I'll give specific answers.
No offense taken, thanks for reaching out.
Come back with your thoughts. I prefer to provide guidance than straight answers. How would anyone learn?
Well my thinking is to eliminate the 192.168.20.0 subnet altogether , change the gateway of the phone server to point the SonicWALL at 192.168.0.254 and attempt to tag traffic coming from the Phone Server with QoS on the SonicWALL. I would think we can remove the static on X3 at that point , test and go from there.
That cleans up the need for the DMZ for the Allworx WAN interface but doesn't solve for your original issue (phones not getting out to the internet). Did the Allworx have issues with connectivity with the Sonicwall in place? Do you even have admin access to the Allworx and are you comfortable troubleshooting it?
Yes it did have connectivity issues with the SonicWALL in place, I could ping the devices on the 192.168.2.0 subnet but they did not have internet access. I do have admin access to the Allworx phone server but wouldn't say I'm "comfortable" with troubleshooting it but have to grab the bull by the horns as they don't have active support. I imagine I should be able to run some tests by plugging my laptop into one of the jacks the phones plug into, check the access rules on the SonicWALL and routes and such but other than that it will take some poking around.
My opinion is leave the DMZ and Allworx WAN as is. Just because the phones had issues connecting to the internet doesn't mean the Allworx did too.
Focus on the core issue, phone connectivity issues.
Thank you for the advice, I will roll with that.
What IP address do the phones use for their default gateway and what device controls that IP address?
192.168.20.1 is the default gateway set on the Allworkx system (192.168.2.254) that currently comes into the Watchguard over the ETH2 interface, so it seems the infamous Watchguard has dominion over it.
I'm not asking about the Allworx system. I am asking about the physical phones. If you login to one of the phones web interfaces, what IP address would it use for its default gateway?
To ask the same question with a different way of discovering the answer:
What does the DHCP server for the physical phones hand out as the default gateway IP address?
Thank you for clarifying, it appears the gateway setting on the phone points to the Allworx Server @ 192.168.2.254
What about all the other DHCP settings? What do the phones get as subnet mask, DNS, etc.?
Current DHCP Server IP 192.168.2.254
Current DHCP Lease Time 0 hr 30 min 54 sec
Current SNTP Time Server IP 192.168.2.254
Current Boot Server IP 192.168.2.254
Current Phone IP 192.168.2.10
Current Subnet IP 255.255.255.0
Current Gateway IP 192.168.2.254
Current VLAN Mode LLDP Enabled
Primary DNS Server 220.127.116.11
So based on all this information what would be the route of a packet from a phone to the internet?
That is a great question.
Phone --> Switch --> Allworx Server --> Watchguard --> Internet
That's my thinking at least.
As long as the Allworx is performing routing I would agree. How can we be sure? A packet capture never lies.
Could the static routes set on the Allworx also provide us clues?