Wave9_Tim

I've seen things like this a few times before and there's a few suspects it could be. You've already sorted out the SIP ALG one (I'm assuming Gamma aren't lying about it being off their router, but sometimes they are mistaken). There's also the external IP setting on the PBX which I seen often to be the cause (in the SIP trunk definition normally). If that is set to anything other that the external NAT RTP goes missing in action. You can check this by running a TCPDUMP on the SIP packets during the call setup (I'd usually do this from the firewall, not sure if you can on a Smoothwall). I don't have an example to hand but during the INVITE stage you should see the external NAT IP showing up, if you post/send me that I can check if you'd like. If it's the internal, private IP of the PBX then that's the issue. You can also see this behaviour when the external NAT and firewall rules aren't allowing the right UDP packet range or is NAT'ing the traffic to the wrong internal IP. It's usually one (or more) of those. You can also TCPDUMP the RTP stream packets (which I presume are being generated but is worth checking) and see what's going on. Gamma will use a seperate IP for the RTP host so it's easy to do (and you should see a stream of UDP packets). That's a rough overview, hopefully one will either sort the problem out or point you in a better direction. Regards

If you were using the interface IP address and not an alias I'd suspect the user portal was getting in the way. A couple of things, as suggested you can run tcpdump from the CLI and see if the traffic passes through the XG to the local IP address (a simple tcpdump host will do, that will show the incoming traffic to the external NAT and the internal traffic leaving the inside interface). You can run that from the Diags > Packet capture tab too (I just prefer the CLI). You can (also from the CLI) run conntrack -L -s -d to see which NAT and firewall rule you hit - 0's show it's hitting system rule. Regards

The NAT statement looks fine, though the firewall rule needs the public IP address of the webserver rather than the internal IP. Regards

I'd be more inclined to re-address the XG to your current default gateway, there's going to less to worry about in getting round everything that might have a fixed IP address/gateway set. Just remember to update the XG IP address in the STAS client on your AD server(s).

Quite possibly this is one of the problems (lack of the appropriate return routes on the SRX), in addition it could be that the Juniper device also requires the access rules/NAT statements to support the downstream IP subnets.