topic Re: IPSEC Traffic through ASA5510 in Network Security

IPSEC Traffic through ASA5510

rpw5354 — Mon, 11 Mar 2019 11:13:15 GMT

I need to allow an AT&T global network client vpn connection on one of our client PC's access through our ASA5510. I was given a white paper on what ports and protocols I need to allow but don't know how to go about opening up these ports and protocols. There's a note that reads, "IPSEC traffic must be allowed as well".

Port 500 UDP In and Out

Port 4500 UDO In

Protocol ESP(50) In and Out

I'd appreciate any help.

Re: IPSEC Traffic through ASA5510

srue — Wed, 19 Sep 2007 12:52:49 GMT

have you tried ipsec passthrough inspection?

http://www.cisco.com/en/US/docs/security/asa/asa72/configuration/guide/inspect.html#wp1522169

Re: IPSEC Traffic through ASA5510

rpw5354 — Thu, 20 Sep 2007 15:56:48 GMT

Thank you for the prompt response. I apologize for not seeing that early POST about the exact same thing. After I followed the directions for allowing IPSEC traffic I continue to get Syslog ID 305006 message and the AT&T VPN will not connect. The msh reads: "regular translation creation failed for protocol 50 src inside:" Any ideas?

Re: IPSEC Traffic through ASA5510

JORGE RODRIGUEZ — Thu, 20 Sep 2007 18:45:21 GMT

Randy, you could also do it through acl, the link provided by previous poster should have done the trick by creating a policy-map for ipsec pass through.

In any case, this is what I have in my pix for cisco vpn client pass through initiated from my inside network if applies.

access-list inside permit udp any any eq 500

access-list inside permit udp any any eq 4500

access-list inside permit esp any any

access-group inside in interface inside

also check your static one-to-one translations for the machine you are testing this vpn client connection from, and that the other end is allowing you through based on your public Ip info.

Re: IPSEC Traffic through ASA5510

rpw5354 — Fri, 21 Sep 2007 18:44:52 GMT

Could you elaborate on your last sentence about the static one-one translations from the client pc. I don't quite understand. Thank you very much.

Re: IPSEC Traffic through ASA5510

JORGE RODRIGUEZ — Fri, 21 Sep 2007 21:38:36 GMT

it may not apply in your case, but will give you an example, we have clients where we have to vpn into their DMZs to give them support in our products, these outside clients only allow specific public IPs into their DMZ, so what we have is VMs server as our vpn client machines each with unique one-to-one local to public NAT translations, the othe end only allows these public IPs. In other words the other side is not wide opened to any other IPs from our public block or any other blocks, that is what I meant on the " verify one to one nat translation" .

Rgds

Jorge

Re: IPSEC Traffic through ASA5510

rpw5354 — Mon, 24 Sep 2007 18:04:29 GMT

Thanks for your help and patience Jorge! I did manage to get the AT&T VPN Client to work.

I need to read up on NAT to fully understand its function. Thanks again and have a good day!

Re: IPSEC Traffic through ASA5510

JORGE RODRIGUEZ — Mon, 24 Sep 2007 18:29:56 GMT

Randy, I am glad you got all resolved.. you are always wellcome.

Here are two very good links on NAT/PAT

ALL NAT scenarios, config examples on NAT IOS or PIX/ASA.

http://www.cisco.com/en/US/tech/tk648/tk361/tk438/tsd_technology_support_sub-protocol_home.html

Q&A on NAT

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_q_and_a_item09186a00800e523b.shtml#intro

Rgds

Jorge

Re: IPSEC Traffic through ASA5510

rpw5354 — Tue, 25 Sep 2007 14:21:37 GMT

I spoke too soon about the NAT. In order for the AT&T VPN to work I needed the following Static NAT statement:

STATIC (inside,outside) interface 172.16.3.31 netmask 255.255.255.252 tcp 0 0 udp 0

When I issue this statement I get a warning

"all services terminating at outside interface are disabled interface"

The VPN client works but my VPN clients can no longer connect. If I remove the STATIC NAT command it fixes my VPN clients but breaks the AT&T VPN from 172.16.3.31

Re: IPSEC Traffic through ASA5510

acomiskey — Tue, 25 Sep 2007 14:25:52 GMT

This sounds like a nat-traversal problem. Does your AT&T Client and remote peer support nat-t?

When you create that static you can no longer peer to your outside interface for your outside vpn clients, but you are able to connect with the AT&T client because nat-t is not required when you are not pat'ing. Do you have any more public addresses?

Re: IPSEC Traffic through ASA5510

rpw5354 — Tue, 25 Sep 2007 14:33:04 GMT

Forgive my stupidity but I know just enough to be dangerous when it comes to our ASA5510 and setting it up. We only have one public ip address given to us by our ISP (Stratus Wave). I created a group object on the ASA that contains all the ip addresses given to me by the AT&T VPN people (GIGS?) I allowed ESP traffic on the outside interface using an ACL. My problem is getting the correct STATIC NAT command to accomodate the traffic for the AT&T VPN but to allow my outside VPN clients to still connect. Hope this helps!

Re: IPSEC Traffic through ASA5510

acomiskey — Tue, 25 Sep 2007 14:42:47 GMT

Yes, this is what I understood.

For esp packets to go through nat you either have to use a 1 to 1 static which you did above using your outside interface or use nat-traversal. If the AT&T client or the peer which the AT&T clients are connecting to do not support nat-t, then you would have to use a 1 to 1 static so the clients are not natted. The problem with that for you is that you only have 1 public ip address, the outside interface address of your ASA. Therefore, when you create that static, any traffic directed to the outside interface address, your outside vpn clients for example, will not work as this traffic is being forwarded to the host in your static statement. Hope that makes more sense.

