Solved

Cisco PIX Client VPN

Posted on 2006-11-17
19
754 Views
Last Modified: 2012-05-05

Hi,

I want to use a Cisco PIX router to allow remote access using the Cisco 4.8 VPN client software.

I need some advice on the best way to configure this.

I have configured ethernet port 1 with a static IP 192.168.10.12, DNS 192.168.10.5 and gateway as the firewall 192.168.10.254
PIX can access everything, local and Internet.

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

I then used the VPN wizard to configure the VPN connection.

I gave the VPN pool an ip address on the same subnet 192.168.10.150 to 192.168.10.190 which are excluded on the LAN DHCP.  

1
Im not sure if this is correct or I should be using a different subnet for the VPN connections and allowing access via firewall.
Which is best?

The firewall has NATed an fixed IP onto the PIX.  I can get ping replies and now can also get the Client software to reach the PIX. However, I dont get a login except from LAN.  

2
When I connect to the VPN on the LAN, I get an IP of 192.168.10.150 which is also the gateway.
I cannot ping any IP on the LAN except 192.168.10.150
VPN requests do not appear to be forwarding to the LAN gateway.
Do I need to manually add a route for VPN traffic and if so, any suggestions?

3
Externally, although I can reach the PIX using ping, the client software does not bring up the login box, bt times out when using the external IP adddress.
Do I need to add the external ip address to the allowed ip addresses or what is required to get this working externally?

4
Is the above outline the right way to do this or is there a better way.  I have only oine cable into the PIX which connects to the LAN and is accessable externally.

Thanks
Here is the current running config

Building configuration...
: Saved
:
PIX Version 6.3(5)
interface ethernet0 auto
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password 7ZwhfsdmoXIvB3/ encrypted
passwd 2KasdfIdI.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_cryptomap_dyn_20 permit ip any 192.168.10.128 255.255.255.192
access-list outside_access_in permit tcp any any
access-list outside_access_in permit udp any any
access-list SkipNAT permit ip 192.168.10.0 255.255.255.0 192.168.10.128 255.255.255.192
pager lines 24
mtu outside 1500
mtu inside 1500
ip address outside dhcp setroute
ip address inside 192.168.10.12 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
ip local pool GROUPVPN 192.168.10.150-192.168.10.190
pdm location 0.0.0.0 0.0.0.0 inside
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 SkipNAT
access-group outside_access_in in interface outside
route inside 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 inside_dyn_map 20 match address inside_cryptomap_dyn_20
crypto dynamic-map inside_dyn_map 20 set transform-set ESP-3DES-MD5
crypto map inside_map 65535 ipsec-isakmp dynamic inside_dyn_map
crypto map inside_map client authentication LOCAL
crypto map inside_map interface inside
isakmp enable inside
isakmp identity key-id password
isakmp nat-traversal 20
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 GROUPVPN
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
dhcpd lease 3600
dhcpd ping_timeout 750
dhcpd auto_config outside
: end
[OK]



0
Comment
Question by:jessmca
  • 8
  • 7
  • 2
  • +2
19 Comments
 
LVL 7

Expert Comment

by:knightrider2k2
ID: 17968493
I would connect like this

Internet______
      |             |
     FW        PIX
      |            |
   SWITCH    |
 =======--|
         |     |
         |     |
         |     |
       LAN NETWORK
0
 
LVL 8

Author Comment

by:jessmca
ID: 17969365
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
0
 
LVL 3

Expert Comment

by:bugsaif
ID: 17970514
What kind of firewall is this 'FW'?
0
 
LVL 20

Expert Comment

by:calvinetter
ID: 17970559
 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
0
 
LVL 8

Author Comment

by:jessmca
ID: 17970836
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
0
 
LVL 10

Expert Comment

by:Joesmail
ID: 17972912
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
0
 
LVL 20

Expert Comment

by:calvinetter
ID: 17972967
>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
0
 
LVL 10

Expert Comment

by:Joesmail
ID: 17973153
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).
0
 
LVL 20

Expert Comment

by:calvinetter
ID: 17975396
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
0
PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

 
LVL 8

Author Comment

by:jessmca
ID: 17978336
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
0
 
LVL 20

Expert Comment

by:calvinetter
ID: 17979141
>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
0
 
LVL 8

Author Comment

by:jessmca
ID: 17985836
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
0
 
LVL 20

Expert Comment

by:calvinetter
ID: 17992894
>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
0
 
LVL 8

Author Comment

by:jessmca
ID: 17993780
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
0
 
LVL 8

Author Comment

by:jessmca
ID: 17994021
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.
0
 
LVL 20

Expert Comment

by:calvinetter
ID: 17995139
 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
0
 
LVL 20

Accepted Solution

by:
calvinetter earned 500 total points
ID: 18001278
>This puts the PIX directly on the external router outsode the firewall
   Hmm, you never mentioned a router outside the FW.  I assume it's not doing NAT - can you confirm?  And is this your router - ie, you have full control of it?

   Assuming the border router (outside the FW) isn't doing NAT, you have 2 main scenarios:
