In article , wrote: :I currently have a pix 515e with vpn groups. we are seeing rapid :growth in the vpn use and i need to be able to make the local pool of :ip addresses larger. to do this, i want to make an entire vlan only :used for the vpn group pool of ip addys. I have a question or two :about this. my pix is connected to my core switch, a 4507R. currently :the port that connects resides on vlan 321, and the pool of addresses :is also in vlan 321. is it possible to have a port in more than vlan :as i assume is needed to have connectivity from the vpn client if given :another vlan address other than the ones on vlan 321. or am i totally :over thinking this?
You're totally over-thinking this ;-)
VPN pool addresses are allocated to clients by the security endpoint (i.e., PIX in this case). The clients continue to use their own addresses internally (e.g., for their local LAN), but when sending to the security endpoint, the VPN client software uses the machine's public IP on the outer wrapping of the packets, and uses the security- endpoint- allocated IP on the interior "encapsulated" packet. When the encapsulating packet gets through the public network to the security endpoint, the security endpoint unwraps it, and submits the unwrapped packet (now with the allocated IP as its source) for routing towards the interior. For proper routing to take place, the VPN pool addresses should not be part of any subnet that is used on the "inside" of the firewall, or else the routing processes on the interior might fail to return reply packets to the security gateway for passing on to the VPN client.
In this configuration, there are no interior systems that generate packets with the vpn pool range as their source: any packet that has a source in that range must have come through the VPN and must be destined for an interior host. Similarily, any packet that has a destination in that range must be a reply that an interior host has generated and which is destined for the security gateway for passing on to the VPN client.
Any packet that is destined for an interior host needs to be directed into the VLAN that is appropriate for that interior host -- and that isn't going to depend upon the source IP.
Any packet that is coming back from an interior host towards the security gateway needs to come through interior host's VLAN until it gets directed to the VLAN that leads to the security gateway -- and again, that isn't going to depend upon the destination IP, since you will be using the general "outbound traffic" VLAN to talk to the security gateway.
In our configuration, we did end up putting the PIX traffic into VLANs, but for different reasons. In our topology, based upon the locations of our devices relative to the demarcation point, we ended up putting the raw exterior traffic into a port on a switch that -also- carried private interior traffic. We seperated out the two using VLANs -- using a *port* based VLAN to transport the raw exterior traffic to a port-based VLAN port on a different switch, which connected to the PIX exterior. A VLAN, yes, but one that was agnostic to the IP addresses involved. We also have IP-based VLANs, but none of those are based upon the IPs that are allocated for the VPN clients, since we do not source traffic with those IPs internally.