VoIP client behind pfSense on German Telekom ISP
-
On incoming calls, the C430 phone does not ring, but the person calling can hear it ring on their side.
That's because a SIP connection is not possible to your phone.
On outgoing calls, the C430 phone does not ring either, but the person being called can hear their phone ring. If they answer the phone, the C430 acknowledges that a call is taking place, but there is no audio either way.
Cause: SIP works outbound but RTP does not work in any direction.
On incoming calls I can see a lot of packets being dropped by the firewall on ports 5000-5010, which are not even listed on Telekom's support page as ports that are required for VOIP.
The Telekom support page does not list the ports used by your phone! These are in your manual (in the German one on page 142, please search for the VoIP settings in the manual). It's 5004 to 5020, SIP is set to 5060. You can change these ports but there should be no need.
The phone should work. I have a similar setup but due to lack of a C430 I cannot verify this. But please try (and give feedback here if it works or not!)
What you need is:
-
Give the phone a fixed IP (either by function of the phone or with phSense). Let's assume this is 192.168.1.10.
- In pfSense in Firewall: NAT: Outbound add a rule on your WAN-Interface, Source = 192.168.1.10, NAT Address = WAN address, static port = yes.
-
Create 2 entries in Firewall: NAT: Port Forward:
If=WAN, Proto=UDP, Src./Src ports = any, Dest. addr = WAN address, Dest. ports = 5060, NAT IP = 192.168.1.10
If=WAN, Proto=UDP, Src./Src ports = any, Dest. addr = WAN address, Dest. ports = 5004-5020, NAT IP = 192.168.1.10 -
In the Firewall outgoing traffic must be allowed (if it has been restricted at least):
Proto = IPv4 TCP/UDP, Source = 192.168.1.10, Dest port = 5060
Proto = IPv4 UDP, Source = 192.168.1.10, Source Ports = 5004 - 5020, Dest / port = any
No need for STUN btw. with this setup.
You might want to have the phone regularly renew connections. I did not look this up in the phone's manual however.
Hope this helps.
-flo-
-
-
Hi -flo-, thank you for your help in getting this sorted. I have a few doubts, still.
On incoming calls, the C430 phone does not ring, but the person calling can hear it ring on their side.
That's because a SIP connection is not possible to your phone.
My understanding was that ringing has nothing to do with SIP. Also bearing in mind that when the callee answers the C430 acknowledges that the call was picked up on the remote site (seconds into the call start counting on the display) wouldn't that mean that SIP is working fine?
The reason why I haven't created an NAT rule for SIP was because the phone sends NAT keep alive packets which I thought should keep the NAT mapping open. Unless there is more than one server on Telekom's side sending SIP packets, which would get blocked by pfSense since the source IP wouldn't match the one on the existing mapping, why would an NAT rule be required? Isn't the keep alive packet enough?
As for RTP, outbound RTP had no reason not to work, in my attempt to get this working I reset pfSense to factory defaults and the C430 phone was on the LAN with the default IPv4 to any and IPv6 to any rules. Even if it was getting blocked, I'd expect something to show up on the firewall, which it didn't - not for outgoing calls anyway. The same should be the case for inbound SIP, if the firewall is blocking it I should see something on the logs, but nothing ever appears there.
I'm not disagreeing with you in regards to your configuration suggestions by the way, I'm just trying to figure out exactly why this happens the way it does.
After posting here yesterday I tinkered around a bit more and all I did was disable STUN on the C430A IP, and things just started working. All of a sudden both outgoing and incoming sound were working fine, phones rang and I could hear it ring when I called someone. Everything just worked! But it doesn't make a lot of sense.
Correct me at point I'm mistaken, but my understanding is that when the phone first registers it sends some data over the SIP port (5060), which pfSense converts into a random port for the NAT mapping (let's say 12345). So when it gets to Telekom all they see is my public IP address sent some SIP data on port 12345. Now Telekom obviously don't restrict the SIP port, so they accept it and keep a record of where to reply to for SIP data, so any SIP data they send back to me will have a destination port of 12345, which allows pfSense to be able to check the existing NAT mapping and redirect it to my C430 phone on port 5060. Because of the keep alive, that mapping will be kept open and Telekom will always reply send SIP traffic on port 12345. This is what allows SIP to work.
Now the part that's a bit hazy for me is the RTP side of things. So in the example above the phone is now registered. At this stage, if I initiate an outgoing call, because there is an IPv4 to any rule, the phone itself can make RTP outgoing connections and so long as Telekom replies on to the same ports, outgoing calls will work just fine as it is an outgoing connection.
However, what about incoming calls? Surely when an incoming calls occurs there is no RTP ports with a mapping made on pfSense. Even if there is, I wouldn't expect it to be the full range of RTP ports used by C430 (5004-5020), so how will the server know on which port to initiate communication on?
Slightly more puzzling even, is why is there a list of over 2000 RTP ports listed by Telekom on their website that need to be opened for incoming traffic? Surely there are the ports they use to send RTP info on, and therefore should be opened?
But as I said, so far everything seems to be working fine with just STUN disabled and no firewall/NAT rules at all!
Even more puzzling still, using their HomeTalk app, which should be "just another VOIP client", without opening any ports at all everything just works out of the box, so why does the configuration of the C430 differ from that of the HomeTalk app (ie, do nothing)?
Again, I'm not disagreeing with you on anything you've written and I really appreciate the help, but I'm just trying to figure out how this works and why some configurations work and others don't.
Thx,
cogumel0 -
Right, I've just been informing myself more about how VOIP works, and it seems that the RTP ports are negotiated in the SIP header as needed, so that would explain why there are no permanent mappings kept open.
However, not having port forwards for the phone should still cause problems with the phone (and the HomeTalk app), since in the SIP header the phone would say "I'm using port 5004", but the firewall wouldn't have a mapping for that port so drop the packets (since it would change the outgoing port from 5004 to another port).
But I read that what some providers do is rather than "respect" the port that the client says it will communicate on and send packets to that port, it just waits to see what the real port used by the phone is (or the router since the router will re-write it) and just reply to that one instead. It sounds like a rather easy "hack" to implement on their side and it would definitely fix any NAT issues.
This would explain why the HomeTalk app works out of the box and just disabling STUN on C430 works too without having to do any firewall rules.
It would be interesting to confirm this by doing some packet capturing, or if someone that has port forwards for the VOIP client (no 1:1 NAT though obviously) to confirm if they actually see any traffic coming in on those ports.
-
First of all: Glad to hear your phone works! That's most important.
Now I don't fully understand how this can work the way you describe.
The static port and the forward for SIP may actually be redundant if the phone can keep the connection open. If the phone should fail in that regard the port forward with static port however is your "safety belt".
Regarding the RTP ports: Yes, within SIP the RTP ports are announced. So there will be an incoming connection on one of the RTP ports which has no connection already open. This requires to have port forwards open. The trick you mention which some providers seem to employ does not sound reasonable to me: Afaik there is always a pair of RTP ports required for each call: One source port for outgoing and one target port for incoming data (two streams). I was thinking that there must always be an incoming RTP connection on outgoing as well as incoming calls. For the incoming connection there must be a port forward.
If it really works the way you describe I must have missed something. In the end all that counts is that it works. ;D
Regarding the ports Telekom mentions in their support page btw: They do not exactly specify but I guess these are source ports from their servers. In my setup I do not filter these so they could use any ports they like.
-flo-
-
Hi -flo-,
Just been doing a bit more reading around this and it seems like Telekom uses Symmetric RTP (http://www.voip-info.org/wiki/view/RTP+Symmetric) which means only one port needs to be open for both incoming and outgoing RTP to work. So while you still have two RTP streams, they are now using the same ports, so they can be almost considered as one stream.
So to summarize, when there's an incoming/outgoing call, the phone and Telekom negotiate what RTP ports to use in the SIP header. There they also agree to use Symmetric RTP (which must be supported by the telephone). At this point Telekom still can't send any RTP packets through because there's a firewall in between with no NAT mappings for the port Telekom expects to be able to send RTP packets to (and receive from, since it's using Symmetric RTP).
But the moment the phone sends an RTP packet out, Telekom can see what the real port it was sent on (router port) and reply back to that port, which will redirect it to the phone on the port the phone expects to receive packets on.
That way, you don't need to open any ports at all and everything just works. All configuration is done on Telekom's side and works behind any type of NAT even without a STUN server or port forwarding. This is the similar to what Skype uses I've been told, and that works flawlessly without any port forwarding too.
-
This is a very interesting information and it explains how some setups can actually work! Thanks for the detective work! :-)
Do you have a source for that information regarding Telekom apart from the mentioned link?
So the bottom-line is: Telekom-only customers can use a very simple setup. It would be an interesting thing however to know which SIP provider uses the same technique. I have for example two other SIP accounts that may not work this way.
-flo-
-
No proof that Telekom works this way I'm afraid, but it's the only theory I've heard that explains things.
I know for a fact I have no port forwards, either for SIP or RTP and things just work seamlessly. However when STUN server was enabled they were a bit iffy. That's because of the NAT type used by pfSense.
In order to confirm this a network capture would be required. The SIP header would state whether symmetric RTP is being used or not and you could then see what port was negotiated for RTP and what port Telekom is actually replying to.
Not sure if Telekom would be willing to confirm this theory either.
-
Thanks to all of you for this informations. I had trouble with exactly this configuration all time after Update to pfsense 2.2.
I can confirm that it works perfectly when STUN is disabled. No need for Portforwardings or special NAT configuration.
What I am intressted in is your "Firewall Optimization Options" under System -> Advanced -> Firewall/NAT.
Did you leave it default (normal) or did you set it to "conservativ"?Regards,
Marcel -
It looks like, that there is still a problem.
My wife (who else …) told me that calls are going to crash after exactly 15 Minutes.Does anyone has an idea why?
-
It looks like, that there is still a problem.
My wife (who else …) told me that calls are going to crash after exactly 15 Minutes.Does anyone has an idea why?
Your wife is talking to the internal answer phone and after 15 minutes it is full, perhaps?
Ok back to the topic.In normal as I am setting up VOIP equipment it follows even three main ways to do so.
- Working with a STUN Server
- The router or Firewall comes with an internal SIP-ALG
- I am Using a VOIP Gateway, VOIP appliance or a VOIP PBX (all the same) in the DMZ
In normal you want to be secure your LAN (local area network) and don´t open ports on
the front side (WAN) so no ones can enter like she want, there fore the routers or firewalls
are doing SPI/NAT and nothing that was called or requested from the LAN will be going in!
But VOIP is like a telephone and for sure peoples like or want to call you from the outside
without that you request this phone call, right? So now you are building a DMZ and placing
there let us imagine an Asterisk VOIP PBX appliance, then you are able to open ports on the
WAN side that are matching the given or offered service at the Asterisk PBX, and now you are
able to connect them from outside (Internet) and from the LAN side, thats it. Ok instead of the
Asterisk you are also able to use a VOIP Gateway from the Germany T-Com without no problems.You can also place the VOIP PBX Apliance in front of the pfSense without problems as I see it right
VOIP PBX –- PoE Switch --- VOIP Phones that is also very easy to use.For a dedicated help or guess it would be even fine if someone draws a small network layout
that we all can see what kind of devices where in the game and where are the placed.
