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

[theunicornxxl]

@manfred_knick

Reporting SUCCESS:

• 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 :

Now I’m positively looking forward to Core update 155

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

[manfred_knick]

@theunicornxxl

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?

[theunicornxxl]

@manfred_knick

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.

[manfred_knick]

Still don’t understand what you are asking about.

@theunicornxxl

Some newer implementations

of what, exactly?

@theunicornxxl

Specially SIP clients shouldn’t change there IP addresses.

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.

[manfred_knick]

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:
[https://www.easybell.de/fileadmin/FAQ/nat-troubleshooting_ger.pdf]

HTH.
Thanks.

[manfred_knick]

NOTABENE:

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 !

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 :

• Eyes wide shut against all doors open .

@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”

[theunicornxxl]

@manfred_knick

Still don’t understand what you are asking about.

@theunicornxxl

Some newer implementations

of what, exactly?

@theunicornxxl

Specially SIP clients shouldn’t change there IP addresses.

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.

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.

[manfred_knick]

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 !