Strange behavior?

And that's the problem, the new ISP keeps telling us it's at our end and so far it's not.
They said they never changed anything but they did and I'm trying to figure out what it might be so that I can have them look closer.

For one, they changed the PRI signalling from incoming digits being 10 to 4 or some such thing which broke our inbound routes.

Now we're seeing remote phones coming over the network showing up as 192.168.1.99 which is screwing things up.
On the remote users phones, we set them all to 192.168.1.99 behind their DSL/Cable modems yet the PBX is seeing some of those phones trying to connect as 192.168.1.99 over the Internet.

In other words, that private IP is coming over the net, into our network and the PBX is not authenticating them.
We never made any changes on the firewall but the new provider did bring in their own voice/data router for this circuit so I suspect a NAT setting on their hardware. This is what I need to prove so that I can call them and explain what I need.

I hope this helps to better explain.

Mike

>I am lost, is this a PRI that is delivered over VOIP and you are connecting the IAD to the
?PRI? If they supplied the router how do you know the port forwarding is still correct?

We had a standard PRI connected to trixbox onto a Rhino card. Our new provider came in with bonded connected and the PRI over IP. They installed their own router and PRI breakout box and told us everything would be identical. There were some minor differences as I mentioned earlier. In my initial post, I mentioned that I was not sure where the NAT problem might be but that the TB was not seeing the users real IP, only their phone IP which is a private NAT address. Not sure why that would even make it across the net. I thought the users firewall/router would translate that to public only. I guess the private IP must be in the session packets.

>The private IP from the remote end has nothing to do with the server end. You really need to >give more information. Did the remote phones ever work? What kind of phones are they? The >trix should see the remote NAT address as the source IP.

I've been giving what ever information anyone would like, am happy to :).
I thought I mentioned that but all of the phones are Linksys SPA-941. Some of the users are able to connect and some aren't.

I did find that someone had enabled Source Translation on the firewall which I've disabled since I started this thread. Now, everyone seems to be connecting but the current problem is;

1776/1776 75.x.x.97 D N 1907 UNREACHABLE

Turning the above off allowed this user to connect but now we're seeing that the TB seems to be communicating with the user over port 1907? We identified that the port is being initiated from the TB and have not figured out why this is happening. Why is this user diferent than the others.

What can I provide in order to help find a solution, I'll be happy to.

Mike

The TB is behind a firewall which is handling NTA. Yes, one of the first things I did was to mod the nat file.

ALG is on but the SIP protocol is disabled. I'm pretty sure that's how it was working before. I had created a custom SIP service and was using that for SIP. I'm no longer sure if juniper support changed something I'm not catching at this point.

The firewall is a juniper, ssg series, screenos.

Mike