ASA 5505 Dropping Connection

[gotigers]

We recently purchased an ASA 5505. We had a pix501 before this and had cisco TAC translate the config from that into a language readable by the ASA. Switched everything over and it all works. VPN tunnels come up. Internet connectivity.. VPN clients can connect.. It's all good.. And that lasts for about a day.. Then the connection drops down to 0 kbps input on the outside connection every 5 minutes or so. People lose remote desktop connections (to other networks), applications running off of remote servers will fail, etc. etc.

We went over this with cisco and they said the config looks good, so they decided it was probably hardware and sent a new device. The new device did the exact same thing....
I suspect it's a problem with the ISP, but I don't know what??

Any thoughts would be appreciated..
here's the current config
ASA Version 7.2(4)
!
hostname *
domain-name *
no names
name 216.150.25.52 tcssql2
name 216.150.25.51 tcsweb2
name 216.150.24.205 tcssql1
name 216.150.24.204 tcsweb1
name 192.168.1.10 req-srv-1
name 66.132.221.236 ttweb1
name 66.132.221.238 ttweb2
name 66.132.221.241 ttsql1
name 66.132.221.243 ttsql2
name 66.132.221.245 ttwitness
name 66.132.221.235 ttwebin
name 216.54.66.173 *
name 216.54.66.172 *
name 192.168.1.20 *
name 192.168.1.121 *
name 192.168.100.0 dmz
name 192.168.100.165 test
!
interface Vlan1
nameif inside
security-level 100
ip address 192.168.1.1 255.255.255.0
speed 100
duplex full
!
interface Vlan2
nameif outside
security-level 0
ip address 216.54.66.174 255.255.255.0
!
interface Ethernet0/0
switchport access vlan 2
!
interface Ethernet0/1
!
interface Ethernet0/2
!
interface Ethernet0/3
!
interface Ethernet0/4
!
interface Ethernet0/5
!
interface Ethernet0/6
!
interface Ethernet0/7
!
ftp mode passive
clock timezone CST -6
clock summer-time CDT recurring
object-group service usftp tcp
port-object range 2121 2121
access-list inside_outbound_nat0_acl permit ip any 192.168.1.80 255.255.255.240
access-list inside_outbound_nat0_acl permit ip 192.168.1.0 255.255.255.0 host 216.150.24.205
access-list inside_outbound_nat0_acl permit ip 192.168.1.0 255.255.255.0 host 216.150.25.52
access-list inside_outbound_nat0_acl permit ip 192.168.1.0 255.255.255.0 host 216.150.25.51
access-list inside_outbound_nat0_acl permit ip 192.168.1.0 255.255.255.0 host 216.150.24.204
access-list inside_outbound_nat0_acl permit ip 192.168.1.0 255.255.255.0 192.168.1.80 255.255.255.240
access-list inside_outbound_nat0_acl permit ip 192.168.1.0 255.255.255.0 172.16.2.0 255.255.255.0
access-list inside_outbound_nat0_acl permit ip 192.168.1.0 255.255.255.0 192.168.10.0 255.255.255.0
access-list inside_outbound_nat0_acl permit ip 192.168.1.0 255.255.255.0 10.0.0.0 255.255.255.0
access-list inside_outbound_nat0_acl permit ip 192.168.1.0 255.255.255.0 host 66.132.221.236
access-list inside_outbound_nat0_acl permit ip 192.168.1.0 255.255.255.0 host 66.132.221.243
access-list inside_outbound_nat0_acl permit ip 192.168.1.0 255.255.255.0 host 66.132.221.241
access-list inside_outbound_nat0_acl permit ip 192.168.1.0 255.255.255.0 host 66.132.221.245
access-list inside_outbound_nat0_acl permit ip 192.168.1.0 255.255.255.0 host 66.132.221.238
access-list outside_cryptomap_dyn_20 permit ip any 192.168.1.80 255.255.255.240
access-list 101 permit tcp host 216.54.66.173 eq www host 216.54.66.174 eq 8090
access-list 101 permit tcp any host 216.54.66.174 eq 2121
access-list 101 permit tcp any interface outside eq 2122
access-list 101 permit tcp any host 216.54.66.174 eq smtp
access-list 101 permit tcp any host 216.54.66.174 eq imap4
access-list 101 permit tcp any host 216.54.66.174 eq 9300
access-list 101 permit tcp any host 216.54.66.174 eq https
access-list 101 permit icmp any any echo-reply
access-list 101 permit icmp any any unreachable
access-list 101 permit icmp any any time-exceeded
access-list 101 permit tcp any host 216.54.66.174 eq pop3
access-list 101 permit tcp any host 216.54.66.174 eq 8088
access-list 101 permit tcp any host 216.54.66.174 eq 8085
access-list 101 permit tcp any host 216.54.66.174 eq www
access-list 101 permit tcp any host 216.54.66.173 eq www
access-list 101 permit tcp any host 216.54.66.172 eq www
access-list 101 permit tcp any host 216.54.66.172 eq https
access-list 101 permit tcp any host 216.54.66.173 eq 88
access-list 101 permit tcp any host 216.54.66.171 eq https
access-list 101 permit tcp any host 192.168.100.165 eq www
access-list 101 permit tcp any host 216.54.66.170 eq https
access-list 101 permit tcp any host 216.54.66.169 eq https
access-list outside_cryptomap_30_1 permit ip 192.168.1.0 255.255.255.0 192.168.10.0 255.255.255.0
access-list outside_cryptomap_20_1 permit ip 192.168.1.0 255.255.255.0 host 216.150.24.205
access-list outside_cryptomap_20_1 permit ip 192.168.1.0 255.255.255.0 host 216.150.25.52
access-list outside_cryptomap_20_1 permit ip 192.168.1.0 255.255.255.0 host 216.150.25.51
access-list outside_cryptomap_20_1 permit ip 192.168.1.0 255.255.255.0 host 216.150.24.204
access-list require_splitTunnelAcl permit ip 192.168.1.0 255.255.255.0 any
access-list outside_cryptomap_dyn_20_1 permit ip any 192.168.1.80 255.255.255.240
access-list outside_cryptomap_50 permit ip 192.168.1.0 255.255.255.0 10.0.0.0 255.255.255.0
access-list outside_cryptomap_70 permit ip 192.168.1.0 255.255.255.0 host 66.132.221.236
access-list outside_cryptomap_70 permit ip 192.168.1.0 255.255.255.0 host 66.132.221.243
access-list outside_cryptomap_70 permit ip 192.168.1.0 255.255.255.0 host 66.132.221.241
access-list outside_cryptomap_70 permit ip 192.168.1.0 255.255.255.0 host 66.132.221.245
access-list outside_cryptomap_70 permit ip 192.168.1.0 255.255.255.0 host 66.132.221.238
pager lines 24
logging enable
logging monitor debugging
logging buffered debugging
logging asdm informational
mtu inside 1500
mtu outside 1500
ip local pool requireippool 192.168.1.85-192.168.1.95
ip local pool pptp-pool 172.16.2.1-172.16.2.254
icmp unreachable rate-limit 1 burst-size 1
asdm history enable
arp timeout 14400
nat-control
global (outside) 1 interface
nat (inside) 0 access-list inside_outbound_nat0_acl
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
static (inside,outside) tcp interface 2121 192.168.1.10 2121 netmask 255.255.255.255 0 0
static (inside,outside) tcp interface 2122 192.168.1.20 2122 netmask 255.255.255.255 0 0
static (inside,outside) tcp interface pop3 192.168.1.10 pop3 netmask 255.255.255.255 0 0
static (inside,outside) tcp interface 9300 192.168.1.155 9300 netmask 255.255.255.255 0 0
static (inside,outside) tcp interface 3389 192.168.1.155 3389 netmask 255.255.255.255 0 0
static (inside,outside) tcp interface 8088 192.168.1.20 8088 netmask 255.255.255.255 0 0
static (inside,outside) tcp interface 8090 192.168.1.121 81 netmask 255.255.255.255 0 0
static (inside,outside) tcp interface 8085 192.168.1.20 https netmask 255.255.255.255 0 0
static (inside,outside) tcp 216.54.66.172 81 192.168.1.20 81 netmask 255.255.255.255 0 0
static (inside,outside) tcp 216.54.66.173 www 192.168.1.121 www netmask 255.255.255.255 0 0
static (inside,outside) tcp 216.54.66.172 www 192.168.1.21 www netmask 255.255.255.255 0 0
static (inside,outside) tcp 216.54.66.172 https 192.168.1.21 https netmask 255.255.255.255 0 0
static (inside,outside) tcp 216.54.66.173 88 192.168.1.158 www netmask 255.255.255.255 0 0
static (inside,outside) tcp 216.54.66.171 https 192.168.1.19 https netmask 255.255.255.255 0 0
static (inside,outside) tcp 192.168.100.165 www 192.168.1.162 www netmask 255.255.255.255 0 0
static (inside,outside) tcp 216.54.66.169 https 192.168.1.40 https netmask 255.255.255.255 0 0
static (inside,outside) tcp interface https 192.168.1.30 https netmask 255.255.255.255 0 0
static (inside,outside) tcp interface imap4 192.168.1.30 imap4 netmask 255.255.255.255 0 0
static (inside,outside) tcp interface www 192.168.1.30 www netmask 255.255.255.255 0 0
static (inside,outside) tcp interface smtp 192.168.1.30 smtp netmask 255.255.255.255 0 0
access-group 101 in interface outside
route outside 0.0.0.0 0.0.0.0 216.54.66.161 1
route outside 192.168.100.0 255.255.255.0 192.168.100.1 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
http server enable
http 192.168.1.0 255.255.255.0 inside
no snmp-server location
no snmp-server contact
tftp-server inside 192.168.1.153 /pixconfig
crypto ipsec transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto dynamic-map outside_dyn_map_1 20 match address outside_cryptomap_dyn_20_1
crypto dynamic-map outside_dyn_map_1 20 set transform-set ESP-3DES-MD5
crypto map outside_map_1 20 match address outside_cryptomap_20_1
crypto map outside_map_1 20 set peer 216.150.25.76
crypto map outside_map_1 20 set transform-set ESP-AES-128-SHA
crypto map outside_map_1 30 match address outside_cryptomap_30_1
crypto map outside_map_1 30 set peer 24.153.242.215
crypto map outside_map_1 30 set transform-set ESP-AES-128-SHA
crypto map outside_map_1 50 match address outside_cryptomap_50
crypto map outside_map_1 50 set peer 68.15.131.130
crypto map outside_map_1 50 set transform-set ESP-3DES-SHA
crypto map outside_map_1 70 match address outside_cryptomap_70
crypto map outside_map_1 70 set peer 66.132.221.239
crypto map outside_map_1 70 set transform-set ESP-AES-128-SHA
crypto map outside_map_1 65535 ipsec-isakmp dynamic outside_dyn_map_1
crypto map outside_map_1 client authentication LOCAL
crypto map outside_map_1 interface outside
isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption aes
hash sha
group 2
lifetime 86400
crypto isakmp policy 20
authentication pre-share
encryption 3des
hash md5
group 2
lifetime 86400
crypto isakmp policy 40
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
telnet 0.0.0.0 0.0.0.0 inside
telnet timeout 60
ssh 206.126.161.217 255.255.255.255 outside
ssh timeout 60
console timeout 0
management-access inside
dhcpd address 192.168.1.50-192.168.1.75 inside
dhcpd dns 216.54.2.10 216.54.2.11
dhcpd lease 3600
dhcpd ping_timeout 750
tunnel-group 66.132.221.239 type ipsec-l2l
tunnel-group 66.132.221.239 ipsec-attributes
pre-shared-key *
tunnel-group 68.15.131.130 type ipsec-l2l
tunnel-group 68.15.131.130 ipsec-attributes
pre-shared-key *
tunnel-group 24.153.242.215 type ipsec-l2l
tunnel-group 24.153.242.215 ipsec-attributes
pre-shared-key *

