@michaelschefczyk wrote:
Dear All,
I have been using FreePBX 12 in a two location SOHO situation with NAT behind static IPs for some years. Luckily, I did use a warm spare setup with two furhter machines in a virtualization environment with substantial backups as a standby reserve.
A week ago, I did upgrade the machines to FreePBX 13. Initially, things went fine. By an upgrade entering the repository not long before November 14, 2015 12:00 EST (I very much suspect the fix of FREEPBX-10691 in core 13.0.10), I ended up with calls no longer working.
Luckily, I could switch to my warm spares after scaling them back to FreePBX 12. Not so good and very time consuming was, that I did reinstall the main (non virtualized) machines from scratch only to find the same problem again.
Many hours later, I did a packet trace on my main pfSense router. To better unterstand the network architecture: I have in each location a dual WAN with DSL and CATV. The telephony provider can only be reached via DSL. The IPs are static but he connection device does impose another layer of NAT. I have a hard time formating the traces well in this interface, but they can be found in my dismissed bug report: http://issues.freepbx.org/browse/FREEPBX-10770
The problem starts with the "100 Trying" step in the Wireshark flow of calls.
In the working scenario, the message header starts with (where 192.168.1.10 is the LAN address of the FreePBX server and XXX.XXX.XXX.XXX is my fixed DSL external IP):
Via: SIP/2.0/UDP 192.168.1.10:5060;received=XXX.XXX.XXX.XXX;branch=z9hG4bK78fe8deb
In the non-working scenario, the message header starts with:
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;branch=z9hG4bK736507bc
Thus, it is no longer Sent-by Address = LAN and Received = WAN, but Sent-by Address = WAN - the latter does not get back to the FreePBX device. This cannot be cured by relaxing firewall rules.
Please verify if this is indeed a consequence of the core module update and how one should deal with it.
Regards,
Michael Schefczyk
Posts: 2
Participants: 2