Hello Jenifer,

I allowed the protocol 132 (its 132 for SCTP not 135, it was my mistype) using access list but ASA is still denying whole protocol 132. I placed the rule at the top of the access list to avoid any doubt in connection with other records in the ACL.

Finally I even tried to temporarily allow ip any any on subjected interfaces on the top of ACLs, but ASA still persists on blocking 132 stream.

Any idea on this ?

thank you...

Robert

Robert,

Can you please do an explicit line in access-list permitting 132 any any rather then ip any any, to see if we get hits on it?

Please also indicate the message you see when SCTP packets are being dropped by the ASA (as seen in syslog messages).

Marcin

Please configure permit ACL on both interfaces of the ASA where the SCTP traffic passes through.

Do you have any NATing configured? PAT will not work since SCTP is a protocol not TCP or UDP with ports.

Also, best is to test with packet tracer as it will tell you where it is failing.

Hello Jenifer, Marcin,

first let me give you many thanks for your willingnes to help me. The problem is solved now and I would like to share some cognition I came to during these two really dreamless nigts. You may will be surprised as I was or can give explanation if you know "whats going on".

Shortly then.

FW was denying any 132 protocol streams even they were allowed. It finaly came to situation that FW even started denying traffic which was not subject of my first problems with 132 prot and it had not anything common with this. It was blocking traffic that was absolutely obviouslypermitted. I was trying disabling/enabling rules from ASDM, recreating them from CLI etc. playing around and getting mad. My conviction that access list on the interface is "somehow" corupted got ripen. I decided then to totaly delete the whole access list, restart FW and recreate ACL on IF from scratch. ...and it works fine now.

Honestly I primarily suspect that (if at all, i do not know exactly) the Cisco ASDM is the root cause why the ACL got corrupted, because FW started being "mad" after I tried to configure rules with it. On the other hand I was using it many time before. I dont know...

Moreover when I added few rules using ASDM after all this the access list´s name , when checked using CLI, was not DMZ_access_in but DMZ_access_in_V1. Do you have any clue why its name addopted _V1 suffix ?

I am enclosing some details from ASA.

ASA5550

Cisco Adaptive Security Appliance Software Version 7.1(2)
Device Manager Version 5.1(2)

Any comments would be appreciated, I really do not have any explanation for this IOS/ASDM behaviour...

Thanks & regards

Robert

Robert,

ASA 7.1 has been discontinued A WHILE back

Wouldn't it just be easier to move to 8.0 or 8.2? We've reworked some of the ASA ACL code to make it faster, I certainly don't remember a big ACL corruption issue since then.

Regarding _V1 behavior this is ASDM specific behavior, wouldn't you rather move to a newer one?

If you wish to sticka round on 7.1 and 5.1 I can try to dig into bugtoolkit and find some (possible) matchs for this behavior.

Marcin

Hello Marcin,

@ASA 7.1 has been discontinued A WHILE back

You are right but customer has two "basic" attitudes...

1. Do not touch the systems if they works fine

2. save money as much as possible

Obviously, in this case, this approach came to what it came.... We say here "the scythe hit the stone finally"    You may feel the sense...

I have the other appliance with 8.1 SW and, as you wrote, I have never encountered there similar problem like this.

We simply have to convince the customer to agree with upg and costs coming with it...

Anyway thank you a lot for help...

regards...

Robert

P.S. Just, hopefully, last question. Upgrade from IOS 7.1 to 8.2 should be possible directly shouldn´t be ? I mean no "inter-upgrade" is needed. I read some articles about upgrade path , there is no mention to have to do so...

Robert,

The only change I'm aware of between 7.1 and 8.x (apart from 8.3!) is related to tunnel group types. Which should be migrated fine to 8.x but not from 8.x to 7.x. This is from the top of my head.

I would be cautious about 8.2.3 which is latest in 8.2 - there is a known bug for management access.

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCti72411

An interim providing fix to this will be published next week.

I would advise to go for 8.0.5 now, but I cannot make any sort of recommendation ;-)

That being said the bahvior you described in 7.1 is clearly buggy (or someone working really hard to make your life a place of misery).

There will be no bug fixes to 7.1 so your best choice is to move to 8.x where I don't remember anyone reporting anything similar.

Marcin

Hi all, I'm having a problem with SCTP, but I don't know if the same than rototh. My case is:

Internal Network      |         External Network
                         |
             Private     |   LAB                        LAB
 +---------+ Address     | Address     /--\/--\      Address +---------+
 |  SCTP   |    Inside+-----+ LAB     /        \             |  SCTP   |
 |end point|==========| NAT |======= | Internet | ========== |end point|
 |    A    |          +-----+         \        /             |    B    |
 +---------+ Internal    |             \--/\--/     External +---------+
  Internal      Port     |                             Port    External
    VTag                 |                                       VTag

I'm doing NAT from a Internal IP address to LAB Address, UDP and ICMP work, ASA translate the IP from Inside to LAB address, but SCTP not.

2: 10:01:02.797261 0022.5597.0e8f 0021.a0b1.b454 0x0800 98: 10.127.80.124(LAB address) > 10.56.161.4: icmp: echo request (ttl 253, id 21167

4: 10:01:03.220554 0021.a0b1.b454 0022.5597.0e8f 0x0800 98: 10.56.161.4 > 10.127.80.124: icmp: echo reply (ttl 240, id 64510)

SCTP NOT

61: 10:02:57.151634 0022.5597.0e8f 0021.a0b1.b454 0x0800 78: 10.2.4.10(INSIDE IP) > 10.56.161.4:  ip-proto-132, length 44 [tos 0xc0]  (ttl 62, id 22027)

Could Anyone help me?

Thanks