!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
!
service-policy global_policy global
prompt hostname context
Cryptochecksum:aeeed4dd5fb2a85b58da1976715607a1
: end

 

[SizroSpunkmire]

You mentioned 0kbps input on the outside connection. Does this mean that your outbound data still sends?

 

[gotigers]

Here's a shot of what's happening - I have not noticed any drop in output, but we normally are not uploading that much here..

I am thinking a denial of service attack on the router.. Again - the connection always comes back and doesn't stay down for long.. but obviously it's not acceptable to be dropping applications all day long..

 

[SizroSpunkmire]

Interesting. It's a long shot but maybe your ISP is filtering or throttling encrypted traffic (assuming its torrents or something instead of VPN)? If it's up for a while and then goes down, that could be caused by the ISP detecting a sudden influx of encrypted traffic to your IP.

Then they cut it off which causes everyone to gradually reconnect and eventually the cycle just repeats itself as more and more traffic finds its way to your network.

Just a theory mind you but it's worth enquiring about.

 

[gotigers]

After working on this for several hours yesterday and then again this morning we've come to realize that it's a single vpn IPSEC tunnel causing the problem.. Those are the only things that get disconnected - the programs and remote desktops that we have open from those remote locations.. The remote desktop connections will reconnect automatically after 10 or 20 seconds but the applications do not as they have to be logged into again.. I'm working with Cisco on this and hopefully will have a resolution soon.. At least now that I have an idea about what's going on.. Thank you for the suggestions!! I appreciate it.

 

