Cisco PIX Client VPN

I would connect like this

Internet______
      |             |
     FW        PIX
      |            |
   SWITCH    |
 =======--|
         |     |
         |     |
         |     |
       LAN NETWORK

I was being lazy as I have not used Cisco routers as a firewall before and we have one already in place.
I would need to block everything in except authenticated VPN and wasnt confident in how to do this with the PIX.

If no-one posts any help on how I can get it working from behind an existing firewall, I will try it that way knightrider2k2.

Jess

What kind of firewall is this 'FW'?

 Sorry, but knightrider2k2's diagram won't work for you: a PIX isn't a router - even with a properly functioning VPN, unless the internal hosts you want to reach have the PIX as their default gateway,  you won't be able to reach them from the VPN clients.
   jessmca, your original diagram also unfortunately won't work either, not with a PIX running 6.x code.  6.x series PIX will NOT let you do 'hairpinning' (aka "VPN U-turn"), only a PIX 515 or above running 7.x would allow a U-turn.

>1 ...or I should be using a different subnet for the VPN connections and allowing access via firewall.
   For the VPN pool, you absolutely must use a subnet different than what's behind the PIX or you'll hit a routing loop.  Also, *don't* use a common IP range for the VPN pool - AVOID: 192.168.1.x or 192.168.2.x or you're guaranteed to hit another routing loop since these IP ranges would overlap a lot of home users (& even some business subnets!).
   Try something a bit unusual, like maybe 192.168.236.x

>2 When I connect to the VPN on the LAN, I get an IP of 192.168.10.150 which is also the gateway.
    That's normal - the gateway will be your own VPN pool IP that you were assigned.
>Do I need to manually add a route for VPN traffic...
    Nope.

If you want to keep your existing firewall & use the PIX as a VPN server, then your only real option is like this:
    Internet <-> FW <-> PIX <-> switch <-> LAN
And the only sane way to do the above would be to have a 2nd small range of public IPs from your ISP for the FW inside interface & the PIX outside interface, disable NAT on the FW, & do all your NAT on the PIX.  You *don't* want to have 2 NAT devices, nor a NAT device in front of your PIX.

Personally, I'd just replace your existing FW with the PIX, if your WAN connection is an Ethernet hand off.

cheers

Hi calvinetter,

The current firewall is simply a powerful PC running Unix.  It also acts as a mail gateway, bandwidth monitor, web proxy, and has multiple site to site VPN's fom other Unix servers.  We only need a handful of client VPNs and I had hoped the PIX would give me an easy option of doing this without interfering with the existing setup which is working very well.
The Unix server has apache running of the lan ip and provides our Intranet with charts and bandwidth monitoring statistics using xml and framed php pages.  I would not want to move to firewall applications and as we would need one in each office it would be costly.

I need to keep the existing firewall and IP addressing in place.  Is there no way of using a PIX 501 as a VPN server in the above scenario?

What about something like this. I can add another NIC to the firewall and forward to the PIX.

Internet
      |            
     FW--------PIX
      |             |
   SWITCH      |
  =======----
  |         |
  |         |
  |         |
 LAN NETWORK

Or is the PIX just not going to be suitable for what I want?

Thanks for your assistance
Much appreciated

Hi Jessmca,

Thats exactly how you can do it.  I recently configured a client with the following limitations.

Current Linux firewall.
- 1 x external IP address to use for VPN.
- No other vpn connections terminating on the firewall.
- Site to site vpn needed with two way communication.

To quickly explain the following.  
- If you are using only one static ip address you need to forward ESP, UDP 500 and UDP 4500 traffic to the PIX's (outside) interface.  This means no other vpn traffic can be terminating on your Unix server.  If you have another ip addres to use for this vpn (disregard).
- Site to site vpn needed to be routable from internal to external subnet and back.

This required the following setup as you have diagrammed above:
Internet
      |    (forward ESP, UDP500, UDP4500)        
     FW--------Cisco 806
      |             |
   SWITCH      |
  =======----
  |         |
  |         |
  |         |
 LAN NETWORK

In this case the client has an old Cisco 806 lying around they wanted to use.  This worked perfectly as I added another card to the Linux firewall and connected the (outside) interface to this new subnet.  The internal interface was on there internal LAN and created a route on the Linux server (default gateway) to route the traffic to the 806 for the required subnets.  
In your case you only have a "remote vpn" group.  So this (diagram above) would work in your situation although if you ever wanted to add a site to site vpn later you would need the following scalability (see below).

