GRE IPSec router in front of a PIX 1

[scottdware]

I have a question. If I have a few (4) small remote offices, and want to use GRE tunnels over IPSec VPN's, back to the main office 2651 router...how does that work as far as having my PIX behind the 2651.

The 2651 will have the Internet T1 coming into it, and the PIX's outside address will have a public IP. Do I just create access-lists on the router to forward the remote office subnets to the pix, and/or acl's on the PIX to allow the remote office traffic?

Sorry if this is a stupid ?. Thanks!

 

[themut]

The VPN will end at the 2651 so the router will decrypt the packets and forward them to the PIX. This means you need a static translation on the PIX for the networks/hosts involved and an ACL applied to the outside permitting the required traffic. You should carefully analyze the static translation since you may also need Internet connectivity for the networks/hosts involved in the VPN.

 

[scottdware]

So then do I just create ip route statements on the 2651 to forward the remote subnet's to the PIX. For example:

Remote office 1 subnet: 192.168.6.0/24

2651: ip route 192.168.6.0 255.255.255.0 66.100.23.2 <- (the outside address of the PIX)

Then in the pix permit 192.168.6.0 to access anything on the inside?

 

[lgarner]

That's pretty much it. Remember to also route outbound to 192.168.6.0 through the Pix using NAT 0.

If possible, I really think that it would be simpler to have the Pix terminate the VPN. It does so very nicely.

 

[themut]

Not quite...

2651: ip route <pix-inside-subnet> 255.255.255.0 66.100.23.2 <- (the outside address of the PIX)

Then in the pix a static translation for the LAN &quot;static (inside, outside)...&quot;

and then permit 192.168.6.0 to access anything on the inside?

Unfortunately you cannot end the tunnel at the PIX because the PIX cannot be configured as a GRE peer.

 

[lgarner]

>Unfortunately you cannot end the tunnel at the PIX because the PIX cannot be configured as a GRE peer.

That makes sense. I'm running GRE from routers behind the Pix VPN endpoints, so hadn't run into this exactly.