[Asterisk-Users] iax behind a SonicWall

Adam Hart adam at teragen.com.au
Wed May 12 19:33:00 MST 2004


John Todd 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?
> 

Correct, a NAT will allocate a unique port for each "talker" so it's 
very common that you'll see connections coming from random ports. Even 
more sexy, if the NAT follows the RFC (can't remember the number) 
suggestion it will reuse the same port if the packets are going to 
another ip.

example

192.168.0.3 (A) wants to reach 1.2.3.4 port 4569, NAT allocates port 
1234 for it
192.168.0.2 (B) wants to reach 1.2.3.4 port 4569, NAT allocates port 
5555 for it
192.168.0.3 (A) wants to reach 4.3.2.1 port 4569, NAT reuses port 1234 
for it.

This is essensial for native transfers for NAT to NAT as 1.2.3.4 (in 
this case) can predict what port the NAT will allocate for the transfer.

-Adam



More information about the asterisk-users mailing list