|
Question : Cisco PIX Client VPN
|
|
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]
|
Answer : Cisco PIX Client VPN
|
|
>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 "
- 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
|
|
|
|
|
