Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3152
  • Last Modified:

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!!!
0
authentify
Asked:
authentify
  • 5
  • 5
1 Solution
 
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 Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

 
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
 
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

Featured Post

Identify and Prevent Potential Cyber-threats

Become the white hat who helps safeguard our interconnected world. Transform your career future by earning your MS in Cybersecurity. WGU’s MSCSIA degree program was designed in collaboration with national intelligence organizations and IT industry leaders.

  • 5
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now