PIX 515 DoS

[nille]

HI Guys,

One of my vpn clients is making my PIX to go down. The client is connecting to the pix from home through a DSl line. The client PC is behind a router which does NAT. I've heard that wouldn't be possible to make VPN to the PIX from a PC behind a router wich does NAT. But belive or not it works for this client.
The problem is that now the PIX is going down and I think the client is the reason for that. I got these errors yesterday when the client tried to connect to the PIX was down minutes after that:

2002-09-26 17:34:15 Local4.Warning 10.137.0.1 %PIX-4-402103: identity doesn't match negotiated identity (ip) dest_addr= 10.137.0.4, src_addr= 10.137.8.1, prot= icmp, (ident) local=213.150.33.210, remote=80.62.107.86, local proxy=0.0.0.0/0.0.0.0/0/0, remote_proxy=10.137.8.1/255.255.255.255/0/0

********************

2002-09-26 17:36:16 Local4.Error 10.137.0.1 %PIX-3-106011: Deny inbound (No xlate) udp src outside:10.137.8.1/138 dst outside:10.255.255.255/138

****************

2002-09-26 18:09:38 Local4.Warning 10.137.0.1 %PIX-4-402101: decaps: rec'd IPSEC packet has invalid spi for destaddr=213.150.33.210, prot=esp, spi=0x719eeea4(-1527865743)


Her is my PIX config:

PIX Version 6.2(2)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 dmz security50
enable password Vp1JhKeFW8Hyr8D3 encrypted
passwd Vp1JhKeFW8Hyr8D3 encrypted
hostname fw-kjaerulf
domain-name Kjaer-kjerulf.dk
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 sqlnet 1521
fixup protocol sip 5060
fixup protocol skinny 2000
no fixup protocol smtp 25
no names
access-list nonat permit ip 10.137.0.0 255.255.255.0 10.137.8.0 255.255.255.0
pager lines 24
logging on
logging buffered notifications
logging trap warnings
logging host inside 10.137.0.10
interface ethernet0 10baset
interface ethernet1 10baset
interface ethernet2 auto
mtu outside 1500
mtu inside 1500
mtu dmz 1500
ip address outside ********
ip address inside 10.137.0.1 255.255.248.0
ip address dmz 192.168.0.1 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
ip local pool vpn 10.137.8.1-10.137.8.200
no failover
failover timeout 0:00:00
failover poll 15
failover ip address outside 0.0.0.0
failover ip address inside 0.0.0.0
failover ip address dmz 0.0.0.0
pdm location ********
pdm location 10.137.0.2 255.255.255.255 inside
pdm location 10.137.0.5 255.255.255.255 inside
pdm location 10.137.0.8 255.255.255.255 inside
pdm history enable
arp timeout 14400
global (outside) 1 interface
global (dmz) 1 192.168.0.10-192.168.0.254
nat (inside) 0 access-list nonat
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
nat (dmz) 1 192.168.0.0 255.255.255.0 0 0
static (inside,outside) ******** netmask 255.255.255.255 0 0
static (inside,outside) ******** netmask 255.255.255.255 0 0
static (inside,dmz) ******** netmask 255.255.255.255 0 0
static (dmz,outside) ******** netmask 255.255.255.255 0 0
route outside 0.0.0.0 0.0.0.0 213.150.33.209 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
aaa-server AuthInbound protocol radius
aaa-server AuthInbound (inside) host ******** timeout 5
http server enable
http 10.137.0.7 255.255.255.255 inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
sysopt security fragguard
sysopt connection permit-ipsec
no sysopt route dnat
crypto ipsec transform-set myset esp-des esp-md5-hmac
crypto dynamic-map dynmap 10 set transform-set myset
crypto map mymap 10 ipsec-isakmp dynamic dynmap
crypto map mymap client configuration address initiate
crypto map mymap client configuration address respond
crypto map mymap interface outside
isakmp enable outside
isakmp key ******** address 0.0.0.0 netmask 0.0.0.0
isakmp identity address
isakmp client configuration address-pool local vpn outside
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 vpn3000 address-pool vpn
vpngroup vpn3000 dns-server 10.137.0.4
vpngroup vpn3000 wins-server 10.137.0.4
vpngroup vpn3000 default-domain ********
vpngroup vpn3000 idle-time 1800
vpngroup vpn3000 password ********
telnet 10.0.0.0 255.0.0.0 inside
telnet timeout 5
ssh ******** 255.255.255.0 outside
ssh ******** 255.255.255.248 outside
ssh timeout 60
vpdn group 1 accept dialin pptp
vpdn group 1 ppp authentication pap
vpdn group 1 ppp authentication chap
vpdn group 1 ppp authentication mschap
vpdn group 1 ppp encryption mppe 40
vpdn group 1 client configuration address local vpn
vpdn group 1 client configuration dns 10.137.0.4
vpdn group 1 client authentication aaa AuthInbound
vpdn group 1 pptp echo 60
vpdn enable outside
terminal width 80
Cryptochecksum:d8194891d9d519960b1a4bd529513415
: end
[OK]

