Problems with PIX in parallel to VPN concentrator

[j.chasser]

We had trouble at an account that recently installed a concentrator to terminate remote users via IPSEC tunnels. No problem there. Problem was all users default gateway points to the trusted interface of the PIX. Inbound users once authenticated and placed on the LAN were directed to the PIX by the servers that they needed (email) instead of the path via the concentrator. PIX cannot have a static route on trusted interface, nor do ICMP redirects. Has anyone run into this, or have any workable configs?

I am wondering if a layer 3 switch is needed to sit behind the PIX and the VPN concentrator.

[scoclayton]

Rather common problem that we see. Yes, the PIX will not redirect packets back out the same interface where they were received. The work-arounds for this are to either add a layer 3 device inside the PIX and concentrator and change the default gateway on the internal LAN to this device. This new device would be responsible for making the routing decision of where to send the packet next. I have seen people do this with a single interface 2500. Obviously, an L3 switch would be better but you are not limited here.

One other option (if you have a PIX with multiple interfaces) is to hang the concentrator off of a DMZ interface on the PIX. This way, the PIX would not need to redirect the packets to the concentrator but could rather route them to the appropriate interface. Sorry for the problems but this is a design flaw that a lot of people make.

Scott

[j.chasser]

One last question. Can the IP address pool be unique, or does it need to be of the same subnet as the LAN?

[scoclayton]

We actually recommend that it be unique as opposed to a subset of the subnet addressing. This helps to prevent some avoidable ARP issues. But if necessary, both options will work.

Scott