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

Security
23

Little update: I have tried it several times: when I turn ALG for SIP and ALG for FTP = off then I have weird behaviour of my phones and FTP. Calls get cut-off or cannot establish at all (incoming calls). Furthermore I cannot connect to webspace I rent using FTP,. When I turn ALG = on, everything works great. I tried grep helper= /proc/net/nf_conntrack during calls and during ftp-transfers but I never got any output. I will set up a seperate machine to do further tests but I just want to advise everybody to test Core 155 very very carefully. Maybe I just happen to be that 1%
 :woozy_face:

1 Like
24

Have disabled all of those ALGs and rebooted. No problem so far, even FTP (plain/insecure) is still working. And yes, ALG is verified off.

2 Likes
25

@alain: FTP should not affect you if you are the client. It only is a problem when you are hosting the server behind IPFire and a client connects from the Internet. I think this might be a different problem.

1 Like
26

The media is reporting about this :slight_smile:

3 Likes
27

I use a PBX running Asterisk for my business, as I have the call center folks working from home thru a VPN I wanted to get a head start and check, so I disabled ALG extensions and I’m HAPPY to report that everything still seems to work as expected.

Of course you need to test your applications, but everything seems to be OK and I appreciate the heads up given, as I was worried a bit :slight_smile:

4 Likes
28

Well, FTP should be used anyway, insecure, so no ALG should never exists for it anyway. If needing file transfers should always use an encrypted session ssh is a very well established standard on all platforms now even comes with windows 10 if turn the feature on. Being in Enterprise Cyber Security, we block all FTP and any other non encrypted traffic period, never ever allowed if coming to/from internet. even all web services, no port 80, most a re B2B sites so we require the session start with https no 80- redirect on those at all. most VoIP hosting services via Internet have their own proprietary or other means to handle NAT/Firewalls, and most enterprise SIP is via dedicated connection, or other tunnel that will pass through firewalls. Only thing can think of if allowing Phone to establish connections to VoIP host through firewall, we do that on our networks and do not use and application gateways just fine Albeit Avaya VoIP systems. I personally use ooma through IPFire, have others in the past for my home services no issues and have all the ALG’s disabled. Like was mentioned there is no good reason to ever use anymmore, if still relying on them then time to look into other options not to use. IF relying on an external VoIP service and is using the ALG then check with them how to get around that they should be able to. as for FTP, why using FTP via Internet, or even internally ?

4 Likes
29

What about a filter for ALGs like SIP to receive and send data only for special internal IP adresses?
This should fix a lot of listed problems, or?

30

If you use a Fritz!Box in the local network behind the IPFire firewall this might be interesting for you to read:

I have tested several scenarios on different machines with a Fritz!Box inside the local network to provide SIP phone services. You will run into troubles when ALG SIP is deactivated. The connection to the SIP provider is cut-off after a few minutes. With SIP ALG on the connection to the SIP provider will stay alive and everything works like a charm. Contacting AVM (maker of Fritz!Box) resulted in “It’s the problem of the firewall. You better connect the Fritz!Box directly to the internet to avoid the firewall.”

1 Like
31

I never used ALG before. I never needed it. I still use my Fritzbox (for Voip only) behind IPFire without any Portforwardings.

1 Like
32

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:

33

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
34

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.)

3 Likes
35

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

2 Likes
36

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.

2 Likes
37

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:

38

@anon33261557
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.

39

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

40

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
41

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
42

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 !

4 Likes