Re: IPSEC Traffic through ASA5510

rpw5354 — Tue, 25 Sep 2007 15:23:43 GMT

Thank you for clarifying. It makes perfect sense in how you worded it. I'm not familiar with nat-traversal and how to implement it though.

Re: IPSEC Traffic through ASA5510

rpw5354 — Tue, 25 Sep 2007 17:01:26 GMT

I verified from AT&T that their VPN does in fact support nat-t and it is turned ON in their client. Can you help me implement this using our ASA5510? Thank you!

Re: IPSEC Traffic through ASA5510

acomiskey — Tue, 25 Sep 2007 17:12:24 GMT

You don't need to do anything on the ASA for outgoing vpn's. For incoming VPNs to the ASA you can enable nat-t with the command "crypto isakmp nat-traversal". You may very well already have it in there since you're not having issues with the inbound vpn clients. Maybe nat-t isn't your issue, but it sure sounded like it.

Do you want to post a sanitized config from the ASA?

edit: The important thing for nat-t in your ASA is to allow udp 4500 outbound, which it looks like you've already done.

Re: IPSEC Traffic through ASA5510

rpw5354 — Tue, 25 Sep 2007 18:15:47 GMT

I actually had a "no crypto isakmp nat-traversal" command in the ASA which I revered it and tried the AT&T VPN again to no avail. I always have to have the STATIC NAT from the client pc to the outside interface in place to get it to work which breaks my outside VPN clients. What am I missing? Plus the ONLY HITS I get on my ACL's when the AT&T VPN connects is the one for allowing ESP(50) traffic coming INTO my network on the outside interface. I never see hits for UDP/4500 or UDP/500...etc. The AT&T white papers state I MUST allow ESP both in and out for all GIGS plus open port UDP/500 for all GIGS both in and out plus UDP/4500 for all GIGS both in and out....which I did but never get any hits on the ACL's.

Re: IPSEC Traffic through ASA5510

acomiskey — Tue, 25 Sep 2007 18:33:02 GMT

1. The acl's shouldn't be a problem as it works when you have the 1 to 1 static. You are allowing the appropriate ports outbound (acl 120).

2. You actually do not need to specify the ports in acl 100. But if you still want to you have it written in reverse. This acl is applied into the outside interface, so the source would be any and the destination would be ATT_VPN_GIGS, like so...

access-list 100 extended permit esp any object-group ATT_VPN_GIGS

access-list 100 extended permit udp any object-group ATT_VPN_GIGS eq isakmp

access-list 100 extended permit udp any object-group ATT_VPN_GIGS eq 4500

but like I said, you shouldn't need this.

3. Leave crypto isakmp nat-traversal. This is so the ASA will do nat-t for your vpn clients terminating on the ASA.

4. Other than that, if the AT&T is truly doing nat-t, I'm at a loss. Try to get some logging going on the ASA.

Re: IPSEC Traffic through ASA5510

rpw5354 — Wed, 26 Sep 2007 11:44:36 GMT

I took out the 1 to 1 STATIC NAT command and I

get the following message when I try to connect the AT&T VPN client.

regular translation creation failed for protocol 50 src inside:172.16.3.31 dst outside:12.65.191.2

172.16.3.31 is the ip address of the client pc

12.65.191.2 is one on the GIGS ip addresses from AT&T

Re: IPSEC Traffic through ASA5510

rpw5354 — Wed, 26 Sep 2007 11:58:28 GMT

I copied the definition of the error msg I'm getting right from Cisco's SYSLOG ID MESSAGES

PDF. Hopefully you can interpret it for me?

Error Message %FWSM-3-305006: {outbound static|identity|portmap|regular)

translation creation failed for protocol src interface_name:source_address/source_port

dst interface_name:dest_address/dest_port

Explanation A protocol (UDP, TCP, or ICMP) failed to create a translation through the security appliance.

This message appears as a fix to caveat CSCdr00663 that requested that security

appliance not allow packets that are destined for network or broadcast addresses. The security appliance provides this checking for addresses that are explicitly identified with static command statements. With the change, for inbound traffic, the security appliance denies translations for a destined IP address identified as a network or broadcast address.

The security appliance does not apply PAT to all ICMP message types; it only applies PAT ICMP echo and echo-reply packets (types 8 and 0). Specifically, only ICMP echo or echo-reply packets create a PAT xlate. So, when the other ICMP messages types are dropped, system log message 305006 (on the security appliance) is generated. The security appliance utilizes the global IP and mask from configured static command statements to differ regular IP addresses from network or broadcast IP addresses. If the global IP address is a valid network address with a matching network mask, then the security appliance does not create a translation for network or broadcast IP addresses with inbound packets.

For example:

static (inside,outside) 10.2.2.128 10.1.1.128 netmask 255.255.255.128

Global address 10.2.2.128 is responded to as a network address and 10.2.2.255 is responded to as the broadcast address. Without an existing translation, security appliance denies inbound packets destined for 10.2.2.128 or 10.2.2.255, and logs this system log message.

Recommended Action If the packet that was denied was destined for a valid host IP address, change the netmask of the static translation, so that the host IP address is not the same as a network or

broadcast address.

Re: IPSEC Traffic through ASA5510

acomiskey — Wed, 26 Sep 2007 12:24:22 GMT

Those aren't always very helpful at all. I still don't think the remote peer is doing nat-t over udp 4500.

Type this in Search NetPro and have a look what other people have done.

"regular translation creation failed for protocol 50"