This discussion is locked

Ask the Expert: Troubleshooting Adaptive Security Appliances (ASA), Private Internet Exchange (PIX) and Firewall Service Modules (FWSM)

Unanswered Question
Jan 14th, 2013

Kureli SankarWith Kureli Sankar

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask any questions about adaptive security appliances (ASAs), Private Internet Exchange (PIX), and firewall services modules (FWSMs) with Cisco Expert Kureli Sankar. This is a continuation of the live Webcast. 

Kureli Sankar is an engineer supporting Cisco's firewall team in Research Triangle Park, North Carolina. Her team supports the Cisco ASA, FWSM, Cisco Security Manager, the Content Security and Control module, and the zone-based firewall module in Cisco IOS Software. Prior to joining Cisco, Sankar worked for the John Morrell Co., where she was the network administrator in charge of the company's enterprise network covering 27 locations in the United States. She also was an adjunct professor at the University of Cincinnati, teaching undergraduate-level networking courses. Sankar holds a degree in electrical and electronic engineering from Regional Engineering College, Trichirappalli, India, and holds CCSP and CCIE Security (#35505) certification.

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. Remember that you can continue the conversation on the Security sub-community discussion forum shortly after the event.  This event lasts through January 25, 2013. Visit this forum often to view responses to your questions and the questions of other community members.

Webcast related links:

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 0 (13 ratings)
Jouni Forss Mon, 01/14/2013 - 14:05

Hi,

I posted this problem some time ago and though if you would have any additional ideas as to whats causing this problem then any advice would be welcome

Heres my original post with a lot of information

https://supportforums.cisco.com/thread/2158473

To summarize the situation for this post

  • ASA 5585-X Firewalls running Multiple Context Mode in several different 8.4(x) softwares
  • Enabling TCP Syslog with missmatched TCP port with the server stops all traffic through the Context without the use of "logging permit-hostdown"  beforehand (Expected now that I know about it)
  • To enable traffic to pass through the Context again there was no other solution other than to "reboot" the context by removing it and configuring it again.

This made me doubt the whole TCP Syslog setup even though naturally my first error was not to use the "logging permit-hostdown" configuration before I enabled TCP Syslog.

Surely though its not supposed to keep blocking the traffic even after the TCP Syslog server became reachable?

I would like to get TCP Syslog enabled in all our environments but to be honest am a bit paranoid if I might run into more problems which would cause problematic situations for our more critical environments.

- Jouni

Poonguzhali Sankar Tue, 01/15/2013 - 10:27

Jouni,

Glad that you attended the webcast.  I hope it was educational for many of our forum readers and customers.

The request to stop processing if the firewall cannot log requirement was put in by our DoD. Hard set requirement, I know. If we CANNOT LOG who is doing what through the firewall, then, we simply DO NOT want to build those connections.  I know, we get burned by this problem off and on.

Well, if your enterprise is extremely strict then, you do not want to add the "logging permit-hostdown" command.  Wait for the help desk to receive the calls and fix the syslog server to get traffic flowing again.

Once the syslog server becomes available the firewall should automatically start building connections through it without the need for "logging permit-hostdown".  Allow me some time and I shall test this out in our lab and get back to you.

-Kureli

Poonguzhali Sankar Tue, 01/15/2013 - 11:37

Jouni,

Tested on ASA running 9.0.1(2) image

Jan 15 2013 03:15:00 14.36.109.35 : %ASA-5-111008: User 'cisco' executed the 'logging host inside 192.168.2.2 6/1469' command.

Jan 15 2013 03:15:00 14.36.109.35 : %ASA-5-111010: User 'cisco', running 'CLI' from IP 192.168.2.2, executed 'logging host inside 192.168.2.2 6/1469'

Jan 15 2013 03:15:00 14.36.109.35 : %ASA-3-302013: Built outbound TCP connection 2766400 for inside:192.168.2.2/1469 (192.168.2.2/1469) to identity:192.168.2.1/41310 (192.168.2.1/41310)

Jan 15 2013 03:15:00 14.36.109.35 : %ASA-3-414003: TCP Syslog Server inside:192.168.2.2/1469 not responding, New connections are denied based on logging permit-hostdown policy

Jan 15 2013 03:15:00 14.36.109.35 : %ASA-3-302014: Teardown TCP connection 2766400 for inside:192.168.2.2/1469 to identity:192.168.2.1/41310 duration 0:00:00 bytes 0 TCP Reset-O

Jan 15 2013 03:15:00 14.36.109.35 : %ASA-3-302014: Teardown TCP connection 2766073 for inside:192.168.2.2/1468 to identity:192.168.2.1/60777 duration 0:09:28 bytes 242437 TCP FINs

Jan 15 2013 03:15:03 14.36.109.35 : %ASA-3-201008: Disallowing new connections.

Jan 15 2013 03:15:04 14.36.109.35 : %ASA-3-201008: Disallowing new connections.

Jan 15 2013 03:15:04 14.36.109.35 : %ASA-3-201008: Disallowing new connections.

Jan 15 2013 03:15:09 14.36.109.35 : %ASA-3-201008: Disallowing new connections.

Jan 15 2013 03:15:10 14.36.109.35 : %ASA-3-201008: Disallowing new connections.

Jan 15 2013 03:15:10 14.36.109.35 : %ASA-3-201008: Disallowing new connections.

Jan 15 2013 03:15:10 14.36.109.35 : %ASA-6-302016: Teardown UDP connection 2766335 for Corp_NET_12345:76.14.0.98/514 to inside:192.168.2.2/1105 duration 0:02:01 bytes 1200

Jan 15 2013 03:15:10 14.36.109.35 : %ASA-7-609002: Teardown local-host Corp_NET_12345:76.14.0.98 duration 0:02:01

Jan 15 2013 03:15:10 14.36.109.35 : %ASA-3-302013: Built outbound TCP connection 2766401 for inside:192.168.2.2/1469 (192.168.2.2/1469) to identity:192.168.2.1/31690 (192.168.2.1/31690)

Jan 15 2013 03:15:10 14.36.109.35 : %ASA-3-201008: Disallowing new connections.

Jan 15 2013 03:15:25 14.36.109.35 : %ASA-3-201008: Disallowing new connections.

logging host inside 192.168.2.2 6/1468

Jan 15 2013 03:15:25 14.36.109.35 : %ASA-6-414008: New connections are now allowed due to change of logging permit-hostdown policy.

Jan 15 2013 03:15:25 14.36.109.35 : %ASA-5-111008: User 'cisco' executed the 'logging host inside 192.168.2.2 6/1468' command.

Jan 15 2013 03:15:25 14.36.109.35 : %ASA-5-111010: User 'cisco', running 'CLI' from IP 192.168.2.2, executed 'logging host inside 192.168.2.2 6/1468'

Jan 15 2013 03:15:25 14.36.109.35 : %ASA-3-302013: Built outbound TCP connection 2766406 for inside:192.168.2.2/1468 (192.168.2.2/1468) to identity:192.168.2.1/42911 (192.168.2.1/42911)

Jan 15 2013 03:15:25 14.36.109.35 : %ASA-3-414003: TCP Syslog Server inside:192.168.2.2/1468 not responding, New connections are denied based on logging permit-hostdown policy

Jan 15 2013 03:15:26 14.36.109.35 : %ASA-3-302014: Teardown TCP connection 2766406 for inside:192.168.2.2/1468 to identity:192.168.2.1/42911 duration 0:00:00 bytes 0 TCP Reset-O

Jan 15 2013 03:15:26 14.36.109.35 : %ASA-3-201008: Disallowing new connections.

Jan 15 2013 03:15:26 14.36.109.35 : %ASA-3-201008: Disallowing new connections.

Jan 15 2013 03:15:29 14.36.109.35 : %ASA-3-201008: Disallowing new connections.

Jan 15 2013 03:15:29 14.36.109.35 : %ASA-3-302014: Teardown TCP connection 2766230 for Corp_NET_12345:172.18.109.166/8014 to inside:192.168.2.2/3720 duration 0:05:19 bytes 624 TCP Reset-I

Jan 15 2013 03:15:29 14.36.109.35 : %ASA-7-609002: Teardown local-host Corp_NET_12345:172.18.109.166 duration 0:05:19

Jan 15 2013 03:15:30 14.36.109.35 : %ASA-3-201008: Disallowing new connections.

Jan 15 2013 03:15:31 14.36.109.35 : %ASA-3-201008: Disallowing new connections.

Jan 15 2013 03:15:31 14.36.109.35 : %ASA-7-609001: Built local-host identity:172.16.1.6

Jan 15 2013 03:15:31 14.36.109.35 : %ASA-7-609001: Built local-host Corp_NET_12345:70.39.176.3

Jan 15 2013 03:15:31 14.36.109.35 : %ASA-3-302013: Built outbound TCP connection 2766407 for Corp_NET_12345:70.39.176.3/8080 (70.39.176.3/8080) to identity:172.16.1.6/20244 (172.16.1.6/20244)

Jan 15 2013 03:15:31 14.36.109.35 : %ASA-6-775005: Scansafe: Primary server Corp_NET_12345:70.39.176.3 is now reachable

Jan 15 2013 03:15:31 14.36.109.35 : %ASA-3-302014: Teardown TCP connection 2766407 for Corp_NET_12345:70.39.176.3/8080 to identity:172.16.1.6/20244 duration 0:00:00 bytes 0 TCP FINs

Jan 15 2013 03:15:31 14.36.109.35 : %ASA-7-609002: Teardown local-host identity:172.16.1.6 duration 0:00:00

Jan 15 2013 03:15:31 14.36.109.35 : %ASA-7-609002: Teardown local-host Corp_NET_12345:70.39.176.3 duration 0:00:00

Jan 15 2013 03:15:31 14.36.109.35 : %ASA-3-201008: Disallowing new connections.

Jan 15 2013 03:15:32 14.36.109.35 : %ASA-3-201008: Disallowing new connections.

Jan 15 2013 03:15:34 14.36.109.35 : %ASA-3-201008: Disallowing new connections.

Jan 15 2013 03:15:34 14.36.109.35 : %ASA-3-201008: Disallowing new connections.

Jan 15 2013 03:15:34 14.36.109.35 : %ASA-3-201008: Disallowing new connections.

Jan 15 2013 03:15:35 14.36.109.35 : %ASA-3-201008: Disallowing new connections.

Jan 15 2013 03:15:35 14.36.109.35 : %ASA-3-302013: Built outbound TCP connection 2766408 for inside:192.168.2.2/1468 (192.168.2.2/1468) to identity:192.168.2.1/60034 (192.168.2.1/60034)

Jan 15 2013 03:15:35 14.36.109.35 : %ASA-6-414007: TCP syslog server connection restored.  New connections allowed.

Jan 15 2013 03:15:36 14.36.109.35 : %ASA-7-609001: Built local-host Corp_NET_12345:172.18.109.166

Jan 15 2013 03:15:36 14.36.109.35 : %ASA-3-302013: Built outbound TCP connection 2766409 for Corp_NET_12345:172.18.109.166/8014 (172.18.109.166/8014) to inside:192.168.2.2/3816 (172.16.1.5/3816)

Jan 15 2013 03:15:36 14.36.109.35 : %ASA-3-302014: Teardown TCP connection 2766409 for Corp_NET_12345:172.18.109.166/8014 to inside:192.168.2.2/3816 duration 0:00:00 bytes 2729 TCP FINs

Jan 15 2013 03:15:36 14.36.109.35 : %ASA-7-609002: Teardown local-host Corp_NET_12345:172.18.109.166 duration 0:00:00

So, without the "logging permit-hostdown" command in the config.

I changed the syslog tcp port to some incorrect port at

Jan 15 2013 03:15:00 14.36.109.35 : 'logging host inside 192.168.2.2 6/1469'

conns were denied and I fixed the port at

Jan 15 2013 03:15:25 14.36.109.35 : logging host inside 192.168.2.2 6/1468

Jan 15 2013 03:15:35 14.36.109.35 : and the TCP syslog server connection restored log at

So, it took about 10 seconds for connections to start automatically building.  As you can see during this time TO the box connections were built without any problem.

-Kureli

Jouni Forss Tue, 01/15/2013 - 11:49

Hi,

To completely test this situation I guess you would have to try it either in 8.4(1)9 or 8.4(2) for ASA 5585-X where I witnessed it.

I ran into the problem in a device with 8.4(1)9 (Software that corrected a bug in Active FTP for 5585-X SSP-20 and other multicore platforms) and I tested the situation in another ASA 5585-X with 8.4(2) and ran into the same problem

I simply wasnt able to get the connections working again.

Is your test ASA in single or multiple mode? If in single, could it have something to do with this? I have only tested this in a multiple mode ASA 5585-X SSP20

- Jouni

Poonguzhali Sankar Tue, 01/15/2013 - 11:56

Agree.  5585 platform and multiple context testing will take a bit longer to accomplish.

The point I was trying to make is the fact though not documented in the command reference, as soon the the syslog server becomes available, we SHOULD start building new "THROUGH" the box connections without the need for any additional command.

I will let you know on the 5585 multiple context 8.2.x code a bit later.

-Kureli

siriphan Tue, 01/15/2013 - 20:02

How about load balance script of asa - x series ? Could be advices ?

Poonguzhali Sankar Wed, 01/16/2013 - 18:19

Siriphan,

Could you please elaborate a little? What scripts are these? What is the purpose?

Thanks,

Kureli

milanrai45 Tue, 01/15/2013 - 21:44

I tried my best to attend the Webcast but i was not................I send mail regarding my problem but it was not solved???? dont know why i was not able to attend...????

Just i would like to know is about the IPS......support on through ASA.......

Do we have this option ??? or we need to go for other vendor.........If i am going for ASA as my firewall........Then why dont i have the option for IPS service?????

If i didn't knew that we do have those support please describe me on very simple words.....

Thank You

Milan

Poonguzhali Sankar Wed, 01/16/2013 - 17:00

Milan,

So sorry that you couldn't attend.  The audio recording along with the slide deck will be made available soon. You can watch/listen at your own time.  I will let our forum admins know about the trouble that you had.

IPS module is supported in the ASA platform. What model are you thinking about?

Check this data sheet:

http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6032/ps6094/ps6120/product_data_sheet0900aecd802930c5.html

Pls. see under.

Table 10.

Characteristics of Cisco ASA 5500 Series AIP SSM and SSC Models

-Kureli

Monica Lluis Wed, 01/23/2013 - 11:48

Hello Milan,

Thanks for trying to join the live webcast. Seems like the recomendation we sent when we responded to your email did not work. Not to worry, the webcast recording is available at https://supportforums.cisco.com/videos/5258. You can also find the document with all the technical questions from the session at https://supportforums.cisco.com/docs/DOC-29454. If you are interested in downloading the PDF version of the slides, you can find them at https://supportforums.cisco.com/docs/DOC-29170.

I hope this helps.

Kindest Regards,

Monica Lluis

Community Lead

CCIE Emeritus

melepruma Wed, 01/16/2013 - 00:16

Does the New ASA module for the 6500 support ture active-active cluster operation (same VLAN active on both ASA modules in the two chassis in VSS configuration) on SUP 720?

erichild2 Fri, 01/18/2013 - 06:15

Good Day,

An issue we seem to be facing with our ASA 5520 8.4(2) is with previously working site2site VPNs no longer working properly.

The tunnels seem to have remained up but to get full data traveling in both directions we have had to

add an outside interface Access Rule.

The only change known is we created a new s2s vpn and it wouldn't work until the Outside Access rule was created.

Not sure if it is a cause or a product of the issue.

Is this something anyone has seen.

Thank You,

Eric

mj11@home_2 Sun, 01/20/2013 - 11:35

Hi Kureli

Subject: FWSM 3.2(20) SIP traffic being dropped by FW. Inspection SIP enabled.

Source: 192.168.5.101 Destination:192.168.254.26

Cap SIP1= Receiving interface Cap SIP2=Exiting interface

We are experiencing a problem passing SIP packets through our FWSM on a new service but have SIP already working successfully. We can see the packets arriving at the firewall but not leaving and have not been unable to determine why this is, we have captured on the ASP but did not see anything. We have tried both UDP and TCP. Interestingly, if we telnet using port 5060, the packets pass fine, however when actual SIP packets are sent, they do not arrive. Below is a packet capture from the FWSM on both interfaces.

FW01# sh cap SIP1 detail

26 packets seen, 26 packets captured

   1: 15:03:48.2232889848 00d0.0143.b400 0008.7cbb.2040 0x8100 78: 802.1Q vlan#810 P0 192.168.5.101 > 192.168.254.26: icmp: echo request (ttl 127, id6762)

   2: 15:03:48.2232889848 0008.7cbb.2040 0000.0c07.ac62 0x8100 78: 802.1Q vlan#810 P0 192.168.254.26 > 192.168.5.101: icmp: echo reply (ttl 252, id 6762)

   3: 15:03:49.2232890848 00d0.0143.b400 0008.7cbb.2040 0x8100 78: 802.1Q vlan#810 P0 192.168.5.101 > 192.168.254.26: icmp: echo request (ttl 127, id 6767)

   4: 15:03:49.2232890848 0008.7cbb.2040 0000.0c07.ac62 0x8100 78: 802.1Q vlan#810 P0 192.168.254.26 > 192.168.5.101: icmp: echo reply (ttl 252, id 6767)

   5: 15:03:50.2232891848 00d0.0143.b400 0008.7cbb.2040 0x8100 78: 802.1Q vlan#810 P0 192.168.5.101 > 192.168.254.26: icmp: echo request (ttl 127, id 6771)

   6: 15:03:50.2232891848 0008.7cbb.2040 0000.0c07.ac62 0x8100 78: 802.1Q vlan#810 P0 192.168.254.26 > 192.168.5.101: icmp: echo reply (ttl 252, id 6771)

   7: 15:03:51.2232892858 00d0.0143.b400 0008.7cbb.2040 0x8100 78: 802.1Q vlan#810 P0 192.168.5.101 > 192.168.254.26: icmp: echo request (ttl 127, id 6775)

   8: 15:03:51.2232892858 0008.7cbb.2040 0000.0c07.ac62 0x8100 78: 802.1Q vlan#810 P0 192.168.254.26 > 192.168.5.101: icmp: echo reply (ttl 252, id 6775)

   9: 15:04:57.2232958948 00d0.0143.b400 0008.7cbb.2040 0x8100 70: 802.1Q vlan#810 P0 192.168.5.101.50505 > 192.168.254.26.5060: S

2621387575:2621387575(0) win 8192 (DF) (ttl 127, id 6935)

  10: 15:04:57.2232958948 0008.7cbb.2040 0000.0c07.ac62 0x8100 64: 802.1Q vlan#810 P0 192.168.254.26.5060 > 192.168.5.101.50505: S [tcp sum ok]

3750378220:3750378220(0) ack 2621387576 win 4128 (ttl 252, id 26637)

  11: 15:04:57.2232958948 00d0.0143.b400 0008.7cbb.2040 0x8100 64: 802.1Q vlan#810 P0 192.168.5.101.50505 > 192.168.254.26.5060: . [tcp sum ok]

2621387576:2621387576(0) ack 3750378221 win 65392 (DF) (ttl 127, id 6936)

  12: 15:04:57.2232958948 00d0.0143.b400 0008.7cbb.2040 0x8100 353: 802.1Q vlan#810 P3 192.168.5.101.50505 > 192.168.254.26.5060: P

2621388112:2621388407(295) ack 3750378221 win 65392 (DF) [tos 0x60]  (ttl 127, id 6938)

  13: 15:04:57.2232958948 00d0.0143.b400 0008.7cbb.2040 0x8100 594: 802.1Q vlan#810 P3 192.168.5.101.50505 > 192.168.254.26.5060: .

2621387576:2621388112(536) ack 3750378221 win 65392 (DF) [tos 0x60]  (ttl 127, id 6937)

  14: 15:04:57.2232958958 0008.7cbb.2040 00aa.0c07.ac62 0x8100 64: 802.1Q vlan#810 P0 192.168.254.26.5060 > 192.168.5.101.50505: P [tcp sum ok]

3750378221:3750378221(0) ack 2621387576 win 4128 (DF) (ttl 255, id 8467)

  15: 15:04:57.2232958958 0008.7cbb.2040 0000.0c07.ac62 0x8100 64: 802.1Q vlan#810 P0 192.168.254.26.5060 > 192.168.5.101.50505: . [tcp sum ok]

3750378221:3750378221(0) ack 2621388112 win 8192 (DF) (ttl 255, id 8468)

  16: 15:04:57.2232958958 0008.7cbb.2040 0000.0c07.ac62 0x8100 64: 802.1Q vlan#810 P0 192.168.254.26.5060 > 192.168.5.101.50505: . [tcp sum ok]

3750378221:3750378221(0) ack 2621388407 win 8192 (DF) (ttl 255, id 8469)

  17: 15:04:57.2232958958 0008.7cbb.2040 0000.0c07.ac62 0x8100 64: 802.1Q vlan#810 P0 192.168.254.26.5060 > 192.168.5.101.50505: R [tcp sum ok]

3750378221:3750378221(0) win 8192 (DF) (ttl 255, id 8470)

  18: 15:05:10.2232972138 00d0.0143.b400 0008.7cbb.2040 0x8100 70: 802.1Q vlan#810 P0 192.168.5.101.50508 > 192.168.254.26.5060: S

3408136717:3408136717(0) win 8192 (DF) (ttl 127, id 6990)

  19: 15:05:10.2232972138 0008.7cbb.2040 0000.0c07.ac62 0x8100 64: 802.1Q vlan#810 P0 192.168.254.26.5060 > 192.168.5.101.50508: S [tcp sum ok]

455106242:455106242(0) ack 3408136718 win 4128 (ttl 252, id 39032)

  20: 15:05:10.2232972138 00d0.0143.b400 0008.7cbb.2040 0x8100 64: 802.1Q vlan#810 P0 192.168.5.101.50508 > 192.168.254.26.5060: . [tcp sum ok]

3408136718:3408136718(0) ack 455106243 win 65392 (DF) (ttl 127, id 6991)

  21: 15:05:10.2232972138 00d0.0143.b400 0008.7cbb.2040 0x8100 352: 802.1Q vlan#810 P3 192.168.5.101.50508 > 192.168.254.26.5060: P

3408137254:3408137548(294) ack 455106243 win 65392 (DF) [tos 0x60]  (ttl 127, id 6993)

  22: 15:05:10.2232972138 00d0.0143.b400 0008.7cbb.2040 0x8100 594: 802.1Q vlan#810 P3 192.168.5.101.50508 > 192.168.254.26.5060: .

3408136718:3408137254(536) ack 455106243 win 65392 (DF) [tos 0x60]  (ttl 127, id 6992)

  23: 15:05:10.2232972138 0008.7cbb.2040 0000.0c07.ac62 0x8100 64: 802.1Q vlan#810 P0 192.168.254.26.5060 > 192.168.5.101.50508: P [tcp sum ok]

455106243:455106243(0) ack 3408136718 win 4128 (DF) (ttl 255, id 23984)

  24: 15:05:10.2232972138 0008.7cbb.2040 0000.0c07.ac62 0x8100 64: 802.1Q vlan#810 P0 192.168.254.26.5060 > 192.168.5.101.50508: . [tcp sum ok]

455106243:455106243(0) ack 3408137254 win 8192 (DF) (ttl 255, id 23985)

  25: 15:05:10.2232972138 0008.7cbb.2040 0000.0c07.ac62 0x8100 64: 802.1Q vlan#810 P0 192.168.254.26.5060 > 192.168.5.101.50508: . [tcp sum ok]

455106243:455106243(0) ack 3408137548 win 8192 (DF) (ttl 255, id 23986)

  26: 15:05:10.2232972138 0008.7cbb.2040 0000.0c07.ac62 0x8100 64: 802.1Q vlan#810 P0 192.168.254.26.5060 > 192.168.5.101.50508: R [tcp sum ok]

455106243:455106243(0) win 8192 (DF) (ttl 255, id 23987)

26 packets shown

FW01# sh cap SIP2 detail

16 packets seen, 16 packets captured

   1: 15:03:48.2232889848 0008.7cbb.2040 0000.0c07.acff 0x8100 78: 802.1Q vlan#800 P0 192.168.5.101 > 192.168.254.26: icmp: echo request (ttl 127, id 6762)

   2: 15:03:48.2232889848 00d0.0143.b400 0008.7cbb.2040 0x8100 78: 802.1Q vlan#800 P0 192.168.254.26 > 192.168.5.101: icmp: echo reply (ttl 252, id 6762)

   3: 15:03:49.2232890848 0008.7cbb.2040 0000.0c07.acff 0x8100 78: 802.1Q vlan#800 P0 192.168.5.101 > 192.168.254.26: icmp: echo request (ttl 127, id 6767)

   4: 15:03:49.2232890848 00d0.0143.b400 0008.7cbb.2040 0x8100 78: 802.1Q vlan#800 P0 192.168.254.26 > 192.168.5.101: icmp: echo reply (ttl 252, id 6767)

   5: 15:03:50.2232891848 0008.7cbb.2040 0000.0c07.acff 0x8100 78: 802.1Q vlan#800 P0 192.168.5.101 > 192.168.254.26: icmp: echo request (ttl 127, id 6771)

   6: 15:03:50.2232891848 00d0.0143.b400 0008.7cbb.2040 0x8100 78: 802.1Q vlan#800 P0 192.168.254.26 > 192.168.5.101: icmp: echo reply (ttl 252, id 6771)

   7: 15:03:51.2232892858 0008.7cbb.2040 0000.0c07.acff 0x8100 78: 802.1Q vlan#800 P0 192.168.5.101 > 192.168.254.26: icmp: echo request (ttl 127, id 6775)

   8: 15:03:51.2232892858 00d0.0143.b400 0008.7cbb.2040 0x8100 78: 802.1Q vlan#800 P0 192.168.254.26 > 192.168.5.101: icmp: echo reply (ttl 252, id 6775)

   9: 15:04:57.2232958948 0008.7cbb.2040 0000.0c07.acff 0x8100 70: 802.1Q vlan#800 P0 192.168.5.101.50505 > 192.168.254.26.5060: S

153485530:153485530(0) win 8192 (DF) (ttl 127, id 6935)

  10: 15:04:57.2232958948 00d0.0143.b400 0008.7cbb.2040 0x8100 64: 802.1Q vlan#800 P0 192.168.254.26.5060 > 192.168.5.101.50505: S [tcp sum ok]

3750378220:3750378220(0) ack 153485531 win 4128 (ttl 252, id 26637)

  11: 15:04:57.2232958948 0008.7cbb.2040 0000.0c07.acff 0x8100 64: 802.1Q vlan#800 P0 192.168.5.101.50505 > 192.168.254.26.5060: . [tcp sum ok]

153485531:153485531(0) ack 3750378221 win 65392 (DF) (ttl 255, id 8466)

  12: 15:05:10.2232972138 0008.7cbb.2040 0000.0c07.acff 0x8100 70: 802.1Q vlan#800 P0 192.168.5.101.50508 > 192.168.254.26.5060: S

3150694522:3150694522(0) win 8192 (DF) (ttl 127, id 6990)

  13: 15:05:10.2232972138 00d0.0143.b400 0008.7cbb.2040 0x8100 64: 802.1Q vlan#800 P0 192.168.254.26.5060 > 192.168.5.101.50508: S [tcp sum ok]

455106242:455106242(0) ack 3150694523 win 4128 (ttl 252, id 39032)

  14: 15:05:10.2232972138 0008.7cbb.2040 0000.0c07.acff 0x8100 64: 802.1Q vlan#800 P0 192.168.5.101.50508 > 192.168.254.26.5060: . [tcp sum ok]

3150694523:3150694523(0) ack 455106243 win 65392 (DF) (ttl 255, id 23983)

  15: 15:05:57.2233018958 00d0.0143.b400 0008.7cbb.2040 0x8100 64: 802.1Q vlan#800 P0 192.168.254.26.5060 > 192.168.5.101.50505: . [tcp sum ok]

3750378220:3750378220(0) ack 153485531 win 4128 (ttl 252, id 26638)

  16: 15:06:10.2233032148 00d0.0143.b400 0008.7cbb.2040 0x8100 64: 802.1Q vlan#800 P0 192.168.254.26.5060 > 192.168.5.101.50508: . [tcp sum ok]

455106242:455106242(0) ack 3150694523 win 4128 (ttl 252, id 39033)

16 packets shown

Regrads MJ

Poonguzhali Sankar Mon, 01/21/2013 - 06:39

MJ,

This does look like SIP inspection problem. I am not aware of any sip related defects in the code that you are running. The SYN and SYN ACK packets are the same inside to outside but, the ACK packet isn't the same.

  11: 15:04:57.2232958948 00d0.0143.b400 0008.7cbb.2040 0x8100 64: 802.1Q vlan#810 P0 192.168.5.101.50505 > 192.168.254.26.5060: . [tcp sum ok] 2621387576:2621387576(0) ack 3750378221 win 65392 (DF) (ttl 127, id 6936)

  11: 15:04:57.2232958948 0008.7cbb.2040 0000.0c07.acff 0x8100 64: 802.1Q vlan#800 P0 192.168.5.101.50505 > 192.168.254.26.5060: . [tcp sum ok] 153485531:153485531(0) ack 3750378221 win 65392 (DF) (ttl 255, id 8466)

The packet ID doesn't match inside to outside for the ACK packet. It would be better to see the captures in the form of a .pcap files instead of text based output.

I'd suggest opening a TAC case and working with an engineer. Let me know the case no. once you open it.

-Kureli           

mj11@home_2 Tue, 01/22/2013 - 03:41

Hi Kureli

Thanks for the response, we have disabled SIP for this flow via a class-map and now this working.

Many thanks MJ

nick.ehlers Tue, 01/22/2013 - 09:40

Kureli,

Thanks for doing this Q&A!

My question is, on a ASA 5510 running 8.2.x code. How do I properly implement Group Based authentication for anyconnect Remote VPN. It will be used in this context. Users from X organization will browse to the public IP address of the ASA from home bringing up the Remote VPN Login page. The user logs in with their Active Directory credentials and based on what group they are in they will be given certain access based on that group, obviously refering to certain ACLs applied to each group.

The customer has windows 2008 R2 so the ASA is pulling from LDAP, they have no radius server. I've made an attempt at the config myself and am hoping you can check my work to see if this will work or not?

Here is the config:

!

access-list ADMIN-VPN-SPLIT extended permit ip 192.168.254.0 255.255.255.0 10.0.0.0 255.255.0.0

access-list ADMIN-VPN-SPLIT extended permit ip 10.0.0.0 255.255.0.0 192.168.254.0 255.255.255.0

!

ip local pool VPN-POOL 192.168.254.1-192.168.254.254

!

ldap attribute-map CISCOMAP

  map-name  memberOf Group-Policy

  map-value memberOf "CN=VPN.Admin.User,OU=VPN,OU=Security Groups,OU=TEST,DC=TEST,DC=local" ADMIN

  map-value memberOf "CN=VPN.Default.Users,OU=VPN,OU=Security Groups,OU=TEST,DC=TEST,DC=local" "Standard Users"

dynamic-access-policy-record DfltAccessPolicy

aaa-server LDAP protocol ldap

aaa-server LDAP (inside) host 10.0.2.1

ldap-base-dn DC=TEST,DC=local

ldap-group-base-dn DC=TEST,DC=local

ldap-scope subtree

ldap-naming-attribute sAMAccountName

ldap-login-password Test123!

ldap-login-dn CN=LDAP,OU=Users,OU=_Applications,OU=TEST,DC=TEST,DC=local

ldap-over-ssl enable

server-type microsoft

ldap-attribute-map CISCOMAP

webvpn

enable outside

character-encoding windows-1252

anyconnect-essentials

svc image disk0:/anyconnect-wince-ARMv4I-2.3.0254-k9.pkg 4 regex "Windows CE"

svc image disk0:/anyconnect-win-2.3.0254-k9.pkg 5 regex "Windows NT"

svc image disk0:/anyconnect-macosx-i386-2.3.0254-k9.pkg 6 regex "Intel Mac OS X"

svc enable

tunnel-group-list enable

group-policy NoAccess internal

group-policy NoAccess attributes

banner value You have no access

wins-server none

dns-server value 10.0.2.1 10.0.2.2

vpn-simultaneous-logins 0

vpn-tunnel-protocol IPSec l2tp-ipsec svc webvpn

default-domain value TEST.local

address-pools none

group-policy DfltGrpPolicy attributes

vpn-filter value 150

group-policy ADMIN internal

group-policy ADMIN attributes

  wins-server none

dns-server value 10.0.2.1 10.0.2.2

vpn-simultaneous-logins 3

vpn-tunnel-protocol IPSec l2tp-ipsec svc webvpn

ipsec-udp enable

ipsec-udp-port 10000

split-tunnel-policy tunnelspecified

split-tunnel-network-list value ADMIN-VPN-SPLIT

default-domain value TEST.local

address-pools value VPN-POOL

webvpn

  svc keep-installer installed

  svc dpd-interval gateway 60

  svc ask enable default webvpn

  hidden-shares visible

  activex-relay enable

  file-entry enable

  file-browsing enable

  url-entry enable

group-policy "Standard Users" internal

group-policy "Standard Users" attributes

banner value You have full access to the TEST network.

wins-server none

dns-server value 10.0.2.1 10.0.2.2

vpn-simultaneous-logins 0

vpn-tunnel-protocol IPSec l2tp-ipsec svc webvpn

split-tunnel-policy tunnelspecified

split-tunnel-network-list value ADMIN-VPN-SPLIT

default-domain value TEST.local

group-policy LDAP-ALLOWACCESS internal

group-policy LDAP-ALLOWACCESS attributes

banner value You have logged in with the LDAP-ALLOWACCESS group Policy

dns-server value 10.0.2.1 10.0.2.2

vpn-tunnel-protocol IPSec l2tp-ipsec svc webvpn

ipsec-udp enable

ipsec-udp-port 10000

split-tunnel-policy tunnelspecified

split-tunnel-network-list value ADMIN-VPN-SPLIT

default-domain value isi.local

address-pools value VPN-POOL

webvpn

  svc keep-installer installed

  svc dpd-interval gateway 60

  svc ask enable default webvpn

  hidden-shares visible

  activex-relay enable

  file-entry enable

  file-browsing enable

  url-entry enable

group-policy LDAP-NOACCESS internal

group-policy LDAP-NOACCESS attributes

vpn-simultaneous-logins 0

vpn-tunnel-protocol IPSec svc

webvpn

  svc ask none default svc

tunnel-group ADMIN-VPN general-attributes

address-pool VPN-POOL

authentication-server-group LDAP

default-group-policy ADMIN

authorization-required

tunnel-group ADMIN-VPN webvpn-attributes

nbns-server 10.0.2.1 timeout 2 retry 2

group-alias ADMIN-VPN disable

group-alias Admin enable

group-alias DEFAULT disable

group-alias Default disable

group-alias Defaults disable

group-alias User disable

tunnel-group "Standard Users" general-attributes

address-pool VPN-POOL

authentication-server-group LDAP

default-group-policy "Standard Users"

tunnel-group "Standard Users" webvpn-attributes

group-alias Users enable

Thanks!

oh and also - how can I verify that if they dont authenticate to any particular group that they will be denied access?

Message was edited by: Nick Ehlers

nick.ehlers Thu, 01/24/2013 - 14:09

Thanks Kureli I look forward to hearing from you.

sestonenppd Wed, 01/23/2013 - 10:13

Is it recommended/possible to attach a 5510 running code version 8.2(5) in transparent mode to a Nexus 2248?  We have 2  contexts but are only connecting one (2 ports) now and the other at a later date.  We had an older 5510 connected to these same ports running code version 7.0(7) with no problems.  However, when we connect up the new 5510, one port or the other sends a BPDU causing the port to errdisable.  Is this a configuration, version, or compatibility problem?

sestonenppd Wed, 01/23/2013 - 11:02

Received this error when I clicked the link:

Dear valued Cisco Bug Toolkit customer, the bug ID CSCsi55476 you searched contains proprietary information that cannot be disclosed at this time; therefore, we are unable to display the bug details. Please note it is our policy to make all externally-facing bugs available in Bug Toolkit to best assist our customers. As a result, the system administrators have been automatically alerted to the problem.

While we are working to resolve this issue, we invite you to reach out to the experts on the Bug Toolkit Support Community. You may find answers there to your Bug Toolkit questions, or post your feedback on our forum as well. Thank you.

Note: Some product enhancement requests and documentation bugs may not be available in Bug Toolkit.

Poonguzhali Sankar Wed, 01/23/2013 - 11:35

Interesting. Not sure why you are unable to view. I am enclosing the RN for this defect.

CSCsl55476    DOC: Transparent firewall failover event causes STP topology change

Symptom:

Failover interface or data interface monitoring can fail due to a switchport entering the blocking state unexpectedly.

Conditions:

Multi-context transparent firewalls in failover pair.

It has not been verified if this affects single-context firewalls.

Workaround:

Configure ethertype ACLs to deny BPDUs from being passed through the transparent firewalls.

access-list 1 ethertype deny bpdu

access-group 1 in interface inside

access-group 1 in interface outside

Also turning off spanning-tree or turning off BPDUs via portfast on the switch ports will give the same affect.

Further Problem Description:

When running transparent firewalls in failover a loop free spanning-tree environment is guaranteed by the fact that the standby firewall will not pass traffic. During failover it is possible for BPDUs to be leaked through the standby firewall causing a spanning-tree topology change and switch ports to enter a blocking state. When the switch ports enter a blocking state this could lead to data interface or failover interface monitoring to fail between the two firewalls. If the firewalls were to enter an active/active failover state it is possible for a spanning-tree loop to occur.

-Kureli

sestonenppd Wed, 01/23/2013 - 12:24

Thank you. We will give that a try and report back.

Message was edited by: Scott Stoner Corrected punctuation

sestonenppd Thu, 01/24/2013 - 05:07

That solved the problem.  Thank you very much.

taufique.shaikh Sat, 01/26/2013 - 09:25

Good Day,

ASA Phone proxy troubleshooting

I have configure 2 ASA 5510 with IPSEC Tunnel and when I start my CIPC from laptop to connect CUCM in USA Office it connects successfully and am able to make and recieve call and hear voice clearly...!

Now when I configured Cisco ASA 5510 USA office where CUCM is connected with Phone proxy having static NAT for CUCM am able to start and register my CICP in laptop from home but unable to retrieve CTL configure in ASA or Trustlist and also am not able to hear voice when making or recieving call..?

My configuration is very similar to below forum and have taken reference of below forum only..!

1. https://supportforums.cisco.com/docs/DOC-8165

2. http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/unified_comm_phoneproxy.html#wp1270838

Addition to this I configure IPSEC Remote Access VPN for USA Office connected from home successfully and then I start CIPC in laptop same problem am able to register but no voice in or out but strange what happen with me was when I removed sccp and sip from class map (inspect) i was able to make call to few of the extensions of Office and then after when I connect again there was no voice..!

Your comments and suggestions are highyl appreciated..!

Thank you.

Poonguzhali Sankar Sat, 01/26/2013 - 09:53

Taufique,

Phone proxy configuration is pretty hard to troubleshoot via the forum.  You mentioned following the forum guide. If CTL file isn't getting to the phone then, there is something wrong with the tftp traffic between the call manager and the phone.

Do you have tftp inspection enabled?

We pretty much following this when troubleshooting phone proxy issues.

https://supportforums.cisco.com/docs/DOC-1226

What do captures and syslogs show?  It would be better if you could open a TAC case and work with a TAC engineer as we need to grab multiple captures, debugs and syslogs to figure out what might be going on. Added to that this event ended yesterday and probably will be closed today or Monday and I will be unable to add or edit content to it.

-Kureli

taufique.shaikh Sat, 01/26/2013 - 10:03

Good Day,

Thankyou for the link. As per the link in deb am getting output as like same below.

Traffic from Call Manager to phone does not traverse ASA causing TFTP failures

PP: opened 0x116804ea

PP: Data Block 1 forwarded from 14.36.107.90/8554 to 172.18.254.73/52361 ingress ifc outside

PP: Received ACK Block 1 from outside:172.18.254.73/52361 to inside:172.18.124.230

PP: Data Block 2 forwarded to 172.18.254.73/52361

PP: Received ACK Block 2 from outside:172.18.254.73/52361 to inside:172.18.124.230

PP: Data Block 3 forwarded to 172.18.254.73/52361

PP: Received ACK Block 3 from outside:172.18.254.73/52361 to inside:172.18.124.230

PP: Data Block 4 forwarded to 172.18.254.73/52361

PP: Received ACK Block 4 from outside:172.18.254.73/52361 to inside:172.18.124.230

PP: Data Block 5 forwarded to 172.18.254.73/52361

PP: Received ACK Block 5 from outside:172.18.254.73/52361 to inside:172.18.124.230

PP: Data Block 6 forwarded to 172.18.254.73/52361

PP: Received ACK Block 6 from outside:172.18.254.73/52361 to inside:172.18.124.230

PP: Data Block 7 forwarded to 172.18.254.73/52361

PP: Received ACK Block 7 from outside:172.18.254.73/52361 to inside:172.18.124.230

PP: Data Block 8 forwarded to 172.18.254.73/52361

PP: Received ACK Block 8 from outside:172.18.254.73/52361 to inside:172.18.124.230

PP: Data Block 9 forwarded to 172.18.254.73/52361

PP: Received ACK Block 9 from outside:172.18.254.73/52361 to inside:172.18.124.230

PP: TFTP session complete, all data sent

PP: 172.18.254.73/52362 requesting SEP0007EBF0EE54.cnf.xml.sgn

PP: opened 0x116974f6

PP: 172.18.254.73/52363 requesting SEP0007EBF0EE54.cnf.xml.sgn

PP: opened 0x116a21e2

PP: 172.18.254.73/52364 requesting SEP0007EBF0EE54.cnf.xml.sgn

PP: opened 0x116b06ae

Is there any NAT issue with my ASA..? as my debug output is same as above.

I have below NAT configure

Static NAT 1.1.1.84(Public routable IP) to 192.168.1.25(IP for CUCM and TFTP as both are on same server)

Media Terminal IP outside (1.1.1.82) and inside(192.168.1.9)

acl for inside and outside both is allow ip any any

I shall enable tftp in inspection as per suggestion.

Addition to this if you can guide something will be great help as per said time by you in reply..!

Thank you.

taufique.shaikh Sat, 01/26/2013 - 10:05

I would like to add one more point in above that...

as per log CIPC from my home laptop is requesting of unsign config file..

that is its requsting file format as SEP0007EBF0EE54.cnf.xml and not SEP0007EBF0EE54.cnf.xml.sgn

That the error messgae from CUCM TFTP

Poonguzhali Sankar Tue, 01/29/2013 - 05:45

If a firewall is in the network path between the phone and the  outside of the ASA, it could be blocking the file from being sent from  the ASA to the remote phone using the secondary UDP data channel. Ensure  that the device is either tracking the TFTP connection statefully  ('inspect tftp' on ASA/PIX) or that the device is forwarding all ports  to the inside phone.

We have seen this problem crop up in some cases where the ISP  itself is blocking tftp traffic. In this case there is nothing that the  user can do, and the ISP has to stop blocking this traffic for the phone  to register correctly. Some ISPs apparently do this to prevent problems  with cable modems, which download their config over tftp as well.

'debug phone-proxy tftp' will show the remote phone requesting a file,  then the phone proxy will send back Data Block 1, which will never be  acknowledged.

As I mentioned earlier, it would be appropriate to work with a TAC engineer to resolve this problem. Pls. feel free to open a TAC case.

-Kureli

derricklearncisco Mon, 01/28/2013 - 19:04

Hi Kureli,

i am new to this support channel,

i am not sure if you could ask you some question on ASA5505,

i have done the basic setup and everything looking fine, now i there is a request on doing web filtering, i just need to

block website like "facebook" "youtube" on only 2 PC with IP Address 192.168.1.10 and 192.168.1.11

the rest of the PC should not affected.

however when i browse through the firewall i didnt see any section available for me to configure as per my requirement.

would you mind advise?

thank you

Derrick

derricklearncisco Tue, 01/29/2013 - 04:41

Hi Thanks for your quick repsonse, i will study on your link post and try on it,

beside this, i have another issue which is ONLY my Laptop (Window XP Pro), i am getting dhcp from the cisco ASA and able to surf net, however i am some how block from ping and accessing the Cisco ASA it self, which is my gateway.

with the same dhcp to the other pc/desktop, all of other station can access the cisco ASA through ssh and ASDM and can ping to cisco asa.

after some troubleshooting i suspect my pc somehow block by cisco ASA. but there is no access list created to block my pc, how can i check further? please advise and appreciate!

Actions

Login or Register to take actions

This Discussion

Posted January 14, 2013 at 1:33 PM
Stats:
Replies:37 Avg. Rating:
Views:5437 Votes:0
Shares:0

Related Content

Discussions Leaderboard

Rank Username Points
1 7,861
2 6,140
3 3,170
4 1,473
5 1,446