1) Connect the PIX outside to the border router's inside (bypassing the FW)
2) Reconnect the PIX to the FW as before.
   Either way, the FW absolutely must be the default gateway for the hosts on the internal LAN, since the PIX 501 can't act as a full router.  We'll go with #2 since this is what I originally tested & only found out about the border router today (though personally, option #1 would be preferred).

  Please reconnect the PIX to the FW as you had before:  PIX outside interface connected to the FW's XL2 interface.  And leave the PIX inside connected to the LAN switch.

    On the FW:
- Make sure you have a static route for the VPN pool 172.25.203.x pointing to the PIX inside IP (192.168.10.12).  This is important! Even with a proper PIX config, if this route isn't setup, your VPN clients connected to the PIX *won't* be able to receive replies from the internal LAN hosts.  (This route must be present, whether using scenario #1 or #2 above.)
- Don't block any traffic whatsoever between the VPN pool & the LAN subnet.
- Set a 1-to-1 NAT for 1 of your public IPs to the PIX outside IP (192.168.20.3); eg:  89.1.1.1 is NAT'd to 192.168.20.3
- For now, don't block any traffic at all to the public IP in the above 1-to-1 NAT for the PIX.
- Later if you want, you could tighten this to only allow the following to the public IP assigned to the PIX in the 1-to-1 NAT:
  * in/out ICMP traffic
  * in/out UDP port 500 & 4500
  * in/out ESP protocol
   (But this isn't necessary, since the PIX by default will block attacks from the outside.)

    Run these commands in this order on the PIX:
no access-list inside_access_in   <- don't need it (& it's redundant)
no route outside 0.0.0.0 0.0.0.0 xxx.xxx.xxx.xxx
no crypto dynamic-map outside_dyn_map 40 set transform-set ESP-3DES-MD5
no crypto dynamic-map outside_dyn_map 60 match address outside_cryptomap_dyn_60
no access-list outside_cryptomap_dyn_60
ip address outside 192.168.20.3 255.255.255.0
route outside 0 0 192.168.20.254
nat (inside) 0 access-list inside_outbound_nat0_acl <- needed to specify VPN traffic
isakmp nat-traversal
clear xlate
crypto map outside_map interface outside
management-access inside    <- lets you ping/connect to PIX inside interface from a connected VPN client (good for troubleshooting)

  Hosts on the internal LAN:
- Ensure their default gateway is still only the FW inside IP (192.168.10.254)!

  What the above config provides:
- Client VPN to the PIX works, able to ping/connect to hosts on the LAN (192.168.10.x) subnet.
- Hosts on the LAN can still get to the Internet (via their default gateway: FW).
- You can ping to the Internet directly from the PIX; eg: while logged into the PIX, you can run "ping <some-external-IP>"
- From the Internet, you can ping the public IP that's NAT'd to the PIX

  What the above config does NOT provide:
- General outbound Internet access for a host behind the PIX *if* using the PIX as it's default gateway.  You don't need this, since all you care about is client VPN access to the internal LAN through the PIX, & besides, the default gateway for internal hosts *must* be the FW, & so non-VPN traffic will exit through the FW.

   Below is a copy/paste of the important config lines from the working PIX I tested, for comparison with your PIX once you've made the changes above.  In my test lab, the "FW" was NAT'ing a public IP to the PIX's outside IP (192.168.20.3), & the VPN client connected to that public IP.

access-list inbound permit icmp any any echo-reply
access-list inside_outbound_nat0_acl permit ip 192.168.10.0 255.255.255.0 172.25.203.0 255.255.255.0
ip address outside 192.168.20.3 255.255.255.0
ip address inside 192.168.10.12 255.255.255.0
ip local pool vpnpool 172.25.203.1-172.25.203.170
nat (inside) 0 access-list inside_outbound_nat0_acl
access-group inbound in interface outside
route outside 0.0.0.0 0.0.0.0 192.168.20.254 1
aaa-server LOCAL protocol local
sysopt connection permit-ipsec
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
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 interface outside
isakmp enable outside
isakmp identity address
isakmp nat-traversal 20
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 juser address-pool vpnpool
vpngroup juser idle-time 1800
vpngroup juser password ********
username smith password ***

cheers
0
 
LVL 8

Author Comment

by:jessmca
ID: 18006236
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
0
 
LVL 8

Author Comment

by:jessmca
ID: 18062818
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.
0

Featured Post

Maximize Your Threat Intelligence Reporting

Reporting is one of the most important and least talked about aspects of a world-class threat intelligence program. Here’s how to do it right.

Join & Write a Comment

Suggested Solutions

Don’t let your business fall victim to the coming apocalypse – use our Survival Guide for the Fax Apocalypse to identify the risks and signs of zombie fax activities at your business.
If your business is like most, chances are you still need to maintain a fax infrastructure for your staff. It’s hard to believe that a communication technology that was thriving in the mid-80s could still be an essential part of your team’s modern I…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
In this tutorial you'll learn about bandwidth monitoring with flows and packet sniffing with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're interested in additional methods for monitoring bandwidt…

705 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

19 Experts available now in Live!

Get 1:1 Help Now