[dieselboy]

gotigers, i am having this EXACT same problem with a 5505 site to site vpn to a 5510.
the users rdp from one site to their hosted equipment in hosted office where the 5510 resides.

i am using DH5 for the ike, and aes-128 / sha1 and the psk is just over 20 chars long..

for some reason, the vpn drops at about 10:20am every day, but reconnects immediately.
the ike does not time out, it just drops for no apparent reason.

did you find resolution on your problem??

 

[techguyinohio]

We are having the same problem as well, but ours is with the RDP and IBM Client Access back to an AS/400 on our VPN. The VPN shows it stays up, but it drops the traffic and then we can reconnect again shortly after with no problem again, then it repeats all over again..

Anyone have any fixes for this yet??? We have the ASA-5505 and had a PIX 506e before...

Thanks

Looking for Answers in Ohio
Technical Rep.

 

[dieselboy]

hey techguyinohio
i fixed the issue with ours..

its a little silly really, but the group policy for the Site 2 site VPN was set to use the same policy as the SSL vpn. which meant that because we had set a time out on the ssl vpn, that after a certain time the ASA closed the site to site vpn, which then immediately came back up again but dropped ALL connections through it.
to resolve, i made a new policy that only closed after no activity and not a set time. and then joined this with the site- to - site vpn.
problem solved.

 

