pix 501- limited vpn hosts?

hi, here's my version:

pix-vpn-gw# sh ver

Cisco PIX Firewall Version 6.3(4) Cisco PIX Device Manager Version 3.0(2)

Compiled on Fri 02-Jul-04 00:07 by morlee

pix-vpn-gw up 29 mins 3 secs

Hardware: PIX-501, 16 MB RAM, CPU Am5x86 133 MHz Flash E28F640J3 @ 0x3000000, 8MB BIOS Flash E28F640J3 @ 0xfffd8000, 128KB

0: ethernet0: address is 000d.6585.845c, irq 9 1: ethernet1: address is 000d.6585.845d, irq 10 Licensed Features: Failover: Disabled VPN-DES: Enabled VPN-3DES-AES: Enabled Maximum Physical Interfaces: 2 Maximum Interfaces: 2 Cut-through Proxy: Enabled Guards: Enabled URL-filtering: Enabled Inside Hosts: 50 Throughput: Unlimited IKE peers: 10

This PIX has a Restricted (R) license.

### tunnel properties seem standard except the lifetime:

crypto ipsec transform-set REMOTE esp-3des esp-md5-hmac crypto map VPN 10 ipsec-isakmp crypto map VPN 10 match address VPN2 crypto map VPN 10 set peer REMOTE-Router crypto map VPN 10 set transform-set REMOTE crypto map VPN interface outside isakmp enable outside isakmp key ******** address REMOTE-Router netmask 255.255.255.255 isakmp identity address isakmp policy 100 authentication pre-share isakmp policy 100 encryption 3des isakmp policy 100 hash md5 isakmp policy 100 group 1 isakmp policy 100 lifetime 86400

### PIX has a vpn tunnel to a remote router, which is not under my control. I have 10 hosts on the inside and there are 35 on the other end of the tunnel.

Am I assuming correctly that I have only one IKEpeer ?

my problem: connection to remote site is very unreliable and it seems after pix reboots everything works. where can i start looking ?

thanks, M

Reply to
mak
Loading thread data ...

Yes.

Check to see if you are running out of memory.

Reply to
Walter Roberson

ok, getting closer: memory seems ok,

10.1.0.19 can ping 10.11.0.67 if 10.1.0.19 tries http to 10.11.0.67 we get this error log: (10.11.0.230 is websense proxy on behind pix) 302014: Teardown TCP connection 79755 for outside:10.1.0.19/1390 to inside:10.11.0.230/80 duration 0:00:01 bytes 2704 TCP Reset-O 302013: Built inbound TCP connection 79756 for outside:10.1.0.19/1391 (10.1.0.19/1391) to inside:10.11.0.230/80 (10.11.0.230/80) 106015: Deny TCP (no connection) from 10.1.0.19/1390 to 10.11.0.230/80 flags RST on interface outside 106015: Deny TCP (no connection) from 10.1.0.19/1390 to 10.11.0.230/80 flags RST on interface outside 302014: Teardown TCP connection 79756 for outside:10.1.0.19/1391 to inside:10.11.0.230/80 duration 0:00:01 bytes 2704 TCP Reset-O 302013: Built inbound TCP connection 79757 for outside:10.1.0.19/1392 (10.1.0.19/1392) to inside:10.11.0.230/80 (10.11.0.230/80) 106015: Deny TCP (no connection) from 10.1.0.19/1391 to 10.11.0.230/80 flags RST on interface outside 106015: Deny TCP (no connection) from 10.1.0.19/1391 to 10.11.0.230/80 flags RST on interface outside 302014: Teardown TCP connection 79757 for outside:10.1.0.19/1392 to inside:10.11.0.230/80 duration 0:00:01 bytes 2704 TCP Reset-O 302013: Built inbound TCP connection 79758 for outside:10.1.0.19/1393 (10.1.0.19/1393) to inside:10.11.0.230/80 (10.11.0.230/80) 106015: Deny TCP (no connection) from 10.1.0.19/1392 to 10.11.0.230/80 flags RST on interface outside 106015: Deny TCP (no connection) from 10.1.0.19/1392 to 10.11.0.230/80 flags RST on interface outside

looks like PIX is detecting an invalid packet, but client is trying to get to websense not the other way round...

how can this be? again after reboot it client can connect

cheers, M

Reply to
mak

This is typical for PIX 6.3 and later PIX 6.2. The PIX is not waiting long enough to scavenge packets "in flight" when it knows that a connection has torn down, and is getting rid of connection information quickly. Then when the packets "in flight" arrive, it thinks they are new attempts and logs denials for them.

The behaviour is annoying but harmless, and does not in itself indicate any problems with the connections. If, though, you were to log to a syslog server with timestamps configured, and the timing of the entries showed signficant time lapses, then that could point to client or server problems; 'capture' would then be of more use in tracking down the detailed information.

Reply to
Walter Roberson

thanks robert,

but why does the problem disappear, after a pix reboot, any ideas?

M
Reply to
mak

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.