Core 155 ALG removal: how to see if it's used at all?

Thanks for your feedback. Very interesting. As soon as I turn SIP ALG off and re-start firewall and fritz!box, the connection to the SIP-provider gets cut-off. No matter if Fritzbox is set to share the local network or if it’s set to set up its own subnet. As soon as SIP ALG is turned on, everything is back to normal. Tested with several fritzbox devices. Will do more testing and see if I can do anything about it. Thanks again, your feedback motivates me to do further investigation. Maybe the upcoming new firmware for fritzbox will so some magic too :+1:

Fritz!OS has a horrible SIP stack which is not even slightly RFC-compliant. I have no idea why that is. Either they are just lazy or have no idea, or they need to be as compatible as they can to other broken SIP stacks.

However, they do not care at all about any devices connected to it being in a different subnet than the directly connected one. You should create firewall rules to your phone behind IPFire for SIP and RTP and then you are alright.

Alternatively you could disable NAT on RED, but that might get a little bit more complicated depending on your setup.

Yes, of course networks are a lot easier to manage if everything is just in one subnet and you have no firewalls blocking anything. But then you do not need to lose sleep over whether someone is stealing your data.

Using those behind IPFire is fine and won’t need the ALG. The other way round using telephony is a problem because of the broken SIP stack.

1 Like

That is not correct. If SIP ALG is enabled it will mess up the packets that should send via IPSec VPN. A second reason to remove it.

I know only one scenario that is not working without the ALG. If you have configured a SIP client in the LAN without a proxy. In this case incoming calls will not established. But every SIP provider should have also a proxy. (Most it is the same like the registrar.)


Yes, this is probably more a bug than a feature :slight_smile:


I use it the other way round.
fritz direct to the internet with WIFI and SIP and for more serious work ipfire after the fritz with WIFI for Laps on blue and office PCs on green.
It’s another strategy, but appropriate for you as well.


In no way do I agree with this for several reasons. But this is totally offtopic…

My motivation for my answer above was to show that a Fritzbox is able to use Voip behind IPFire without ALG. Nothing more, nothing less. :wink:

Can you please tell me how you operate Fritzbox VOIP behind IPFire without ALG? Did you have to set up any rules etc. to IPFire?
So far I have simply added the Fritzbox 7490 to my local network (plugging in at LAN1) and in Telefonie, Eigene Rufnummern I set up the 4 numbers I have. They all connect to my SIP provider. And that works great as long as I have SIP ALG turned on. After turning SIP ALG off, the connection to the SIP phone company times out after a few minutes. So nobody can call me.

The difference between ALG on and off is that on IPFire “Verbindungen”: When ALG is on, I see a connection to the SIP provider with a time-out of 59 minutes. And that is getting refreshed to 59 minutes every few minutes. So it never times out. When ALG is off, that connection shows a time-out of approx 3 minutes After a few minutes it times out and the connection gets cut.
I have no deep understanding of internet connections so I was wondering if you need to create some rules on IPFire or if it’s a problem of my SIP provider.

You should first look at the following setting (Fritzbox)

Eigene Rufnummern → Anschlusseinstellungen → Portweiterleitung des Internet-Routers für Telefonie aktiv halten. → 30 Sek.

I cant speak for every SIP Provider but in my case no Portforwardings needed, no special rules.

All what i have done in the Fritzbox is setting above, choosen my SIP Provider enter the settings and it works for years [ without ALG :wink: ]

This doesn’t have much to do with the ALG, but it looks like your provider or your devices are not sending keepalives. This is pretty much default.

You could change your registration to TCP if your provider supports this.

1 Like

Update of my experience with ALG and Fritzbox:
After I have switched off SIP ALG and turned on the 30-sec-Portweiterleitung, re-booted everything, it got even worse. Outgoing calls were fine, but incoming calls were cut-off after ringing twice. Then I switched back to ALG but it would not work either! So I thought it might be a problem between the SIP-Provider and my firewall. Some mess-up with current connections, open ports or whatever. As it was getting late I decided to go home and retry the next morning. But today all is good! Without touching anything telephony now works like a charm and all ALG are OFF. “Zeit heilt alle Wunden”, obviously that’s true for IT as well :smiley:
Thanks @anon33261557, @ms and the others who have contributed for your help! In case others run into the same problem I hope this update can help them too.

1 Like