[techguyinohio]

dieselboy-

Thanks for the update and quick response. I will try that and let you know...

techguyinohio

 

[dieselboy]

the thing was, that both the site to site and ssl vpns were using the default group policy set by ASDM. hope you get it sorted!

 

[techguyinohio]

Yeah here too.. The only question I have is we have 2 site to site vpn's using access rule 102 and 103 - the vpn using 102 is always up as it is our connection to our minnesota location. this connection is usally the only one on. The other vpn is for our software vendor in florida, but they hardly connect to us. the VPN in MN is the one that when using the asa-5505 7.2(4) version that it drops the telnet sessions and rdp, etc. the entire connection does not seem to go down, just those services and then once they close the programs and reopen, they are fine again.

When we go back to the PIX-506e, we don't have those problems, all works fine... i am being told its not the router, but there has to be some settings for the ibm client access software which connects back to the as/400 here in ohio that is causing the drop. There is nothing in the client access software to change, its a cut and dry terminal session program using port 23 to connect, that's it, no timers or anything on it. The two routers have almost identical configs the 506e and the asa-5505. The problem i am seeing, maybe is... that i can see when telnet sessions connect for the as/400 usage in MN when they logon using the Client access software, but after they connect, that's it, you don't see any more items built, or torn down in the syslog messages on the asa's front page like you do when you browse web sites, etc using IE, or Firefox, etc. With each site you goto it throws a line into the log showing your connection to the site and back, etc.. it's like it sees you connect and that's it with the client access.. while you run reports and use the software across this software which again connects on port 23, it does not see anything, or log anything. then drops the connection after a while like a timer is causing the problem, but can't seem to find it.

