Hi Manfred,
That’s OK. It is the ‘private’ IP address of my modem of the ‘local’ Vodafone cable network CMTS (CM Termination System) only. This is translated ‘somehow’ to my public IP address by Vodafone.
I’m using several SPAs behind IPFire without any problems. ALGs in general are theoretically a good thing, but may practically cause different problems.
So cleanest is to turn them off - or even better completely get rid of them as in core 155.
That being said, you have two options to avoid VoIP NAT problems: Use STUN/ICE or plain port forwarding.
In my case port forwarding is working fine, it’s strait and clean.
Create two firewall forwarding rules:
Red (UDP) 5060 → Green SPA-IP 5060 for SIP traffic
Red (UDP) RTP-Start : RTP-End → Green SPA-IP RTP-Start : RTP-End for RTP traffic
Use SIP over UDP transport, TCP may cause trouble with some ISPs.
The RTP range is setup in Voice / RTP Parameters menu, enable RTP symmetric in Line menu. A port range of 100 is a good default (mostly more than enough).
Hi Marco,
Thanks a lot.
Red (UDP) 5060 → Green SPA-IP 5060 for SIP traffic
Red (UDP) RTP-Start : RTP-End → Green SPA-IP RTP-Start : RTP-End for RTP traffic
Source or Destination NAT?
Can I limit the forward NAT rules to my ISP’s proxy?
I tried these two forward NAT rules, however no success. Still no incoming call 
RTP symmetric in Line menu is selected.
I do not get any logs in IPFire’s Firewall log for ports 5060 or 5004 despite I selected log???
It’s Destination NAT (change the destination IP from FW-IP to 192.168.1.5 in this case).
I limited the SIP source location to DE, in my case German Telekom is the provider.
RTP source must be ‘Any’. Port-Range must be the same as setup in SPA (its IP is 192.168.1.5 here).
Result should look like:
You might, but it’s often difficult, cause you have to know exactly the origin net or server address of you provider. And their values may vary.
In case of German Telekom you can limit SIP to match 217.0.0.0/8 but if the Telekom changes this, its a problem.
If SIP is done/setup right, you don’t need further security filters, using “Location:DE” just prevents all the noise from mostly African/Russian SIP scanners.
Hi Marco,
I tried now these two rules:
that should be in line with yours.
No success! Still no incoming calls possible. Interestingly, I cannot find any log information in IPFire’s Firewall log for the SIP/RTP connection despite having ticked the ‘log’ click box.
You need to check if your SPA is registered at all, look in the Voice menu at Line 1/2 Status.
Registration State: Registered
Thanks for your hint. My ATA is registered:
However, RTP Bytes Received is 0! See attached picture.
How can I log the SIP/RTP traffic in IPFire? I.e. all traffic to the SIP/RTP ports?
IPFire not need TCP for SIP. I use telefonica they use also UDP only. The sipclient must keep the connection open. (keepalive) In my Fritzbox there is an option that i have set to 2min (5 min was too long)
For RTP i have needed an outbound SIP Proxy. (same as the registrar) with this settings.
i have no rule in the firewall for SIP telephony.
Hi Arne,
Thanks.
Did you mean such a setting:
I tried it.
Without forward NAT rules:
No incoming calls possible. Outgoing calls are OK.
With forward NAT rules (see above):
Same:
No incoming calls possible. Outgoing calls are OK.
I set NAT Keep Alive Intvl: 2
Is your phone ringing on inbound calls?
If no: SIP problem, but strange, because SPA is registered
If yes: You have no audio, just in one direction or both?
On outbound calls: Audio possible in both directions?
Is your phone ringing on inbound calls? No
On outbound calls: Audio possible in both directions? No, only in outbound direction. Inbound no voice.
Please note that RTP Bytes Received is 0! see above. Therefore, no inbound audio nor ringing. But why?
How can I track (easily) which SIP messages are send by my ISP to the RTP ports?
I had to downgrade to 154, to many problems otherwise.
Hi @raffe,
Thanks. I want to avoid this. Hopefully we can identify and fix the root cause of my problems.
Downgrading isn’t that easy for me. My last backup is some versions old 
Exactly: No public (dynamic) IP address has been exclusively assigned to you.
That’s right again.
DS Lite
…
DS Lite steht für Dual Stack Lite und ist eine Tunneltechnik. Das heißt: Jeder Kunde hat ein öffentliches IPv6-Präfix, also mehrere IPv6-Adressen. Zusätzlich nutzen bis zu 60 Kunden zusammen eine öffentliche IPv4-Adresse. So kann jeder Kunde sowohl IPv4- als auch IPv6-Dienste nutzen. Gleichzeitig werden die selten gewordenen IPv4-Adressen gespart.
[ Wissenswertes über DS Lite - Vodafone Community ]
Many more hints available by a simple search in
google.de → “Vodafone DS light” (restrict to ‘last year only’)
1 Like
Hello Manfred,
Thanks for your explanations. All your arguments sound reasonable to me that I seem not to have a real IPv4 address. Unitymedia sold it to me as IPv4 :
I got a written confirmation like this '… und IPv4 Anschluss bleibt erhalten".
What does it mean to solve my problem?
Is there any IPFire core 155 user with Unitymedia as ISP, a Dual Stack Lite connection, and an ATA SP112 working behind the IPFire firewall?
Christian Morgenstern - “Die unmögliche Tatsache” :
Weil, so schließt er messerscharf,
nicht sein kann, was nicht sein darf.
Kind regards
Manfred
1 Like
Either live with it, and open the required (UDP) ports,
or upgrade your ISP contract.
As usual:
- You get what you pay for.
Personally, I decided to pay for a business connection by M-Net (Munich)
which even provides a static IPv4 
,
circumventing all of those problems initiated by “Geiz ist geil”.
From the experience with one of my customers in Bergisch Gladbach,
I humbly propose to look into serious contracts with NetCologne.
They offer cheap DS Lite - right;
but AFAICR they also offer connections on serious basis.
The weighing of interests is completely up to you.
1 Like
@ewald, okay, that all makes perfect sense, let me explain what happens here. Thanks for the details.
You have a typical VoIP NAT problem.
First of all, for your understanding, VoIP consists of two parts, signaling and media, signaling is done via SIP while the media (audio here) is done by RTP. Dialing, ringing, answering, forwarding, registration, all is handled by SIP, mostly using UDP on port 5060.
Once a connection is established between two partys, a media stream flows between the two endpoints using RTP on negotiated ports.
What is happening in your case?
Your SPA is registering itself at the ISP using SIP over UDP.
All it can do is to tell your ISP, “Hello I’m here and my IP is 192.168.1.5”. Your ISP sends an answer via UDP from where it got the request. Because IPFire has a port forward rule on port 5060, your SPA will receive this answer. So far, so good.
Outbound signaling works fine, this is like registering, you will receive an answer from the ISP.
But you won’t get any inbound calls, because your ISP just knows your SPAs internal IP, which the SPA has registered, but which can’t be reached, of course.
What your ISP should/must know is the external IP, the IP of IPFire’s red interface.
Media (audio), is pretty much the same, your SPA sends RTP to the ISP, the other party can hear you.
The ISP sends its RTP to the registered address, which is (again) your internal one. You won’t hear the other party.
An ALG “sniffs” all SIP messages and replaces the SPAs internal address with the external IP, so the ISP knows where to send SIP and RTP packages.
Replacing SIP IPs correctly, is often challenging and not all ALGs did it the right way.
But you don’t have an ALG anymore, so you need to setup a STUN server as alternative. Basically the STUN server helps the SPA to get/know its outside IP.
This is done in the SPAs SIP menu under “NAT Support Parameters”.
If your ISP has no own STUN server, just use a free one.
In your setup, using a STUN server is nearly the only alternative, I can see.
You can track/log SIP messages on IPFire using tcpdump on the CLI.
Google “tcpdump SIP decode” for parameters and instructions.
Install tcpdump as Addon.
3 Likes
Hi @marco,
You are great! It is working now 
Many, many thanks!
Adding a STUN server did the trick:
Now my phone works again without (!!) any additional forward firewall rules.
The solution is so simple.
Thanks again for your good explanation and your decisive hint how to solve my problem.
Happy Easter!
1 Like