Reporting SUCCESS: “mini-HowTo” in a nutshell

  • Firmware-upgrade Gigaset DX800A
  • Firmware-upgrade Gigaset S850A GO
  • Firmware-upgrade CISCO SPA122
  • Make sure that all devices exploit their SIP / RTP ports being totally unique
    throughout the whole NAT-internal IP range (they should all reside in “orange”, btw!)
  • Make sure that “STUN=disabled” in all devices
  • Disabled all ALGs including SIP in Core Update 154
  • Final test: Shut them all down → power off; re-start with IPFire, …
    accept calls / FAX from external
  • Ultimately I felt relieved :slight_smile: :

Now I’m positively looking forward to Core update 155

NOTE: No port forwarding rules introduced into IPFire at all !


Works this configuration with incoming calls e.g. 2 days later?

Sorry - I don’t really understand your question.
Or is it a sublime hidden suggestion?

The point is SIP use for each voice direction it’s own TCP/IP connection:

  • one from left client to the right client (or server)
  • one from right client (or server) to the left client.

That was the original reason for a SIP ALG. It’s a protocol out of hell.
Some newer implementations can handle SIP on a not standard way but have often problems with timeouts for incoming calls. This is the reason for my question to you.

I asked a few days ago for a ALG with filter for internal IP addresses to handle this. Specially SIP clients shouldn’t change there IP addresses.

Still don’t understand what you are asking about.

of what, exactly?

Let me guess you mean “their”.
Configured with a fixed IP (orange! ; no DHCP),
my HW equipment does not even dare to dream about changing that …

To cut this short:

  • I tend to test longer than only seconds before posting …
  • And No, I still do not experience any problems at all.
    Otherwise, I would have withdrawn any falsified results.
1 Like

ADDENDUM (in a nutshell, AFAIU):

SIP (static IPs / ports) exploits SDP (static IPs / ports)
which initiates RTP (-> UDP ports) connections dynamically:

  • 1 UDP port (static) as base, plus
  • 1 UDP port (dynamic) for every connection being built up
    (always the next free even-numbered)

Esp. the latter ones are creating the sorrows:
In case you have identical dynamically assigned port ranges on different IPs,
that has been a NAT-confusing ‘problem’ being ‘solved’ by STUN / SIP ALG / IAX etc.

As long as you observe above urgent recommendation to keep separate RTP → UDP port ranges being totally unique, plain NAT can very easily map it’s way from external Port_ID to the one and only internal IP having accessed that port number in it’s use.
Otherwise, without additional specialized header information / specialized evaluation,
it might have no indication available to tell arriving-with-identical-UDP-port packet’s destinations apart.

Perhaps the following (german) background information might help users,
esp. but not only of above mentioned devices:


1 Like


Without “keeping … unique”,
if all you’ve got is the (external) [IP:PORT] tuple in the adress field of the arriving packet’s IP header
and PORT is ambiguous / used on multiple boxes / (internal) IP destinations,
you don’t have any chance at all to solve this
by setting up classical port forwarding rules in the first place:

  • To which of those boxes would you like to specify to re-direct this package then ? !

K I S S :slight_smile: !

This whole business ( TR-069 [!] ; STUN, ALG, … ) has just one goal:

“Just plug them in - and everything works.” (Your ‘benevolent’ manufacturer / provider)

Yes, everything works - but not only for the (credulous / lazy) user :innocent: :

  • Eyes wide shut against all doors open :weary: .

@ms and @bbitsch are perfectly right:
In that case, you don’t need any (linux or bsd based) open-source firewall at all.

Thanks @pmueller for his article:
Security Announcement: Mitigating NAT Slipstreaming

Link: “Strange Invitation” :wink:


Please don’t take statements out of context.

With SIP you have not only a connection from a client to a server.
You have additionally independent UDP connections from the server to the client. And this is behind a firewall a big problem.

If you work with standard SIP, Internet and a firewall in front of your LAN you have two possibilities to get this stable work.

  • Open a lot of high UDP ports (number and quantity varies from manufacturer to manufacturer and from device to device) from the Internet to the LAN SIP client on the firewall
    Here a description of 3CX:
    How to configure your Firewall Router in 3CX Phone System

  • Use an good ALG wich tracks outgoing SIP connections to let incoming SIP connections work.

To minimize the problems a ALG with filter for fixed LAN IP addresses would be the best. This was my request a few days before.

Although not running for more than 2 days yet (ehm),
I very much appreciate that -prepared and upgraded in the way described-
core 155 works flawlessly like a charm for me!

Many thanks @ms and the whole crew behind IPFire !