firewalld and Ekiga

Thu Dec 27 21:30:34 UTC 2012

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nella citazione in data gio 27 dic 2012 20:14:20 CET, Jared K. Smith ha
scritto:
> On Thu, Dec 27, 2012 at 1:38 PM, Basil Mohamed Gohar
> <basilgohar at librevideo.org> wrote:
>> Someone with more networking experience than me should probably reply,
>
> I'll do my best to help give some background information here that
> might be useful.  It's probably a bit more than you were expecting,
> but I've taught this topic for a number of years, and figured that
> some examples might be of some use.
>
> In general, the SIP protocol has *two* major problems with NAT
> traversal.  I'll explain them below.  For the sake of illustration,
> let's say that you have a SIP device behind a NAT firewall, which
> we'll call Alice, and it has a (private, RFC1918) IP address of
> 192.168.123.45.  Let's say you're trying to communicate with both
> another SIP device (not behind NAT) on a public IP address of
> 44.55.66.77 -- let's call this device Bob.  Just for the fun of it,
> let's say you also have a VoIP provider (we'll call it
> SuperHyperMegaVoIP) that you'd like to use to connect you to the
> public switched telephone network.  It's at the domain
> sip.superhypermegavoip.com.
>
> The first (but less serious) problem of SIP and NAT traversal is that
> the SIP messages contain IP addresses and ports within the SIP
> messaging itself.  Let's say Alice is trying to register with
> SuperHyperMegaVoIP, so that SuperHyperMegaVoIP knows where to send
> inbound calls to Alice.  Alice sends a SIP message (a REGISTER
> message) to sip.superhypermegavoip.com. That SIP REGISTER message says
> "I'm Alice, I'm trying to register, and my IP address is
> 192.168.123.45.  Assuming that Alice authenticates correctly,
> SuperHyperMegaVoIP saves Alice's IP address for a limited amount of
> time.  Then an incoming call comes into SuperHyperMegaVoIP for Alice,
> and they try to route the call to 192.168.123.45, and realize they
> don't have a route to that network.  In a nutshell, a SIP client
> behind NAT is advertising its private (RFC1918) address, rather than
> its public address.  I'm not an expert on STUN, but what I know about
> STUN is that it's a service whereby a SIP client (such as Alice in
> this example) can find out what it's public (masqueraded) IP address
> is, and use that address in SIP messages instead of its private
> address.  Many SIP registration servers get around this issue by
> recording the actual IP address and port that the REGISTER message
> came from, rather than the one which was reported in the REGISTER
> message.
>
> The second (and more serious) problem of SIP and NAT traversal has to
> do with the way SIP handles voice (or video or other media).  The SIP
> protocol is designed to only handle the messaging of call setup and
> teardown -- the media is described by the SDP protocol, and the media
> is transported using the RTP protocol.  The SIP messages (containing
> the SDP session descriptions) are typically transmitted over port 5060
> (UDP or TCP, but UDP is used more than 90% of the time).  The RTP
> streams are transmitted using high-numbered randomly assigned UDP
> ports.
>
> So let's dive into an example.
>
> Alice wants to call Bob.  Alice sends a SIP message (an INVITE
> message) to Bob.  The INVITE message contains Alice's contact
> information and an SDP section which describes the types of media
> (audio typically, but could include video or other media types) that
> Alice is willing to use in the  call, as well as the IP address and
> port on which Alice is going to be listening for media streams.
> Because UDP is a stateless protocol, when the firewall sees the
> outgoing UDP packet, it records the destination IP and port in a table
> and allows return traffic from that IP and port to go back to Alice
> for a limited amount of time. (And each time another packet goes out,
> the timer on that table entry gets refreshed.)  As long as Alice sends
> a UDP packet to Bob every so often, Bob will be able to respond to
> Alice.  The problem comes in when Bob tries to send audio (or other
> media) to Alice.  Let's say the SIP messages from Alice say that she's
> going to listen for Bob's audio on her port 38719 UDP.  Bob responds
> and says "Sure, I'll send you audio in an agreed-upon format, and I'll
> listen for your audio on my port 44901."
>
> Unfortunately, Alice's firewall knows nothing about this inbound audio
> coming in on port 38719, and is likely to reject the packets outright.
>  (Some firewalls try to use a "fixup" or ALG to be smarter about this,
> but more often than not they only make matters worse.)  The
> traditional symptom for this type of problem is one-way audio.  In our
> example, Bob can hear Alice's audio, but Alice doesn't hear any audio
> coming from Bob.
>
> To make matters worse, there's very little Alice can do to get around
> this problem.  She can hope that Bob is setup and configured for
> symmetrical RTP, where Bob sends his audio back from the same port
> that he's listening for Alice's audio on.  (That's not mandated by
> either the RTP or SIP protocols, unfortunately.)  Alice could also
> configure her firewall to forward tens of thousands of UDP ports to
> Alice, but that's a VERY BAD IDEA.  Obviously you could also use VPNs
> to make Alice and Bob appear on the same un-NAT'd network, but VPNs
> tend to force TCP semantics onto UDP packets, and the encryption often
> adds to latency.
>
> Hopefully this background information helps you understand the SIP
> protocol a bit more, and in particular how the SIP protocol runs into
> issues with NAT firewalls.
>
> --
> Jared Smith