Thanks

 

[yizhar]

HI.

I don't know the answer, but here are some guesses that might help you.

**

> The problem is that now the PIX is going down
What exactly do you mean?
When this happens, can you access the pix with telnet/PDM?
Can you ping perimeter router and internal hosts from the pix console?

**

What is the client OS?
What is the VPN client version?

Did you try to set a low MTU at the client? There are several problems with ADSL that are related to MTU setting.
Try first a low value of 500, then if this help try values between 500 and 1400.

**

Deny inbound (No xlate) udp src outside:10.137.8.1/138 dst outside:10.255.255.255/138

The client seems to have a subnet mask of 255.0.0.0 and sending network broadcast.
Since there is no "split-tunnel", all traffic from the client is sent to the pix.
If you configure split tunnel, it might prevent this, but you should decide if this is what you want from security point of view.

**
ip local pool vpn 10.137.8.1-10.137.8.200

The client NIC connected to ADSL modem might also be configured with the 10.x.x.x network, so the ip subnets might overlap at the client, changing the addresses used for VPN clients to something like 172.16.x.x might be better.

**

Check the PIX field notice page about the pix hang problem:

http://www.cisco.com/warp/public/tech_tips/index/hardware/security/500/fn.html

Bye
Yizhar Hurwitz

http://come.to/yizhar

http://teachers.sivan.co.il/yizhar

 

[nille]

Hi Yizhar,
Thanks for you help!

The Pix is going down... I mean that the PIX crashed minutes after the errors have occured. I couldn't access the PIX either from the internal network or from the internet, no telnet ,ping or pdm .

The Client OS is W2K, the VPN client is version 3.0.2

I didn't t tried the MTU settings, I will do that.

"split tunnel" How/where can I configure that? On the client? or on the PIX?

The Client network is configured with 192.168.***.****

 

[yizhar]

HI.

> the VPN client is version 3.0.2
Try the newer version 3.5.x, and see if it makes any difference.

> isakmp key ******** address 0.0.0.0 netmask 0.0.0.0
I think that you can remove this line from configuration because this one is used to determine pre-shared key:
vpngroup vpn3000 password ********


How old is the pix device (hardware), and did you check the field notice page?


If you need to solve this fast and cannot afford the downtime until you solve the issue, you can purchase or set-up a dedicated VPN server instead of using the pix.
In addition to better stability (distributing firewall and VPN tasks) you can get stronger encryption and better management depending on the solution you use.


BTW - Here is what Cisco wrote on those messages:

%PIX-4-402103: identity doesn't match negotiated identity (ip) dest_addr= IP_addr, src_addr= IP_addr, prot= protocol, (ident) local=IP_addr, remote=IP_addr, local_proxy=IP_addr/IP_addr/port/port, remote_proxy=IP_addr/IP_addr/port/port

Explanation An unencapsulated IPSec packet does not match the negotiated identity. The peer is sending other traffic through this security association. It may be due to an security association selection error by the peer. This may be a hostile event.

Action Contact the peer's administrator to compare policy settings


%PIX-4-402101: decaps: rec'd IPSEC packet has invalid spi for destaddr=IP_addr, prot=protocol, spi=spi

Explanation Received IPSec packet specifies SPI that does not exist in SADB. This may be a temporary condition due to slight differences in aging of SAs between the IPSec peers, or it may be because the local SAs have been cleared. It may also be because of incorrect packets sent by the IPSec peer. This may also be an attack.

Action The peer may not acknowledge that the local SAs have been cleared. If a new connection is established from the local router, the two peers may then reestablish successfully. Otherwise, if the problem occurs for more than a brief period, either attempt to establish a new connection or contact the peer's administrator


Bye
Yizhar Hurwitz

http://come.to/yizhar

http://teachers.sivan.co.il/yizhar