Re: [OpenWrt-Devel] Facilitating collaboration -- the labor exchange
On Sun, Jun 19, 2011 at 3:41 PM, Philip Prindeville philipp_s...@redfish-solutions.com wrote: 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: 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. Ah, OK. That would be great. In fact, I wouldn't mind setting up a test platform 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 1 through 2 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. Considering that we're speaking in the context of openwrt and and embedded platforms, good point. 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. Not sure how I missed that when researching. /me adds it to his bag of tricks I would be very interested in seeing asterisk handle the firewall stuff. Now that I understand exactly what you're describing, it seems it would be the best solution for this particular problem. I'll gladly set up a testbed server for this work. I'll also comment and contribute to the administration side of the project as much as I am able. ~Jonathan Bennett ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Facilitating collaboration -- the labor exchange
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 1 through 2 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
Re: [OpenWrt-Devel] Facilitating collaboration -- the labor exchange
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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Facilitating collaboration -- the labor exchange
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. Also, IPsec QoS marking is easier to handle than mixing several protocols over an SSL stream all with the same markings. One thing I like to use IPsec for is running SIP to my soft client on my laptop or even to my iPhone. 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. 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. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Facilitating collaboration -- the labor exchange
On Fri, Jun 17, 2011 at 4:12 PM, Jonathan Bennett jbscienc...@gmail.comwrote: 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. N2N is always a good choice for VPN capabilities ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Facilitating collaboration -- the labor exchange
I've been thinking about a couple of projects that I'd like to add (below) to OpenWRT, but that I don't always have the subject matter expertise to either configure or test them... but I do know how to do scripting, manage configurations with UCI, etc. What would be useful for me would be a way to list a project or feature on the Wiki that I'm willing to work with, and to solicit a partner to collaborate with. It's sometimes the case that programmers aren't power admins of certain features, and the people that understand those features don't always know all the subtleties of building OpenWRT support in for them. So this would be a means for someone to say, Hey, I want to work on X, and I can do the scripting, but I'm not exactly clear on all of the configuration details (for example), and someone with the competence and time and motivation could reply. Does this seem reasonable? For my part, I'm interested in the following two projects for now: (1) Add IPsec road-warrior capability to OpenWRT, so that (a) we could use certificate-based authentication for the mobile clients (which might include smartphones), and (b) if we had 192.168.1.0/24 as the LAN subnet for OpenWRT (as we often do), a pool of /32 addresses could be carved out from that, say 192.168.1.241-192.168.1.254 which the router would then Proxy-ARP for (making hosts on the LAN network believe that the IPsec clients were adjacent, which is useful for a whole lot of things... including DirecTV media sharing, etc). Anyway, as I said, I could do the scripting, but some of the Ipsec-tools (or Strongswan) stuff I'm a little unfamiliar with, like how to use openssl to generate self-signed certificate authorities, etc. (2) Add NAT hooks to Freeswitch and Asterisk so that when either brokers an incoming phone call's SIP path, it uses ipt to automatically set up (and later, tear down) a NAT hole for the call, so that the phones themselves don't have to be configured explicitly for NAT (and even when you get it right, have of the phones out there don't seem to handle NAT correctly in all cases anyway). So in this case, I could add the NAT hooks to SIP signaling for Asterisk and walk the fix through upstream, but I'm a little rusty on some of the signaling corner cases (like re-INVITEs, for example) or how to best test for all of the scenarios. Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
