1. Home
  2. Cisco Systems
  3. VPN Probleme with Pix 515 and operator router.

VPN Probleme with Pix 515 and operator router.

Hi! I have a problem trying to configure a VPN access to my internal network.

On the inside interface, the address is 172.23.107.254/24. On the outside interface, the address is 192.168.1.2/24 connected to

192.168.1.1/24 on the router of the operator. Then, I have a public address like 81.XX.XX.XX ...

The original configuration was this one : PIX Version 6.2(3) nameif ethernet0 outside security0 nameif ethernet1 inside security100 enable password AAAAAAA encrypted passwd AAAAAA encrypted hostname pix-515 domain-name test.fr 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 fixup protocol sip udp 5060 names object-group service PROTOPERMIT tcp port-object eq ftp port-object eq pop3 port-object eq imap4 port-object eq domain port-object eq www port-object eq https port-object eq smtp access-list outside_access_in deny ip any any pager lines 24 interface ethernet0 auto interface ethernet1 auto mtu outside 1500 mtu inside 1500 ip address outside 192.168.1.2 255.255.255.0 ip address inside 172.23.107.254 255.255.255.0 ip audit info action alarm ip audit attack action alarm pdm location 172.23.107.251 255.255.255.255 inside pdm history enable arp timeout 14400 global (outside) 10 interface nat (inside) 10 0.0.0.0 0.0.0.0 0 0 access-group outside_access_in in interface outside route outside 0.0.0.0 0.0.0.0 192.168.1.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 172.23.107.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 no sysopt route dnat telnet 172.23.107.0 255.255.255.0 inside telnet timeout 5 ssh timeout 5 terminal width 80

Then I add that, to connect to the pix with a Cisco VPN client contacting the public IP address 81.XX.XX.XX :

access-list 103 permit ip 172.23.0.0 255.255.0.0 any ip local pool POOL_VPN 172.23.107.101-172.23.107.103 nat (inside) 0 access-list 103 sysopt connection permit-ipsec sysopt ipsec pl-compatible crypto ipsec transform-set myset esp-des esp-md5-hmac crypto dynamic-map cisco 1 set transform-set myset crypto map dyn-map 20 ipsec-isakmp dynamic cisco crypto map dyn-map interface outside isakmp enable outside isakmp policy 10 authentication pre-share isakmp policy 10 encryption des isakmp policy 10 hash md5 isakmp policy 10 group 1 isakmp policy 10 lifetime 1000 vpngroup ICR_ALLIANCE address-pool POOL_VPN vpngroup ICR_ALLIANCE idle-time 1800 vpngroup ICR_ALLIANCE password TEST

Can you please help me ????

Thanks a lot !

Jov.

Reply to
LLFF
Loading thread data ...

I don't know what kind of address translation your router performs (can it handle protocol ESP or not), so in order to be on the safe side you need a newer PIX OS version. PIX OS 6.3(x) adds "nat-traversal" to your feature list. With a PIX

515 you could also try 7.0, but this may require a memory upgrade.
Reply to
Jyri Korhonen

In article , LLFF wrote: :I have a problem trying to configure a VPN access to my internal :network.

:On the inside interface, the address is 172.23.107.254/24.

:ip local pool POOL_VPN 172.23.107.101-172.23.107.103

:vpngroup ICR_ALLIANCE address-pool POOL_VPN

The address-pool used for your vpngroup must not be part of the inside interface IP range when the VPN is connecting to the outside interface. This is because the PIX *routes* the packets in order to decide which interface to use; when the dynamic range is part of the inside range, then the PIX is going to try to send the packets back towards the inside [and will promptly drop them because you cannot loop-back packets until PIX 7.0]. The outgoing packets to the remote device must "cross" the PIX in order to be encapsulated for delivery through the outside interface.

The other poster's reference to NAT-T is not relevant to your connection difficulties: NAT-T is for the case where you are trying to "pass through" IPSec packets to an inner device.

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.