|
Home > Archive > CCIE > December 2002 > How to allow OSPF across a PIX?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How to allow OSPF across a PIX?
|
|
|
| I am trying to setup a router behind a PIX to be an OSPF router with another router in front of the firewall. I was thinking of doing a tunnel across the PIX. Is there a simpler way of doing it?
Thanks
 | |
| MadChef 2002-12-13, 6:55 pm |
| If you tunnel through the pix, then you kinda negate the effect of the pix since it will simply be passing all tunnel traffic. The way I've done this before is to redistribute OSPF into BGP on the routers on each side of the Pix and then do multi-hop BGP between the two routers. That way the only thing you have to permit on the pix is TCP 179 between your bgp peers and then the particular traffic you want to allow. It's dynamic and its still secure.
I've also seen people doing this with RIPv2, but I think BGP is the more appropriate way to go. Multihop BGP is one of the things BGP was designed to do. Doing this with RIPv2 is really just a good hack.
MadChef | |
| LANlord 2002-12-19, 2:46 pm |
| There is a lot associated with using BGP, however. You must get an AS number. You must make sure that your ISP supports BGP. There are still some tier 3 ISP's that do not use BGP. Also, there is the expense of buying a router that can support a 64mb routing table.
quote:
I've done this before is to redistribute OSPF into BGP on the routers on each side of the Pix and then do multi-hop BGP between the two routers.
Why would you run BGP and OSPF on the inside of the firewall? All you need on the inside is OSPF... right? | |
|
| Well, it is a scenario I was trying to solve.
I would say it would be a lousy practice to do that in real life, inside is inside and outside is outside, mixing both inside and outside in a routing table eliminates one major advantage of a FW! But always remember, in CCIE if there are 4 ways to configure a problem, they will ask you to use the 5th way.  | |
| MadChef 2002-12-20, 5:11 am |
| quote:
Originally posted by LANlord
There is a lot associated with using BGP, however. You must get an AS number. You must make sure that your ISP supports BGP.
I really wasn't involving the ISP at that point as I also wouldn't expect you to run OSPF between you and your ISP, though some do.
The reason I've done this in the past is because the client firewalls off a significant portion of the network and their entire network is running OSPF. Since BGP here is only used internally, you just use one of the private ASes set aside for this purpose. Since it's only internal, factoring BGP into the equation takes little more resources than your IGP took. If you want to dynamically pass routing information through your pix, I know of no other way.
MadChef | |
|
| Well, I would consider running OSPF for a large network a more load on the perimeter router than using simple BGP session with no more than few tables passing through.
If this were a real-life situation, I would recommend running RIP between the FW and the perimeter router and then you have many alternatives to use between the perimeter and the ISP router.
1) You can statically default the traffic to your ISP, even in case of multiple links. However, this solution would be ideal in case of a single link to the ISP.
2) If I am in the ISP shoe, I will never recommend OSPF, instead, I could run something like RIP and then redistribute carefully into my routes. Yes, I know some do OSPF though.
3) In case of multiple links, BGP would be the best way to go. | |
| darthfeces 2002-12-20, 8:45 pm |
| i guess if you wanted to get real tricky you
could pass updates within a gre or gre/ipsec tunnel btween routers.
i can think of reasons as mc said for using
ibgp or private as's
w/multihop.
you could always write an access list permitting
the ip protocol for bgp or ospf ?
check this mosam
http://www.amnh.org/exhibitions/einstein/?src=e_ce | |
| MadChef 2002-12-21, 7:02 am |
| quote:
Originally posted by darthfeces
i guess if you wanted to get real tricky you
could pass updates within a gre or gre/ipsec tunnel btween routers.
If you do that, you also end up sending you traffic through the GRE tunnels, which kind of subverts the FW. 
All, look at this from the point of view of being totally internal and that you need to pass dynamic information pass the firewall. Drop the inclusion of you ISP and because that may not even be an issue. Imagine that you firewall off your server farm, for example. You server farm has multiple paths out of and now you need to determine which path to use based on the reachability of networks well beyond the firewalls. What's the best way to do this? How do you solve the problem attached with a Pix? With Checkpoint this is easy b/c you could just run OSPF on the FW if you're so inclined, but with the Pix this is more difficult.
Comments?
MadChef | |
|
| I know what you mean MadChef, however, in the example you have attached, there won’t be a real need for dynamic routing to pass the FW, if it is only a server farm we are talking about, then you would simply point the default gateway of all servers to may be an HSRP running between the L3 switches, meanwhile the RSM of the switches may run a RIP with the inside interface of the PIXes.
The same way, if you run a rip in the outside interface as well along with the 7206 routers, and as long as the whole outside network is running any form of IGP, you will achieve the desired routing goal. (Trying to avoid static routes so far)
Remember that inside network (if it has a larger number of routers), can still run its own IGP as well, it can be another process id in case of OSPF or another EIGRP AS, but will still have the same exit point hat is being advertised by the FW (after redistributing RIP into the inside IGP).
Now, in life internetworking situations, you can not ignore an ISP being in place. The scenario in this case would be different. Passing default information in the outside interface would be a problem now unless you are running BGP in both 7200 with a full BGP table imported from your ISP, and even then, I still won’t recommend running RIP on the outside interface of the FW.
Consider both 7200 routers in the diagram, each are dual homed to two different ISPs. To be able to access the Internet, you will have the option either to receive default information from your ISP into your IGP, or just broadcast two different default routes from each 7200. And of course, stop running RIP in these two routers as well as the outside interface of both FWs.
Static routes in this case would be the only way to go in order for the network to be bale to access the network behind the FW. You will need to add a static entry in both routers for all the network blocks you have in the inside network or in the DMZ (if exist).
I still can not think of a real need (in a real life situation) to pass dynamic routing information through a FW. I still believe in a complete isolation between both inside and outside. If you keep opening ports one after another in the FW, and keep putting conduits one after another, you are for sure putting yourself more and more vulnerable to network attacks.
Still trying to make it as simple as possible but not simpler.. | |
|
| darthfeces,
Thaks for the link | |
| MadChef 2002-12-22, 5:55 am |
| quote:
Originally posted by mosam
meanwhile the RSM of the switches may run a RIP with the inside interface of the PIXes.
You CAN run RIP with the pix and the RSM, but that will do you little good. The pix can listen passivly to RIP, but can ONLY generate a default route on its inside interface.
Say the link between SiteA & 7206B goes down. Lets say RSM B is the Active HSRP device for all our servers and either gets a default route from the PIXB RIP process or has one configured to point to Pix B. It will have no knowledge of the outage between 7206B & Site A. and will continue to blindly send packets off to PIX B where they will simply fall in a black hole. You lose connectivity even though there is a redundant path.
You could rememdy this by putting both PIX interfaces on the same broadcast network with both 7206s so that the pixes could catch RIP updates, but lets say your 7206s are in geographically disparate areas and this isn't feasible. This was the case when I did this in real life and it wasn't just a server farm, it was a small network running OSPF with maybe half a dozen or 8 routers in it.
What then? I still disagree with you and think you have to pass dynamic information through the Pix.
MadChef
BTW, this is one of the best discussions I've seen on this board in a long time. | |
|
| You are right. Excellent point!
Usually if you have such design, both 7206s will be either in the same data center or in two separate main data centers. So, you still can connect both 7206s either by a WAN link or simple FE/GB link.
If you consider such, you should not run default information in the outside network and instead just have the network blocks you have in the inside configured in the 7206s known through the PIX outside interface, otherwise, in case of a total failure in SiteA forexample, you may experience a routing loop.
In this case if the link you pointed fails, 7206B will receive the IGP updates through 7206A and forward siteA traffic through that link.
mmm. I think this will do it.. hehe.. with no dynamic routes through the PIX.. I still insist.. | |
| MadChef 2002-12-23, 6:33 am |
| quote:
Originally posted by mosam
You are right. Excellent point!
So, you still can connect both 7206s either by a WAN link or simple FE/GB link.
You're right. If you put another routed interface between the 7206s, you'll maintain connectivity as long as 7206 doesn't tank. If your 7206B tanks, you still black hole your traffic because 6509 B has no way of knowing this....
So seperate WAN link between the 7206s or 2 bgp peer points. Your call. I know where my preference is.
MadChef |
|
|
|
|