pix and multiple gateways.

You can use a route command to send all traffic for your inside nets to a particular destination. For that to work, the destination IP must be part of the same subnet as the PIX inside interface; and if you want the combination to be handling "all internet requests" then the inside interface subnet could not match the routed subnet.

For example,

ip address inside 192.168.255.253 255.255.255.252 route inside 192.168.1.0 255.255.255.0 192.168.255.254

where 192.168.255.254 was the IP assigned to the outside interface of the ipcop box that was handling traffic for the 192.168.1/24 inside subnet. The ipcop box would have to be passing the outbound traffic along to the PIX with 192.168.1/24 source IPs.

Basically what I have is a pix gateway of 192.168.1.1 and the ipcop gateway of 192.168.1.251. They are separate pipes out of the network on the same subnet and they have different public ip's.

I want the pix to handle exchange and the vpn's alone, and forward everything else (http, ftp, https etc) over to the ipcop box. I need a sample command to go by as I can't find it anywhere.

The head office internal network cannot see the other networks thru the vpn tunnels as the pix is not the gateway for the main network. The Ipcop was put in place as a test to see what the capabilities are and it works very well but has difficulties in addressing static routes. Basically, if I try to RDP into one of the remote workstations using the ipcop gateway, the ip doesn't exist cause there's no static routes involved. If I can address the problem with the ipcop, then I wouldn't need to use the pix as the gateway at all, but it would still be preferred.

Okay.

Your earlier request was to forward *all* the internet traffic to the ipcop box, and I took that to mean that any incoming VPN traffic should go to the ipcop box after being decapsulated. The route solution I gave works for that scenario.

If you want VPN traffic to arrive, be decapsulated, and be exempt from going to the ipcop box, even when the internal destination is the same as for some of the traffic handled by the ipcop box, then that's a problem. If, though, the ipcop box is doing NAT and the VPN tunnels can be expressed in terms of the "raw" IP addresses, then you can route the NAT'd IPs to the ipcop box and have the "raw" IPs go directly (or to a different internal router.)

If, though, you want to be able to distinguish based upon protocol (good luck characterising exactly what protocols Exchange uses though), with some protocols going directly and the rest going via the ipcop box, then you cannot directly use the "route" solution, because the PIX 501 does not support policy-based routing [PBR] (the other PIX models aren't exactly marvels at PBR either.] In such a case you would have to combine static PAT and different IP ranges with NAT on the ipcop box, so that after the static PAT step the apparent destination IP range would differ for the two cases. The PIX 501 can route based upon destination IP but not source IP and not protocol or port. (It can NAT differently based upon source IP or protocol or source or destination port though.)

In my route and differential NAT solutions above, I did not deal with the problem of reply packets and how they travel back via the ipcop box or skip the box as appropriate. I do not, though, know what the capabilities are of ipcop, and I am not certain quite yet about how you want different traffic types to be handled.