[Asterisk-Users] iax behind a SonicWall

[John Todd]

At 3:06 AM -0600 on 5/13/04, Rich Adamson wrote:
>  > At 8:23 PM -0600 on 5/12/04, Rich Adamson wrote:
>>  >Current dev cvs install on two systems. System A is behind a SonicWall
>>  >firewall, and system B is on a registered IP address. (System B has
>>  >multiple iax links that are fully functional to multiple locations.)
>>  >
>>  >System A is correctly registering with System B, with no special firewall
>>  >rules.
>>  >
>>  >Should System B be able to take advantage of the "registration" to send
>>  >iax/gsm calls to System A without installing any firewall rules?
>>  >
>>  >I assumed it could, but an ethereal trace indicates a new call is
>>  >placed from B -> A, but A never acknowledges the iax2 packet, etc.
>>  >
>>  >The trace suggests the registration is happening with
>>  >  src port 28277 (or whatever) -> dest port 4569
>>  >however, calls are processed with
>>  >  src port 4569 and dest port 4569
>>  >
>>  >Shouldn't we expect src=4569 and dest=4569 on all iax2 interactions?
>>  >
>>  >Rich
>>
>>  If src=4569 and dst=4569 always, then it would be impossible to have
>>  more than one IAX2 talker behind a firewall talking to an external
>>  Asterisk server, right?  There would be no method by which the
>>  firewall would "know" which packet was destined for what device
>>  inside the firewall, since the source port and destination port would
>>  be the same for each "connection".   I'm not thinking this through
>>  completely, and it seems like there is a flaw in this argument... but
>>  with UDP, there is no sequence number that should have attention paid
>>  to it (like TCP) so... er... someone tell me why this is incorrect.
>>
>>  note: firewall in this case is really "NAT", right?
>
>Hi John,
>
>Using src=4569 and dst=4569 is not a problem with any firewall as long
>as the destination IP address differs. The firewall's nat table for two
>different iax links would look something like:
>   Src: 1.2.3.4 udp 4569   Dst: 5.6.7.8 udp 4569
>   Src: 1.2.3.4 udp 4569   Dst: 6.7.8.9 udp 4569
>Since nat table entries always include all four values (regardless of
>firewall vendor), there is always uniqueness for the sessions from the
>firewall's perspective.
>
>In the case of iax, if two or more sessions were attempted between like
>addresses (as in two iax calls), the firewall would not be aware that
>two sessions were even happening as the udp src & dst header data is
>identical. Asterisk knows the two sessions are different as the iax2
>header includes "source call: 5" and "Destination call: 0" to differentiate
>the packets (as real examples).
>
>If we look closely at a working iax trunk call today, the src and dst
>ports are actually the same (udp 4569). Its only the "initial" registration
>process that actually uses a non-4569 source port number. Following that
>initial registration, even the registration refresh packet exchange
>uses src and dst port of 4569.
>
>So, it almost looks like either: a) everyone has been content to install
>a firewall rule to handle inbound udp 4569, or, b) no one has recognized
>that if the registration process used udp 4569 for its src port, no
>changes would be needed to any firewall, or, c) there is something wrong
>with my logic.
>
>Since I do a lot of protocol analysis and network security work (as a
>professional), I'm 98% convinced "b" is probably correct. If no one can
>point out the flaw in that logic, I'm tempted to open a bugtracker item
>to change it.
>
>Rich

I also suspect that "B" is correct, but let me clarify a bit...

Let me understand your problem in a bit more detail: you're saying 
that even though your NAT is creating a mapping for 1.2.3.4 udp 28277 
-> 5.6.7.8 udp 4569 that this causes your NAT/FW to refuse return 
connections?  Shouldn't your NAT automatically create that mapping 
and keep it open for some period of time?  Or is Asterisk ignoring 
the 28277 src and sending the reply back on 4569?

Thanks for the expanded discussion on NAT; that's helpful for the 
larger audience.  My point in my message was that if I have two IAX 
devices (let's say, I have two IAXy's) behind the same NAT, and 
they're both pointed at the same non-NAT (external) Asterisk server, 
then that would not work.

   src: 1.2.3.4 udp 4569   dst: 5.6.7.8 udp 4569
   src: 1.2.3.5 udp 4569   dst: 5.6.7.8 udp 4569

Packets coming from 5.6.7.8 might have internal (application-layer) 
flags that assign them to different devices, but the IP header 
information between packets for either device would be 
non-distinguishable by the NAT device.  It would have a mapping for 
both IAXy's on the same port.

Now, the way I've seen some NAT devices handle this is to give 
pseudo-random return ports to new sessions (new internal hosts) that 
request something that is already mapped, so that they can 
distinguish between return packets on the "outside" interface.  The 
internal port mappings are kept the same.  So, when the first packet 
is seen from IAXy #2 destined for the remote Asterisk server, the NAT 
has this internal thought: "Whoa! We've already got a mapping for 
packets coming from 5.6.7.8:4569, so I'd better make a different 
mapping on my outside interface for this new packet flow from a 
different internal host, so I can keep track."  This then turns into 
(using 3422 as a "random" number):

   src: 1.2.3.4 udp 4569   dst: 5.6.7.8 udp 4569
   src: 1.2.3.5 udp 3422   dst: 5.6.7.8 udp 4569

So, the NAT now expects to map any packets from 5.6.7.8 on port 3422 
and convert them to port 4569 on host 1.2.3.5, which should solve the 
problem.

I am (unfortunately) well-versed in NAT, and I know many NAT devices 
don't do this trick, and so having two IAX talkers behind the same 
NAT talking to the same external Asterisk host may sometimes fail.  I 
don't recall if this is part of the BCP's or RFC's for NAT or not... 
Anyway, I don't recall how Asterisk handles that circumstance.  Will 
* reply on the provided return port (in our example, 3422) or will it 
hard-wire the return port to 4569?   I assume it will use the reply 
port it gets on the inbound packet, since nobody has complained to 
this point about not being able to have multiple IAX talkers behind a 
NAT (except perhaps those with really, really broken NATs.)

My comments were perhaps separate from your issues with registration. 
I'm actually coming up with a slightly different angle than you are, 
I think, on the resolution, and that is that IAX2 packets should use 
pseudo-random return ports in some circumstances to assist b0rked NAT 
implementations.  However, this may be incorrect because I haven't 
heard anyone complaining about it so maybe this is all just hot air.

Sorry there isn't much experimentation or code examination here; too 
busy right now to do anything other than pontificate.  :-)

JT