I turned timers off, which is not good due to all connections would never drop and would degrade performance, but even then it still dropped, but just not as quickly. The other problem is the DSL provider we have has us on a 3mb/1mb 1/2 duplex connection which is all they offer right now which is fine, they are updating their network but then that uses a mipex box for a static IP that we need so they are saying we are probably going to have to stay with what we have, so our 5505 is set to have the eth0 port at 10mb-half and the inside eth1 is at 10mb-full duplex that connects to our network internally to our 3-com switch. of course we have collisions due to the mis-match of duplex, but when we go back onto the old PIX 506e, we don't have this trouble, timers are left at normal and not off like in the asa. i hope we did not buy an $800 paper weight. I am on 45 days+ trying to find an answer to this.... IBM, nor Cisco nor the hardware tech company we bought this from wants to take responsibility. they have all ran tests and say, nothings wrong... obviously if everyone is having trouble from what i see here, they missed something somewhere, and i hope to find it here...

Any and all suggestions would be great if this is similar to your issue, but we do not have any ssl vpn's, just site to site only on IPSec Tunnel.

Thanks had to change back to the PIX 506e for now until I get more information to maybe help.. Cisco is also looking into it again, but they are clueless right now and IBM said on things it all looks fine that if we hookup the asa and it fails and then go back to the pix-506e and it's good again that it has to be with the ASA config somewhere it's cutting the connection for a split second like a timeout and then it lets you back on no problem and repeats again... Very frustrating...

Thanks dieselboy for any info you can give, or if anyone else has anything as well to add I was GREATLY APPRECIATE THE HELP!!! Thank you...

TechGuyInOhio

 

[dieselboy]

im a little lost.. you wont have a duplex mismatch if both sides are configured the same. having both sides half duplex is far better than having one side set to full duplex and the other side failing negotiation and falling back to half duplex.

anyhow, as you say if it works on the pix it should work on the 5505.
is it possible you could post your config of the 5505 MINUS THE PASSWORDS!! AND WAN IP INFO AND PEER ETC... also what is doing your DSL ?
where do you say the half duplex connection is? is it in the isp network?
more info needed i will try and help..
thanks!

 

[dieselboy]

edit:
another thing, can you log into ASDM and go to monitoring, then look at the current active vpns.. you can double click on them, and it can tell you how long it has been up for.
what i would like to determine first, is if the clients lose connection to the remote site lan because of the vpn closing..
the best way to tell this is know when or what time they lost connectivity, and then look at the current vpns and see how long the one in question has been up for. if its been up for 10 minutes, and they lost connection 10 minutes ago then that would match up...

 

[techguyinohio]

dieselboy-

I will post the config here shortly for you to review. i appreciate the assistance and insight into this. i will also change the inside connection to 1/2 duplex instead of it being full and see if that will make any difference. the vpn i can say seems to stay up it's just the telnet port 23 sessions that are dropping..