In your case (as mentioned above) the PIX 501 cannot perform as a router.  To provide the ability to create site to site VPN's later you would need to configure the following:

(SCENARIO: IF you have only 1 x external ip address on FW and no other vpn traffic terminating on FW)
To get this working add 2 x NIC's to the Unix box.  

Internet
      |            
     FW--------PIX
      |  ---------|          
   SWITCH      
  =======
  |         |
  |         |
  |         |
 LAN NETWORK

- Add a rule to FW to forward all ESP (50) traffic and UDP 500,4500 to the PIX (outside) int.
- Add a route for the (remote vpn traffic) to terminate on the PIX (inside) int.

The above will provide you with flexibility to add other site to site vpns and remote access vpn's later.
Alternatively, if you only want to have the 1 x network card  this will also work.  It just means that you cannot use the PIX

>Or is the PIX just not going to be suitable for what I want?
   Unfortunately, not a PIX 501 running 6.x software.

>Joesmail: In your case (as mentioned above) the PIX 501 cannot perform as a router.
   Exactly.  A PIX has *some* routing capabilities, but it's not a router.  And the security algorithm in the 6.x series software just won't allow traffic to enter & exit the same interface (ie U-turn as I mentioned above).

  To repeat, unless you have the following layout:     Internet <-> FW <-> PIX <-> switch <-> LAN  
(or the PIX & FW in reversed positions)  ...a PIX 501 (or 506) just won't work, because even though your Unix box can fully function as a router, the PIX 501 can't & absolutely won't let you pull the "hairpinning/U-turn" maneuver.

   But as Joesmail said, a Cisco router can work in place of the PIX, since it allows hairpinning.  If you're doing multiple site-site VPNs right now, you'll want to go with at least a Cisco 1700 series router; an 1800 series would be best if budget allows, & will give you more growth room than a 1700 or smaller would.

cheers

Hi calvin,

I cannot see anywhere the need for hairpinning?  Maybe I have missed some prior comment?  Looking at the config from the 501 he needs a working solution using the Unix box as the current firewall (default route).

Hi Joesmail & knightrider2k2 , I stand corrected - after doing a bit of testing, the diagram below will work, with the following setup:

