Same subnet on different physical WAN/LAN segments.

hi all,

is this possible.

network 1 - 10.3.3.0
network 2 - 192.168.50.0

they are connected via VPN. all traffic is flowing nicely apart from the phones.

the client has bought a VoIP phone system which needs to be on the same subnet, is it possible to 'trick' the 192 network to have a 1x 10.3.3.0 IP address on its network so that the phones can talk back to the phone system? And then to have the routing on the routers to move the traffic correctly.

Thanks
Gareth
Gareth McKeeCEO/OwnerAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Timothy EstesSr. Voice EngineerCommented:
I assume that you have DHCP working on both of these VLANs / subnets.
If you put both IP Subnets on the same VLAN, you would have to disable DHCP on the phones (or the data VLAN). This is totally a bad idea, but if you have a Cisco router and use IP Secondary, both IP Subnets will work. Again this is definitely not Best Practice. If you don't have a Cisco router, the IP Secondary function may be named something else, or not supported.
Fred MarshallPrincipalCommented:
I don't like to discuss things like this using loose terminology.  So, for reference, here is what I suggest:
1) I don't know exactly what a "network" is.  It could be a lot of things..... so unless it's clear or clearly shorthand, it's best to not use it when trying to get things straight.
2) You have:
subnet 1 - 10.3.3.0
subnet 2 - 192.168.50.0
Except for the mention of a VPN, there is nothing that I see that describes the physical network or LANs or .....

So, I'm going to make a bunch of assumptions:
Subnet 1 has a physical LAN with an internet gateway with its own public IP address.
Subnet 2 has a physical LAN with an internet gateway with its own public IP address.
The VPN is between the two LANs using their individual internet gateway devices as their VPN terminations.
Their public IP addresses and the remote LAN address are part of the VPN setup.
I hope so far, so good.

Now to the phones and your ultimate objective:
"The client has bought a VOIP system which needs to be on but a single subnet."  Is that the correct interpretation?
BUT, the client want to have VOIP phones on both subnets just the same.  Is that the correct interpretation?
SO, the implication is that one site will have the internet feed for the VOIP and the other will be using the VPN for the VOIP connection to the outside world.  Is that the correct interpretation?
If all this is correct then I would encourage you and the client to reconsider by answering this question:
Q: "Why is it not possible to access the VOIP servers from anywhere / from any public IP address?"
The implication here is that it would be far better to access the phone service through EACH internet gateway - site for site or subnet for subnet.

I'm sure there's more to be discussed but this stuff ought to be clear first.....
Robert OrnelasVP Operations at Cook's ComputerCommented:
what type of phone system is it? can you add the subnet as a trusted network? you can possibly add a static route to the gateway and assign static ips to the phones routing them to the correct subnet.
Price Your IT Services for Profit

Managed service contracts are great - when they're making you money. Yes, you’re getting paid monthly, but is it actually profitable? Learn to calculate your hourly overhead burden so you can master your IT services pricing strategy.

masnrockCommented:
1) You should ideally keep VoIP traffic on a separate VLAN/subnet
2) Depending on your network layout, along with the type of phone system you have, there could be a few different ways to solve the communication issue

Please give us information about your network, along with the type of phone system you have in place.
atlas_shudderedSr. Network EngineerCommented:
Post a diagram of what you are trying to explain please.
Gareth McKeeCEO/OwnerAuthor Commented:
Hi Fred - all your assumptions are correct.

The phones system at HQ is an Avaya, the base station which we are trying to put in at the other location is also Avaya, but it will only work if on the same subnet as the phone system itself. A major flaw but we are where we are.

Voice on different VLAN - I agree normally, this is only a small set up with 2 phones at one location and 1 at the other. Small amount of PCs also, no need (and no money) for even marginally expensive routers/swiches to achieve this.
masnrockCommented:
Small amount of PCs also, no need (and no money) for even marginally expensive routers/swiches to achieve this.
We still need to know what you have in order to have an idea of what we are working with here.
Gareth McKeeCEO/OwnerAuthor Commented:
head office
router - cisco asa 5505
switch - unmanaged
phone system - Avaya IP 500 V2
phones - a mixture of softphones on  PCs and 1x hard phone - all work fine

connected to satellite office through VPN

Satellite office
router - cisco rv180w
switch - Netgear GS752TP
phone base station - D100 Avaya base station
Fred MarshallPrincipalCommented:
head office
router - cisco asa 5505
switch - unmanaged
phone system - Avaya IP 500 V2
phones - a mixture of softphones on  PCs and 1x hard phone - all work fine

