atcomsystems.ca/forum Forums VOIP Phones & IP PBX VoIP & Cloud Phones, Hosted PBX, General IP Phones Help! Can't network system anymore!

Oh, I am not doubting what you said, Rusty, it's just that the customer isn't willing to pay for the routers and installation/programming cost. I agree that if they were in place, something as simple as just placing the IP's in the DMZ would work. It's just that; they customer doesn't think that they should have to pay for all of this additional hardware just because one of their locations relocated. Fortunately, the cable company agrees and by going with DSL at one site, they will actually be paying less per month.

I really do appreciate your insight though. Even though we think we have reached a "poor mans" conclusion, your information has been helpful to me for future applications.

Well,

I just wanted to clarify that simply adding routers will not solve the problem, unless you are able to change one side to another subnet, and if that were the case this thread would be non-existent.

However I would say Zyxel vpn routers with one configured as DHCP (giving you that different subnet)would only cost about $250 per location.

But yeah, ultimately if the customer does not want to pay then they dont want to pay.

Yes, I know Rustynails. We just couldn't get a separate subnet while being on the same node's gateway. It has been confirmed by Cox that they just don't have the ability to do this due to the inherent nature of the US cable distribution network.

Ironically, we tried one, then two Zyxel routers (provided by Cox) and still, they couldn't get it to work. I don't understand why. If they say it can't be done, they are the service provider, they suggest DSL and they let the customer out of the contract, then either it really can't be done or they just don't know how to do it.

Regardless, $250.00 times four locations on the VPN for now would have meant $1,000.00 to restore something that the customer already had. That cost is before installation and programming labor for them. The worst thing is that this is just a temporary situation for 3-6 months as the customer consolidates locations, so a hardware investment of that magnitude is out of the question. I don't blame them.

Ed, the key is setting one location to DHCP, where I live, Cox always provides a different subnet for DHCP request distinctively seperate from their stattic addressing, regardless if you are on the same node.

At that point you allow for the DHCP router to initiate the VPN connection.

And to be quite frank with you, i think Cox tech/engineers are horrible. Think about it they went from CATV to internet and dialtone in just a matter of years. A lot of crash and burning at our expense. However as i have mentioned in another post, once you get their service to your facility, up and running, i think its the best out there; price and quality.

Well, several people requested that I post back with the outcome, so here it goes:

The cable TV provider let the customer out of their contract for one site. They admitted that they knew what the customer needed and simply couldn't provide it.

We had the customer order DSL from Verizon for the smaller of the two sites. At first, there was a minor problem since they were using AT&T as their CLEC. Eventually, Verizon brought the DSL in on a separate cable pair on a separate account. Two days late, but they got it there.

Then, it turned out that they set the account up for PPOE, as in for a typical residential user who only uses their DSL for Internet access. We contacted them to change it to provide us with static IP addresses, but it took them eight business days to make it happen. They would not provide us with any technical support on their modem; that we would have to reconfigure these settings on our own through their technical support website. This was nothing but a PDF of the manual for the modem.

Once this was done, the process resulted in a new batch of IP addresses being issued, but they didn't tell us that they changed, so we chased our tails and kept trying to make the original ones work. Eventually, through the grace of God, we got in touch with someone at Verizon with more than a pulse who figured this out. He remotely reconfigured the modem for us in about two minutes. Our technicians literally watched the "sync" lights come up on the VoIP cards while he was on the phone with them.

Two weeks after the DSL was installed, it is finally working. Months of wasted time, and countless dollars down the drain, but at least the systems are working properly and the customer is happy.

The customer hand-delivered a check for the second half of the system relocation and one invoice for our time spent on-site troubleshooting the IP situation. We'll probably never recover payment for the dozens of hours spent on this matter, but at this point, I am glad to see it resolved.

Now, here's the punch line. The customer will be closing one site within three months and consolidating them in one building. :bang:

I wanted to wait at least a week before posting back about this matter just to make sure it remains working. So far, so good. Thanks to all of you for your ideas and assistance.

Dear ev607797,


You wrote:

"Now everything is 24.XXX.XXX.XXX at both ends with the same subnet."

Just because both ends have an address of 24.xxx.xxx.xx does not mean they are on the same subnet. You need the entire IP address and SUBNET MASK of each system to tell if they are on the same subnet.

You also wrote:

"We do have different static IP's for each network card. It's the fact that these IP's are in the same subnet that is apparently causing the problem."

This is very unlikely to be the problem. The most likely problem is that the configuration of both systems needs to be changed to reflect the new IP address and other network information. In particular the security information needs to be changed and any security certificate needs to be updated.

If you have solved this problem, I would like to know how. Did switching to a different internet service provider solve the problem?

Yes, it was resolved on July 5. I detailed what we did in my post right before yours. Thanks for checking in anyway.