cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
20823
Views
48
Helpful
112
Replies

ASK THE EXPERTS - TROUBLESHOOTING ASA, PIX, and FWSM

ciscomoderator
Community Manager
Community Manager

Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to learn how to address and troubleshoot common problems with Adaptive Security Appliances, Private Internet Exchange and Firewall Service Modules with Kureli Sankar.  Kureli is an engineer supporting Cisco's firewall team in Research Triangle Park, North Carolina. Her team supports the Cisco Adaptive Security Appliance, Firewall Services Module, Cisco Security Manager, the Content Security and Control module, and the Zone Based Firewall module in Cisco IOS Software.

Remember to use the rating system to let Kureli know if you have received an adequate response.

Kureli might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through July 30, 2010. Visit this forum often to view responses to your questions and the questions of other community members.

112 Replies 112

Thank you, Kureli,  We did the workaround that successfully allowed our H.R. department to upload their payroll to our payroll hosting company’s https web server.

Would you know if there any thoughts on what side is causing the issue … the client side / browser or app initiating the SSL 443 or the host / receiving side?

Trevor,

Glad to hear that. Without the exact syslogs and/or captures, it will not be possible to say which side may have caused the problem.

-Kureli

Jigar Dave
Level 3
Level 3

Hi Kureli,

This is Jigar, I am having a strange scenario at my office, I am using PIX 525E at my office, on this PIX I have created tunnels with different vendors to reach to their networks. I have used AES-sha-MD5 authentication and preshared key to negotiate tunnels. now the issue happened is that when I ping to remote network (at the other side) only during that time only the tunnel is showing up otherwise the tunnel is down. I did debug and found that all two phases of negotiation gets complete. so what would be the issue here.

I want it like this --- irrespective to traffic flown through the tunnel or not - the tunnel should always be on.

Please help here.

Thanks in Advance

Jigar Dave

Hello Kureli,

Can you spare sometime here and reply on my query ?

Thanks,

Jigar

Jigar,

As I understand, if there is no interesting traffic and if the default timeout before rekey is (for example) 28800 seconds then, the tunnel will be torn down unless there is interesting traffic.  The IPsec tunnel terminates when the IPsec SAs are deleted or when the lifetime expires.

What you can do is increse the SA lifetime. The command is "isakmp policy 10 lifetime". Seems like the default according to 8.2 command reference is 86,400 seconds (one day).

http://www.cisco.com/en/US/docs/security/asa/asa82/command/reference/i3.html#wp1882554

-Kureli

kmcdonald1973
Level 1
Level 1

Hello,

I am used to using the Checkpoint Firewalls and they include a Smart Tracker that makes troubleshooting and viewing packets (translations, rule base number used, blocks..etc).

I have several Cisco 5505 but they do not have a similar way of viewing packets in such detail. can youi please tell me what is the best way to do this on the ASA's?

Thanks

Kevin,

Welcome to the PIX/ASA/FWSM world.  We have packet-tracker command that can provide some of what you are looking for. The rest you can view by collecting packet captures on the ASA. This command is not available on the FWSM.

Packet-tacker command: http://www.cisco.com/en/US/docs/security/asa/asa82/command/reference/p.html#wp1913020

How to collect packet captures on PIX/ASA/FWSM: https://supportforums.cisco.com/docs/DOC-1222

For troubleshooting first and foremost we collect logs (in debug level, which is level 7).  You can enable buffer logging and see what the logs show.

conf t

loggin enable

logging buffered 7

exit

sh logg | i x.x.x.x

where x.x.x.x is the IP address in question. To look at the translation that this host is taking you can issue the command

sh xlate debug | i x.x.x.x  -----> this command is pre 8.3 code.

For 8.3 code you need to issue the "sh nat" command.

-Kureli

Thanks for the quick response. I will try your suggestions and see how it works out. Thanks Kevin

bubarooni
Level 1
Level 1

Hi,

Any tips on improving RDP performance across a site-to-site VPN would be greatly appreciated.

