Vonage Business with Untangle Firewall

[tek9]

I'm wondering if anyone has any experience with using Vonage Business VOIP service behind an Untangle firewall.
Basically, I have a client which I've setup wtih an Untangle firewall and they're using VOIP phones with Vonage Business. Some users are complaining about the call quality being terrible, that they can't hear every third word or so. It appears to be random phones.
This is their setup: AT&T direct symmetrical fiber 100Mbps connection directly connected to an Untangle Firewall appliance built by Nexgen Appliances - NG500. Two unifi 48 port switches connected in series to the firewall, to which all the phones are connected, and the PCs are connecting to the phones' passthrough ports.
There is a vlan setup for the voice network (and another vlan for the guest wifi). The entire voice vlan - source and destination - is bypassed in untangle so it's not being inspected by any modules, and I also bypassed destination ports 5060-5080 and 10002 as instructed by Vonage. I also turned on QOS for those destination ports, even though I believe it's unnecessary given the bandwidth they have and considering they only have less than 100 users on the network between PCs, phones and wireless clients.
Now I don't think it's an Untangle issue since I've setup Untangle with other VOIP providers, (but for those I setup a local FreePBX server, and using separate interfaces for LAN and VOIP, with no vlans). Untangle shouldn't even be looking at the voip packets since they're bypassed. The bandwidth should be more than enough.
Does anyone have any experience with this type of setup and issue and can shed some light?
Thanks in advance.

 

[YeOldeStonecat]

Yeah by default SIP is already bypassed...you'll see default rules already in there.
I tell ya, I hate Vonage...just this afternoon a client called having issues with Vonage, all Ubiquiti system there...but ends up after spending time troubleshooting it's their cable ISPs end of things for that one.

You have a larger setup, last fall I did a larger setup also behind an NG-500 appliance, a small school..probably similar size network to yours. I put their VoIP in a VLAN, and I had that VLAN exit the switch to a dedicated ETH interface on the NG-500. Total bypass rules for that interface, and actually they have a backup (2nd) WAN connection...DSL, I bound it to that, main traffic of the 150 meg pipe on WAN1. Worked great. I'm guessing you don't have a 2nd WAN connection....but breaking that VoIP VLAN out on a dedicated separate ETH interface on that big NG-500 would help things. Totally different IP range..just run DHCP on that extra ETH interface. I just untagged the VoIP VLAN on the switch interface facing that extra inward facing Untangle interface.

 

[tek9]

Yeah by default SIP is already bypassed...you'll see default rules already in there.
I tell ya, I hate Vonage...just this afternoon a client called having issues with Vonage, all Ubiquiti system there...but ends up after spending time troubleshooting it's their cable ISPs end of things for that one.

You have a larger setup, last fall I did a larger setup also behind an NG-500 appliance, a small school..probably similar size network to yours. I put their VoIP in a VLAN, and I had that VLAN exit the switch to a dedicated ETH interface on the NG-500. Total bypass rules for that interface, and actually they have a backup (2nd) WAN connection...DSL, I bound it to that, main traffic of the 150 meg pipe on WAN1. Worked great. I'm guessing you don't have a 2nd WAN connection....but breaking that VoIP VLAN out on a dedicated separate ETH interface on that big NG-500 would help things. Totally different IP range..just run DHCP on that extra ETH interface. I just untagged the VoIP VLAN on the switch interface facing that extra inward facing Untangle interface.

Correct, just a single WAN connection.
How would I put the VOIP vlan on a separate ETH interface on the router? Currently the voip vlan is on a different IP range with DHCP (LAN is 192.168.0.x, voip is 192.168.33.x) but it's a tagged vlan in Untangle, numbered 1.33 in the network config page, so it's using ETH1 as the parent interface. This vlan interface (?) is bypassed in Untangle both source and destination. If I were to use a separate ETH interface (eth2, for example), I would have to connect both the LAN interface, eth1, and the voip interface, eth2, to the same switch, but I don't think you want that. Unless I'm not understanding clearly what you're suggesting.

 

