cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
768
Views
0
Helpful
9
Replies

Translation Failing for protocol 50

lracano
Level 1
Level 1

I have a user that is trying to establish a VPN tunnel using an AT & T Global dialer. I configured on the ASA 5510 3 ACL's

access-list outside extended permit tcp 192.9.X.X 255.255.255.255 eq 50 any

access-list outside extended permit udp 192.9.X.X 255.255.255.255 eq isakmp any

access-list outside extended permit udp 192.9.X.X 255.255.255.255 eq 4500 any

I was still getting a regular translation creation failed for protocol 50 src inside:192.9.X.X dst outside:12.65.185.2 Syslog #305006.

I then added the static statement

static (inside,outside) tcp interface 50 192.9.X.X 50 netmask 255.255.255.255, but I am still getting the error message.

I am not sure I even need the ACL's in there. Has anyone come accross this?

9 Replies 9

Richard Burts
Hall of Fame
Hall of Fame

Lorna

You have made a fairly typical misunderstanding. This line:

access-list outside extended permit tcp 192.9.X.X 255.255.255.255 eq 50 any

is attempting to permit ESP but calls it TCP 50. But ESP is really IP protocol 50 not TCP port 50.

And if you have properly configured IPSec VPN on the ASA then the ASA will accept IPSec packets without them being configured in the access list.

HTH

Rick

HTH

Rick

acomiskey
Level 10
Level 10

It appears the client is inside the ASA? Or is the ASA terminating the vpn?

Hi Yes, the AT & T global Network Client is installed on a PC inside the ASA. The ASA is not terminating the VPN, I need the traffic to pass thru the ASA.

Lorna

I am sorry that I misunderstood and assumed that the VPN was terminated on the ASA. If the traffic is coming from inside and going out I would have thought that inside to outside would go through ok. But if you need an access list for it then I believe that the problem is what I had discussed in my first post: ESP is IP protocol 50 and not TCP port 50. So you need to change the lines that are permitting TCP 50 and have them permit IP protocol ESP (protocol 50).

[edit] were you getting hits on the access line that permitted UDP 500 (ISAKMP)? If so it shows that your access list was working and the main issue was that ESP was not getting through (and without ESP there is no VPN).

HTH

Rick

HTH

Rick

Thanks Rick

I have changed the ACL

access-list outside extended permit esp host 192.9.X.X any

access-list outside extended permit udp 192.9.X.X 255.255.255.255 eq isakmp any

access-list outside extended permit udp 192.9.X.X 255.255.255.255 eq 4500 any

I have enabled

crypto isakmp enable outside

crypto isakmp nat-traversal

And my static statement is

static (inside,outside) tcp interface 50 192.9.X.X 50 netmask 255.255.255.255

I am still getting the same error message regarding the translation of protocol 50.

You don't need the static statement.

Is access-list outside applied, "access-group outside in interface inside"?

Did you mean to put source ports in 2 of our acls statements?

access-list outside extended permit esp host 192.9.X.X any

access-list outside extended permit udp 192.9.X.X 255.255.255.255 any eq isakmp

access-list outside extended permit udp 192.9.X.X 255.255.255.255 any eq 4500

Is nat-traversal enabled on the client and on the remote vpn device?

Lorna

The static statement is still trying to translate TCP port 50 and not ESP. So even if it was needed it would not work.

I believe that the port numbers in two of the ACL statements are appropriate.

Perhaps you can tell us some more detail of how your have configured translation on your ASA. As I think about the error message I believe that it indicates that it is attempting and failing to translate this traffic.

And then I think about what would happen if you did translate the traffic. If the traffic is attempting to establish a VPN connection from inside and then the IP address of the packet gets changed what happens when the other end attempts to validate the IPSec header?

Perhaps you can clarify what the intent is: should that traffic be translated? If not then perhaps we need to look at your nat0 configuration?

HTH

Rick

HTH

Rick

Hi Rick

I was able to pass the traffic by adding

to the policy class inspection:

inspect ipsec-pass-thru

Thanks for all your help

Lorna

I am glad that you got it worked out. Thank you for posting back to the forum and indicating what you did to resolve the problem. It makes the forum more useful when people can read about a problem and can read what was done to resolve the problem.

The forum is an excellent place to learn about Cisco networking. I encourage you to continue your participation in the forum.

HTH

Rick

HTH

Rick
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: