Re: [asterisk-users] Asterisk both behind a NAT and outside at the same time
Seems to me that you have a routing problem, asterisk should not know how to send packets to an outside IP using the NATed network. Make sure that the internal (NAT) interface doesn't have a gateway to it. On 10/31/06, Brad Templeton [EMAIL PROTECTED] wrote: I've read a lot of the descriptions of handling NAT with Asterisk, and the use of both the nat and canreinvite flags. I am very familiar with Sip and NAT but have not seen an answer to the following question. My Asterisk server runs on a machine with two ethernets. One is an external net, with exposed IP addresses. The other is an internal net with natted IP addresses. Thus the server has two addresses. The server is _not_ the NAT gateway. That's a linksys box which has its own external IP to gateway traffic from the internal natwork. The phones are on the internal NATwork. Asterisk talks to them over it. Outside peers, such as SIP termination providers etc. talk to the Asterisk server via its outside address, which is as you would expect. However, from time to time I get the famous one-way audio because Asterisk has decided to do a native bridge between a natted SIP phone and an external SIP peer. It sends the internal IP of the SIP phone in the SDP and of course the outside service can't send packets to that. I could just turn off reinvites on the internal phones, but this would cause them to route all traffic through the asterisk box, even on internal calls between phones on the same ethernet, which seems foolish to me. I don't want to turn off reinvites to the external peers -- if a call comes in from a SIP originator for example, and is send back out to a SIP terminator (call forwarding) I want a native bridge for sure.(Handling the internal traffic is not so much of a burden though sometimes I hear latency because of it, but routing external traffic through the asterisk box is a bad thing.) So what I want is for Asterisk to use native bridges when connecting two channels behind the NAT, or two channels on the real internet, but not to do so when connecting an internal and external channel. It should be able to see the IP addresses, and know the difference between natted and external ones and know they can't talk to one another. (The ICE protocol would handle this someday.) Is IAX smarter about this? Of course I might even want to get smarter about this. Is it possible, typically by configuring stun in the phones, to have them be aware of their external IP and tell Asterisk about it? With a full cone NAT, it would work to do a native bridge between the internal and external devices so long as the external device is given the right address and port of the NAT box, not the internal address of the phone. However, we don't want to do this on internal to internal calls -- many NATs can't hairpin. I would think this would be a common situation (though perhaps more commonly the asterisk server IS the firewall/NAT.) Is there a solution that does the right thing most of the time? ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk both behind a NAT and outside at the same time
Sorry for my previous post I misunderstood the problem. You should set canreinvite=no to all sip peers that connect from outside. On 10/31/06, C F [EMAIL PROTECTED] wrote: Seems to me that you have a routing problem, asterisk should not know how to send packets to an outside IP using the NATed network. Make sure that the internal (NAT) interface doesn't have a gateway to it. On 10/31/06, Brad Templeton [EMAIL PROTECTED] wrote: I've read a lot of the descriptions of handling NAT with Asterisk, and the use of both the nat and canreinvite flags. I am very familiar with Sip and NAT but have not seen an answer to the following question. My Asterisk server runs on a machine with two ethernets. One is an external net, with exposed IP addresses. The other is an internal net with natted IP addresses. Thus the server has two addresses. The server is _not_ the NAT gateway. That's a linksys box which has its own external IP to gateway traffic from the internal natwork. The phones are on the internal NATwork. Asterisk talks to them over it. Outside peers, such as SIP termination providers etc. talk to the Asterisk server via its outside address, which is as you would expect. However, from time to time I get the famous one-way audio because Asterisk has decided to do a native bridge between a natted SIP phone and an external SIP peer. It sends the internal IP of the SIP phone in the SDP and of course the outside service can't send packets to that. I could just turn off reinvites on the internal phones, but this would cause them to route all traffic through the asterisk box, even on internal calls between phones on the same ethernet, which seems foolish to me. I don't want to turn off reinvites to the external peers -- if a call comes in from a SIP originator for example, and is send back out to a SIP terminator (call forwarding) I want a native bridge for sure.(Handling the internal traffic is not so much of a burden though sometimes I hear latency because of it, but routing external traffic through the asterisk box is a bad thing.) So what I want is for Asterisk to use native bridges when connecting two channels behind the NAT, or two channels on the real internet, but not to do so when connecting an internal and external channel. It should be able to see the IP addresses, and know the difference between natted and external ones and know they can't talk to one another. (The ICE protocol would handle this someday.) Is IAX smarter about this? Of course I might even want to get smarter about this. Is it possible, typically by configuring stun in the phones, to have them be aware of their external IP and tell Asterisk about it? With a full cone NAT, it would work to do a native bridge between the internal and external devices so long as the external device is given the right address and port of the NAT box, not the internal address of the phone. However, we don't want to do this on internal to internal calls -- many NATs can't hairpin. I would think this would be a common situation (though perhaps more commonly the asterisk server IS the firewall/NAT.) Is there a solution that does the right thing most of the time? ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Asterisk both behind a NAT and outside at the same time
I've read a lot of the descriptions of handling NAT with Asterisk, and the use of both the nat and canreinvite flags. I am very familiar with Sip and NAT but have not seen an answer to the following question. My Asterisk server runs on a machine with two ethernets. One is an external net, with exposed IP addresses. The other is an internal net with natted IP addresses. Thus the server has two addresses. The server is _not_ the NAT gateway. That's a linksys box which has its own external IP to gateway traffic from the internal natwork. The phones are on the internal NATwork. Asterisk talks to them over it. Outside peers, such as SIP termination providers etc. talk to the Asterisk server via its outside address, which is as you would expect. However, from time to time I get the famous one-way audio because Asterisk has decided to do a native bridge between a natted SIP phone and an external SIP peer. It sends the internal IP of the SIP phone in the SDP and of course the outside service can't send packets to that. I could just turn off reinvites on the internal phones, but this would cause them to route all traffic through the asterisk box, even on internal calls between phones on the same ethernet, which seems foolish to me. I don't want to turn off reinvites to the external peers -- if a call comes in from a SIP originator for example, and is send back out to a SIP terminator (call forwarding) I want a native bridge for sure.(Handling the internal traffic is not so much of a burden though sometimes I hear latency because of it, but routing external traffic through the asterisk box is a bad thing.) So what I want is for Asterisk to use native bridges when connecting two channels behind the NAT, or two channels on the real internet, but not to do so when connecting an internal and external channel. It should be able to see the IP addresses, and know the difference between natted and external ones and know they can't talk to one another. (The ICE protocol would handle this someday.) Is IAX smarter about this? Of course I might even want to get smarter about this. Is it possible, typically by configuring stun in the phones, to have them be aware of their external IP and tell Asterisk about it? With a full cone NAT, it would work to do a native bridge between the internal and external devices so long as the external device is given the right address and port of the NAT box, not the internal address of the phone. However, we don't want to do this on internal to internal calls -- many NATs can't hairpin. I would think this would be a common situation (though perhaps more commonly the asterisk server IS the firewall/NAT.) Is there a solution that does the right thing most of the time? ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk both behind a NAT and outside at the same time
Brad Templeton wrote: I've read a lot of the descriptions of handling NAT with Asterisk, and the use of both the nat and canreinvite flags. I am very familiar with Sip and NAT but have not seen an answer to the following question. My Asterisk server runs on a machine with two ethernets. One is an external net, with exposed IP addresses. The other is an internal net with natted IP addresses. Thus the server has two addresses. The server is _not_ the NAT gateway. That's a linksys box which has its own external IP to gateway traffic from the internal natwork. The phones are on the internal NATwork. Asterisk talks to them over it. Outside peers, such as SIP termination providers etc. talk to the Asterisk server via its outside address, which is as you would expect. However, from time to time I get the famous one-way audio because Asterisk has decided to do a native bridge between a natted SIP phone and an external SIP peer. It sends the internal IP of the SIP phone in the SDP and of course the outside service can't send packets to that. I could just turn off reinvites on the internal phones, but this would cause them to route all traffic through the asterisk box, even on internal calls between phones on the same ethernet, which seems foolish to me. I don't want to turn off reinvites to the external peers -- if a call comes in from a SIP originator for example, and is send back out to a SIP terminator (call forwarding) I want a native bridge for sure.(Handling the internal traffic is not so much of a burden though sometimes I hear latency because of it, but routing external traffic through the asterisk box is a bad thing.) So what I want is for Asterisk to use native bridges when connecting two channels behind the NAT, or two channels on the real internet, but not to do so when connecting an internal and external channel. It should be able to see the IP addresses, and know the difference between natted and external ones and know they can't talk to one another. (The ICE protocol would handle this someday.) Have you tried setting the externalip and localnet parameters? Leo ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk both behind a NAT and outside at the same time
On Tue, Oct 31, 2006 at 07:40:35PM +0800, Leo Ann Boon wrote: Have you tried setting the externalip and localnet parameters? Localnet makes some sense, and is set (should be the default anyway, no?) externalip, as I understand it, is for an Asterisk which is behind a NAT. This asterisk is not behind a NAT to anybody. The phones are behind a NAT to the outside world but not to the Asterisk box, which has two ethernets on it, one for the internal natwork and one for the real internet. It uses bindaddr=0.0.0.0 and listens to both addresses. Sorry for my previous post I misunderstood the problem. You should set canreinvite=no to all sip peers that connect from outside. That's precisely what I don't want to do. This would block native bridging in the one case where it's most important. The correct behaviour, as I see it is: a) Native bridge when connecting two external channels -- everybody is on the real internet b) Native bridge when connecting two internal channels -- everybody is on the 192.168.* network c) Route RTP through Asterisk when connecting internal and external d) When a channel is to a device behind a remote NAT, the usual rules apply (either use STUN or other smart NAT, or route RTP through Asterisk) The super correct behaviour, which I don't expect but would be nice is e) Clever native bridge between internal and external by being aware that the device talks to the outside world using a different address than it talks to you. (Possibly if the phones use STUN they will tell Asterisk their external IP, which is not the same as Asterisk's though it's on the same subnet) I have used localnet=192.168.* and nat=yes on a local device and it still attempts an incorrect native bridge between internal and external, with one-way audio. If I do canreinvite=no on the local devices then it works of course, but now means the local phones will never native bridge amongst themselves. In a larger network, that would be a problem, and it's a poor result in any network. This is the latest svn of 1.2, by the way. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk both behind a NAT and outside at the same time
On 10/31/06, Brad Templeton [EMAIL PROTECTED] wrote: On Tue, Oct 31, 2006 at 07:40:35PM +0800, Leo Ann Boon wrote: Have you tried setting the externalip and localnet parameters? Localnet makes some sense, and is set (should be the default anyway, no?) externalip, as I understand it, is for an Asterisk which is behind a NAT. This asterisk is not behind a NAT to anybody. The phones are behind a NAT to the outside world but not to the Asterisk box, which has two ethernets on it, one for the internal natwork and one for the real internet. It uses bindaddr=0.0.0.0 and listens to both addresses. Sorry for my previous post I misunderstood the problem. You should set canreinvite=no to all sip peers that connect from outside. That's precisely what I don't want to do. This would block native bridging in the one case where it's most important. The correct behaviour, as I see it is: a) Native bridge when connecting two external channels -- everybody is on the real internet It might not work if one of them is NATed. Therefore the correct way to do this is to use canreinvite=no b) Native bridge when connecting two internal channels -- everybody is on the 192.168.* network canreinvite=yes will take care of this. c) Route RTP through Asterisk when connecting internal and external Again by adding canreinvite=no to externals you have this. d) When a channel is to a device behind a remote NAT, the usual rules apply (either use STUN or other smart NAT, or route RTP through Asterisk) How will asterisk know? The correct *setting* (not behavior) is canreinvite=no for the external devices. The super correct behaviour, which I don't expect but would be nice is e) Clever native bridge between internal and external by being aware that the device talks to the outside world using a different address than it talks to you. (Possibly if the phones use STUN they will tell Asterisk their external IP, which is not the same as Asterisk's though it's on the same subnet) I have used localnet=192.168.* and nat=yes on a local device and it still attempts an incorrect native bridge between internal and external, with one-way audio. If I do canreinvite=no on the local devices then it works of course, but now means the local phones will never native bridge amongst themselves. In a larger network, that would be a problem, and it's a poor result in any network. Why are you so against having the RTP go thru asterisk? ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk both behind a NAT and outside at the same time
Brad Templeton wrote: On Tue, Oct 31, 2006 at 07:40:35PM +0800, Leo Ann Boon wrote: Have you tried setting the externalip and localnet parameters? Localnet makes some sense, and is set (should be the default anyway, no?) I don't think it's set by default. Anyone know how we can see which localnets are in use from the CLI? sip show settings doesn't work even if I explicitly defined a localnet. externalip, as I understand it, is for an Asterisk which is behind a NAT. This asterisk is not behind a NAT to anybody. The phones are behind a NAT to the outside world but not to the Asterisk box, which has two ethernets on it, one for the internal natwork and one for the real internet. The way I understand it, externalip and localnet work hand-in-hand. I do agree with you that this is commonly used for Asterisk behind a NAT. I believe these parameter just helps asterisk determine what to do. In your case, you don't lose anything - the external IP would still have to be written into every outbound packet. It uses bindaddr=0.0.0.0 and listens to both addresses. externalip doesn't affect the bindaddr. Leo. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk both behind a NAT and outside at the same time
On Tue, Oct 31, 2006 at 04:51:44PM -0500, C F wrote: The correct behaviour, as I see it is: a) Native bridge when connecting two external channels -- everybody is on the real internet It might not work if one of them is NATed. Therefore the correct way to do this is to use canreinvite=no Of course, if the external peer or user is natted, you would want to turn on nat and canreinvite=no for such channels. However, I do not wish to set canreinvite=no for an external peer like another asterisk box with an external IP, or a SIP termination provider. More than do not wish -- this is the most important case. b) Native bridge when connecting two internal channels -- everybody is on the 192.168.* network canreinvite=yes will take care of this. Of course, but the point is that the internal channels (local SIP phones) are involved in connections to both local phones, and to external peers. c) Route RTP through Asterisk when connecting internal and external Again by adding canreinvite=no to externals you have this. But this defeats the entire purpose. Here are two situations where you would most definitely not want to have canreinvite=no a) Call comes in via SIP origination, and you direct it back out to a PSTN phone via your SIP termination. You want the RTP to go directly from the originating point to the termination point, not to hairpin through your asterisk box, which would just add latency and eat bandwidth. b) Click to call APP I have where I connect two PSTN endpoints. Again, it's necessary not to hairpin the RTP. c) Double all this with some advanced providers who, once they figure where the call is actually being terminated, do their own native bridging and direct your RTP to the actual PSTN entry point. There it's possible to get the RTP to go by the shortest (and lowest latency) path it can. But not if you hairpin it. d) When a channel is to a device behind a remote NAT, the usual rules apply (either use STUN or other smart NAT, or route RTP through Asterisk) How will asterisk know? The correct *setting* (not behavior) is canreinvite=no for the external devices. I would have to differ. That's the right setting for external user devices behind NAT. Do you believe it's correct for devices not behind NAT? Asterisk can tell if a device is behind NAT if the device has been made in the last few years, because such devices support a variety of techniques to inform the server they call that they are behind NAT, and even what their external IP is if need be. However, reinvite is not safe with a symmetric nat unless there is really good cooperation. So I understand turning off reinvite for any external device behind NAT. (Of course a clever box can notice that it sees two devices that have NAT addresses on the same subnet and both are using the same external IP. In that case, it can tell them to send their RTP directly to one another which is very much the best thing to do. This allows things like a branch office using a head office Asterisk server and calls within the branch staying on the LAN. This is what the ICE protocol is supposed to solve, of course.) Why are you so against having the RTP go thru asterisk? For external connections? There are a ton of reasons, some outlined above. An asterisk box with proper use of native bridging can handle a virtually unlimited number of calls.Put the RTP through it and it can handle only a modest number, and reduces the quality of those calls significantly. Having internal calls go through the asterisk box is not as much of a problem, but I have noticed latencies because of it even on my internal LAN, though I have not pieced together exactly why, it's almost certainly because of the RTP bridging. Which I always get when I call IAX to SIP of course. It's not because of load. Anyway, my main question is, has anybody figured out how to make Asterisk do the right thing here. I am surprised if my configuration is that unusual. Having both an internal and external network is pretty common at a lot of places. And a server that's on both is, I think, quite common, so I had not expected this to be a difficult thing to figure out how to do. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk both behind a NAT and outside at the same time
On Wed, Nov 01, 2006 at 08:10:29AM +0800, Leo Ann Boon wrote: Brad Templeton wrote: The way I understand it, externalip and localnet work hand-in-hand. I do agree with you that this is commonly used for Asterisk behind a NAT. I believe these parameter just helps asterisk determine what to do. In your case, you don't lose anything - the external IP would still have to be written into every outbound packet. It's called externip I think, not externalip. I have set both externip to be my external IP address, and localnet to be the natwork, and even set canreinvite=no and nat=yes and the SDP I get back from an invite to [EMAIL PROTECTED] still has 192.186.* in it. It uses bindaddr=0.0.0.0 and listens to both addresses. externalip doesn't affect the bindaddr. Would not expect it to. Just trying to be clear to people that the machine has two ethernets. I was hoping Asterisk would just automatically say, Wait a minute, I'm taking an SDP with addresses in the localnet, and sending it out to a peer on the outside internet. That's not going to work! Now one of my tests has a SIP program I have written attempt to call Asterisk. It sits on port 5061 invites to Asterisk on 5160 of the machine with the external address as follows: INVITE sip:[EMAIL PROTECTED]:5160;transport=udp SIP/2.0^M Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE^M From: Voxable sip:[EMAIL PROTECTED];tag=3445^M To: Party Leg1 sip:[EMAIL PROTECTED]:5160^M Via: SIP/2.0/UDP 198.144.201.82:5061;branch=z9hG4bK6563eba5fd430b5af93579617a44450e^M Max-Forwards: 12^M Contact: Caller App sip:[EMAIL PROTECTED]:5061^M Date: Wed, 01 Nov 2006 04:52:07 GMT^M User-Agent: Voxable 0.1^M Content-Type: application/sdp^M Content-Length: 154^M ^M v=0 o=capp 1162356727 1 IN IP4 198.144.201.82 s=CApp3PCC c=IN IP4 198.144.201.82 t=0 0 m=audio 5308 RTP/AVP 0 8 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PMCA/8000 Asterisk sends this on to the phone, but rewrites the SDP to present a local one: o=root 26391 26391 IN IP4 192.168.123.10 s=session c=IN IP4 192.168.123.10 t=0 0 m=audio 10856 RTP/AVP 0 97 8 101 I answer the phone and it responds to this SDP with an OK o=brad 8000 8000 IN IP4 192.168.123.18 s=SIP Call c=IN IP4 192.168.123.18 t=0 0 m=audio 5004 RTP/AVP 0 101 a=sendrecv a=rtpmap:0 PCMU/8000 a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 Asterisk then sends back this SDP without rewriting it. Is it only doing that because it knows the traffic came from the same machine? Asterisk forwards this OK back. Note the SDP SIP/2.0 200 OK^M Via: SIP/2.0/UDP 198.144.201.82:5061;branch=z9hG4bK94e379b15dbd22f8594fa6e88a4cfcc0;received=198.144.201.82^M From: Voxable sip:[EMAIL PROTECTED];tag=3445^M To: Party Leg1 sip:[EMAIL PROTECTED]:5160;tag=as62de8d32^M Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE^M User-Agent: Caller Asterisk^M Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY^M Supported: replaces^M Contact: sip:[EMAIL PROTECTED]:5160^M Content-Type: application/sdp^M Content-Length: 199^M ^M v=0^M o=root 26391 26391 IN IP4 192.168.123.18^M s=session^M c=IN IP4 192.168.123.18^M t=0 0^M m=audio 5004 RTP/AVP 0 8^M a=rtpmap:0 PCMU/8000^M a=rtpmap:8 PCMA/8000^M a=silenceSupp:off - - - -^M a=sendrecv^M My software then forwards that SDP on to an outside location, where the SDP is useless. It works if the outside provider I forward the SDP to has my asterisk box set with some flags (nat=yes I presume?) though I can't figure why. That box is presumably, seeing the internal address, routing the audio to some port on the * box, and asterisk is forwarding it but I can't see how this is happening. Odd. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users