the funny part is i can see all the traffic across the router in the logs coming in and out, except for the telnet sessions back and forth. i can see the connection and the failed connections when the router drops them all and says the packets are not associated with anything and it lists them all as DENY and closes the sessions that were active due to ?? not seeing traffic packets back and forth maybe??? IBM is puzzled as to why we can see all other traffic in the logs every second for web sites visited, the exchange email, etc. but nothing except for the connect and disconnect of the client sessions using telnet. they said unless maybe the packets were being ignored due to their size???? they are 41 and 46 bytes back and forth, very small basically a keep alive from OH to MN and BACK but again, these are not shown as a TCP port 23 session anywhere in the traffic list going back and forth. they only show up when we first load the client session software to the as/400 and login and then that's it... Is there a setting i am missing to where the ASA is ignoring these packets and I can change this??? Or an encapsulation problem??? doesn't the asa auto on port 500 and 4500 for encapulation? that shouldn't be the issue, but the packet traffic not showing up could be???? again, is there a setting for packet size to ignore if below a certain amount? or should it be seeing that traffic and packets TCP regarless on port 23?
IBM says yes that the router is somehow ignoring them...

thanks again.... your thoughts?

TechGuyinOhio

 

[techguyinohio]

dielselboy-

now this is not good. our new cisco 1841 at our ohio location here is allowing incoming traffic, but we can't go to any websites, or send e-mail to anyone outside. web server and email server is up and i can connect to our network from outside in, but not inside out now. i do see alot of denied UDP from all these ip addresses on port 53 to our exchange server ip on all the ports. this just started yesterday and we have reset the 1841 several times to try and clear it and get it going. Our VPN is also still working fine, it's just our outbound traffic so i am sending this from home to see if you have any ideas???? for some reason it says on the interface front page that the firewall rules are inactive, but it shows all these packets getting denied.

I am trying to get this figured out before the start of monday to get us back up. Something to do with DNS I see, but not sure where to look????

As for our MN location on the asa-5505, the DSL company we have is upgrading us to a 100mb full duplex network on Tuesday as we are on VDSL out there and they are switching us to ADSL. I thought we were already on ADSL so they are saying all the errors are probably causing the drop of the 5505 intermittantly cause it goes for quite a few hours and drops and starts all over, so this way everything will be 100mb full. Sound like that could be the problem... Hopefully.. Let me know and thanks again for anything you can give me on the current issue at our ohio location with the 1841. this is all new equipment we just got. we upgraded from a pix515e in ohio and never had any trouble like this before. We also just upgraded to Time Warner Fiber 5/5mb as well, but they checked all and said its ok but we still cant get out....

Thanks again.

Help!

TechGuyinOhio

 

[dieselboy]

sorry i completely forgot about this thread..

if the firewall is denying traffic, but there is no acl on that interface, what is the security level of that interface? make sure the number is higher than the outside interface so that traffic can flow to it.

if you have any acl outbound then there is an implicit deny at the end.

 

[techguyinohio]

sorry i completely forgot about this thread..

if the firewall is denying traffic, but there is no acl on that interface, what is the security level of that interface? make sure the number is higher than the outside interface so that traffic can flow to it.

if you have any acl outbound then there is an implicit deny at the end.

dieselboy-

Hey thanks for the help on everything.. after investigating with IBM a couple things, it turned out to be a combination of the ispection rules on the firewall as well as the ibm client access terminal sessions keep alive needing added to each computer's config file. and updating the TCP/IP in windows registry to add the line KEEPALIVETIME=60000 for (60 sec) decimal

Everyhing is up and running normally now.. I appeciate the insight and have saved all the info if anyone else needs, or runs into this problem with remote connections back through to an AS/400, or similar using a client access product, etc.

Thanks again.
TechGuyinOhio

 

[techguyinohio]

sorry i completely forgot about this thread..

if the firewall is denying traffic, but there is no acl on that interface, what is the security level of that interface? make sure the number is higher than the outside interface so that traffic can flow to it.

if you have any acl outbound then there is an implicit deny at the end.

dieselboy-

Hey thanks for the help on everything.. after investigating with IBM a couple things, it turned out to be a combination of the ispection rules on the firewall as well as the ibm client access terminal sessions keep alive needing added to each computer's config file. and updating the TCP/IP in windows registry to add the line KEEPALIVETIME=60000 for (60 sec) decimal

Everyhing is up and running normally now.. I appeciate the insight and have saved all the info if anyone else needs, or runs into this problem with remote connections back through to an AS/400, or similar using a client access product, etc.

