On 6/17/11 1:12 PM, Jonathan Bennett wrote: > On Fri, Jun 17, 2011 at 1:56 PM, Philip Prindeville > <philipp_s...@redfish-solutions.com> wrote: >> On 6/17/11 9:35 AM, Jonathan Bennett wrote: >>> Phillip, >>> What would be the advantage of ipsec over OpenVPN? >>> >>> In my experience, if you have Asterisk deployed, the call is >>> routed through Asterisk, which handles the Nat traversal fairly well. >>> Are you describing a sip re-invite, where the local phone connects >>> directly to the remote end? >>> >>> ~Jonathan Bennett >> >> Well, I know a lot of hotspots (hotels, airports, etc) that don't handle >> OpenVPN SSL... or even at all. > What do you mean? I've gotten OpenVPN through some very hostile > environments (a network that allows *only* web browsing, and that > going through a forced proxy and web filter). It uses a single tcp or > udp connection, which means it can get out through most any network. >> >> Also, IPsec QoS marking is easier to handle than mixing several protocols >> over an SSL stream all with the same markings. > I can see the advantage of true QoS, though. I would imagine that > IPsec would be more efficient, too. >> >> One thing I like to use IPsec for is running SIP to my soft client on my >> laptop or even to my iPhone. > Agreed. That's a nifty use. >> >> As for Asterisk, it handles NAT fairly well *unless* Asterisk happens to be >> running on the machine providing NAT mapping itself (i.e. on your firewall >> appliance). Then... not so well. > > Hmm... That's exactly how I have a server set up. I maintain a small > network at a church, and we have an Asterisk phone system. We use a > remote Sip provider for incoming and outgoing calls. It works because > Asterisk can talk to the provider without going through the NAT. It > has the public IP on one of its ethernet ports. The disadvantage is > that a bunch of UDP ports are open. I've always seen that as a > downside of SIP.
That's what I'm saying. If you look into the INVITE messages (as the nf_conntrack_sip helper does), you can see the remote address and port # for the media connection, and plumb an association for that dynamically... you can also tear it down when you see the associated BYE message). If you do that, then you don't need to have any ports open. >> I'd like to see Asterisk punch holes for the media stream via ipt on-the-fly >> so that the phones don't actually have to be NAT-aware. > > As apposed to leaving UDP 10000 through 20000 open in the firewall? > That *would* be quite useful. Indeed. > Now, if the phones are routing everything through Asterisk, they don't > have to be NAT aware. Asterisk makes the connection internally. The > phones talk to Asterisk, and Asterisk talks to the Remote server. Yeah, but I don't necessarily want Asterisk in the media path. Especially not on some of the slower processors. > If the sip stream is going to re-invite, would Asterisk know the > incoming and outgoing ports to be able to open everything up? You leave Asterisk in the SIP stream... just not in the media stream. > I'd be very interested in a solution more like this: > http://www.iptel.org/sipalg/ > > It claims to be a connection tracker for sip+rtp. Similar to how > iptables can handle the FTP issues. This seems like a much better > solution for most cases. Ideally it's as simple as > iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > > IPtables should see the rtp stream as related, and let it through. That's how nf_conntrack_sip already works. > Just my 2 cents, > Jonathan Bennett _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
