Inbound VoIP calls not connecting due to fragmentation
-
Hi all
I got a new Fibre (XGS-PON) internet access at home (Swisscom). Now I am using a Zyxel PM7300 as a modem bridge and PFsense with DHCP on WAN. Internet is working fine.
Depending on the provider of the caller, VoIP calls will not ring the phone. This seems to be related to UDP packets being fragmented. This only happens with inbound calls.
I tried disabling scrub, even disabled the firewall completely but even then calls will not get through (phone does not ring). Using a different cell provider, inbound calls work fine. I tried using different MTU settings on the WAN interface as well (I set it to 2000 which is the same as the default value of the bridge).
A few months ago I had a very similar issue using a different firewall product but on the same ISP. The only solution back then was to plug the phones directly in to the router and use the network behind the firewall only for the 'normal' office network. On the previous subscription line I put the PFsense behind the ISP provided consumer router (and used a separate VLAN for the phone which was directly connected to the router) which I would really like to avoid this time (Double-NAT).
Here we can see an inbound call with fragmented packets, source being the VoIP server of the ISP (Swisscom).
login-to-viewHere we can see a call that went perfectly OK.
login-to-viewShould I try the siproxd package?
Best regards
-
Give this setting a try. It’s One of the changes I made for my office IP phones. Give your phone a static IP address then give it a static port on its outbound NAT. This solve some inconsistencies for me.
Another thing to try is go to systems- Advanced-firewall and Nat- and change the firewall optimization from normal to conservative.Also take a look here to see if this offers any help.
https://docs.netgate.com/pfsense/en/latest/recipes/nat-voip-phones.html
-
@phming 2000 MTU??
-
@Uglybrian Thanks for your reply. I tried creating an outbund NAT with static port, perhaps my settings are wrong:
login-to-view outbound_NAT.png
source being the phone (SIP client)Timeouts are not a cause I am pretty sure of this. I set conservative optimization and increased UDP timeouts manually.
@chpalmer Curious, right? I reset the device.
I launched the capture before starting the call, it seems like the the first part of the call is just getting dropped silently.
-
Everything looks right to me. I don’t think it’ll help but, try changing your source and destination ports to any and only use one rule. Keep your rules wide open, and once things start to work, then narrow them down.
-
Fix mtu
-
@Uglybrian Yea I don't think NAT rules or firewall rules are causing this. To be certain I opened up UDP any in general for the local IP phone and also set UDP any for the outbound NAT rule -- no change. Like I said already I disabled the firewall completely to test.
@JonathanLee I reset MTU on the pfsense back to default and set 1500 on the bridge, like would be 'normal' or 'expected' but it doesn't help.
I haven't yet tried to configure the modem as a router but if that would solve the problem I could just go back to using the default ISP router. I'm not even sure it's an issue on my end. With other deployments using different ISP I never had such problems. From my experience it seems that only with this ISP you have no other way but to use their devices. There is a tutorial of someone using opnsense in a similar fashion which was shown to work but I doubt that there would be a big difference compared to pfsense.
-
Did you ping test the MTU?
-
@JonathanLee I say yes try the siproxd package. If you need help setting it up I can help you.
The other thing you can try is to force your client device to use static IP.
SIP was not originally designed to be behind NAT. In order for companies like Vonage to start selling to consumers they had to hack NAT into it. It's still not pretty and double NAT could give you twice a headaches if not more.
-
@JonathanLee No I didn't. If you don't mind could you give an example for how to test please.
@chpalmer I'll try to see if it works better with siproxd but I probably won't have time to test until next weekend.
-
@phming Like this
https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on-Router
-
-
thanks I'll give this a try