Thanks again.
TechGuyinOhio

 

[dieselboy]

glad you got it sorted!
for future, i have found that the following are really helpful with issues -
http://networking-forum.com
http://ocforums.com

 

[EmBee]

dieselboy-

Hey thanks for the help on everything.. after investigating with IBM a couple things, it turned out to be a combination of the ispection rules on the firewall as well as the ibm client access terminal sessions keep alive needing added to each computer's config file. and updating the TCP/IP in windows registry to add the line KEEPALIVETIME=60000 for (60 sec) decimal

Everyhing is up and running normally now.. I appeciate the insight and have saved all the info if anyone else needs, or runs into this problem with remote connections back through to an AS/400, or similar using a client access product, etc.

Thanks again.
TechGuyinOhio

Hello TechGuyinOhio,

I hope you are still reading this thread. recently we bought a couple of ASA5505's running os version 8.2.1 and implemented L2L tunnels to our headquarter. At random we have dropped sessions with clients running custom software which connect to a database from Windows XP maschines.
First i suspected something with the L2L IpSec tunnel so I moved one of the 5505's to a direct connection just doing firewall functions first without (no nat-control) and later with translation (nat-control). The problems still excists. Now I have done a lot of packet capturing wich still needs to be analyzed. Also in the ASP capture I see a lot of drops. Mostly keep-Alives sent from the database server. Which I still can not explain why they are dropped. Maybe this problem can be resolved by adding keep alive to the client software
and to Windows XP(Where in the registry exactly?). But as you also stated. There were no problems with a PIX firewall. So the big question is: is it a Cisco or a software problem? Any help would be much appreciated.

Thanx in advance.
EmBee

 

[ruben76]

dieselboy-

Hey thanks for the help on everything.. after investigating with IBM a couple things, it turned out to be a combination of the ispection rules on the firewall as well as the ibm client access terminal sessions keep alive needing added to each computer's config file. and updating the TCP/IP in windows registry to add the line KEEPALIVETIME=60000 for (60 sec) decimal

Everyhing is up and running normally now.. I appeciate the insight and have saved all the info if anyone else needs, or runs into this problem with remote connections back through to an AS/400, or similar using a client access product, etc.

Thanks again.
TechGuyinOhio

Hi TechguyinOhio,

I'm facing the same problem you explained here above. The strangest thing is that while the remote client access is working, the connection with as/400 randomly drops. I modified the client access keepalive setting and registry keepalive setting in the windows xp remote client, but the problem persists.
Can you please explain me what you did with ispection rules?
I've a couple of ASA5505, in L2L IPsec configuration (no trafic filter enabled on L2L with sysopt exception).
I hope you will get back soon.

Thanks in advance.

Ruben ItalianTechguy

 

[tromance]

Hi ruben76,

We are seeing the same issues with as/400 drops. Did you ever get your issue resolved?

Thanks,
tromance

 

[Guest]

Hello all, we are seeing almost the same issue. We have several sites which are using ASA5505's. Each ASA at the remote site has 2 tunnels, one to the the location which hosts our AS400 server and one to the corp office. The tunnel to the AS400 server will continually drop even there is activity within the AS400 client, they simply get kicked off. The other tunnel to the corp office never drops, only the tunnel providing access to the AS400. I have keepalives enabled on the ASA but does not matter. A side note, I can keep the tunnel open if I put a constant ping from one of the clients at the client site to a server at the server site. I assume the perm fix would be to implement the keepalives on the AS400 client and possibly modify our inspection rules that was mentioned by TechGuyInOhio. Does anyone know the specifics? Any help is greatly appreciated as this is affecting every site we have our AS400 clients at.

 

[Mark1818]

I too would like to know what inspection rules were changed. We have tried the other AS400 changes and are still dropping connections. Thanks

 

[senamegan]

I also am having the same problem. I have made the registry change but I would like to know what changes you made to the inspection rules in the firewall. Please help me out with this! I hope you have a Happy Thanksgiving by the way!

TechGirlinOhio