vpn client and pix to pix vpn

[sjung]

I have a pix to pix vpn that encrypts and works well for the 2 inside lans. Pix A is set up for vpn clients as well. From a connected vpn client to pix A what is needed to direct traffic that is destined to pix B inside lan over the established ipsec tunnel between the 2 pixes? Syslog messages from pix A give me a %PIX-3-106011: Deny inbound (No xlate) message. I'm not clear on how to correct this since the pix is seeing my vpn client as an outside source trying to reach an outside destination. I have an access-list for the vpn pool that should be doing nat 0 when the destination is the lan behind pix B. The problem is that this nat 0 is (inside). Applying outside is useless since that interface has the lowest security but it is also where the crypto map policies are applied. Any help would be greatly appreciated.

[vimal1980]

Hi!

your post and the below document having same set of configuration. Pl. go through it. You can able to solve ur problem.

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a008019e6d7.shtml

HTH.

Rgds

Vimal

[chris.kemp]

You need a router on the inside to bounce the packets off of. A pix will not route packets from a vpn tunnel (your client) to another tunnel (your lan to lan).

[sjung]

Chris;

Thanks for the reply. I came across an article a couple weeks ago that confirmed what I was suspecting which is

exactly what you mentioned. I tried a different approach and placed a vpn only pix off the outside interface subnet and terminated it's inside interface on the same subnet as the inside interface of the production pix. The only traffic the vpn pix handles is vpn clients, so once the vpn is established the production pix handles the traffic like any other inside lan. Traffic to another site brings up the pix-to-pix vpn. Thanks again.

[rgcowie4D]

I have a similar setup with two PIX 501s, with one as VPN only from the Internet, and the other as firewall to the Internet. Both are terminated on the same LAN subnet inside, and the same Internet subnet outside.

(Our VPN clients must have access to the LAN, and also go out to the Internet with authorized IP to access protected remote servers. Thus the odd need to tunnel in and then use the tunnel for Internet access. Split-tunneling prevents the use of our authorized IP.)

The two-PIX setup works except VPN clients cannot access the Internet through the firewall PIX. All the interfaces on the LAN can be pinged from each other, including both inside PIX interfaces & tunneled VPN clients, so I suspect this is either a default gateway problem or a firewall permission problem.

Either:

1. VPN packets from outside interface of VPN PIX are not being routed to the inside interface of the firewall PIX as the default gateway.

or

2. Firewall PIX is denying those packets.

I checked the logs in both PIX but could find no evidence of either event happening.

It may be that the VPN clients from the outside interface of the VPN PIX have an implicit default gateway of the inside interface of the same PIX. I'm not sure.

The EZVPN client software automatically sets the default gateway on the VPN client machine to the same as the client IP. I tried changing that to the firewall PIX inside IP, but it didn't help.

I did try assigning a different host machine on the LAN with the same IP address that's used by the VPN client, and that works fine. That machine can access the Internet. The only difference between it and the PIX VPN is that the default gateway can be specified. The VPN client default gateway is automatic, as above.

Did you need to set any special routing in your configuration, to get packets to flow from one PIX to the other? Or am I thinking incorrectly about this method?

Any help would be appreciated. I've invested a lot of time in this problem with no success so far. Thanks in advance for your time!

[sjung]

I'm not sure that I can add anything insightful to your dilema since my situation is a little different in that our vpn clients are using split tunneling. When our clients establish a vpn session they get the routes installed on their host machine that I specify in the vpn acl. These routes are all the lans behind the firewall as well as the 5 dmz's. The address pool that the host is allocated from is a private class C in the 192.168.x.x range. Since the vpn hosts appear is an inside source to the firewall they are coming from a higher security interface when they access the dmz's so the only command needed to allow that is the nat 0 translation. This in turns means that I am routing the private address space within the firewall and behind it. Access to anywhere else on the network would use the client split tunnel. I' m sure I haven't mentioned anything that you don't already know at this point but is it possible that (1)a proper translation rule has not been set up for your vpn clients? or (2) The downstream router from your firewall does not know how to return traffic to the pool that you are natting to? I'm just shooting in the dark since I have no idea how your vpn pool is setup. Those are the reasons I could foresee to be a problem if my clients were not using split tunneling. If you haven't already try installing a syslog server such as kiwi on your workstation and have the firewall log to it. The licensed version allows you to filter on text or hostname or a number of different parameters. The unlicensed one does not but should do the trick if you have the syslog log to a text file and then filter from there. I'm guessing that you would want to look for any type of denial for the vpn client such as no translation. Good luck to you and let me know what you find. Peace.

