- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
09-24-2010 02:07 PM
Hello all,
I currently have the following:
e1/1 - untrusted - L3 interface - "Internet_VR"
e1/2 - trusted - L3 interface - "Internet_VR"
We have an MPLS network handled by our ISP that links remote facilities back to corporate HQ. For the most part the remote facilities can be considered "Trusted," but it would be nice to be able to segregate traffic, so I'm hesitant to put them in the "trusted" zone.
The MPLS handoff is going to be ethernet, so I'm setting up e1/3 for this, I've created a new zone called "MPLS", and a new virtual router called "MPLS_VR".
I need for the MPLS traffic to be able to reach certain hosts on the "trusted" interface, as well as have Internet-bound traffic from the MPLS get routed and NAT'ed out the untrusted interface.
I'm not exactly sure how to set this up.
Should the MPLS have its own virtual router? Or does it need to be a part of the main "Internet_VR" if I want MPLS traffic to be able to reach the internal LAN and the internet as well? There are multiple subnets on the MPLS - several different /24s from private address ranges. I'd like it to work with the least amount of rules on my end - I basically want all of the MPLS traffic to be treated exactly like my normal LAN traffic and get NAT'ed out the internet, unless I have rules allowing it to go to my LAN instead.
09-24-2010 02:16 PM
Hi There,
The simplest solution would be to keep the MPLS interface in the same VR as the others and put it in the Trust zone. This way your networks will route and nat just like the local LAN traffic and you don't need any security policy for traffic to flow between sites.
If you use a different zone, you will need to allow the traffic with a security policy.
If you use a different VR, you will need to somehow route between them. Today that would require a physical cable between VR's and static/dynamic routes. I would not recommend doing this.
Since there is only a single connection to the MPLS cloud, the easiest routing solution would be to configure one or more static routes out to the MPLS next hop in the same VR as the other links. You could also use a dynamic routing protocol if your provider supports it and you are currently using that for your other sites, but there is probably no point since there is only a single connection.
Hope that helps.
Cheers,
Kelly
09-24-2010 02:16 PM
Hi There,
The simplest solution would be to keep the MPLS interface in the same VR as the others and put it in the Trust zone. This way your networks will route and nat just like the local LAN traffic and you don't need any security policy for traffic to flow between sites.
If you use a different zone, you will need to allow the traffic with a security policy.
If you use a different VR, you will need to somehow route between them. Today that would require a physical cable between VR's and static/dynamic routes. I would not recommend doing this.
Since there is only a single connection to the MPLS cloud, the easiest routing solution would be to configure one or more static routes out to the MPLS next hop in the same VR as the other links. You could also use a dynamic routing protocol if your provider supports it and you are currently using that for your other sites, but there is probably no point since there is only a single connection.
Hope that helps.
Cheers,
Kelly
09-24-2010 02:25 PM
Kelly,
OK, that makes a lot of sense. The current setup is a Cisco 1800 with a couple of T1s in multilink, and it is on the trusted network currently.
The ISP currently doesn't run any routing protocol over it, but we have discussed possibly using OSPF. We have >38 remote sites, each with two separate /24s that need to be passed across the MPLS (a 10.x for phone/voip traffic and a 192.168.x /24 for data). Due to this, it makes the routing table a bit of a mess on the corporate end, (I have 3 sites setup now with a Cisco 1800-series and I have 6 static routes for them).
I suppose I could just feed it larger subnets though? Is the routing in the PAN smart enough to understand that a local subnet should have lower metric than a static route? I.e. if I enter 10.0.0.0/16 and route it to my MPLS gateway, but I have the subnet 10.0.1.1/24 defined on a local interface, is it smart enough to pass the traffic for 10.0.1.20 (for instance) across the local interface but then route traffic for 10.0.105.119 across the MPLS?
I'm not certified in any networking and I understand just enough about subnets and IP routing to be dangerous to myself and others.
09-24-2010 02:31 PM
No worries!
You are absolutely correct - the PAN will understand that more specific subnets take precedence in routing, so connected routes on your LAN will supercede more general static routes.
You should be able to get away with two static routes pointing to your MPLS: 10.0.0.0/8 and 192.168.0.0/16.
When you take a look at the routing table (show routing route) you will notice the connected routes and the static routes living in harmony.
Cheers,
Kelly
09-24-2010 02:37 PM
We're not currently using any of the second octet in the 10/8 block, so just to simplify things I was shooting for 10.0/16 Each facility is never going to have more than 200-some phones so a /24 per location is fine, and at the moment we aren't anywhere near 254 facilities, so /16 works to summarize those and I can leave that 2nd octet free for future expansion.
Now if only I had a way to automate translating all of my rules from our old Sonicwall into PAN-speak so I could get this thing live... Every time I sit down to try to work on rules something else comes up. :smileysilly:
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!