- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
05-18-2015 08:05 PM
I have a firewall running in layer-3 mode. I've got multiple separate virtual routers on the inside, there is no overlapping address space in any of these. I need all of these to share one outside internet connection. I'd like to do it without static routes (other than the main default to the outside).
Right now I have the outside virtual router separate from the inside ones. In the inside virtual routers, I am advertising a default route in OSPF with a next hop pointing to the outside virtual router. My problem is coming back in from the outside. Traffic comes into the outside virtual router, but it doesn't know where to go. I can static 10/8, 172.16/12, and 192.168/16 back into one of the inside virtual routers, but not all at the same time. I could go through and manually list each individual route as statics back to the proper inside virtual router, but I really don't want to have to keep up with that.
One idea I've come up with is to run BGP between each inside virtual router and the outside virtual router and redistribute OSPF into BGP so it knows what routes are in each virtual router. But not redistribute BGP back into OSPF. I don't want to bridge the inside virtual routers, I want users to go outside and back in to get from one to the other.
Is this a good way to do it? Is there another, or better way to accomplish this?
05-19-2015 04:08 AM
I would use BGP for this setup with each inside VR having a peer to the outside VR but noone else.
On the inside
Import policy to accept default exact and deny everything else
Export policy to send connected routes (and static if you have more behind this)
On Outside
Export policy to send default route exact only
Import policy to accept everything
This should give you the routing table you need.
On the security policies each inside VR would need to be a different zone. You would allow the traffic only from each inside zone out to the internet but nothing between the inside zones to each other. This will drop all their traffic by default without needing to create policies.
05-18-2015 08:27 PM
howardtopher
If static routes doesn't work for you, then redistribution between dynamic routing protocols is the next best option. I guess there is no way to prevent briding between virtual routers because you need to advertise default routes into the inside of these VRs. Any host inside one of these VRs, will send traffic using the default route, and if the destination exists in another VR it will go there. You need to control the traffic using security rules. So I guess it doesn't matter if you distribute BGP into OSPF or not, unless you have a big BGP routing table, but if not than this should not make any difference.
Amjad
05-19-2015 04:08 AM
I would use BGP for this setup with each inside VR having a peer to the outside VR but noone else.
On the inside
Import policy to accept default exact and deny everything else
Export policy to send connected routes (and static if you have more behind this)
On Outside
Export policy to send default route exact only
Import policy to accept everything
This should give you the routing table you need.
On the security policies each inside VR would need to be a different zone. You would allow the traffic only from each inside zone out to the internet but nothing between the inside zones to each other. This will drop all their traffic by default without needing to create policies.
05-21-2015 03:30 PM
I figured BGP would be the way to go, but I was unsure of exactly how to pull it off.
It took me a couple days to get around to it, but I just finished trying it out and it works perfectly.
Thanks so much for pointing me in the right direction.
05-21-2015 03:35 PM
Glad to hear you have a successful implementation. Always feels good when they are complete.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!