[Asterisk-Users] Re: IAX2 Nat issue, Any help greatly appreciated

Tue Oct 19 07:22:25 MST 2004

On Tue, 19 Oct 2004 09:44:12 -0400, Gene Willingham
<gwillingham at comcast.net> wrote:
> What I think is happening is:  If I receive an inbound call on IAX during an
> IAX registration, the call does not get setup.  I appear to be unavailable
> to the other server. When a call fails I noticed using tcpdump that the
> inbound packets are destined for port 13081.  When the call succeeds the
> inbound packets are destined for port 4569.  Port 13081 seems to make sense
> when looking at iax2 show registry.  But it does not match the output from
> tcpdump when compared to calls that succeed.
> 
> gw1*CLI> iax2 show registry
> Host                  Username    Perceived             Refresh  State
> 66.234.228.170:4569   QSa55JPy58  x.x.x.50:13081           60  Registered
> 
> [IAX2 debug enabled]
> Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass:
> REGREQ
> 
>    Timestamp: 00017ms  SCall: 00002  DCall: 00000 [66.234.228.170:4569]
>    USERNAME        : QSa55JPy58
>    REFRESH         : 60
> 
> gw1*CLI>
> Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 001 Type: IAX     Subclass:
> REGACK
>    Timestamp: 00015ms  SCall: 00186  DCall: 00002 [66.234.228.170:4569]
>    USERNAME        : QSa55JPy58
>    DATE TIME       : 156437288
>    REFRESH         : 60
>    APPARENT ADDRES : IPV4 x.x.x.50:13081
> 
> gw1*CLI>
> Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 001 Type: IAX     Subclass: ACK
> 
>    Timestamp: 00015ms  SCall: 00002  DCall: 00186 [66.234.228.170:4569]
> Rx-Frame Retry[ No] -- OSeqno: 001 ISeqno: 000 Type: IAX     Subclass:
> HANGUP
>    Timestamp: 09779ms  SCall: 00518  DCall: 00000 [66.234.228.170:4569]
> 
> Output from tcpdump:
> 22:02:48.246092 x.x.com.4569 > 170-228-234-66.cosmoweb.net.4569: udp 12 (DF)
> [tos 0x10]
> 22:03:18.597719 170-228-234-66.cosmoweb.net.4569 > x.x.com.13081: udp 84
> (DF)
> 22:03:20.601668 170-228-234-66.cosmoweb.net.4569 > x.x.com.13081: udp 84
> (DF)
> 22:03:28.406522 170-228-234-66.cosmoweb.net.4569 > x.X.com.13081: udp 12
> (DF)
> 22:03:30.406566 170-228-234-66.cosmoweb.net.4569 > x.x.com.13081: udp 12
> (DF)
> 22:03:30.601889 170-228-234-66.cosmoweb.net.4569 > X.X.com.13081: udp 84
> (DF)
> 22:03:38.236056 X.x.com.4569 > 170-228-234-66.cosmoweb.net.4569: udp 28 (DF)
> [tos 0x10]
> 22:03:38.246584 170-228-234-66.cosmoweb.net.4569 > x.x.com.4569: udp 52 (DF)

The last two look like an outgoing call which you initiated.

You have to distinguish between incoming and outgoing calls, they are
two entirely different scenarios, especially when you traverse NAT.

An incoming call is -- from the viewpoint of your NAT router -- a
response to your earlier registration. So, as far as the NAT router is
concerned, you are the one who originated the incoming call by calling
out first making the registration request.

NAT uses different ports in order to map different streams going to
the same target port. In your example, the registration request is
mapped to 13081 but it will nevertheless reach Voicepulse's server on
port 4569. When you get an incoming call from Voicepulse, then as a
result of that registration having arrived from 13081, Voicepulse will
come in at your NAT router on 13081 even though it will have used 4569
on its own outbound interface. This is what allows your NAT router to
figure out that this is a response to your earlier registration and
that the stream is to be sent to your Asterisk server.

There could still be another IAX device on your network also having
registered with Voicepulse. Your NAT router would have mapped that to
another port, for example 19999. Then Voicepulse would send a call for
that device to port 19999 and your NAT router would then know that the
call is meant for the other IAX device and not your Asterisk server
whose registration was mapped to 13081. This is how NAT works.

Now when you make an outgoing calls, then that call may well use port
4569 on the WAN side of your NAT router and response traffic would
then come in on port 4569.

What I believe may be the problem you are facing is that your NAT
router may perceive the NAT mapping and the fact that your Asterisk
server is in a DMZ as a conflict. When you get the incoming call on
port 13081, the NAT router may not properly map it according to the
NAT mapping table but it may give the DMZ rule priority and simply
pass the traffic on to your Asterisk server in the DMZ that is to say
it will not be mapped back to 4569 but it will come in on port 13081
which your Asterisk server isn't configured to recognise as an IAX
port. It doesn't know anything about the mapping table of your NAT
router, so it won't map it back to 4569. After all, this is the job of
your NAT router, but it seems that for some reason it didn't do that
job.

I have seen this with quite a few software DMZs. In most cases this
can be solved by taking the Asterisk server out of the DMZ and use
individual port forwarding for those ports that you want to be
exposed, like 5038 for remote management for example, and not forward
4569. This will allow the NAT router and the IAX register mechanism to
work the way they are intended to work. When a call comes in on 13081
the NAT router will not be confused about the DMZ and it will map the
traffic back to port 4569 on your Asterisk server.

If you need to offer IAX service to IAX clients who register with your
server, you may want to do that on a different port, ie 14569, like
so:

[someIAXclient]
type=user
secret=blah
host=dynamic
port=14569

then port forward 14569 on your NAT router to port 14569 on your
Asterisk server.

hope this helps
regards
benjk

-- 
Sunrise Telephone Systems, 9F Shibuya Daikyo Bldg., 1-13-5 Shibuya,
Tokyo, Japan.

NB: Spam filters in place. Messages unrelated to the * mailing lists
may get trashed.