Cient VPN full tunnel on a Pix

Greetings. Is it possible to do a full clinet VPN tunnel on a Pix? I've been scouring Cisco's docs and google to no avail. This is trivial on a 3000 Concentrator. Is the answer to not specify vpngroup split-tunnel at all? I'm trying to do this on a 515e runngin 6.3(4).

Thanks J

Reply to
Loading thread data ...

I am not sure what you mean by a "full client VPN tunnel".

A vpngroup with no split-tunnel clause will forward all data over the connection, -except- for the client system talking to itself [but including attempts from the client system to talk to its local LAN.]

If you want the destination PIX to essentially "proxy" the connections addressed to locations outside the PIX, then in PIX 5.x / 6.x you run into the limitation that through PIX 6.x, the PIX will never forward packets out exactly the same [virtual] interface that the packets came in on. So if the client is connecting via a public network to the "outside" interface, and you want client packets destined to (say) google to head off through the "outside" interface, then you run into problems. There are various work-arounds for the problem, involving extra physical interfaces, or involving extra 802.1Q VLANs, or extra VPN endpoint hardware [the PIX 501 only has the latter option available]. In PIX 7.0 [on the devices that support that...], there is a configuration option to allow same-interface forwarding when at least one VPN tunnel is involved in the transaction.

Reply to
Walter Roberson


Thanks for the reply. That's exactly what I'm talking about. I need the all traffic from the clients routed over the IPSec connection to the Pix. The users must have Internet access through this IPSec connection (through the Pix, not unencrypted over their own Internet connection. Like I said this is trivial on the Concentrator; it's a simple option in a drop-down menu. I suppose the security levels on the interfaces of the Pix could present a problem; I hadn't considered that. I don't have any extra physical ports to work with. I'd like to replace this Pix with an ASA but that probably won't happen for a while. Do you have any links to docs that cover implementing this with

1Q ports? I'll try to get this device upgraded to 7.0.4 as time permits. Though that won't happen for a while either unfortunately.

Thanks for the info. Justin

Reply to

In a sense, in that one explanation you could come up with for why the PIX has the limitation is that there are semantic difficulties with applying NAT when going between two interfaces with the same security level, so PIX 6.x does not allow that... and of course going from one interface to the same interface would be a case of going to the same security level.

But another equally valid explanation is simply that "The PIX is designed to prevent this from happening in order to reduce security risks."

Well, I could give links to a bunch of my old postings ;-)

PIX 501: you can't do this. PIX 7.0 is not available for these, but Cisco said they would be releasing a restricted version of 7.0 for it, with a target release date of last summer.

PIX 506/506E: you need 6.3 to do this. PIX 7.0 is not available for these, but Cisco said they would be releasing 7.0 for it, with a target release date of last summer.

PIX 510: you can't do this, and PIX 7.0 will never be available for it.

PIX 520: you need 6.2+ to do this; PIX 7.0 will not be available for it.

PIX 515/515E, 525, 535: you need 6.2+ to do this; these devices support 7.0, which has a command that makes the task fairly simple.

Implementing with a PIX model + OS that supports VLANs:

- Use the 'interface' command to create a "logical" interface on top of a physical interface. The number you associate in the 'interface' command is the 802.1Q VLAN number, and an interface named as "vlan" followed by that number is -implicitly- created. You don't get to chose or indicate the "logical" interface name in the "interface" command, and the documentation doesn't talk about the implicit interface name, which is why I point this out here.

- Once the vlan interface is created, you can use all the regular commands to assign layer 3 attributes to it. The IP address subnet assigned to it must be distinct from all the other interface subnets. You cannot assign layer 2 attributes such as duplex to the VLAN.

- You can use "nameif" to give a more meaningful name to the implicit vlan# interface. You have to use "nameif" anyhow, in order to assign a security level to the logical interface. The security level does NOT need to be the same as the physical interface underlying the VLAN.

- If you assign an IP subnet to the physical interface underlying the VLAN, then that interface will receive all the untagged packets and will send untagged packets -- so you can just add a new logical interface on top of a physical interface and nothing will change as far as traffic to the physical interface is concerned.

- All traffic from the logical interface (according to normal routing rules) will be tagged with the associated 802.1Q VLAN number, and the logical interface will -only- receive traffic tagged with that VLAN number. Thus, you can have multiple logical interfaces on a single physical interface, each "as if" it was a physical interface that dealt only with the appropriate IP range.

- When you have a logical interface layered on a physical interface, then you have to have 802.1Q support on all the devices between that physical interface and whatever device will do the VLAN routing for you. Thus in order to make this work with respect to an outside interface, your WAN router must support routing of the outside traffic into 802.1Q VLANs on the appropriate physical interface. Consumer-level routers and "cable modems" and such, usually do not have that capability. (The Cisco 87x support 802.1Q but the other 8xx do not; the 1600 series does not either, but the 1700 upwards do.)

- Alternately, if you have a WAN router that has a spare routing interface (e.g., the 83x can split off one of the four inside interfaces), and if you have an 802.1Q switch between the PIX and the WAN router, you could have the switch deliver the different VLAN traffic untagged to the different WAN interfaces -- then the WAN router would not itself need

802.1Q capabilities.

- The basic logical setup is relatively simple: subnet your public IP space (or use a second public IP space) and have your WAN router send some of it to the original [physical] interface and some of it to the new logical interface. Then, attach your vpn configuration to the *logical* interface.

- The clients would send the packets to the IP space associated with the logical interface, the PIX would decapsulate them and see that they were addressed to an IP range through the [logically-distinct] outside interface, and would route the packets out the outside interface, applying NAT as they went. The reply packets would then be addressed to an IP attached to the outside [physical] interface, would come in, be de-NAT'd, the PIX would see the target was a [logically-distinct] interface, would route the packets there, and they would undergo normal encapsulation for transmission towards the VPN client. The encapsulated packets would have the 802.1Q attached, would go out on the physical interface but with the different VLAN, and your WAN router [or WAN switch, as described above] would strip the VLAN tag and dispatch them towards the Internet for delivery to the VPN client.

- If for some reason you cannot subnet your public IP space, and cannot get [or cannot afford] the provider to route a second IP public IP space to your WAN router... then you have problems!

- The problems can be overcome if your WAN router supports NAT and you have at least one IP to spare: you could have the WAN router NAT that public IP into a private IP address range that you then configured as the IP range for the logical interface. If you do this, then you cannot use AH unless you also turn on "isakmp nat-traversal". If you are using PPTP or L2TP/IPsec then you need a complete spare IP address (one-to-one mapping); if you are using EzVPN or IPSec and have "isakmp nat-traversal" turned on, you just -might- be able to get this to work with static PAT (port address translation) of UDP 500 and UDP 4500 even with a single IP address.

Reply to
Walter Roberson


Many thanks for the reply. I may have a free /30 I can use in this scenario. Our /19 is pretty much consumed as it stands right now. The

515 outside int terminates on a stack of 3750s w/ EMI code so this should be doable. I may push for an upgrade to 7.0 though. My last 6.3x to 7.0.4 upgrade went as smooth as can be with no config changes needed whatsoever, outside of what the 7.0 code changed upon the initial boot. The upgrade would be a better long-term solution. I can definitely use your info at another site though. Many thanks. J
Reply to
J Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.