VM problem resolved. Due to having to restore to older configs when looking for problems, old passwords came back :).
Things seem to be getting better today. A few reports on one way audio so far. Probably more NAT things going on.
Doesn’t seem to be either the nat setting on their phones or in the device option settings. Yet there are still one way audio problems. What else can I try?
One way audio is 99.5% of the time either a firewall or Nat setup issue. See http://nerdvittles.com/index.php?p=216 5th paragraph.
Yup, it was the juniper firewall and it’s ALG setup causing all of the problems. I disabled that and created my own service and policy and calls started flowing 100% perfectly.
Mike
With all the posts on this issue in this forum, and the very helpful replies. And your duplicate post over at the trix forums you did not mention that you where running the Juniper.
Then to top it all off no thank you to all the folks who beat their head against the wall trying to figure out what you where doing wrong.
If you had mentioned the Juniper (and you still did not mention which Juniper) we would have told you to not use the ALG and how to setup a working MIP/DIP (Juniper’s terms for various NAT configurations) and policies.
You also should check, Juniper outbound NAT is very picky. If you policy is wrong the inbound translation that you have defined the policy for (untrusted to trusted) will use the MIP. However if you do not have a specific outbound policy the traffic will egress the default NAT policy and use the interface IP as the outbound NAT source. This asymmetric NAT can cause all sorts of issues.
Duh, I mentioned very early on, let me know if there is anything else. Then the thread grew from there and not once did that come up. What’s wrong with you? Giving me grief over such a thing? Are you 14?
Pretty weird of you to point out that I didn’t say thanks, which is hilarious considering I always do or at least close the thread by giving what the problem was. The latter being much more important than a thanks anyone who helps should simply take for granted. That’s what forums are all about.
Mike,
I’m not 14, I wish (lol). What I am is seriously burned out on folks that post the same issue on multiple forums in multiple posts and hijack threads in hopes of getting a different answer and blame the software instead of looking at their implementation.
I clearly remember that it was similar to pulling teeth to get you to admit you changed your firewall. Now after all of this you let us know it was a Juniper.
You never mentioned Juniper before in this post (my research limited to a searching the keyword on this web page) and I am fairly sure you did not in your original post over at trixbox. To my knowledge there are two Juniper guys who hang out and I try and notice and help out with Juniper specific issues.
So yes I was aggravated at the amount of time you wasted, many people tried to help you despite the fact you defended your network at every turn.
Then you took your problems here, a very different community with a much larger population of experts and developers who do everything they can to help.
You attitude is exactly why trix users have a poor reputation in the community.
That’s all I’ve got.
You’re not going to change anything by posting this kind of drivel. Either don’t help or don’t read the forums or pick the ones you wish to help more careful and don’t bother complaining. It’s silly, you can’t change a thing.
You’re dreaming in Technicolor my man, I’ve never had a problem admitting I screwed something up so no idea where you’re getting this from other than you own frustrations. In fact, I have no issues what so ever about making a mistake, it’s how I learn. While this was going on, I was also working with Juniper on another matter and mentioned that I thought I was having some damned weird VoIP problems which I suspected might be firewall related. Over and over they told me no, it could not be, after spending hours looking so it’s not like it was not looked at. If you’re with Juniper, I’ll be happy to give you the case # if you care to look it up.
(my research limited to a searching the keyword on this web page)
You’re wasting an awful lot of investigation time on trying to give me shit for no obvious good reason. You’re not helping anything, you’re just adding to forum nonsense.
I understand what you’re saying but you jumped the gun in this case. I didn’t feel the thread was closed, I was sure the folks who helped would add a few thoughts and once it was at an end, I would have thanked, as I always do.
Anyhow, can we move on to what the thread was about again, thanks.
Yes, we all make mistakes, that certainly is a primary method for me.
I made a point relevant or not and as far as I am concerned that’s all there is to it.
So what is the end? What Juniper firewall are you using? It may help folks that are searching if you post your policy (use the Juniper CLI and use the command ‘show policy’ to determine your policy number the ‘show policy id #’ to display details of the policy.
As always, please use the code tags.
No problem.
It’s an SSG-20 unit running 5.4.
I had first created a SIP service and had ports 5060 and 10k to 20k in it. I then created a policy using that but had also used SIP as application. After many calls to Juniper about VoIP problems, someone finally thought about the fact that ALG is installed and active by default. I seemed like something was conflicting and that turned out to be the case.
We (Juniper support and I) removed my policy, made absolutely sure that there were not multi-wan problems or conflicting services and fully activated ALG at that point. For the next week, it seemed to work fine then all of a sudden, calls start getting cut off, voice mail can’t be reached.
The more I try to change things a little here and a little there, also based on input from my posts, things don’t get any better, they seem to be getting worse.
I start thinking about the fact that with my service/policy, we at least had services with minor problems. I start looking into that and someone either says in this post, or I found it in another, not sure at this moment, as I write this, but anyhow, gets me thinking about it.
I call them back and tell them about this and demand to speak with someone who is very well versed with SIP, and asterisk. I tell him about the problem and tell him that my service at least seemed to have some success, and that I’ve read that ALG is a problem. He’s not aware of this but we remove the built in stuff, get mine back in there and all of the problems go away.
I have to admit that I am very surprised that this happened. I’ve been using watchguard for a long time but have heard about and read about Juniper being a good contender so wanted to give it a try on a small multi-wan network.
Anyhow, when you have problems it’s not always obvious what direction to go into so you start asking questions, getting some input and trying various things. I didn’t think about mentioning the firewall because I was simultaneously working on that with Juniper and kept pushing to make sure the firewall was not the issue. According to them, it wasn’t, until I found the ALG post.
Mike
Interesting history lesson, it sill would help others for you to post your policy. The SSG series are very nice boxes, in my opinion Watchguard is not even in the same class.
Do you have a service contract with Juniper? There TAC is so much better than Cisco’s.
Anyway Juniper KB ID: KB7407 talks about back to back ALG’s. NAT in Asterisk is actually an ALG of sorts, since it rewrites the SIP mesages to include your outside IP. Since the Juniper was trying to do the same thing it gets confused. The main purpose of the ALG is security, it opens the RTP ports on the fly and also makes sure that all RTP is tied to an application session.
They should have only disabled the ALG for the Asterisk box in the policy so any other SIP devices on the network can still benefit from the ALG.
The custom service is called Custom SIP and is;
TCP src port: 0-65535, dst port: 5060-5060
UDP src port: 0-65535, dst port: 5060-5060
UDP src port: 0-65535, dst port: 10000-20000
The policy is untrust to trust, from ANY to a MIP (NAT back to trixbox PBX)
The service is my Custom SIP with no Application.
No advanced functions, no shaping, etc.
In Advanced and ALG on the Juniper, only SIP is disabled, everything else is still checked.
I wanted to give the Juniper a try after being a Watchguard user for a long time. I like it so far. A hell of a lot of clicking to get something done but I like it and it seems to have a great deal of power. I might have to go with another unit however as the SSG-20 only seems to handle some 40 SIP calls at most. And yes, I do have TAC access.
Like I said, I wish they would have known about this right from the start because it caused loads of grief for weeks with intermittent problems and no solutions. Looking better now, the only other issue we’ve yet to figure out is why we are having a hard time making outgoing https connections. They don’t seem to have a clue about that one. Incoming https connections seem to have problems as well.
I should point out that the last support person I spoke with also told me that version 6.2 I think it is, is supposed to address the ALG issue.
Mike