What's wrong with this config?

I'm mostly new to Cisco, and a problem has been haunting me that I just can't fix. We have an odd issue that various types of outbound VPN connections do not work. Some do, but many will allow connection, but then no traffic will pass. I've taken out most things for security reasons, but the config is here... These same VPN connections work fine on the same client computers when the PIX is not used. Any help would be appreciated.

# sh run : Saved : PIX Version 6.3(3) interface ethernet0 auto interface ethernet1 100full interface ethernet2 100full interface ethernet3 auto shutdown interface ethernet4 100full nameif ethernet0 outside security0 nameif ethernet1 inside security100 nameif ethernet2 DMZ security50 nameif ethernet3 DEMO security5 nameif ethernet4 Pub_Wireless security8 enable password xxxxxxxxxxxx encrypted passwd xxxxxxxxxxxxxxx encrypted hostname xxxxxxxxxx domain-name xxxxxxxxxxx.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 ils 389 fixup protocol pptp 1723 fixup protocol rsh 514 fixup protocol rtsp 554 fixup protocol sip 5060 fixup protocol sip udp 5060 fixup protocol skinny 2000 no fixup protocol smtp 25 fixup protocol sqlnet 1521 fixup protocol tftp 69 names access-list OutIn permit udp any host x.x.x.x eq domain

-many others similar to one above.

access-list dmz1 permit ip any any

no pager logging on logging timestamp logging buffered emergencies logging trap debugging logging history debugging logging host inside x.x.x.x mtu outside 1500 mtu inside 1500 mtu DMZ 1500 mtu DEMO 1500 mtu Pub_Wireless 1500 ip address outside x.x.x.x ip address inside x.x.x.x ip address DMZ x.x.x.x.x

ip audit info action alarm ip audit attack action alarm drop ip local pool POOL no failover failover timeout 0:00:00 failover poll 15 no failover ip address outside no failover ip address inside no failover ip address DMZ no failover ip address DEMO no failover ip address Pub_Wireless pdm history enable arp timeout 14400 global (outside) 10 x.x.x.x nat (inside) 10 0 0 nat (DMZ) 11 0 0 static (DMZ,outside) x.x.x.x x.x.x.x netmask 0 0 many others static (inside,DMZ) netmask 0 0 many others

access-group OutIn in interface outside access-group dmz1 in interface DMZ access-group Pub_Wireless1 in interface Pub_Wireless route outside x.x.x.x 1 timeout xlate 3:00: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 uauth 0:05:00 absolut aaa-server TACACS+ protocol tacacs+ aaa-server RADIUS protocol radius aaa-server LOCAL protocol local aaa-server AUTH protocol radius aaa-server AUTH (inside) host .radius. timeout 10 url-server (inside) vendor websense host timeout 5 protocol TCP version 4 url-cache src_dst 128KB filter url except filter url http allow http server enable http inside snmp-server host inside poll snmp-server location snmp-server contact snmp-server community public snmp-server enable traps floodguard enable sysopt connection permit-ipsec crypto ipsec transform-set SET esp-des esp-md5-hmac crypto dynamic-map dynmap 10 set transform-set SET crypto map MAP 10 ipsec-isakmp dynamic dynmap crypto map MAP client authentication AUTH crypto map MAP interface outside isakmp enable outside isakmp identity address isakmp nat-traversal 20 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 vpn address-pool POOL vpngroup vpn dns-server vpngroup vpn default-domain xxxxx.com vpngroup vpn idle-time 1800 vpngroup vpn password ******** telnet inside telnet timeout 5 ssh inside ssh timeout 5 console timeout 0 url-block url-mempool 1500 url-block url-size 4 terminal width 80 Cryptochecksum:00000000000000000000000000000000 : end
Reply to
Loading thread data ...

Is the difficulty with VPN traffic -through- the PIX, or VPN traffic where the PIX terminates the tunnel (and traffic then goes unencrypted to inside hosts) ?

There are some known security problems in 6.3(3) and 6.3(4) and a known security problem in 6.3(5) . You should be able to get

6.3(4) for free even if you don't have a support contract; you probably can't get 6.3(5) itself for free without a support contract, but in theory you can get the 6.3(5) rebuild free without a support contract [but it's a bit of a nuisance to do so if you have to go through Cisco.]

The problem would have been easier to resolve if you had not hidden the internal IP address.

Where is your global statement that references policy 11 ?

Based upon those statements, and the lack of a displayed route statement that would contraindicate, we deduce that chances are good that your internal IP address range is 192.168.1.* .

POOL is in 192.168.1.*, the same IP range that we deduce that your inside interface is in. The address-pool statement directs that incoming EzVPN clients be given IP addresses in the range denoted by POOL. Because the clients will be outside but POOL refers to IP addresses that are inside, you are going to encounter routing problems that will cause the clients to fail immediately after negotiation.

You should change POOL so that it refers to an address range that is outside (e.g., because of the default route) rather than inside. For example, 192.168.3.* .

Reply to
Walter Roberson

Thank you for your help Walter... responses inline...

The difficulty is traffic THRU the PIX. We no longer terminate inbound VPN connections to it. I also realized that I forgot 1 very important troubleshooting note. The problem goes away if you use a server that has a static route mapped to the outside. Anything that has a static mapping from the inside (192.168.1.x) to an outside IP works fine.

I will check on the support and getting the IOS updated soon.

Internal IP is

unknown. Nat may not be needed. Everything in the DMZ is a static map.

Point taken, but at this time, we're not terminating any VPN's to this device.

Thanks again for your time.

Reply to

If you are strictly talking about outbound VPN connections. What you are going to need to do is give each VPN client connection its own static and ACL. VPN does not like NAT. So in order to bypass the issues that VPN has with NAT you need to do one of two things. Either use NAT traversal or give each client a static ip connection to the outside.

Reply to

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.