> 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 _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users