Link to home
Start Free TrialLog in
Avatar of meade470
meade470

asked on

Policy-basd Routing on the PIX

Does anyone know it it's possible to do policy-based routing on the PIX, ver 6.3(3)?  I'd like to direct traffic from a specific host through our VPN tunnel.  To do this, the PIX would have to disregard the routes in the routing table for that specific host.

Thanks!
Avatar of Les Moore
Les Moore
Flag of United States of America image

Not unless you upgrade to PIX ver 7.0(1)

However, what you are trying to do is simple with access-lists that define the traffic that must be encrypted (your host to remote network), applied to the crypto map that defines the destination peer (next hop). That's basically the same thing.. just that the other end needs to also define their traffic to come back you your host.

Do you already have an existing VPn tunnel between the two networks?


Avatar of meade470
meade470

ASKER

Thanks, lrmoore.

I currently have a working VPN across the 2 sites.  The probelm is that I also have a T1 connecting the sites.  

This is my existing network (abbreviated, somewhat):
192.168.25.170 (MyPC) --> 192.168.25.1 (2611 Cisco) --> T1 -->192.168.17.0 network (Cisco 1711)

This is how I'd like traffic to go for MyPC:
192.168.25.170 (MyPC) --> 192.168.25.1 (2611 Cisco) --> 192.168.27.254 (PIX 515) --> Internet --> 192.168.19.257 (PIX 506) --> 192.168.17.0 network (Cisco 1711)

I'd like traffic from MyPC to ignore the routing tables and head straight for the VPN at its local PIX.  I can do this at the 2611 with PBR.  But the PIX ver 6.3 doesn't like PBR.  Is there any other way/workaround to make this happen?

Thanks!!!
Why not configure a GRE tunnel connecting the two sites and run IPSEC across the tunnel. This would give you an additional
network in which to route to for the remote network.

Is routing dynamic or static in you environment?

You could also prefer the VPN route over the T-1 route by either assigning a higher metric to the less desired route.


harbor235
harbor235:  You could also prefer the VPN route over the T-1 route by either assigning a higher metric to the less desired route.

Could I do this for a specific host?  I don't want all the traffic to cross the VPN, just traffic from MyPC.

Thanks!!
Then you simply define the VPN traffic as host x.y.z.z to subnet a.b.c.0 in your acl for the vpn, and create a static route on the PC for that subnet to go to the pix

 C:\>route add a.b.c.0 mask 255.255.255.0 <ip of pix>
lrmoore,

I can't do this because the IP of the PIX is off the network my PC is on.  (I'm no 192.168.25.0; the PIX is on 192.168.27.0.)

Any other suggestions?  I don't know if this is possible without PBR or 7.0.  What a drag.
As long as the PIX has a route to you (can you ping the PIX IP address?)
If yes, then it should not be a problem...
I can ping the (192.168.27.254) PIX without a problem.

What I believe is the issue might be best represented in the following diagram:

      Internet
      |          \
      |            \
            PIX 1          PIX 2
      |        \
      |                  \
      |           \      
 192.168.17.0          192.168.25.0      
      |                      |
      |                      |
     (Cisco 1721)
           (Cisco 1721)    
                ----- T1 ----------



Ugh.  Lets try this one instead:
(Note:  Graph is "abbreviated")

      Internet
      |         \
      |          \
    PIX 1      PIX 2
      |             \
      |              \
      |               \      
 192.168.17.0     192.168.25.0 (where the 192.168.25.170 pc would be; default route is PIX 2)      
      |                |
      |                |
     Cisco 1721      Cisco 1721---------------(more networks/T1s/etc)
                |                |
       ---- T1 -----

There is a VPN between the PIXes.  PIX 2 believes (via the routing tables) that the route to 192.168.17.0 exists through the Cisco 1721 beneath the 192.168.25.0 network.  The route does, in fact, exist.  This is preventing me from routing traffic from 192.168.25.170 to 192.168.17.0 through the VPN tunnel.  (Which is what I want, to test the effectiveness of the VPN tunnel in regards to speed and application response.)

Thanks!! Your help is appreciated.
Sorry about those graphs.  They were clean until I hit Submit; I don't get it.

The bottom of the graph should indicate the following:
1.)  There is a T1 connectino between the 1721s.
2.)  The right-most 1721 has other network connections to it.

Anytime you have a router on your internal network and pix connected to the internet, it is much cleaner and easier on yourself if you set your PC's default gateway to the 1721 and not the PIX (absolutely must be this way on both sides). The 1721 then has its default pointing to the respective pix. PIX 2 does not have to know about .17.0 subnet at all and the static route gets removed..
This way, you have two easy choices to run your test -
1) use policy-based routing on the 1721 to only route your PC's source IP out the PIX to the remote side (must do it on both routers for return traffic)
2) use static route on your PC to direct your own traffic destined for the .17.0 network to the PIX2, bypassing the 1721.. but the host on the other side that you want to talk to must also have a static route to your host pointing to PIX1

That makes sense.

The routes in the PIX are actually not static routes, but rather learned from OSPF.  I have always suspected this is unneccessary (not our config).  Does the PIX even need routing tables?  It only has two interfaces--shouldn't it by nature know the interface to put specific traffic on?
ASKER CERTIFIED SOLUTION
Avatar of Les Moore
Les Moore
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Aha!!  I finally see what you're saying!

Thanks for sticking it out with me.  I appreciate it.

One last question, if you don't mind:  What is the command for OSPF entries in the PIX?  I couldn't find them in the config.

Thanks again.