With Firewalld I’m not able to get my SIP-client (Ekiga or Linphone) connected to the SIP-Server. I allowed the rules SIP and SIPS to pass through, but it never connects. With 42.3 on a different machine I have no issue connecting to the SIP server, with the same account. I’ve been fiddling around with zones, allowed applications and what not in Firewalld, but I’m not able to get the configuration set-up right to get either client connected to make calls.
Can somebody help to set up the firewall, so that I can connect to SIP without having to go through the different machine?
The settings have been applied permanently. I notice a lot of zone and I assume that ‘public’ is the best one to use. Albeit I added the rules to all zones in the hopes that this should work. After stopping the Firewalld Ekiga is not connecting to the SIP service. The exact same set-up for the accounts on a different machine with 42.3 works without issue.
Are there any other suggestions to try, as I still need to rely on opensuse 42.3 to use Ekiga and with Tumbleweed I’m not able to get connected to the SIP server.
In general,
SIP is not well supported by NAT, to make SIP work with NAT you may need a “helper” proxy… Once upon a time SIP proxies had to be installed on the edge node (your machine with firewalld and your NAT running), but nowadays SIP proxies can be found on the Internet. If you use one of these, follow their instructions.
Else,
Configure your SIP client with a public IP address (no NAT) and open up the appropriate ports in your zone.
I don’t really follow your comment. I have Ekiga set-up to connect to a SIP server for outgoing calls. With my Tumbleweed installation Ekiga is not willing to connect to the SIP server (on the Internet). With 42.3 the same account under Ekiga can connect. In firewalld I have set SIP to be allowed through, but this is not working. This approach did work with firewall2 with 42.3.
Thus laptop with 42.3 no issues to make outgoing calls.
Desktop with TumbleWeed not able to connect to make outgoing calls.
Verifying,
I are saying that you have 2 different machines on your network, a TW and a 42.3 each with ekiga installed, you can make outbound calls using your 42.3 but not with your TW. These two machines exist at the same time, so for instance this is not a machine that dualboots TW and 42.3 or a machine which was upgraded from 42.3 to TW… In both of these cases only one machine running ekiga is present on your network at a time.
If the above description is accurate,
Then the problem is likely in your TW and not a firewall issue.
If the above description does not describe your situation (eg one of the two latter described scenarios), then your situation needs more analysis.
In any case,
My personal experience has been to set up fully functional SIP clients, not one-way calling as you describe. If your clients are set up behind NAT without a SIP proxy, that breaks location awareness and I’m not sure how that would affect VoIP services running on top of SiP… It’s certain no inbound connections would be possible, and it would also mean that a sustained session would be required, vulnerable to interruption.
After some additional thought,
I’m going to guess that any SIP rules are intended mainly for inbound connections from the untrusted side of the firewall (Internet0.
I’m going to guess that you have assigned an inapproriate zone to your LAN network interface,
What is it set for currently?
Yes it are 2 separate physical machines, my desktop (TW) and my laptop (42.3). And yes Ekiga runs only on 1 machine at a time.
Ekiga needs to be able to connect the “Ekiga Call Out” service on an external server in order for me to make VOIP calls.
My current zone active is “Public”.
Ok as trial I have tried Linphone, connecting the same SIP/ VOIP account to the same VOIP server. Linphone is able to connect without issue and I can make outgoing calls. Perhaps I just have to ditch Ekiga. Too bad as the VOIP provider I use sponsors them based upon my Ekiga call usage.
If this is related to TW, I seem to be the only one having issues.
Submit an issue directly to ekiga.
TW is on the leading/bleeding edge of technology so may have implemented something that causes ekiga to fail.
Let ekiga figure it out.
When you say you connect to an ekiga server, I’m guessing it’s that server that is functioning as your SIP proxy…