Thank you for your response.
> Well, it depends, there are a lot of setups where the registrar is
> also proxying RTP. But the main reason why this defaults to 1 is
> because netfilter usually doesn't allow expectations for addresses
> not belonging to the connection since that allows to poke holes to
> arbitrary peers into the firewall. So people should think before they
> enable this and adjust their ruleset to restrict this as far as
> possible.
I agree that it has a potential to be a minor security risk. However,
the entire point of NAT is to allow packets through a firewall. If an
interior host signals that it wants to accept foreign packets on a port,
NAT should not hamper him from it.
This is a very prominent problem. Search google: people everywhere are
whining about this, though most of them don't know the cause.
sip_direct_media=1 simply does not work with the majority of common SIP
scenarios and does not conform to the standard. We have three options:
(A) unsatisying user experience, (b) informing every noob that they need
to set sip_direct_media=0 for their phone to work, or (C) fixing the
default. Option (A) rules supreme today.
Should defaults reflect the most secure possible setting, or should they
reflect the most commonly-used setting? We can have the best of both
worlds, as the default is to leave nf_conntrack_sip/nf_nat_sip out of the
kernel entirely -- secure wins by default. Any user who goes to the
effort to include these modules does so because they want their NAT to be
able to handle SIP connections. My SIP-conforming device opens a UDP
socket and accepts packets from *.*.*.*:* so I don't see why my
SIP-conforming NAT wouldn't also accept packets from *.*.*.*:*.
And thanks for informing me of early media. I was not aware SIP would
allow that, but it makes sense since really only one side of the
conversation really needs to provide an SDP anyways.
> > An observation about SIP failure modes. I have the impression that
> > nf_conntrack_sip almost never intervenes successfully. With my
> > particular phone/provider, it manifest in being able to receive calls but
> > not place them. It turns out this is because my telco uses two totally
> > different servers for incoming and outgoing calls. Coincidentally, the
> > one that is used for outgoing calls blindly sends media packets to the
> > address that I tell it to. However, the one that is used for incoming
> > calls is specifically aware of broken NAT and sends messages to the UDP
> > port that you send from, regardless of what packet was specified in the
> > header. In effect, they ignore the port number that is specified in the
> > SIP transaction because it is so often wrong (due to NAT).
>
> That's usually caused by your client inserting headers that are not
> translated, making the remote side aware that the peer is behind a NAT
> and enabling workarounds. Have a look at the outgoing packets and look
> for untranslated addresses or port numbers. Fixing those should fix this
> behaviour.
Fixing those was the first thing I did and is what resulted in the
off-by-one patch to handle compact SIP. I think you may not be aware of
this particular hack, so I will explain it in more detail. With
sip_direct_media=1 this is what happens.
When I receive an incoming call, I get an SDP payload indicating I am to
exchange media with hostA:portA, and I send an SDP payload indicating I
am at hostB:portB. hostB:portB in this case happens to be correct on the
external interface (the nat mapping is correct), the only trouble is that
the conntrack expectation is for the SIP host instead of hostA.
So the RTP streams on the external interface look like this:
hostA:portA -> hostB:portB - doesn't match expect, ignored by NAT (dropped)
hostB:1024 -> hostA:portA - doesn't match expect, default NAT mapping
gets port 1024 instead of portB.
hostA:portA -> hostB:1024 - remote host has detected that I am not using
portB, and silently switched ports
hostB:1024 -> hostA:portA
hostA:portA -> hostB:1024 ... the communication proceeds correctly
However for outgoing calls, the remote SDP uses a different hostA at a
different data center, and that conversation goes like this:
hostA:portA -> hostB:portB - doesn't match expect, dropped
hostB:1024 -> hostA:portA - port 1024 instead of portB
hostA:portA -> hostB:portB
hostB:1024 -> hostA:portA ....
Since the remote host is always sending to portB while NAT has assigned
me 1024 by default, one side of the conversation is dropped.
This is a result of sip_direct_media=1 interacting with two different
remote RTP peer implementations, even after all of the SIP/SDP fields
have been correctly modified by nf_nat_sip. In the first case, the
connection works even though the sip_direct_media=1 setting is wrong for
my scenario. If you want, I can send you URLs for many threads containing
end-user complaints that exactly match this scenario, most of which went
unresolved. I am using Gizmo5, which is quite popular.
Thanks!
- Greg
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
