This might work, but it must not.
You are counting on a technique, that UDP responses are being forwarded by IPFire to the SPA.
DNS over UPD works the same way.
Problem is, when your ISP initiates an UPD request at some time later which IPFire drops. SPA has a keep alive mechanism to circumvent this, but I would not rely on it.
So my advice is to leave the two forwarding rules in place.
2 Likes
Hi Marco,
thanks a lot again. So far the first telephone calls with the STUN server setting, but without any forward rule in place, were OK. I will observe the call quality and add the two rules as necessary.
Thanks again for helping me (and others with the same configuration) to overcome my telephone problems after the ALGs were removed in IPFire.
1 Like
@ewald Hello ewald
I recommended you if something works without opening from outside to inside (portforwarding), then prefer this way. Iam a big fan from only open if its absolute necessary!
My own experience how Voip works for me since several years in orange, ipv4 only (no CGN)
- without portforwardings
- without ALG (from beginning i never needed this)
- without SIP Proxy
3 Likes
@anon33261557 Thanks Tulpenknicker for your recommendation and sharing your experience.
I share your opinion to use port forwarding only if absolutely needed. In my case, port forwarding is not needed, too. I am listening if my telephone shows any (short) audio interruptions. So far, no interruptions did occur.
Is there any security risk to switch on the SIP proxy inside the SPA112?
@marco: A very nicely written compendium, indeed!
There is only one point where I would like to expand your wording:
Exploiting one (dynamically assigned) external IP, this problem simply does not exist at all.
As proven, with proper distinct SIP / RTP configurations, neither ALG nor STUN are needed at all.
@ewald’s situation seems comparable to a huge housing block with 60 flats,
where the 60 families decide to share a single private class A network 10.0.0.0
and one ISP connection with ‘only’ one single (dynamic) external IPv4.
Any Problem? Not at all!
The SysAdmin will assign IP ranges and disjunct port number groups for each family - that’s it.
NAT and Masquerading will work their way.
BUT in case of Vodafone et al, they want to spare themself this administrative effort = cost.
And the users still expect to “just plug their devices in, and everything has to work out-of-the-box”,
without any ‘configuration burden’ for them at all.
But that comes with a cost:
- disclosing internal information externally
- allowing external techniques to open your firewall → broken by purpose
@ewald, with stun.t-online.de, you have chosen quite a reliable candidate.
But this night I came across a proposal for you to circumvent the need for ALG and STUN:
You can’t really get to know which ports the other guys in your up-to-60-customers-herd are using;
but with a very high probability, most of them are just using equipment defaults and ALG.
So if you are only a little bit prepared to test,
configure your ATA to some not-so-obvious UDP ports, e.g.
- SIP TCP Port Min: nnn60
- SIP TCP Port Max: nnn80
- RTP Port Min: nnn04
- RTP Port Max: nnn20
- Per default, the RTP port range is specified from 16384 to 32767.
I expect NAT to work without ALG, without STUN,
hopefully without port forwarding rules,
at least as long as no other guy in your up-to-60-customers-herd starts
using exactly these same numbers by accident → bad luck for both 
,
but not very probable; and you could re-select a-new in only a few seconds.
I’d like to encourage you to at least test this out, please.
That would clarify the situation for others as well.
Sorry, I have no chance to test that myself (no ‘DS lite’).
In the Vodafone Community Forums, you can find hints how to enforce Vodafone
to upgrade your connection to a (dynamic) exclusive IPv4 or a real dual stack.
Kind regards to NRW.
Thanks again to @marco.
1 Like
Not that I know of. But here I do it the same way. If I don’t need it, I don’t use it. Remember that I can only talk about what works for me. For example, I know that @arne_f has written here and in other threads several times that he needs a SIP proxy.
Right, that completely depends upon your ISP’s / your SIP provider’s demand.
In my case, I use identical “Proxy-Server-Adress” = “Registration-Server”.
In my Vodafone(UnityMedia) case a SIP proxy is NOT necessary.
Here my configuration once more:
- Provider Vodafone (UnityMedia), Technicolor TC4400 cable modem in bridge mode, power upload option (dual stack), TC4400’s WAN address shown is 10.xx.xx.xx, IPv4 address (may be DS lite??)
- Router IPFire core 155, w/o port forward, no open ports, no ALG,
- ATA SPA112 w/ STUN server set, no SIP proxy necessary
- BTW, even for business customers Vodafone does NOT offer in Germany, NRW a fixed ‘IPv6 prefix’, only the IPv4 address is fixed! The ‘IPv6 prefix’ can vary!
A good explanation about DS lite in German language is here
I will test Manfred’s proposal later on.
1 Like
I did now the experiment as suggested by Manfred @manfred_knick
SIP port: UDP 5060 (required by my ISP)
SIP TCP Port: Min 17860 Max 17880 (nnn=178)
RTP Port: Min 17804 Max 17820 (nnn=178)
STUN server set and enabled: Phone works incoming and outgoing properly
STUN server cleared and disabled: No incoming call possible
No port forwards defined in both cases. ALGs not available in IPFire core 155 anymore.
For this experiment, a working STUN server is necessary. Just choosing nnn differently from 080 does not help.
BTW:
@manfred_knick : In the Vodafone Community Forums, you can find hints how to enforce Vodafone
to upgrade your connection to a (dynamic) exclusive IPv4 or a real dual stack.
=> This upgrade is called ‘Power Upload Option’ which I have. I comes with a dynamic public IPv4, real dual stack, and a double upload speed, in my case 20 Mbps. It is a reasonable cheap upgrade. I purchased it since I need a VPN connection from outside which required IPv4 at that time.
Hope this helps. At least, I am very happy to have a working solution. Working with STUN is OK for me.
1 Like
Yes, indeed.
Last unknown combination:
- no STUN
- but port forwards
Could you provide us with the favor of this final experiment?
Thanks a lot!
Just remembered and found your post 57 above containing
and
which displays a private 10.xx.yy.zz address only.
I’m still puzzled 
.
To me, https://ip.zuim.de/ seems to be a good page to test for real dual stack.
Nevertheless:
- Enjoy your phone working again !
Hi Manfred @manfred_knick ,
Happy Easter!
I was able to get a bit more detail on my internet connection type:
The config file of my TC4400 cable modem allows conclusions:
ex-Unitymedia/Vodafone is still using config files as follows:
native IPv4: cust-own_<download_rate><upload_rate>ipv4_sip_wifi-on.bin
Dual Stack lite: cust-own<download_rate><upload_rate>dslite_sip_wifi-on.bin
Dual Stack: cust-own<download_rate>_<upload_rate>_ds_sip_wifi-on.bin
There are some examples for this in the Internet.
My one is of type ‘native IPv4’. Therefore, I do have a public IPv4 address which is dynamically assigned, usually it changes once a day (after reboot of my modem).
Basically, I am an native IPv4 existing customer (Bestandskunde). BTW, this is what I requested ex-UnityMedia when I switched to my private modem TC4400.
However, I do not know whether my IPv4 is tunneled inside IPv6.
At least, this explains above test results.
1 Like
Hi All,
Here the final test result as suggested by Manfred @manfred_knick for my configuration:
port forward red => IP of SPA112 / UDP 5060
port forward red => IP of SPA112 / UDP RTP min : RTP max
port forward red => IP of SPA112 / TCP SIP min : SIP max (? not sure if this is necessary)
STUN server cleared and disabled in SPA112
Result: No incoming calls are possible.
Summary: For my configuration the definition of STUN server is the only working solution.
1 Like