Inbound calls not reaching FreePBX (Nothing in sngrep either)

FreePBX Providers
, , ,
81

Because it is pfSense and pfSense handles SIP poorly. Step 1 is simple, provide a PCAP from pfSense for an incoming call from the provider. Let’s make sure it is hitting pfSense and pfSense is actually sending the request through.

82

I think PfSense backup is simple.. make a backup export out. wipe FreePBX rules and make a NAT 1:1 or direct connection. FreePBX Firewall will take over security. ( This is ONLY for Test purposes )

83

Part of the problem is pfSense not handling the NAT for SIP to begin with. Let’s validate actual details first before we start offering suggestions of reinstall the PBX OS or hacking away at the firewall of the rest of the network.

84

Hi @BlazeStudios i just made suggestion to make a backup for his PfSense.. instead of re-install FreePBX. Let’s see details from @AlexMHz
By the way, I have up and running 3 Pfsense for different locations and i never had that issue. Must be PfSense side setup or configuration side issue.

85

PCAP from pfSense shows a few INVITES from numbers and IP addresses I don’t recognise.

If I narrow it down to Telephony/VoIP calls in Wireshark, I see this:

86

This isn’t a PCAP, can you not get a capture at the pfSense? And can you put this in a paste bin to make sure the forum isn’t formatting things weird.

87

However, it seems when I make a call inbound, the PCAP shows there’s fragmented IP protocol.

1 0.000000 VOIP.PROVIDER.IP WAN.PUBLIC.IP IPv4 1496 Fragmented IP protocol (proto=UDP 17, off=0, ID=9134)
2 0.494503 VOIP.PROVIDER.IP WAN.PUBLIC.IP IPv4 1496 Fragmented IP protocol (proto=UDP 17, off=0, ID=915b)
3 1.494570 VOIP.PROVIDER.IP WAN.PUBLIC.IP IPv4 1496 Fragmented IP protocol (proto=UDP 17, off=0, ID=9248)
88

This is what I want to see a PCAP. We need to see what is in the messages.

Also, what type of Internet connection do you have? Specifically, are you using PPPoE for it?

89

Correct. The internet connection to us is via PPPoE (Username and Password authentication)

The ISP is the same as our VoIP provider.

The first frame in the PCAP shows this - Pastebin

90

Had made two similar requests prior

Thought they said Opensense, but would have been easily translated to pf equivalent. But yeah good to see a more experienced hand take charge

91

It may have confused matters and I apologise, but at that time, I decided to do a fresh install in a different office in which OPNsense is running - I understand it is a fork of pfSense but I thought I’d try it since I had no other ideas at the time.

I have since abandoned that idea and have been running tests where the PBX was originally working and is meant to be staying.

I really appreciate your efforts in this @airsay and sorry if I’ve confused anyone.

Hopefully my latest pastebin can shed some light on the problem @BlazeStudios

1 Like
92

Alright, I still need to see the actual SIP packet. You’re having an MTU issue as the SIP packet is 1496 bytes and PPPoE has a maximum MTU of 1492. PPPoE encapsulation adds 8 bytes to the packet.

Basically, any packet with a size larger than 1492 bytes can cause fragmentation over PPPoE connections. You’re receiving packets that are 1496 bytes which is over the limit and thus packets are fragmenting.

The reason I want to see the packet is to see how much is in the packet. Extra headers or a large SDP body can increase the packet size. You didn’t have to touch anything, your carrier could have made an adjustment like add headers or additional codecs to the message which increased its size and started to cause the fragmentation.

93

Hi Tom, You are saying that, @AlexMHz mentioned change was happened at ISP side?

94

This is the packet from the first SIP frame. Let me know if you need more, as I believe the other two are exactly the same.

95

I have contacted the VoIP provider initially before this thread and they say they’re sending data to the PBX but they’re not getting any response back such as 200/180/130, etc.

Now that I think about it, with what @BlazeStudios said, if they’re sending fragmented data - or it becomes fragmented as a result of the size - then it won’t be able to reply back. Am I understanding that correctly ?

Do you think it would help if I removed codecs and tested it again with one or two main codecs like alaw and ulaw ?

I have access to the control panel for the VoIP provider, although not a lot can be changed there, I know codecs can be disabled/enabled there too.

96

That doesn’t look like an abnormally large packet at all. What’s the MTU settings you are using? Just keep in mind at this point, this is an MTU problem. Could it be bad MTU settings on the firewall? Possible. Could the firewall be fragmenting when it shouldn’t? Possible. Could it be something with the ISP? yes.

But this is now a networking related problem.

97

If it gets fragmented, and you have a firewall that is only letting through certain port numbers, the continuation fragments will be lost. If that happens, the whole packet is lost.

98

Yes, they are being fragmented for some reason. Could be bad MTU settings. That’s why there is no reply and they see a timeout.

You could try that. It would reduce the packet size.

99

The packet shown is truncated. That’s either because it is has been fragmented, or because the packet capture truncated the captured copy. The last line is

a=fmtp:10

when it should be

a=fmtp:104

and followed by more on the same line, and, potentially, much more on following lines.

Also, the redaction will have affected the length, although that is more likely to have made it longer, than shorter.

100

I believe it is set to default. Normally 1500 but it drops down to 1492 due to the 8 bytes for the PPP/PPPoE header.

Don’t think there is much I can do regarding that, but I can certainly attempt to lower the packet size with a codec change.

I’ll let you guys know once I’ve done that