connected to satellite office through VPN
By this, you apparently mean that there is a VPN tunnel via the internet and NOT a private link such as MPLS, right?

Satellite office
router - cisco rv180w
switch - Netgear GS752TP
phone base station - D100 Avaya base station

The phones system at HQ is an Avaya, the base station which we are trying to put in at the other location is also Avaya, but it will only work if on the same subnet as the phone system itself. A major flaw but we are where we are.
I don't know what you mean by "the phone system" here.  So saying "on the same subnet" is still too vague.
OK, so I'm not a VOIP expert and certainly not an Avaya system expert.  But some things are still fairly fundamental.
Where is the PBX?  Is it in the Avaya equipment (each?) or in the cloud?
What do you mean by "the phone system"?
Where is the PBX function?
WHY do some things have to be "on the same subnet"??
Gareth McKeeCEO/OwnerAuthor Commented:
Hi Fred,

VPN - across internet, no MPLS

The phone system  - the PBX
Subnet - the locally hardwired LAN

The PBX is in the head office

The base has to have an IP from the same subnet as the PBX - 10.3.3.0 - where as it is located at the satellite office which is 192.168.50.0 - this is by design, i dont know why?
Gareth McKeeCEO/OwnerAuthor Commented:
apologies for mixing my terminology.
atlas_shudderedSr. Network EngineerCommented:
There are a couple of things I can think of that may help to alleviate the trouble.

1.  NAT the remote site phone traffic at the WAN side edge.  This would require 1 to 1 NATs
2.  Attempt building L2TP connection between your remote site and the corporate head end.  This would allow you to extend the 192 network across the WAN to the remote site.

Most I can do with the information at hand.
Fred MarshallPrincipalCommented:
Gareth:  Thanks for the clarification, that helps a lot.
In small systems at least, the VPN has to terminate at *different* subnets.  I think you might imagine how addressing would work (or not work) if the two subnets were the same.

Maybe a good way to think about this is as if the VOIP phones are like any other device.  
Surely you can address from one site to the other over the VPN.
So, you can address a remote phone the same way.
Probably the trick here is that the phone system only addresses phones in one subnet, right?

I might try this as a wild thought.  I have no idea if you can make it work.
So consider this a strawman approach that could stand improvement......
Use 192.168.50.0/24 as now.
Switch 10.3.3.0/24 to 192.168.51.0/24.
Set the VOIP subnet to 192.168.50.0/23 and avoid using 192.168.50.254 for any device - as it is the broadcast address for 192.168.50.0/24.
Now the VOIP subnet can address devices at both sites on "its own" subnet; phones at one site within the 192.168.50.0/24 range and phones at the other site within the 192.168.51.0/24 range.
Ideally, I would have the phone system at the site using 192.168.51.0/24 so their broadcast addresses would be the same 192.168.5.254.
But doing this may create other problems and I can't be sure that it won't.
I can certainly identify things that could happen but can't guarantee that they *will*.
If you do this there is little I can see that can go drastically wrong and you can always fix the subnet in the phone system to be /24 if it doesn't work with /23.
In that case you are no worse off than now.
atlas_shudderedSr. Network EngineerCommented:
Any traffic destined for the remote half of the /23 will never leave the local network because it will not be seen as non-local. Basic networking.

Like I said.  L2TP or NATing.
Fred MarshallPrincipalCommented:
atlas_shrugged:  I realize it's a bit of a stretch to consider overlapping subnets.  So, consider:
EACH site's network is using one of the two /24 subnets.  
THE VOIP devices only are using the /23 subnet.

If a VOIP device is located at the site of the lower /24, it will also be required to be on the the lower end of the /23.
If it is transmitting to a device at the upper end of the /23 the surrounding network will see the address as "not in this subnet" AND "accessible via the VPN").  So, the packets will be directed to the VPN and will arrive at the site using the upper /24.

I didn't say that this would work for sure but what I've described above - taken in isolation - surely will.  
Things like broadcast addresses would be a concern.
atlas_shudderedSr. Network EngineerCommented:
You would still have to use a /24 mask to get IP to forward traffic to the gateway when going from upper to lower and vice versa.

If both sides stay IPed as /23s then the traffic stays local, doesn't matter if you physically split high/low at the actual sites. IP won't even able to calculate non-local between high/low.

If you keep them /23 on the hosts but /24 on the gateway, this doesn't change a thing. The local host is never going to unicast to the router in an attempt to send traffic to the upper half/lower half, whichever is applicable. Local host will simply ARP themselves to death.  Which takes us to proxieARP. You could try this, but then you get into both the security and the care and feeding. You'd ultimately open yourself to a ton of headaches and very hands on administration.