Hi Jared.

Thank you very much for your closer analysis.

If I understood fine, Fedora's firewall allows the outgoing UDP packets
sending from Ekiga on condition that the reply (from "Bob") comes back
in a prearranged time, although it is not guaranteed.
In this way the (Fedora's) firewall setup is not fundamental according
to the ekiga wiki page.

- --
Antonio Trande
"Fedora Ambassador"
"Fedora italian translation group"
"Blogger"

mail: mailto:sagitter at fedoraproject.org
Homepage: http://www.fedora-os.org
Sip Address : sip:sagitter AT ekiga.net
Jabber :sagitter AT jabber.org
GPG Key: D400D6C4
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQ3L36AAoJED2vIvfUANbEoq0P/0eOvI0kuzBEXWIxa48SE9pQ
thhPi6aSWynSghySWId9TQxzW5FVofb99jOiJrxIA6G6odA7/PkEkb0W4CcQksH0
BQu4GrT0pXjmwciX4QfGhBYrWZWUFSrr6CeJ6z2SxpVZGHoaB0gP9Xl6gQ5NL3e/
cGg/lLpLkzNRplmOAFkZ6AWFAHbyoDdA7+2qZmy35fHDSiv5orrF97dsoZN4t4kH
fwIMsXJFKf1t0KyYcEN7D3fa+VH7TuZq+kzUKGpzW5g/b0Uc4W4Jg2K2ZC3U4kN+
oo1h8DdYrTF100eOFAxRbgEILQdVuAjOvWoyb4h4R2Mqh+5OZfKpvzSy3IGZJwYV
yqMGUtiH3yfBEpcDKiwNMmOTLMYg+sOG6VOnW+LOtIk/iCJULOgyuvEWznMX+3dh
U8vtYV/ikhdrcrycEvdJ3YdWOFdj4TqmqYFXcdlR/RFdurfHVymmiVs02hPjOcb2
07+EIEyMe+zKvqw/76sHW1Wo62rY5GVA3IH+PbAO05dFDNbDx3TaJlrMET0bya/5
45sd5O4eWmeZx6oeGVqRHa8MWbTIbHBYxirA19sFXG3/JQFsFuaDtYVP3wZ7r0p+
bnwln3FYzjNqxE1E/uQGY2yYAQYtMtKg5ZrUn8EyufKDnh48Wp9036nIvMNdMekj
07iR9l8BtSOK6dcOLLnE
=pjbd
-----END PGP SIGNATURE-----