[Sky-Knight]

SIP is bypassed by default, if and only if it's running on UDP 5060, Vonage loves to move to 5061. To make matters worse, bypassing SIP doensn't really help all that much, SIP is just the control session. The audio problems are the RTP sessions that SIP is used to setup, THOSE must be bypassed or bad things happen, and that is most certainly NOT automatic.

If you've got an IP network full of phones, you can bypass them entirely just to be lazy and safe.

The easy way to do that is two bypass rules, one simply says source address: IPofPBX, the other is simply destination address: IPofPBX. Does vonage give you a list of IPs they use as the PBX? Stop thinking about ports, and start byassing everything to and from that PBX.

Oh, and since I have both you and Stonecat in this tread... *WARNING* to all Nexgen customers. Untangle v14 is in alpha, this version of Untangle us utilizing Debian 9 as a base OS. Something about that new kernel pitches a fit if the OS sees the CF card readers in my servers. So the day has finally arrived, we can no longer use the recovery system we've enjoyed for all these years. If the system is young enough to allow it, the BIOS can disable the SATA port. These systems can be used still, but the SATA port must be disabled to allow Untangle to boot. Older systems that emulated IDE, or didn't have the ability to disable the CF card must have the cards physically removed BEFORE the upgrade.

Tek, your system has the option in the bios to disable the SATA port with the CF on it, please do so as soon as possible. If you need to reinstall the platform you'll simply need a USB key with Clonezilla on it. v14 means Clonezilla has to update AGAIN anyway, so what's on the CF in there won't work without help anyway.

I haven't made any general announcements yet. Another thing v14 is doing is deprecating 32bit, so any NG-Mini platforms in the field may or may not work after upgrade as they are 32bit only.

And as always, v14 is an OS update, which means huge, failure prone, AND you have to manually pick a new kernel after reboot to complete it. So start turning off automatic updates and start scheduling time for maintenance.

I am still testing, and hoping I can find some work arounds for the issues v14 brings, but given Untangle's track record we may have less than 30 days to mitigate this, so I want everyone here to know sooner so you've got an easier time with your schedules.

 

[YeOldeStonecat]

Correct, just a single WAN connection.
How would I put the VOIP vlan on a separate ETH interface on the router? Currently the voip vlan is on a different IP range with DHCP (LAN is 192.168.0.x, voip is 192.168.33.x) but it's a tagged vlan in Untangle, numbered 1.33 in the network config page, so it's using ETH1 as the parent interface. This vlan interface (?) is bypassed in Untangle both source and destination. If I were to use a separate ETH interface (eth2, for example), I would have to connect both the LAN interface, eth1, and the voip interface, eth2, to the same switch, but I don't think you want that. Unless I'm not understanding clearly what you're suggesting.

Right now it sounds like you have Untangle terminating the VLAN by adding a tagged VLAN to that same ETH port you have for your LAN.
So for example, on the NG-500, you have ETH 0 for the WAN, ETH 1 for the LAN, and also on ETH 1...a VLAN added to it. So all the internet traffic and VoIP is using ETH 1.

What I often to is try to split the load on the LAN ports of firewalls of larger networks. So...say you have VLAN 3 for your VoIP. On your Untangle NG-500 box, take ETH 2 (the 3rd ethernet interface)...set its IP at 192.168.33.1 and DHCP for your 192.168.33.0/24. Now on your switch, for example...take port 23...Untage VLAN 3 on it, exclude VLAN 1 and any other VLANs from it..and uplink it to ETH2 on your NG-500.

Now all VoIP traffic will exit your switches on that port 23...and arrive at that dedicated ethernet interface, cleaner, less traffic...not mingled with data traffic. Basically just streamlines performance, less traffic on the ethernet interfaces.

