VLAN issues with FreePBX 14

I’m having a crazy issue with VLANs in the latest version of FreePBX.

We’re using Grandstream GXP 2130 phones with FreePBX 14. It’s running on a Dell R710.

When the phones are on the VLAN (eth0.20) they don’t hang up after a call completes. There are also strange issues like some calls going straight to voicemail instead of ringing the destination phone.

When the phones are NOT on the VLAN they hang up properly - all is well.

Could these issues be because I’m running on old hardware with a newer CentOS release?

The Dell has Broadcom NICs and the kernel module being used is BNX2.

I’m going back to FreePBX 13 and testing the exact same setup to confirm my suspicions but I have a strong feeling there’s something wrong with VLANs in the newest kernel with the BNX2 driver. I’ll report back with some findings tomorrow.

Remembering through pudding…

There are some phones that do not send the hang-up packets (or was it listen for the hangup packets) on the VLAN interface. I remember someone having a huge epiphony about this (@avayax maybe) about a year ago.

I recall that it wasn’t anything about the actual VLAN, it was something in either FreePBX or the phone not using the VLAN to terminate the call and sending the traffic out on the wrong VLAN.

I had a similar problem a couple of years ago with some Polycom phones, and just stopped using VLANs because of it. Never looked back.

If you no longer use VLANs how to you set up your network?

We have only enough physical drops for one ethernet port per office. So the phones share the same physical ports. And, there are DHCP options which apply to the phones but not the PCs. Without VLANs I’m unsure how to set DHCP options the way I need.

Using subnets. I set up DHCP to recognize the requesting system type and send the phone setup packets to the phones. Everything else drops into a different pool on a different subnet.

On the phone system, I set up the interface the phones see on one network (192.168.99.x/24) and the workstations on the other (192.168.199.x/24). The phone server lives on the .99 network (to talk to the phones) and has another interface that talks to the 199 network (for phone services, etc.). Set the DHCP server up so that it interfaces with both networks, and off you go. Basically, you just set up two networks on the same switch. Most switches handle it without problems, and you avoid the VLAN complications.

It’s a “poor man’s” VLAN. Both network run on the same network equipment; the phones pass the PC traffic through to the wire and the phones talk on the other network. Everybody that needs to see the outside world routes through the 199 network, and everyone that doesn’t is on the actual private network.

This is my lack of deeper network skills but … my DHCP server adheres strictly to the standard and only permits a single network per physical interface. However I can VLAN on that interface.

HOWEVER

I’m experiencing strange issues even when the Grandstream phones are not using VLAN.

It’s just when on the VLAN the issues become worse.

I’m starting to believe there’s something deeper causing me trouble.

Upon further testing once a call exceeds roughly 35 seconds it gets dropped, leaving one phone off-hook and still connected but the other party is dropped.

@cfapress OK so now explain how you have this setup. Because right now your first post is saying you have eth0.20 as the “VLAN” which is more like a virtual interface on the PBX’s ethernet card. So how do you have this VLAN configured? You have it programmed in the switch that the phone is connected to? You have the VLAN tag set in the phone? Is the switch/router dealing with the VLAN tags properly (stripping/adding/etc)?

There is nothing in this thread showing what your actual setup is. All you’ve shown is that you have a virtual interface on the PBX that when used the GXP doesn’t hangup right.

As for this whole “I use subnets” thing, that’s exactly what VLANs are for. They aren’t for the same subnet they used to send traffic for multiple subnets over the same interfaces and being able to tell what is what by it to route it as needed.

My typical office setup is user’s PCs piggy backed off the phones, the office has their own DHCP server/network and they all plug into the switch. Program my router (as it is the core router for everything) with the VLANs, leave the office network on VLAN1 (untagged), setup the switch to allow both VLAN1 and the voice VLAN and boom done. I even have a DHCP server for the voice network VLAN. Using either Polycoms or Yealinks and not single issue with calls going over those VLANs and disconnecting properly.

You need to show call that isn’t hanging up properly in full that is going over the VLANs so we can see exactly what is happening. If you’re using Chan_SIP then do a sip set debug on and make the call to get the trace. If you’re using Chan_PJSIP then do pjsip set logger on then make the call. Post the entire there here so we can see it.

So … the solution is not related to VLANs at all.

I had to modify the Settings > Asterisk SIP Settings > NAT Settings

And manually add the 10.8.2.0 network.
My data network is 10.8.1.0/24
My voice network is 10.8.2.0/24

After applying the config everything works properly.

I guess I assumed that if Admin > System Admin > Network Settings had interfaces on networks they’d be understood to be local to the Asterisk. Also, the Firewall is configured to understand that 10.8.2.0 is a local trusted network.

For curiosity sake, details on my setup include:

pfsense as the router and DHCP server, configured LAN and VLAN 20
Unifi 24-port POE switch programmed to pass VLAN 20 on all ports
FreePBX 14 with eth0 and eth0.20
Grandstream phones programmed to VLAN 20

LAN = 10.8.1.0/24
VLAN 20 = 10.8.2.0/24

To eventually discover the trouble I mirrored all traffic from a port on the Unifi Switch to another port. Using a laptop with Wireshark I captured all packets during a phone call. I observed the phone attempting to reach the Internet to call an internal phone. The call would successfully reach my FreePBX server but it would send the BYE packets to the Internet. Upon seeing that I know there was a configuration problem with SIP which led me to the solution - Settings > Asterisk SIP Settings > NAT Settings.

I appreciate everyone’s ideas and time spent considering my situation.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.