- "FW" in my test lab was a Cisco router
- VPN terminated on the outside of the PIX as usual
- VPN client pool on PIX: 172.19.9.0/24
- FW has a route pointing to PIX inside IP for the 172.19.9.x subnet
- NAT disabled on PIX  (don't need it & double NAT in a VPN situation is a nightmare!)
- FW doing all NAT with static NAT entries for UDP 500 & 4500, & ESP traffic to PIX outside - this was used for testing since obviously you already have VPN traffic terminated on your FW; simpler & even better if you've got a 2nd public IP that the FW is doing 1-to-1 NAT to the PIX.
- default gatway for hosts on LAN is the FW (10.1.1.1)

Internet
    |            
   FW ---- PIX
   .1         .2
    |          |
  =======          
   SWITCH      
  =======
       |
     LAN (subnet: 10.1.1.0/24)

So, apologies all -  misunderstanding/brainfart on my part; if the FW is able to correctly handle the routing (& traffic isn't trying to do a U-turn on the PIX) this will keep the PIX happy.  
  FYI - since a PIX 501 is a rather wimpy box compared to your FW, I'd suggest either 1) getting at least a PIX 506E if you're going to shift all VPN duties off the FW,  or 2) keeping the site-site VPNs on the FW, get a 2nd public IP from your ISP & do a 1-to-1 NAT on the FW to the PIX outside.

cheers

Hi,

Thanks for the confirmation and assistance with this.
It is reassuring to know that this will work when I can get it setup right.

What I have done so far.
We have 5 spare IP addresses so I have added an extra NIC to the FW and added another IP as an alias to forward onto the PIX.

XL0 X.X.X.X (+4 static aliases)
XL1 192.168.10.254 ----> SWITCH ---> LAN 192.168.10.0/24 <------------------------------------|
XL2 192.168.20.254 ----> PIX OIF 192.168.20.3                                                                    |
                                      PIX IIF 192.168.10.12  -----> SWITCH  ----> LAN 192.168.10.0/24---|

I can get a reply from the PIX externally using the extra static IP forwarding onto it.
The FW is pretty open onto XL2 at this point, I will tighten firewall rules when I get the VPN working.

Telnetting externally to ports 500, 4500 etc.. time out.
The Cisco client 4.8 times out and deletes keys due to peer not responding.  Either the PIX acl are not allowing this traffic or it is unable to get back out again.

I can ping from the PIX externally from both inside and outside interfaces, but cannot get a reply from the LAN gateway 192.168.10.254 from the external interface.

I have posted the running config.  I am going to need to read up on Cisco, but for now would appreciate any advice on getting this running.

I  have a feeling that traffic is forwarding onto the PIX from external ok, but the responses are going back via inside interface.

What way should the PIX be routing for this setup?

Thanks
Jess


PIX Version 6.3(5)
interface ethernet0 auto
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password 7ZwherttmoXIvB3/ encrypted
passwd 2KFQnrtIdI.2KYOU encrypted
hostname pixfirewall
domain-name domain.com
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
names
access-list inside_outbound_nat0_acl permit ip any 192.168.20.128 255.255.255.192
access-list outside_cryptomap_dyn_20 permit ip any 192.168.20.128 255.255.255.192
pager lines 24
mtu outside 1500
mtu inside 1500
ip address outside 192.168.20.3 255.255.255.0
ip address inside 192.168.10.12 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
ip local pool VPNPOOL 192.168.20.150-192.168.20.170
pdm location 192.168.10.128 255.255.255.192 outside
pdm logging informational 100
pdm history enable
arp timeout 14400
nat (inside) 0 access-list inside_outbound_nat0_acl
route outside 0.0.0.0 0.0.0.0 192.168.10.254 1
timeout xlate 0:05:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout sip-disconnect 0:02:00 sip-invite 0:03:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local
http server enable
http 192.168.10.0 255.255.255.0 inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto dynamic-map outside_dyn_map 20 set transform-set ESP-3DES-MD5
crypto dynamic-map outside_dyn_map 40 set transform-set ESP-3DES-MD5
crypto map outside_map 65535 ipsec-isakmp dynamic outside_dyn_map
crypto map outside_map client authentication LOCAL
crypto map outside_map interface outside
isakmp enable outside
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash md5
isakmp policy 20 group 2
isakmp policy 20 lifetime 86400
vpngroup GROUPVPN address-pool VPNPOOL
vpngroup GROUPVPN dns-server 192.168.10.5 192.168.10.16
vpngroup GROUPVPN default-domain domain.com
vpngroup GROUPVPN idle-time 1800
vpngroup GROUPVPN password ********
telnet timeout 5
ssh timeout 5
console timeout 0
terminal width 80

>Telnetting externally to ports 500, 4500 etc.. time out.
   Exactly, this is expected for 2 reasons: 1) it's *UDP* 500 & 4500, not TCP ports  2) if you tried hitting the PIX's outside interface from the inside it won't work: PIX 6.x won't let you directly access the outside interface from the inside (U-turn situation, remember?).

>route outside 0.0.0.0 0.0.0.0 192.168.10.254
   Looks like you got a typo on your default gateway:
no route outside 0.0.0.0 0.0.0.0 192.168.10.254
route outside 0.0.0.0 0.0.0.0 192.168.20.254

> ip local pool VPNPOOL 192.168.20.150-192.168.20.170
   Once again, the VPNPOOL must *not* overlap any local networks, whether they're directly attached to the FW, the PIX or something else internally, otherwise you'll hit a routing loop.   Run this:

no vpngroup GROUPVPN address-pool VPNPOOL
no ip local pool VPNPOOL 192.168.20.150-192.168.20.170
ip local pool VPNPOOL 172.25.203.1-172.25.203.170   <- we'll use an uncommon private IP range
vpngroup GROUPVPN address-pool VPNPOOL

>access-list inside_outbound_nat0_acl permit ip any 192.168.20.128 255.255.255.192
>access-list outside_cryptomap_dyn_20 permit ip any 192.168.20.128 255.255.255.192
     Never use "ip any" in any of your VPN ACLs!  Run this:
