authentify
asked on
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!!!
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!!!
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.
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.
ASKER
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
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
ASKER
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......
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......
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.
Make sure you have a "nat (inside) 0 access-list <ACL-name>" command, and that the SCTP traffic is listed in the access list.
ASKER
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.
If I list ip, that doesn't seem to natively cover 132 for some reason.
OK, try "nat (inside) 0 192.68.1.0 255.255.255.0".
Er... Should be "192.168.1.0"
ASKER
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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....
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....
Can you post your config anyway?