I  have a PIX 506e and an 1841 that I have used to establish a  site-to-site vpn.  Servers are located behind the PIX that the users  behind the 1841 access through a Win2k3 Terminal server which is also  behind the PIX.  I have about 14 users at the remote site where the 1841  is located.

The PIX has a cable modem and is rated at 8x2 mb's.  The 1841 has 2 bonded T1's.

A tracert from the central site to the remote site is about 13 hops.

My  users at the remote location where the 1841 is located complain about  sluggish performance.  And they complain all the time...

Pinging  from my central location (where all servers are located) to the remote  location I came up with a MTU of 1272 using the ping command:

ping 192.168.9.29 -f -l 1272

and from the remote location to a server at the central location I got a MTU value of 1414 using the same procedure.

So  the smallest value I found that works is 1272.  Should I set that as  the value on the PIX and Router I'm using or should I use 1300 which I  keep seeing as I google this issue.

Also,  if I'm setting the MTU on the network devices, does that mean I don't  have to set it on the Terminal Server or the clients?

Anyway,  I'm hoping someone on this board will have ran across the same issue of  sluggish performance of RDP over a VPN and know a magical way for me to  fix or at least help it perform better.

Thanks In Advance!

bubarooni,

You have done quite a bit on your own. I'd say keep the MSS at 1272. On the remote router end under the interface config mode you can issue

"ip tcp adjust-mss" command. I have seen many cases especially with RDP over site to site tunnel being sluggish cases.  In almost all the cases lowering the value using the "ip tcp adjust-mss" command has helped.

-Kureli

If your link/s on the firewalls or ISP pipe is oversubscribed then LLQ priority queueing on both ends will help you.

Though, if the issue is unreliable links dues to ISP (drops etc) or propagation delays dues to the many hops in the middle, or oversubscribing on the hops in the middle themselves I am afraid there is not much you can do unless you have access to them.

The mss adjustment will help as much as it can. I believe you have adjusted to the max value that you can, so if increasing it a little doesn't help then the mss might not get you any further.

I hope it helps.

PK

Thanks for your quick responses!

I wasn't sure whether to use the 1272 or 1272 + 28 (for vpn overhead) but will leave at 1272 for now.

It will fly along just fine for awhile and then everything bogs down on them and the phone calls start pouring in!  I think a lot of it is just the work they are doing.  A lot of print jobs seems to be the main culprit but also an application they use on the term server that retrieves pdf's for editing and saving.

I will also start googling the LLQ thing which I'm not familiar with.

Thanks Again!

Refer this link below:

http://www.cisco.com/en/US/docs/security/asa/asa82/command/reference/s8.html#wp1517601

1380 data + 20 TCP + 20 IP + 24 AH + 24 ESP_CIPHER + 12 ESP_AUTH + 20 IP = 1500 bytes

In your case the calculation would be 1272+20TCP+20IP+24ESP_CIPHER+12 ESP_AUTH+20 IP=1348. May be a layer 3 device in the path has a lower MTU configured and the huge packets may be sent by the RDP server with a DF bit set which may be dropped along the way.  If lowering it to 1272 still doesn't resolve the issue try to lower it further.

When you say people are only complaining about RDP sluggishness (I am assuming internet traffic and other site to site traffic - loading a web page or e-mail is working fine), then the problem may very well be related to MSS.

-Kureli

I will also start googling the LLQ thing which I'm not familiar with.

LLQ is practically prioritization. http://supportforums.cisco.com/docs/DOC-1230 explains it with examples on the ASA.

PK

I would be a little suspect of the Cable modem connection.  Last year I troubleshot a problem for a client with site-site VPN with same symptom, one end was 3825 router with T1 and the remote site was 1700 on cable modem.  The cable modem was auto duplex only, and the cable company tech support said there was no option to change it.  1700 was set to full duplex so there was duplex mismatch and lots of late collisions.   Even after setting 1700 to half duplex to fix the duplex mismatch, there were lots of collisions on the cable modem and the connection was shared with other cable customers in the neighborhood. I never could get good results with the cable modem connection.   I would suggest Symetric DSL (SDLS) if it is available, or T1.  I have another client with 1841 on 1M SDSL and it works great.