access-list inside_outbound_nat0_acl permit ip 192.168.10.0 255.255.255.0
no access-list inside_outbound_nat0_acl permit ip any 192.168.20.128 255.255.255.192
no access-list outside_cryptomap_dyn_20     <- don't need this ACL, & it's not in use anyway
clear xlate

>crypto map outside_map client authentication LOCAL
  If you're going to use local usernames on the PIX, you need to create one:
username vpnuser1 password secretstuff

no crypto dynamic-map outside_dyn_map 20 set transform-set ESP-3DES-MD5   <- not needed
crypto map outside_map interface outside              <- important! resets crypto map on the interface

   Just for good measure, this lets oubound pings & traceroute work through the PIX:
access-list inbound permit icmp any any
access-group inbound in interface outside

cheers

Hi,

There are users in the local database, I just removed these and changed domains for security reasons when posting to a public site.

The VPN is configured for the PIX OIF, 192.168.20.3
This connects to the FW on XL2 at 192.168.20.254

This is reachable externally and responds to pings using a static ip which forwards to the PIX OIF on all ports.
From the PIX, I can ping any external ip address but cannot ping the IIF which is 192.168.10.12.

Likewise, the PIX IIF of 192.168.10.12 can ping any LAN address 192.168.10.0/24 but cannot ping externally and cannot ping the OIF.

There is a cross over cable between the PIX OIF and the FW XL2 which is required for them to speak.  

Should the outside interface be able to ping the inside and vice versa.

I think there are ACL's missing to allow this to work.

If I unplug the LAN IIF on the PIX, I cannot ping from the OIF as everything drops.

If I unplug the OIF and leave only the LAN, I can ping every LAN IP from the IIF except the gateway 192.168.10.254

It appears the LAN gateway 192.168.10.254 is routing on the PIX through the OIF on the PIX and preventing the IIF from reaching any external IP address as it cannot find the OIF.

Does this shed any light??

Thanks
Jess

>There are users in the local database, I just removed these and changed domains for security...
   Thanks for clarifying.  Ok, understandable.

> From the PIX, I can ping any external ip address but cannot ping the IIF which is 192.168.10.12
   You must be trying to ping an IP while specifying the opposite interface as the source, eg:
ping inside <outside IP>   or: ping outside <192.168.10.12>
   That won't work, as expected - PIX isn't a router, no route for the external IP going out the inside interface (or vice versa), & can't do a U-turn anyway.

> It appears the LAN gateway 192.168.10.254 is routing on the PIX through the OIF...
  Did you make the corrections I outlined earlier?

  Also keep in mind that to properly test client VPN to the PIX, you must test from a client outside your FW, (ie, from the public Internet).

Please post the current "sanitized" output of "sh run" (passwords removed).

cheers

Hi Calvin,

I see what you mean about it not being a router.
Here is the current config after yesterday

I have a static IP forwarding all traffic to the PIX OIF 192.168.20.3 via the FW on 192.168.20.254 (XL2)

The PIX IIF 192.168.10.12 connects direct to a LAN switch 192.168.10.1 connected to LAN 192.168.10.0/24 with gateway 192.168.10.254 (FW XL1)

The VPN is enabled on the PIX OIF using a seperate VPNPOOL using the IP range you suggested 172.25.203.1-172.25.203.170.

Pinging the PIX OIF externally replies OK.
Cisco client 4.8 does not get a response and times out.

This is the LOG with the FW temporarily OPEN

Cisco Systems VPN Client Version 4.8.01.0300
Copyright (C) 1998-2005 Cisco Systems, Inc. All Rights Reserved.
Client Type(s): Windows, WinNT
Running on: 5.0.2195 Service Pack 4
Config file directory: C:\Program Files\Cisco Systems\VPN Client

1      07:37:08.937  11/22/06  Sev=Warning/3      GUI/0xA3B0000B
Reloaded the Certificates in all Certificate Stores successfully.

2      07:37:23.921  11/22/06  Sev=Info/4      CM/0x63100002
Begin connection process

3      07:37:23.953  11/22/06  Sev=Info/4      CVPND/0xE3400001
Microsoft IPSec Policy Agent service stopped successfully

4      07:37:23.953  11/22/06  Sev=Info/4      CM/0x63100004
Establish secure connection using Ethernet

5      07:37:23.953  11/22/06  Sev=Info/4      CM/0x63100024
Attempt connection with server "xxx.xxx.xxx.xxx"

