DIDWW calls issue call close after 30s with NAT FreePBX

Maybe we can have an explanation why it work fine when I setup local network to 0.0.0.0/1? This could lead to a solution maybe?

That should cause all addresses from 0.0.0.0 to 127.255.255.255 to be treated as not being subject to NAT, so should cause the provider (46 <= 127) to be treated as local and receive your local address, so really shouldn’t work. I’m not sure of there is also an implied local network setting for the network to which your Ethernet interface is connected.

Did you ever follow up on turning off SIP-ALG?

Hi David

Thanks for your engagement! In my firewall thre is no SIP-ALG (PFsense) so I have nothing to turn off.

Nat is set as pure NAT and outbound are with static ports.

The question for me is how that is I have no interruption when I set that 0.0.0.0/1 in if is not something in FreePBX settings that is closing those calls as it was for Outbound when I set up this 0.0.0.0/1.

Thanks

Ionut

By default pfSense firewall settings are not the most appropriate for SIP.

Is your SIP provider using registration or IP based authentication?

You haven’t provided a working case log, or you included both cases in one log without stating you were doing that. The logs I’ve seen were going to fail because of the wrong IP addresses in the Contact headers.

As I’ve pointed out 0.0.0.0/1 makes no sense at all and given that your provider’s address starts with a number less than 128, should be equivalent to not specifying local networks and public addresses.

Your earlier logs showed the source IP address as that of the router, which would only happen if there were a SIP proxy on the router, which implies it is running an application level gateway, although it may call it something else. On the other hand, none of your logs from Asterisk seem to be showing that as the source IP address, which futher adds to the confusion.

Hi Ariel

Provider is using registration not IP base for outbound (user and token) as far as I’m aware. For inbound is ip based forwarding.

Hi David

Not sure what logs you are talking about as at that point we was talking about outbound and interior that are dropped after 30s with 0.0.0.0/1 that I understood that was expected. For inbound drop I don’t think I have send any logs or captures but I can do it if can help.

I would say that we should concentrate on origin of the issue that was inbound drop after 30 seconds with correct local net. Workarround with 0.0.0.0/1 is working, but screw up outbound and interior calls.

I will come back in few min with pcap for inbound drop

Thanks

Ionut

cap7.tgz (2.0 MB)

Have you configured the external address and local networks in section ā€œNAT Settingsā€ under Advanced SIP Settings?

Are you using PJSIP or SIP?

Sorry if those questions have already been answered.

Hi Ariel

Yes I have setup external address and local network in section Nat settings. I’m using pjsip for this lines and interiors.

You haven’t provided a working case log, or you included both cases in one log without stating you were doing that. The logs I’ve seen were going to fail because of the wrong IP addresses in the Contact headers.

As I’ve pointed out 0.0.0.0/1 makes no sense at all and given that your provider’s address starts with a number less than 128, should be equivalent to not specifying local networks and public addresses.

Your earlier logs showed the source IP address as that of the router, which would only happen if there were a SIP proxy on the router, which implies it is running an application level gateway, although it may call it something else.

In your latest, pcap, frame 6979 is being treated as a response to a local network call, so your private address is being sent:

Contact: <sip:172.23.3.112:5060>

That is probably because frame 3609 has come from

Source Address: 172.23.0.1

which is on your local network, and is presumably your router, in which case it is definitely running SIP ALG (under some name). You want simple port forwarding. There should be no 172.23.0.1 column in you message sequence chart.

As part of the same problem it is fairly clear that the router is also transforming the port number.

You can also see this in the Via line, in 6979. The provider has sent without a port number, so they are using 5060, Asterisk has recorded it as 24608, in rport, and also recorded a different address, in received.

Via: SIP/2.0/UDP 46.19.212.14;rport=24608;received=172.23.0.1;branch=z9hG4bKDqjyMa4E
Transport: UDP
Sent-by Address: 46.19.212.14
RPort: 24608
Received: 172.23.0.1
Branch: z9hG4bKDqjyMa4E

This is a router problem, not an Asterisk one.

I’m not sure if this actually possible to configure, but I suppose it could be implementing outgoing NAT in the inbound direction, but only for cases where outgoing traffic hadn’t created an automatic incoming rule. In that case it would be an IP layer, not an application layer, problem, in the router.

Make sure that you have correctly configured firewall rules for SIP

Take a look at this document from the official pfSense documentation

1 Like

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