Have you configured a sip proxy at your settings on the ata. Without the ALG this is needed. (for most providers it is the same like the registrar url.)
Also add UDP rules for the SIP port. Usually SIP try UDP and fall back to TCP.
1 Like
Hello Manfred,
I was using IPFire on a APU1D with a Cisco ATA SP112 (only one) up to IPFire version 154 without problems. The SP112 is connected to my green interface (I know that I should better use the DMZ).
Unfortunately I missed to do any preparation steps before upgrading to IPFire version 155 last Sunday.
Now I recognized that my telephone is not working properly anymore after the IPFire upgrade. I tried to follow your advice concerning the SP112 config settings above as follows:
SP112 Software Version: 1.4.1(SR5)
SIP TCP Port Min: 5060
SIP TCP Port Max: 5080
RTP Port Min: 5004
RTP Port Max: 5008
NAT Keep Alive Enable: yes
NAT Keep Alive Intvl: 5
Redirect Keep Alive: yes
I get a tone tone when I pick up the telephone, cannot dial. Also I cannot be called from outside.
What do I need to change additionally to get my telephone working again?
Thanks a lot in advance.
Best regards,
Ewald
Yes, I have SIP Proxy on the ATA.
Yesterday I spent another hour and a half with my ISP working through everything trying to get it to go, without success. Like @ewald I have a RED/GREEN zone configuration only. I have come to believe that this is the issue.
Therefore I tried to find documentation on how to configure IPFIRE to have a specific IP address as a DMZ, and didn’t find anything, as it appears it requires another physical network interface card. Unfortunately with the hardware I have that is not possible!
With playing with SETUP from SSH I got Orange on a bridged adaptor, but of course that didn’t help, and all firewall rules stopped working. So I reverted the settings to RED/GREEN only. And although the web interface shows all the rules to be valid again, still no rules are working. <BIG SIGH 
>
So today I shall wipe IPFIRE, reinstalling it and setting all the rules up again. If it still fails then I know that my theory of ATA needing to be on the DMZ is correct. If it works then obviously something became too borked in my current installation of IPFIRE.
I have DMZ and yes, it is a separate NIC. I put my Ooma device (which I think is SIP) in the DMZ and all has worked well for the past few years. I have no clue if an Ooma device has the same challenges as the Cisco box.
This is the device I have…
1 Like
Hello again.
Let me add some additional information on my configuration:
-
I have a 3 port IPFire router with a DMZ. However, the DMZ can’t be used (easily) for the SIP without major hardware and software changes.
-
Currently I am NOT using any incoming port forwarding of port 5060 to the SP112 ATA device.
In the forum of my internet provider I found the required setting for a pfSense router:
a) Port forwarding of port 5060 is a wrong and dangerous approach.
b) Instead, for pfSense define an outbound NAT rule as follows:
Select Firewall -> NAT -> Outbound -> "Hybrid Outbound NAT rule generation."
Add a static mapping for the IP address of the SPA112: tick the check box "Static Port".
If you can read German, details can be found here
Question: How does such a pfSense rule translate into an IPFire rule?
1 Like
Hi @ewald ; thanks to you, I struck the solution! For me this worked:
New rule=
Resulting in.
(10.0.2.54 is my SPA112)
I tested incoming and outgoing calls just fine! 
EDIT: just to be clear; I have no idea about the security implications of the above rule. It is working for me in a GREEN/RED configuration.
Thanks to everyone, especially @manfred_knick for chipping in to help here!
Thanks @onyxnz
I am not a firewal guru. However, I regard your new firewall rule as very dangerous: You opened ALL internet traffic to your SP112 IP address 10.0.2.54. All ports are OPEN! Such your SP112 is endangered by any attack from the internet. I strongly recommend to delete this rule.
2 Likes
Hmmm, I had considered as much, so will look at 5060 only.
I would even limit it to your SIP providers proxy. I tried but it did not work for me. You may need also a rule for RTP port(s).
Interestingly, I cannot see in IPFire’s Firewall log (IP) no refused connections of port 5004 (RTP). However, I see several attacks to port 5060!
Try making the rule, reboot ipfire, reboot the spa112…just found that helped.
which rules exactly did you use?
…
Thanks. Would it still work if you you limit the access to the ports UDP 5060 and 5004?
Let me repeat:
In an office sharing environment, I am running
- multiple VoIP devices
- behind IPFire Core Update 155
- implying no ALG
- STUN disabled
- without any rule entry in IPFire → Firewall → Firewall rules at all:
- The CISCO SPA122 serves as a rock-solid 2-line ATA for 2 analog FAX servers.
As proven in a different simpler “Green+Red” environment,
VoIP / SIP from inside “Green” is not an issue at all -
it is only not as secure as isolating the device into DMZ.
BTW:
“Green” does not enforce devices to rely on DHCP necessarily.
Like routers, VoIP devices can and should be nailed statically onto an IP outside the DHCP range
with a fully static [ IP | mask | gw | nameserver (p|s) ] tuple.
I can’t help the impression that - because of too much irritating noise on the net -
people are tempted to meddle too much, irritating plain NAT / Masquerading to map it’s way.
One single VoIP / SIP device is the most simple case one can possibly imagine;
defaults should be sufficient.
If you have more of them, exploit making sure that all devices are statically configured
to SIP / RTP ports being totally unique throughout the whole NAT-internal IP range.
EXAMPLE:
- FAX ATA: IP=x.y.z.5, use defaults SIP = 5060, RTP = 5004 …5020
- Phone 1: IP= x.y.z.8, SIP = 40860, RTP = 40804 …40820
- Phone 2: IP= x.y.z.9, SIP = 40960, RTP = 40904 …40920
- Phone 3: IP= x.y.z.10, SIP = 41060, RTP = 41004 …41020
- …
- Using the forth IP element in the Port numbers helps to memorize
If a more complex SIP phone provides an internal ATA for analog FAX e.g.,
that has to be mapped to one of the configured SIP connections.
WARNING:
- A firmware upgrade of such devices quite often demands
a HW reset to default factory settings first
and a re-configuration afterwards - Changes in configuration quite often demand a reboot at least to take effect
- In some cases, this applies to IPFire as well
2 Likes
You are most likely right, in that I hadn’t until this morning completely reloaded IPFIRE, it has been merely ongoing upgrades. This managed to fix the snafu I introduced yesterday trying to mangle everything into a working state, even through multiple reboots and with/without rules, nothing changed there. So the only way that I can explain it is that perhaps there is something odd on my ISP’s SIP server, that requires a particular port to speak to, and the NAT is shifting that around too much?
Anyhow, it’s now going for me, with only a rule to tell IPFIRE to let the traffic in from the ISP’s server. God help me if some nefarious cracker manages to take that over…but that would be the case anyway.
I’ve now had a good schooling in SIP!! 
Thanks Manfred.
I have currently no additional firewall rules for SIP (same as for core 154). However, I cannot receive any calls with core 155. I followed your config settings of SP112 (see above).
Both my IPfire router and my SP112 are shutdown every night and rebooted in the morning.
In the connections of IPFire I see an established connection from my SP112’s IP address to my SIP Providers SIP proxy IP address port 5060.
However, in IPFire’s Firewall log I see no dropped connections related to port 5004 or any from my SIP Providers SIP proxy IP address.
Do you have any hint where to look at?
Hi, Ewald, welcome!
Is your error description still valid:
If YES, please, digest all three links given in post 2
and confirm the To-Do in the first.
After that, you are welcome to supply your SPA’s
- Network setup → Internet settings
- Voice setup → [ Information | System | Sip | Line_1 ] setup
Hints:
- Firefox offers a right-click to take a Screen photo,
including the option to save the whole page
- for non-public-disclosure, you may mail it to my account
1 Like
Hi Manfred,
Thanks for your great support! I really appreciate that you help me to get my problem solved.
I tried to add several screen dumps below, but the system is allowing me as a new user to add only one media. So I had to delete all except one.
I reconfirmed the items of your ToDo list:
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 !
- Firmware-upgrade CISCO SPA112 DONE => 1.4.1 (SR5) Oct 14 2019, but no reset to factory settings!
- Make sure that all devices exploit their SIP / RTP ports being totally unique DONE
1 have 1 ATA Cisco SP112:
SIP port: 5060
RTP port min: 5004, RTP port max: 5008
-
STUN disabled CHECKED
-
Disabled all ALGs including SIP in Core Update 154 => ALGs are removed in core 155
-
Set NAT Keep Alive Enable: yes CHECKED (see picture below)
Set NAT Keep Alive Intvl: 5 CHECKED (see picture above)
Set Redirect Keep Alive: yes CHECKED (see picture above) -
Final test: Shut them all down → power off; re-start with IPFire, … DONE this morning (every morning)
The other settings I will send to your account.
Thanks again for helping me!