1. Home
  2. Cisco Systems
  3. PIX 520 VPN problem

PIX 520 VPN problem

Hello:

I'm using a PIX 520 (running IOS 6.2(2)) as the VPN gateway. Then on the client side I'm using the Cisco VPN client ver 3.2.6.

I can connect through the Cisco VPN client to the firewall fine.

From the internal network (192.168.0.x), I can connect to the network

that is coming in through the Cisco VPN client (192.168.200.x). But that computer connecting through the client (192.168.200.x) cannot see the internal network (192.168.0.x) but it can connect to the internet.

So, the computer on the Cisco VPN client side that has (192.168.200.x) IP address cannot ping to the (192.168.0.x) network and connects to the Internet. But the (192.168.0.x) can ping to the (192.168.200.x) network.

Please help me out here.

Here's the configuration.

nameif ethernet0 outside security0 nameif ethernet1 inside security100 enable password 2KajajNIdI.8K9OU encrypted passwd 2KsjkskskI.89OU encrypted hostname pix520 domain-name pix520.com fixup protocol ftp 21 fixup protocol http 80 fixup protocol h323 h225 1720 fixup protocol h323 ras 1718-1719 fixup protocol ils 389 fixup protocol rsh 514 fixup protocol rtsp 554 fixup protocol smtp 25 fixup protocol sqlnet 1521 fixup protocol sip 5060 fixup protocol skinny 2000 names access-list 101 permit ip 192.168.0.0 255.255.255.0 192.168.200.0

255.255.255.0 access-list 102 permit icmp any any echo-reply access-list 102 permit icmp any any unreachable access-list split-tunnel permit ip 192.168.200.0 255.255.255.0 any access-list split-tunnel permit ip 192.168.0.0 255.255.255.0 any pager lines 24 interface ethernet0 10baset interface ethernet1 10full mtu outside 1500 mtu inside 1500 ip address outside 12.47.8.2 255.255.255.0 ip address inside 192.168.0.1 255.255.255.0 ip audit info action alarm ip audit attack action alarm ip local pool ippool 192.168.200.10-192.168.200.50 pdm location 192.168.0.0 255.255.255.0 outside pdm history enable arp timeout 14400 global (outside) 1 interface nat (inside) 0 access-list 101 nat (inside) 1 0.0.0.0 0.0.0.0 0 0 access-group 102 in interface outside route outside 0.0.0.0 0.0.0.0 12.47.8.1 1 timeout xlate 3:00:00 timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00 si p 0:30:00 sip_media 0:02:00 timeout uauth 0:05:00 absolute aaa-server TACACS+ protocol tacacs+ aaa-server RADIUS protocol radius aaa-server LOCAL protocol local http server enable http 192.168.0.0 255.255.255.0 inside no snmp-server location no snmp-server contact nmp-server community public no snmp-server enable traps floodguard enable sysopt connection permit-ipsec no sysopt route dnat crypto ipsec transform-set myset esp-des esp-md5-hmac crypto dynamic-map dynamic 10 set transform-set myset crypto map mymap 10 ipsec-isakmp dynamic dynamic crypto map mymap interface outside isakmp enable outside isakmp identity address isakmp policy 10 authentication pre-share isakmp policy 10 encryption des isakmp policy 10 hash md5 isakmp policy 10 group 2 isakmp policy 10 lifetime 86400 vpngroup vpnpix address-pool ippool vpngroup vpnpix dns-server 192.168.0.2 192.168.0.1 vpngroup vpnpix wins-server 192.168.0.2 vpngroup vpnpix default-domain pix520.com vpngroup vpnpix idle-time 1800 vpngroup vpnpix password ******** telnet 192.168.0.5 255.255.255.0 inside elnet timeout 5 ssh timeout 5 dhcpd address 192.168.0.10-192.168.0.41 inside dhcpd dns 12.47.8.3 12.47.8.4 dhcpd lease 36000 dhcpd ping_timeout 750 dhcpd enable inside terminal width 80

I was working with that firewall since a week and couldn't figured it out.

Reply to
CIB3RGUY
Loading thread data ...

you should update to PIXos 6.3.x and CCVPN 3.6.x or higher then you can add isakmp nat-t command

Reply to
Martin Bilgrav

Thanks for that. You are right. it might be a PAT issue as the client side am using is behind a Dlink router. I'll do that.

Atiq CIB3RGUY

Reply to
CIB3RGUY

You are not allowing any traffic from the client pool to the internal network in your access-list 102. You would need some statements such as access-list 102 permit ip 192.168.200.0 255.255.255.0 192.168.0.0

255.255.255.0 access-list 102 permit icmp 192.168.200.0 255.255.255.0 192.168.0.0 255.255.255.0 in order to allow your client users to reach your lan. Traffic is still moving from a lower security interface to a higher, even though it's ostensibly trusted traffic, and you need to explicitly define what you want to allow through.

Also, it would be a good idea to upgrade the PIX firmware and use a more recent version of the Cisco VPN Client.

Reply to
Jason

Which interface should i apply this access-list. I mean to the inside interface or outside interface.

Reply to
CIB3RGUY

To the same interface which access-list 102 is currently applied, the outside interface.

Reply to
Jason

totally nonsense ! He uses sysopt connection permit-ipsec, hence the ACL for outside is only for him to be able to ping and traceroute

Reply to
Martin Bilgrav

In article , CIB3RGUY wrote: :I'm using a PIX 520 (running IOS 6.2(2)) as the VPN gateway. Then on :the client side I'm using the Cisco VPN client ver 3.2.6.

:I can connect through the Cisco VPN client to the firewall fine.

:From the internal network (192.168.0.x), I can connect to the network :that is coming in through the Cisco VPN client (192.168.200.x). But :that computer connecting through the client (192.168.200.x) cannot see :the internal network (192.168.0.x) but it can connect to the internet.

The only way that the VPN clients would be able to see the internet is if split-tunneling was enabled. PIX 6.2 won't accept IPSec packets on the outside interface and route them to the outside interface, so the internet packet must not be hitting the PIX at all.

:nat (inside) 0 access-list 101 :nat (inside) 1 0.0.0.0 0.0.0.0 0 0

:sysopt connection permit-ipsec

:crypto dynamic-map dynamic 10 set transform-set myset :crypto map mymap 10 ipsec-isakmp dynamic dynamic :crypto map mymap interface outside

:vpngroup vpnpix address-pool ippool :vpngroup vpnpix dns-server 192.168.0.2 192.168.0.1 :vpngroup vpnpix wins-server 192.168.0.2 :vpngroup vpnpix default-domain pix520.com :vpngroup vpnpix idle-time 1800 :vpngroup vpnpix password ********

I think your VPN clients must be connecting through the vpngroup you have configured, rather than through the crypto dynamic map. Otherwise, the address-pool ippool wouldn't be having any effect.

Your vpngroup does not have a 'split-tunnel' statement, at least not in what you posted, so your split-tunnel ACL isn't doing you any good... but that also means that, contrary to my earlier paragraph, that your clients are -not- getting to the internet through a split-tunnel. Perhaps the split-tunnel statement got chopped from the posted configuration, or perhaps your clients are not actually connecting through the VPN at all, or perhaps your clients have done some tricky work to override the efforts that Cisco goes to to ensure that routings are only possible as configured at the firewall.

If that split-tunnel ACL is being activated, then it is incorrect. The split-tunnel ACL should be read in terms of packets going out of the PIX towards the VPN client. As you have allocated 192.168.200/24 to those clients, then 192.168.200/24 should be the -destination- in the ACL.

Reply to
Walter Roberson

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.