- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
02-14-2016 02:06 PM
I have an issue where we have mulit-VRs in place 1) default and 2nd) VR that is utilized for DMZ and untrust routes
Both VR's share a common zone name "public" for example.
I have issues routing where for instance I have my internal network segments in the VR's FIB's and my routed networks fail to return back through the correct interfaces.
I have a need for select internal subnets but RFC 1918 and Public routed ranges reaching into into the DMZ for administrating a Server.
The security policy logic is in place and sound transit zone VR default > public zone (VR Untrust/DMZ) with applications ssh,ssh-tunnel.
This DMZ server also has restricted subnets from Public zone to allow Untrust traffic to server.
Issue my my server works from untrust perspective, however if my more trusted zones access the server in the DMZ I don't get traffic there.
Server is a Virtualized we got it to route properly once we added a second v-nic to the host server and had the server administrator add static routes pointing out a different gateway which lays in the VR default.
I am hoping as we build and scale this network edge / dmz services over the internet that we don't have to apply host routing and allow OSPF to take place and advertise into both respected Virtual Routers.
Still working with TAC on this.
02-15-2016 05:05 AM
Hi!
could you provide a schematic to help us gain some insight into your design ?
If you want to keep networks separate through multiple VRs, I would recommend also changing the zones so none are shared to prevent confusion or accidental overlap. To enable intra-VR routing, static routes need to be added in the VR where you assign the other VR as next hop and a returning static route needs to be in place to allow the traffic to take the same route back
03-24-2016 05:03 AM
Sorry for not getting back we ended up putting static routes to next hop vr XYZ. Until we want to decide going down the BGP option or the OSPF with loopback (port to port) on PA in different VR's.
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!