6      07:37:25.000  11/22/06  Sev=Info/6      IKE/0x6300003B
Attempting to establish a connection with xxx.xxx.xxx.xxx.

7      07:37:25.015  11/22/06  Sev=Info/4      IKE/0x63000013
SENDING >>> ISAKMP OAK AG (SA, KE, NON, ID, VID(Xauth), VID(dpd), VID(Frag), VID(Nat-T), VID(Unity)) to xxx.xxx.xxx.xxx

8      07:37:25.046  11/22/06  Sev=Info/4      IPSEC/0x63700008
IPSec driver successfully started

9      07:37:25.046  11/22/06  Sev=Info/4      IPSEC/0x63700014
Deleted all keys

10     07:37:30.046  11/22/06  Sev=Info/4      IKE/0x63000021
Retransmitting last packet!

11     07:37:30.046  11/22/06  Sev=Info/4      IKE/0x63000013
SENDING >>> ISAKMP OAK AG (Retransmission) to xxx.xxx.xxx.xxx

12     07:37:35.156  11/22/06  Sev=Info/4      IKE/0x63000021
Retransmitting last packet!

13     07:37:35.156  11/22/06  Sev=Info/4      IKE/0x63000013
SENDING >>> ISAKMP OAK AG (Retransmission) to xxx.xxx.xxx.xxx

14     07:37:40.171  11/22/06  Sev=Info/4      IKE/0x63000021
Retransmitting last packet!

15     07:37:40.171  11/22/06  Sev=Info/4      IKE/0x63000013
SENDING >>> ISAKMP OAK AG (Retransmission) to xxx.xxx.xxx.xxx

16     07:37:45.171  11/22/06  Sev=Info/4      IKE/0x63000017
Marking IKE SA for deletion  (I_Cookie=7ECFFFA4058EF141 R_Cookie=0000000000000000) reason = DEL_REASON_PEER_NOT_RESPONDING

17     07:37:45.671  11/22/06  Sev=Info/4      IKE/0x6300004B
Discarding IKE SA negotiation (I_Cookie=7ECFFFA4058EF141 R_Cookie=0000000000000000) reason = DEL_REASON_PEER_NOT_RESPONDING

18     07:37:45.671  11/22/06  Sev=Info/4      CM/0x63100014
Unable to establish Phase 1 SA with server "xxx.xxx.xxx.xxx" because of "DEL_REASON_PEER_NOT_RESPONDING"

19     07:37:45.671  11/22/06  Sev=Info/5      CM/0x63100025
Initializing CVPNDrv

20     07:37:45.703  11/22/06  Sev=Info/6      CM/0x63100046
Set tunnel established flag in registry to 0.

21     07:37:45.718  11/22/06  Sev=Info/4      IKE/0x63000001
IKE received signal to terminate VPN connection

22     07:37:45.734  11/22/06  Sev=Info/4      IKE/0x63000086
Microsoft IPSec Policy Agent service started successfully

23     07:37:45.750  11/22/06  Sev=Info/4      IPSEC/0x63700014
Deleted all keys

24     07:37:45.750  11/22/06  Sev=Info/4      IPSEC/0x63700014
Deleted all keys

25     07:37:45.750  11/22/06  Sev=Info/4      IPSEC/0x63700014
Deleted all keys

26     07:37:45.750  11/22/06  Sev=Info/4      IPSEC/0x6370000A
IPSec driver successfully stopped

Should the VPN be on the IIF?


Here is the current run config