If you make them /24s, then you defeat the point of the exercise. The networks are now remote to each other.
Fred MarshallPrincipalCommented:
atlas_shuddered:  Well, I'm trying to postulate a potentially feasible solution.  I just don't know if it will work in the broader context of things - especially broadcast address situations.  The idea was that the VOIP devices only would use the /23 subnet mask.  Everything else on the /24 subnets - including the routers.  So the non-local VOIP traffic would be non-local.

But, as you point out, it may be that ARP won't work.
atlas_shudderedSr. Network EngineerCommented:
Its basic networking.  Broadcast traffic will not traverse the boundary between layer 2 and 3.  Confined to local network only.

Additionally, you don't have a /23.  You have two /24s that you are attempting to fool into thinking they are a /23 but act like /24's.
Fred MarshallPrincipalCommented:
Additionally, you don't have a /23.  You have two /24s that you are attempting to fool into thinking they are a /23 but act like /24's
That's your construct, not mine.  Anyway, you have made the case that it won't work.
robocatCommented:
Let's try to uncomplicate things instead of making them more complex. And assume that you want to stick to the current IP ranges for the main and remote site.

>the base station which we are trying to put in at the other location is also Avaya, but it will only work if on the same subnet as the phone system itself
>The base has to have an IP from the same subnet as the PBX - 10.3.3.0 - where as it is located at the satellite office which is 192.168.50.0 - this is by design, i dont know why?

Provided all devices are properly configured, this is simply not true. Don't let them tell you this is impossible.

The base station should work if it has an IP in the range 192.168.50.0 and all routing is set up towards the PBX without firewall limitations.

Things to check that could be wrong:
- IP, default gateway and subnet mask of the base station is not correct for range 192.168.50.0.
- routing is not correctly set up on the PBX (no default GW, no correct subnet mask, ...)
--> Check if the basestation can ping the PBX and vice versa

Also check if there's any firewall rule or any VPN rule that would restrict full network access for any of these devices. Make sure there are no NAT rules.
Gareth McKeeCEO/OwnerAuthor Commented:
Hi Robocat,

I completely understand your frustration, but from the Avaya engineers themselves, the base station has to be on the same subnet 10.3.3.0.

All traffic from either location traverses the VPN with no issues.

No NAT or any weird VPN rules.

ty
G
atlas_shudderedSr. Network EngineerCommented:
Did you look into the L2TP?  If you have to extend the subnet between the two sites, this is about the only way to get that done.  If you want to buy a pair of nexus 7 or 9ks then you could run OTV.
Gareth McKeeCEO/OwnerAuthor Commented:
Hi Atlas, thanks for the input, if I go to the client asking for the money for a Nexus they will chase me down the road with pitch forks!!
atlas_shudderedSr. Network EngineerCommented:
Understandable.  Was meant to be /sarcasm/.

What you've described has only got a handful of solutions.  Aside from the two that I posted at the top of your question (L2TP or NATmagic), you can consider physical extension of the segment, if the two sites are near enough to each other.

I guess that one other thing you could consider is extending point to point layer 2 type private circuit between the two sites.

The first two are the only ones where you may be able to *potentially, not incur cost, that being dependent on existing technology in environment.
robocatCommented:
>from the Avaya engineers themselves, the base station has to be on the same subnet 10.3.3.0.

I don't specifically know this product, but having a quick look at the manual, I would dare to contradict this:

https://www.thetelecomspot.com/downloads/Avaya/D100admin.pdf

In this manual there are clearly several screenshots showing the base station on a different subnet. I think it is a matter of disabling DHCP on the base station and configuring it with a static ip address and  modifying the discovery process so that it looks on other subnets to find the server.

This how this generally works for this kind of equipment and I can not imagine that Avaya doesn't support this. Of course you need competent engineers that know their stuff and are not too lazy to do a little research instead of immediately saying "not possible".
Gareth McKeeCEO/OwnerAuthor Commented:
hi all, thanks for all the help, it turns out that it should work but the 'central' IP phone system needs an update.

in its current version it will only work on the same subnet, once up to date it will work.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
robocatCommented:
There you go.

“Impossible” is often an excuse for incompetente or pure lazyness of IT engineers. I learned never to accept impossible for an answer.
Gareth McKeeCEO/OwnerAuthor Commented:
I do struggle to understand that the voice engineers who have deployed this 'hundreds of times' did not know this???
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Networking

From novice to tech pro — start learning today.