[rgcowie4D]

Sorry, the message below is only a fraction of what I wrote in response. The forum connection keeps timing out on me so I lose what I've written. I'll write my response again in a text editor and then cut and paste into another response later today.

"Again, thanks for your help and your patience. I'm struggling a bit but still hope to make this work. :}"

[rgcowie4D]

Finally had a chance to get back on this:

Thanks for your advice on the Kiwi syslog. I have that running and it helped me determine that the Easy VPN client is discarding packets bound for the Internet (any packet not bound for the inside LAN). The packets never arrive at the VPN PIX.

I checked the client log, and saw that the PIX pushes a routing table to the client on connection. That table does not include a route for anything other than the VPN PIX, the local machine's virtual VPN address, the local machine's Internet address, and the local LAN which the VPN is connected to.

Do you know if there is a way to push another route to this table from the PIX, or add one to the client? I don't see an obvious way to do either. But it would seem that this is the problem. If another entry could be added to define the firewall PIX on the local LAN as the gateway for Internet-bound traffic, I think the routing might work.

Unless, of course, the PIX has been hard-coded to program the client to dump non-local packets. Given that a single PIX does not have the ability to route VPN traffic back to the outside interface (as I understood from previous posts), I'm somewhat afraid this might be true. If so, the PIX would be unusable for our purpose.

Please let me know what you think. I really appreciate your advice. And thanks again.

[sjung]

I think we can remedy your problem fairly easily. What you can try is actually specify split-tunneling for your vpn group and associate an acl with the command. What the acl does in conjunction with split-tunneling is install routes on the client when a vpn session is established. You can verify this with the route print command at the cmd line on the client. In your previous post you stated that split tunneling would not work due to the security setup on your servers. One way to circumvent this is to create an extended or named access-list that permits all the networks behind your firewall and on the dmz'z of the firewall as well as a 0.0.0.0 route. On the vpn pix put a default route that points to the inside interface of the firewall. That way any vpn client traffic will appear as normal inside lan traffic. Don't forget to include the appropriate nat commands on the firewall for the vpn pool. Your vpn pix should not try to route any traffic to its outside interface. It should pass all traffic from the vpn clients to the firewall inside interface or any layer 3 devices that you have behind it in the inside. What would happen is a vpn client would come through the outside interface of the vpn pix and proceed to the inside interface where a default route would point him to the inside interface of the pix firewall. You are correct in assuming that the vpn pix will not route some traffic to the inside and some to the outside. Unfortunately they do not work that way. Passing all traffic to the firewall from the vpn pix should not be a problem.....unless you have site to site vpns terminating on the vpn pix as well. In that case you will have to get a little more granular with the vpn acl , nix the default route and specify exact subnets that you want the client to traverse the firewall to reach. If there are only clients then you should be good to go. Hope this helps. Peace.

[rgcowie4D]

Thanks again for your help on this. What you're saying makes sense. I'm wondering if maybe my VPN configuration should be changed from the default, in order to accomplish this?

For example, currently I've accepted the PDM default setting of the VPN pool being taken from the inside interface IP space.

VPN PIX inside interface: 192.168.1.2

VPN Pool: 192.168.1.5 to 192.168.1.10

The VPN also defaults to "exempt from NAT", as no translation is necessary to access the local LAN on the inside interface with this configuration.

But, I think this makes it difficult to assign a static route for the VPN pool, since the pool exists on the outside interface yet has inside IP addresses. This is a bit odd, and the PIX has rejected or ignored my attempts to define a static route for traffic originating from them.

If instead, I define the VPN pool on another subnet (say 192.168.2.5 to 192.168.2.10), and turn off the "exempt from NAT" option, I should be able to create translation rules for the outside VPN pool to inside addresses. To the LAN, the VPN packets would appear to have originated on the VPN PIX inside interface (outside interface no longer involved), and I should then be able to specify a static route that points their traffic to the inside interface of the firewall PIX, as you suggest.

Do you agree this is a better approach?

Also, by default the PDM creates an implicit rule allowing traffic from the inside to outside interfaces, which cannot be edited or deleted. Along with that is an implicit static route that defines the default gateway of the inside interface to be the inside interface itself. This route cannot be edited or deleted, and adding another route for 0.0.0.0 requires a metric greater than 1, which really isn't true (only one hop is required to access the firwall PIX inside interface).

Is part of the problem my use of the PDM and it's "wizards"? Can I get around this by using the CLI instead?

