[Asterisk-Users] iax behind a SonicWall

[Rich Adamson]

> 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