Routing Traffic Through IPSec Tunnel on Cisco ASA

This on is for the ages!   I would give a million points if I could if someone figures this one out.

I have a Cisco ASA 5510, I am initiating a VPN tunnel to a vendor who has a NetScreen FW on teh other end.  The tunnels, not a problem, get those intitiated with no problem.  The problem comes when I try to pass SCTP (protocol 132) over the VPN....the firewall just doesn't see it as interesting traffic.  This is NOT a config issue, I have had both the vendor AND Cisco say my config is fine....

Ultimately the problem Cisco said is they do nto support SCTP.  It turns out we cannot wrap it in TCP?UDP, etc.  So my qustion is, can I just route through the ASA without packet or protocol inspection?  Or any other creative ideas people my have out there....please I am desperate to figure this out!!!
LVL 1
authentifyAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

asavenerCommented:
Does the vendor have other clients using an ASA as the VPN endpoint?

Can you post your config anyway?
0
pgolding00Commented:
if your config has a permit entry for proto 132 in the acl used in the match address statement of the crypto definition, this should work fine. you can verify that the asa is trying to do the right thing by "sh access-l <list name>" and you will see a counter at the end of each line, indicating matching traffic. look at the line with proto 132 to verify that much is right.

next, "sh cry ips sa peer <netscreen public address>" will show if an sa has been established for this traffic, plus encrypted and decrypted traffic count. if both of these show other than 0, you should be in business.
0
authentifyAuthor Commented:
Yeh I did the sh access-list thing with both the Cisco tech and the the vendor.  Here is what happens....

I can initiate a tunnle by doing a simple ICMP (Ping) request from a node on the network that is supposed to go over the VPN Tunnel.  When I packet sniff those ICMP requests, I see it hit the interface, translate and end up ESP traffic over the tunnel and back....the vendor verify he sees the pings on the other end....no problem......I do a SCTP request from that same node, I see it hit the interface, not get translated and then egress the outside interface....clearly not headed for the VPN tunnel.....for whatever reason the FW does not see it as interesting traffic.....I have specified Proto 132 and the hit count remains "0".  In the packet sniff I can clearly see in the IP header Proto:SCTP
0
The Ultimate Tool Kit for Technolgy Solution Provi

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more!

authentifyAuthor Commented:
asaevener,

They say they do but to what capacity they do not specify...so are they passing SCTP?  Who knows...I can post my config but it will have to be tomorrow......
0
asavenerCommented:
Sounds like the SCTP traffic gets picked up by NAT.  (Cisco devices have an order of operations; NAT takes place before crypto.)

Make sure you have a "nat (inside) 0 access-list <ACL-name>" command, and that the SCTP traffic is listed in the access list.
0
authentifyAuthor Commented:
So I created access-list 199...allowed 192.168.1.x to any Destination and defined the 132 protocol with an object group....I can't apply the NAT because it says "access list 199 contains a protocol or port"

If I list ip, that doesn't seem to natively cover 132 for some reason.
0
asavenerCommented:
OK, try "nat (inside) 0 192.68.1.0 255.255.255.0".
0
asavenerCommented:
Er... Should be "192.168.1.0"
0
authentifyAuthor Commented:
Yeh no nat is not going to work....from my understanding...my crypto map is from 66.54.x.x to the destination on the other end...my static nat is from 192.168.x.x to 66.54.x.x...no nat means no traffic is sent to the crypto map ACL....so when I put a no nat statement in no traffic goes over the vpn...

So it looks from packet sniffs that the nat works in getting it to the outside interface it is just ignored by the crytpo map as uninteresting traffic.
0
asavenerCommented:
So, does a "show xlate" display the SCTP traffic as being NAT'd correctly?

Still kinda flying in the dark here, without a config to peruse.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
authentifyAuthor Commented:
Hey all sorry to go dark there for a little bit....the truth is that setting up the VPN through thye ASDM is not rocket science, so it was clear that the acl and ace's were all correct, especially since ICMP traffic would clearly use the correct crypto map ACL....the problem is with the SCTP traffic specifically.  

It clearly does not like being NAT'd...this goes back to the ASA's having no native support for SCTP.  When i set up the vpn tunnel as a direct connect network....menaing the other end accepting traffic directly from the nodes and not translating the address, it worked fine.  

asavener, you were correct in the nat was the problem, but it is further than that just a bit.  The ASA does not want to translate addreses when the protocol is SCTP and Cisco has confirmed that.....very disappointed in Cisco though, this protocol is not that new....
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Cisco

From novice to tech pro — start learning today.