I'll also review the Cisco PIX split-tunneling examples and see how to specify the acls to push the required routes to the client. I have a bit of a learning curve there, but will try it this weekend. The list of Internet servers that need to be routed through the VPN is short. All other Internet-bound traffic could be split out of the tunnel without causing a problem.

I appreciate all your help & time on this. I'll let you know how it goes.

[sjung]

As a personal rule I stay away from any of the gui apps such as the pdm or http servers on routers and switches. I feel that I have more control with the cli and it gives me a better understanding of what needs to be accomplished. Your vpn pool does not need to be associated with any active interface subnet so you could change your pool to whatever you want. If you do not route private addresses on the outside of your firewall you will most definitely have to change the exempt from nat rule. Whether you are actually natting the private addresses to global address space or doing nat 0 the firewall needs to know how to handle them when they traverse the inside interface. For example:

nat (inside) 0 192.168.1.0 255.255.0.0 0 0

What this command says is to leave the address alone when it is accessing the outside world.

Another example is :

nat (inside) 1 192.168.1.0 255.255.0.0 0 0

global (outside) 1 199.199.199.3-199.199.199.62 netmask 255.255.255.192

This is telling the firewall to nat the 192.168 address space to the global pool defined.

You can also specify source and destination by referring to an access-list such as:

nat (inside) 0 access-list 105

access-list 105 permit ip 192.168.0.0 255.255.0.0 200.200.200.0 255.255.255.0

access-list 105 permit ip 192.168.0.0 255.255.0.0 201.201.201.0 255.255.255.0

access-list 105 permit ip 192.168.0.0 255.255.0.0 207.207.207.0 255.255.255.0

access-list 105 permit ip 192.168.0.0 255.255.0.0 210.210.210.0 255.255.255.0

Again this is allowing the traffic to pass but without natting. It's actually natting them back to themselves.

On your vpn pix you should have a configuration such as the following:

ip local pool vpn-pool 192.168.1.1-192.168.1.150

crypto ipsec transform-set VPN-SET esp-3des esp-md5-hmac

crypto dynamic-map ip-dynamic 10 set transform-set VPN-SET

crypto map VPN-MAP 10 ipsec-isakmp dynamic ip-dynamic

crypto map VPN-MAP client configuration address initiate

crypto map VPN-MAP client authentication AuthVPN

crypto map VPN-MAP interface outside

isakmp enable outside

isakmp key ******** address 0.0.0.0 netmask 0.0.0.0

isakmp identity address

isakmp policy 10 authentication pre-share

isakmp policy 10 encryption 3des

isakmp policy 10 hash md5

isakmp policy 10 group 2

isakmp policy 10 lifetime 86400

vpngroup VPN-USERS address-pool vpn-pool

vpngroup VPN-USERS dns-server x.x.x.x

vpngroup VPN-USERS default-domain whatever.com

vpngroup VPN-USERS split-tunnel acl-vpn

vpngroup VPN-USERS idle-time 1800

vpngroup VPN-USERS password ********

access-list acl-vpn permit ip 0.0.0.0 0.0.0.0 192.168.1.0 255.255.255.0

*************This acl referenced by the split-tunnel command will push a default route to your clients. You can also just specify whatever networks you want pushed down instead of a default.*****************************************

************* if you are using AAA authentication ****************

aaa-server AuthVPN protocol radius

aaa-server AuthVPN max-failed-attempts 3

aaa-server AuthVPN deadtime 10

aaa-server AuthVPN (inside) host x.x.x.x key timeout 20

route inside 0.0.0.0 0.0.0.0 x.x.x.x <----- the inside interface of the firewall

On the firewall:

route outside 0.0.0.0 0.0.0.0 x.x.x.x <----- layer 3 gateway for the subnet of the outside interface.

Since you might be sending all traffic from the vpn client to the firewall make sure that the right nat commands are in place or the traffic will just die. If your pool is this on the vpn pix:

ip local pool vpn-pool 192.168.1.1-192.168.1.150

You will need something like this on the firewall:

nat (inside) 1 192.168.1.0 255.255.0.0 0 0

global (outside) 1 199.199.199.3-199.199.199.62 netmask 255.255.255.192

I hope this helps. Peace.

[drumrb0y]

I have a similar situation, but with CVPN clients who need to connect to a VPN 3030 Concentrator and out through it, to a LAN-to-LAN tunnel and a network on the other side.

'sjung', can you apply this concept to a VPN3030 in the form of static routes that would direct VPN client traffic to one of it's LAN-to-LAN tunnels?

Marc