> 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
_______________________________________________ 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
