Multiple WAN interface setup for router
Need education on 5 WAN IP block (same subnet) and the MPOE running up a fiber connection to the office suite. We walked into this situation illustrated below. There is one circuit coming into the suite. The internet service installed a 200 megabit fiber connection at the MPOE. A couple businesses want their own separate public WAN IPs running off of this one circuit. There is currently a couple TP Link routers that we like to replace. What device (switch? what kind of switch? Any problems using one switch over another one?) do we use between the biscuit (one ethernet port) and the multiple WANs on the Sonicwall? Here's what we summed up the ultimate game plan below...
Use a Sonicwall Tz 500(a model with at least x8 interfaces) and configure 2 additional interfaces as WAN ports - this would then give us 3. Each of these we can configure with their own static IP accordingly. Next we would configure a LAN interface for each company. Then we would use Policy Based Routing to move traffic from example: LAN 1 "Company A" to WAN 2. Sonicwall also provides QoS I believe which will support VOIP traffic through the routing.
Use a Sonicwall Tz 500(a model with at least x8 interfaces) and configure 2 additional interfaces as WAN ports - this would then give us 3. Each of these we can configure with their own static IP accordingly. Next we would configure a LAN interface for each company. Then we would use Policy Based Routing to move traffic from example: LAN 1 "Company A" to WAN 2. Sonicwall also provides QoS I believe which will support VOIP traffic through the routing.
Being that the ip's are on the same subnet, you most likely won't be able to assign an address per wan interface. This is a perfect scenario where you'd want to use a private vlan feature. I don't know if the switches you have can do this or not. Essentially, you would create a primary vlan, which is the subnet that the block is part of. Then you would create isolated secondary vlans which would be assigned to each company. The interface out to the provider would be promiscous (able to communicate with each isolated secondary vlan) but the isolated vlans won't be able to talk to each other.
Since all of the 5 IPs are in the same subnet and on the same circuit, you could replace all of the routers with the Sonicwall. You would only need one WAN port, no switch necessary. The Sonicwall could have multiple LANs or VLANs defined on it. Note that this ties everyone together a bit more tightly. So you'd have to be sure to do the following:
1) Bear in mind that you're going to be responsible for all of the firewall changes since everyone's running off the same device
2) Make sure that you prevent LANs from talking to one another. (Specifically, make sure that one company's LANs cannot talk to another)
3) Create NAT policies. This way, you can ensure that traffic of each company properly translates to the public IP address of that company. (And vice versa)
4) Bear in mind that if you need more than the 5 total IPs you have now, you're going to most likely get assigned a totally new block in place of what you have now, which changes the IPs for everyone.
5) Be sure to properly document and label any rules/objects that are specific to one business
Just let me know if you need more help/detail on this one.
1) Bear in mind that you're going to be responsible for all of the firewall changes since everyone's running off the same device
2) Make sure that you prevent LANs from talking to one another. (Specifically, make sure that one company's LANs cannot talk to another)
3) Create NAT policies. This way, you can ensure that traffic of each company properly translates to the public IP address of that company. (And vice versa)
4) Bear in mind that if you need more than the 5 total IPs you have now, you're going to most likely get assigned a totally new block in place of what you have now, which changes the IPs for everyone.
5) Be sure to properly document and label any rules/objects that are specific to one business
Use a Sonicwall Tz 500(a model with at least x8 interfaces) and configure 2 additional interfaces as WAN ports - this would then give us 3.This only becomes necessary if there are multiple circuits, which you don't have. Reasons listed above. However, some of those interfaces would be useful in other respects (namely LANs), depending on how many businesses are would be behind this Sonicwall.
Just let me know if you need more help/detail on this one.
ASKER
I think we are going to repurpose one of these TP link 5 port router/switch guys. Use one them to handle the initial load coming off the circuit and deploy the TZ 500 for router LAN traffic.
I don't want too place too much load on the sonicwall.
I don't want too place too much load on the sonicwall.
Actually, it wouldn't be too bad. I've done your type of scenario with older units. Just get an idea of what the load is.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I agree with Fred by seperating the 5 companies with their own firewalls by placing a switch between the handoff and the 5 devices, each individually owned by each company is the best way to go. If you control the vlans and internet traffic to all companies then you will be liable if any unwanted access or breach occurs.
So I'm going to post a few scenarios:
1) Dumb switch + Sonicwall w/ multiple WAN interfaces
Pointless. The Sonicwall looks at not only the IP address(es) set on its WAN interfaces, but can also work with other IP addresses in its same subnet. Jump to #4 for a much better setup.
2) Dumb switch + Sonicwall + other router(s)
Mixed bag. The Sonicwall looks at not only the IP address set on its WAN interfaces, but can also work with other IP addresses in its same subnet. While you can do this, there is a possibility of getting errors on the Sonicwall related to the fact another device is using a public IP in the same subnet. Dumb switch cannot control bandwidth to any given router. Multiple devices to maintain.
3) Dumb switch + several routers
Upside: Can have one router for each company. If at least one of the companies wants a Sonicwall, see #2.
Downside: Multiple devices to maintain. Dumb switch cannot control bandwidth to any given router.
4) Sonicwall only
Upside: Only one device to maintain. Able to handle the block of public IP addresses. Should be able to manage all of the traffic, especially given the routers that you've mentioned are currently in place. Can control bandwidth via Global Bandwidth Management.
Downside: Single point of failure for all of the companies. Breach of firewall leaves you switch multiple companies to have to account for. You have to be sure to properly segregate the traffic, and carefully plan out and document the rules.
A managed switch may help you fix one of the flaws of #2 and #3, which would be ability to control bandwidth (remember that all multiple routers behind a dumb switch will all fight for traffic on their WAN interfaces).
All of that said, I would personally go with #4. #1 is making your life harder than it needs to be for your scenario. #2 or #3 can be done, but unless the companies aren't in agreement OR the landlord (who I presume is one of the 5 companies), I really don't see a reason to go those routes. I could also point out that #4 is done way more than you think (shared workspace companies are a perfect example)
1) Dumb switch + Sonicwall w/ multiple WAN interfaces
Pointless. The Sonicwall looks at not only the IP address(es) set on its WAN interfaces, but can also work with other IP addresses in its same subnet. Jump to #4 for a much better setup.
2) Dumb switch + Sonicwall + other router(s)
Mixed bag. The Sonicwall looks at not only the IP address set on its WAN interfaces, but can also work with other IP addresses in its same subnet. While you can do this, there is a possibility of getting errors on the Sonicwall related to the fact another device is using a public IP in the same subnet. Dumb switch cannot control bandwidth to any given router. Multiple devices to maintain.
3) Dumb switch + several routers
Upside: Can have one router for each company. If at least one of the companies wants a Sonicwall, see #2.
Downside: Multiple devices to maintain. Dumb switch cannot control bandwidth to any given router.
4) Sonicwall only
Upside: Only one device to maintain. Able to handle the block of public IP addresses. Should be able to manage all of the traffic, especially given the routers that you've mentioned are currently in place. Can control bandwidth via Global Bandwidth Management.
Downside: Single point of failure for all of the companies. Breach of firewall leaves you switch multiple companies to have to account for. You have to be sure to properly segregate the traffic, and carefully plan out and document the rules.
A managed switch may help you fix one of the flaws of #2 and #3, which would be ability to control bandwidth (remember that all multiple routers behind a dumb switch will all fight for traffic on their WAN interfaces).
All of that said, I would personally go with #4. #1 is making your life harder than it needs to be for your scenario. #2 or #3 can be done, but unless the companies aren't in agreement OR the landlord (who I presume is one of the 5 companies), I really don't see a reason to go those routes. I could also point out that #4 is done way more than you think (shared workspace companies are a perfect example)
My hope would be that any competent networking person could replace the idea of a "dumb switch" with something more suitable for the situation. So far, the only situational information is that some want their own public IP addresses. So this would be fine.
But if more controls, bells and whistles are needed or wanted then by all means substitute what I called a "dumb switch" for pedagogical reasons with anything more capable. I actually prefer a managed switch for this - and those generally come with bandwidth controls, etc.
Anyway, the focus on responding to "dumb switch" is most unfortunate.
But if more controls, bells and whistles are needed or wanted then by all means substitute what I called a "dumb switch" for pedagogical reasons with anything more capable. I actually prefer a managed switch for this - and those generally come with bandwidth controls, etc.
Anyway, the focus on responding to "dumb switch" is most unfortunate.
I would go with the Sonicwall only and used port based LANs for each of the companies. The sonicwall can handle all the WAN ip addresses and you can use routes to take each LAN out it's own IP. And firewall rules to block LAN to LAN access. This will keep the sonicwall config pretty simple. Plus the TP-Links are junk :-)
oh forgot to add, yes setup the sonicwall to prioritize the voip traffic. (BMW)
The sonicwall can also handle multiples WAN IP's on different physical ports too, but in this scenario that doesn't make sense.
As long as your Sonicwall model can handle your load.
If the load is too much, then I would agree with the other suggestions, add a switch on the WAN connection and separate the firewalls physically on that WAN switch.
oh forgot to add, yes setup the sonicwall to prioritize the voip traffic. (BMW)
The sonicwall can also handle multiples WAN IP's on different physical ports too, but in this scenario that doesn't make sense.
As long as your Sonicwall model can handle your load.
If the load is too much, then I would agree with the other suggestions, add a switch on the WAN connection and separate the firewalls physically on that WAN switch.
zubar75 suggests something that I'd not thought of. We should make sure it's well understood (and whether I got it right:
It sounds like:
You could put the entire public subnet block on a single WAN interface. This would take up one of the public addresses for the router (in addition to the gateway/source).
This would deal with the idea of routing a public IP to a private subnet EACH and makes sense.
What it *could* do is *assign* a public IP address per company for addressing from the public internet.
But it wouldn't segment the firewall functions "per company" nor provide any of them with their own public IP address to handle.
Is that correct?
It sounds like:
You could put the entire public subnet block on a single WAN interface. This would take up one of the public addresses for the router (in addition to the gateway/source).
This would deal with the idea of routing a public IP to a private subnet EACH and makes sense.
What it *could* do is *assign* a public IP address per company for addressing from the public internet.
But it wouldn't segment the firewall functions "per company" nor provide any of them with their own public IP address to handle.
Is that correct?
It can segment both LAN and WAN to each company.
It can, you could create LANs on separate ports (or Vlans), I am suggesting ports. Then set firewall rules to block and traffic between the LANs, and add a routing rule that would route traffic from specific LANs out specific WAN IP.
So each company gets its own LAN and it's own specific WAN IP. You can then also isolate any incoming traffic (NAT rules) on static IPs to specific LANs (companies), if so desired.
It can, you could create LANs on separate ports (or Vlans), I am suggesting ports. Then set firewall rules to block and traffic between the LANs, and add a routing rule that would route traffic from specific LANs out specific WAN IP.
So each company gets its own LAN and it's own specific WAN IP. You can then also isolate any incoming traffic (NAT rules) on static IPs to specific LANs (companies), if so desired.
It sounds like there is agreement on these matters.
...
WAN <> Switch - Router 3 - Wan IP 5