PIX Version 6.3(5)
interface ethernet0 auto
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password 7ZwhfahjkIvB3/ encrypted
passwd 2KFQhkIdI.2KYOU encrypted
hostname pixfirewall
domain-name domain.com
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
names
access-list inbound permit icmp any any
access-list inside_outbound_nat0_acl permit ip 192.168.10.0 255.255.255.0 172.25.203.0 255.255.255.0
access-list outside_cryptomap_dyn_60 permit ip any 172.25.203.0 255.255.255.0
access-list inside_access_in permit ip 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0
access-list inside_access_in permit tcp 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0
access-list inside_access_in permit icmp any any
pager lines 24
mtu outside 1500
mtu inside 1500
ip address outside 192.168.20.3 255.255.255.0
ip address inside 192.168.10.12 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
ip local pool VPNPOOL 172.25.203.1-172.25.203.170
pdm logging informational 100
pdm history enable
arp timeout 14400
access-group inbound in interface outside
access-group inside_access_in in interface inside
route outside 0.0.0.0 0.0.0.0 192.168.20.254 1
timeout xlate 0:05:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout sip-disconnect 0:02:00 sip-invite 0:03:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local
http server enable
http 192.168.10.0 255.255.255.0 inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto dynamic-map outside_dyn_map 40 set transform-set ESP-3DES-MD5
crypto dynamic-map outside_dyn_map 60 match address outside_cryptomap_dyn_60
crypto dynamic-map outside_dyn_map 60 set transform-set ESP-3DES-MD5
crypto map outside_map 65535 ipsec-isakmp dynamic outside_dyn_map
crypto map outside_map client authentication LOCAL
crypto map outside_map interface outside
isakmp enable outside
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash md5
isakmp policy 20 group 2
isakmp policy 20 lifetime 86400
vpngroup GROUPVPN address-pool VPNPOOL
vpngroup GROUPVPN dns-server 192.168.10.5 192.168.10.16
vpngroup GROUPVPN default-domain domain.com
vpngroup GROUPVPN idle-time 1800
vpngroup GROUPVPN password ********
telnet timeout 5
ssh timeout 5
console timeout 0
terminal width 80

I didnt get trying too much yesterday, will try a few tests such as placing the PIX outside the FW and checking I can connect to the OIF using the client VPN (which it has only done on the IIF so far).
Will post results.

Jess

This is interesting.

I made the following changes.

no access-list inside_access_in permit ip 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0
no access-list inside_access_in permit tcp 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0
access-list inside_access_in permit ip 192.168.10.0 255.255.255.0 xxx.xxx.xxx.0 255.255.255.0
access-list inside_access_in permit tcp 192.168.10.0 255.255.255.0 xxx.xxx.xxx.0 255.255.255.0
no route outside 0.0.0.0 0.0.0.0 192.168.20.254 1
route outside 0.0.0.0 0.0.0.0 xxx.xxx.xxx.xxx 1

This puts the PIX directly on the external router outsode the firewall with the new static ip address directly on the OIF

I checked ping from the PIX and can reach any external IP
I still cannot reach any extrtnal IP from the inside interface though.  This doesnt appear to work without NAT on the PIX and I think is required for the VPN to work.

I can reach the new PIX IP externally, but the exact same log results from the Cisco client.
At present, the PIX is not accepting client VPN connections.

Will try a few more tests and post back.

 I'm on my way out the door, so I'll have to be very brief...

>I still cannot reach any extrtnal IP from the inside interface though.  This doesnt appear to work without NAT
>on the PIX and I think is required for the VPN to work.
   NAT isn't required for VPN to work.  And you *don't* want both the FW & PIX doing NAT.

>Should the VPN be on the IIF?
   Nope.

Please hold off making any more changes or posts, I believe I can save us both some time & effort if we don't get off track...  I'll post back tonight after work with several changes to make.

cheers

Sorry Calvin,

Our network is on ADSL.
The router outside the FW is an ADSL Modem / Router.  All NAT is done at the firewall.  The ADSL Router only handles the connection to the ISP and uses the ISP gateway as its only IP.  The FW XL0 uses the first available static IP with 5 aliases and the ADSL Router as its gateway.  We have 13 static IP addresses available.

For this, the ADSL router is irrelevant.

I took the PIX home last night and the Cisco client could not conect to either interface on the PIX even after resetting keeping the inside interace intact and reconfigurng a few times.  

I reset completely to defaults including inside and configured the inside for my home lan and the work XL2 subnet on the outside.
This time the cisco client connected again  nop probs.
I then moved the VPN to the OIF and used a cross over cable to test direct from the laptop.
Again it connected.

I have changed the inside subnet back to the work lan and tested the client again.  Still working.
So once back in the office, I will reconnect the PIX outside to the FW XL2 and PIX inside to the LAN.

Hopefully the client will connect and I will use the detail you have posted to iron out any access issues.

Will let you know how I get on.

Many thanks for your assistance.  With luck will be functioning shortly.

Jess

I reset to factory settings and used the command line to configure as per your posts Calvin.

disabled isakmp and then enabled again, clear xlate and have just successfully connected from home.

Thank you for your assistance and effort.
Much appreciated.