You stopped providing CF cards in the units at some point a while ago right? So units we ordered since...(dd/mm/yy) would not have them?

 

[YeOldeStonecat]

These systems can be used still, but the SATA port must be disabled to allow Untangle to boot. Older systems that emulated IDE, or didn't have the ability to disable the CF card must have the cards physically removed BEFORE the upgrade.So start turning off automatic updates and start scheduling time for maintenance.

I am still testing, and hoping I can find some work arounds for the issues v14 brings, but given Untangle's track record we may have less than 30 days to mitigate this, so I want everyone here to know sooner so you've got an easier time with your schedules.

Gah...so, we got around 65 or so units out there...I know on that last update that wasn't fond of the CF card (I think going from 10 to 11, or was it 11 to 12?) we pulled a lot of CF cards. But many units may still have the CF cards in there. You got a way to tell from doing a local SSH/Putty in?

 

[Sky-Knight]

Gah...so, we got around 65 or so units out there...I know on that last update that wasn't fond of the CF card (I think going from 10 to 11, or was it 11 to 12?) we pulled a lot of CF cards. But many units may still have the CF cards in there. You got a way to tell from doing a local SSH/Putty in?

Yes, ssh in and do fdisk -l

If you see two disks, you need to get to that unit. The only appliance that doesn't have a CF in it even currently is the 100D. The change that was supposed to be made to the rest was the BIOS was supposed to ship with the SATA port the CF lives on disabled. So you could turn it on / off in the BIOS as needed. BUT, I'm now noticing the factory wasn't all that great in following that instruction.

As for the inconvenience, I'm sorry for that. But because this is yet another in place OS upgrade for Untangle, none of us should be deploying that upgrade without a tech on site. Again you cannot complete the upgrade without manually choosing the new kernel from the physical console on reboot. Yes, you can reconfigure Grub via SSH, but what are you going to do if the thing doesn't reboot?

So everyone should be warned now, on my hardware or not, disable automatic upgrades on all Untangle installs before the v14 upgrade rolls. You do NOT want this one automatically applying. Backup your stuff, be ready for doomsday, and you'll be bored while it all works. Make Murphy work for you, be prepared for the worst and he'll give you the best.

 

[tek9]

Right now it sounds like you have Untangle terminating the VLAN by adding a tagged VLAN to that same ETH port you have for your LAN.
So for example, on the NG-500, you have ETH 0 for the WAN, ETH 1 for the LAN, and also on ETH 1...a VLAN added to it. So all the internet traffic and VoIP is using ETH 1.

What I often to is try to split the load on the LAN ports of firewalls of larger networks. So...say you have VLAN 3 for your VoIP. On your Untangle NG-500 box, take ETH 2 (the 3rd ethernet interface)...set its IP at 192.168.33.1 and DHCP for your 192.168.33.0/24. Now on your switch, for example...take port 23...Untage VLAN 3 on it, exclude VLAN 1 and any other VLANs from it..and uplink it to ETH2 on your NG-500.

Now all VoIP traffic will exit your switches on that port 23...and arrive at that dedicated ethernet interface, cleaner, less traffic...not mingled with data traffic. Basically just streamlines performance, less traffic on the ethernet interfaces.

You stopped providing CF cards in the units at some point a while ago right? So units we ordered since...(dd/mm/yy) would not have them?

So I'm assuming to change my current config, I would remove the vlan from eth1 and create a new interface on eth2 with the 192.168.33.x settings. Then exclude this .33.x network from the port on the switch which is connected to eth1, and untag the voip vlan and exclude the other network from the switch port connected to eth2. Or do I NOT need to exclude the voip vlan port from the switch port connected to eth1 since the traffic will automatically go to eth2 since it's the one configured for that network?
I currently have the Unifi switch ports set to tag the voice vlan and untag the LAN network, so that the phones automatically grab the voice vlan for themselves and pass the LAN network to computers connected to their passthrough ports. Will these changes to the router/switch cause problems with that setup?