cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
18172
Views
10
Helpful
19
Replies

Site to Site VPN ISSUE

Hi, im triying to configure a Site to Site VPN with a ASA 5510 in one side, and other vendor firewall (chekcpoint) on the other side. However the VPN never gets up

In my side im behind a router that makes static PAT for ports UDP 500 and 4500 (ie ASA has a private address on outside interface), and in the remote side a public ip is assigned direclty to the firewall.

i tried enabling and disabling NAT-T on my side but the only difference i get is a log message that says "Automatic NAT Detection Status:     Remote end is NOT behind a NAT device     This   end   IS   behind a NAT device", Im not sure if this message is just imformtional, or is the cause for the VPN tunnel dont working.

The output of debug crypto isakmp is:

*i replaced the real public IP of the remote Firewall by 190.190.190.190

%ASA-7-713906: NAT-T disabled in crypto map outside_map 1.

2012-09-12 11:54:45    Local4.Notice    192.168.202.2    %ASA-5-713041: IP = 190.190.190.190, IKE Initiator: New Phase 1, Intf outside, IKE Peer 190.190.190.190  local Proxy Address 192.168.202.2, remote Proxy Address 190.190.190.190,  Crypto map (outside_map)

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-715046: IP = 190.190.190.190, constructing ISAKMP SA payload

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-715046: IP = 190.190.190.190, constructing Fragmentation VID + extended capabilities payload

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-713236: IP = 190.190.190.190, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + NONE (0) total length : 108

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-609001: Built local-host outside:190.190.190.190

2012-09-12 11:54:45    Local4.Info    192.168.202.2    %ASA-6-302015: Built outbound UDP connection 83198007 for outside:190.190.190.190/500 (190.190.190.190/500) to identity:192.168.202.2/500 (192.168.202.2/500)

2012-09-12 11:54:45    Local4.Info    192.168.202.2    %ASA-6-725007: SSL session with client Inside:192.168.51.15/3006 terminated.

2012-09-12 11:54:45    Local4.Info    192.168.202.2    %ASA-6-302020: Built outbound ICMP connection for faddr 192.168.23.253/0 gaddr 192.168.32.80/0 laddr 192.168.32.80/0

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-713236: IP = 190.190.190.190, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + SA (1) + NONE (0) total length : 84

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-715047: IP = 190.190.190.190, processing SA payload

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-713906: IP = 190.190.190.190, Oakley proposal is acceptable

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-715046: IP = 190.190.190.190, constructing ke payload

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-715046: IP = 190.190.190.190, constructing nonce payload

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-715046: IP = 190.190.190.190, constructing Cisco Unity VID payload

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-715046: IP = 190.190.190.190, constructing xauth V6 VID payload

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-715048: IP = 190.190.190.190, Send IOS VID

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-715038: IP = 190.190.190.190, Constructing ASA spoofing IOS Vendor ID payload (version: 1.0.0, capabilities: 20000001)

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-715046: IP = 190.190.190.190, constructing VID payload

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-715048: IP = 190.190.190.190, Send Altiga/Cisco VPN3000/Cisco ASA GW VID

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-713236: IP = 190.190.190.190, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 256

2012-09-12 11:54:45    Local4.Info    192.168.202.2    %ASA-6-302020: Built outbound ICMP connection for faddr 192.168.23.253/0 gaddr 192.168.32.80/0 laddr 192.168.32.80/0

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-713236: IP = 190.190.190.190, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + NONE (0) total length : 184

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-715047: IP = 190.190.190.190, processing ke payload

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-715047: IP = 190.190.190.190, processing ISA_KE payload

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-715047: IP = 190.190.190.190, processing nonce payload

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-713906: IP = 190.190.190.190, Connection landed on tunnel_group 190.190.190.190

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-713906: Group = 190.190.190.190, IP = 190.190.190.190, Generating keys for Initiator...

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-715046: Group = 190.190.190.190, IP = 190.190.190.190, constructing ID payload

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-715046: Group = 190.190.190.190, IP = 190.190.190.190, constructing hash payload

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-715076: Group = 190.190.190.190, IP = 190.190.190.190, Computing hash for ISAKMP

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-715046: Group = 190.190.190.190, IP = 190.190.190.190, constructing dpd vid payload

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-713236: IP = 190.190.190.190, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + ID (5) + HASH (8) + VENDOR (13) + NONE (0) total length : 84

If someone can help, many thanks in advance.

2 Accepted Solutions

Accepted Solutions

Julio,

As per the debugs looks like your pre-shared-key is not matching what the remote end is sending. please double check the key and let me know. You can use the command "more system:running | be tunnel-group" to check the key on your ASA.

Also I just wanted to mention that you are absolutely right if you are just forwarding the ports to the ASA this will not work without Nat-t.

Regards,

Luis Ramirez

VPN Team

Cisco TAC Support Engineer

View solution in original post

I have an exact VPN setup in my lab and it is working fine between a Pix 8.0(4) and a Checkpoint firewall R70.50 firewall.

The Checkpoint firewall has public IP address while the Pix is sitting a cisco 2600 router.  The cisco router has public IP address while the pix "outside" has private address.

Here is what I have on the cisco 2600 router:

ip access-list extended allow

   permit icmp any any log

   permit ip any any

ip route 0.0.0.0 0.0.0.0 1.1.1.1

interface f0/0

  desc  public facing 

  ip nat outside

  ip add 1.1.1.2 255.255.255.252

  ip access-group allow in

interface f0/1

  desc internal facing

  ip address 192.168.1.254 255.255.255.0

  ip nat inside

  ip access-group allow in

ip nat inside source static udp 192.168.1.1 500 interface f0/0 500

ip nat inside source static esp 192.168.1.1 interface f0/0

assuming that your ASA "outside" interface ip address is 192.168.1.1 and that you configure VPN correctly between the ASA and the checkpoint firewall, it will work.  It is not difficult at all.  It is working as we speak.  On the router, do "show ip nat trans" and see if you address is being translated properly by the router.

View solution in original post

19 Replies 19

Julio,

Please enable the following debugs and attach the output (make sure you have enough lines of scrollback):

     debug crypto isakmp 190

     debug crypto ipsec 190

BTW, here is a good document:

Checkpoint to Cisco ASA VPN Example

Keep me posted.

Thanks.

Portu.

Please rate any post you find helpful.

luisram2
Cisco Employee
Cisco Employee

Hi Julio,

In this particular case you can be sure that Nat-t should be enable as your device is behind Nat. Also in regards to the log you are seeing you are correct the log is just information and it doesn't represent the reason why the tunnel is not comming up.

Looks like the logs were cut at the begining of the negotiation so we will need to get them again for sure.

Please take a moment to collect the debugs Javier is requesting on his reply.

Regards,

Luis Ramirez
VPN Team


thanks for answering..

Ok, ill get the debug output as Javier requests.

i have a question, if i configure a static NAT (1-to-1) in the router, do i still need the NAT-T option in the ASA??

the checkpoint admin, told me that they dont have NAT-T enabled (and he wont enable it, because there are other VPN services that could be impacted) so i though that their firewall doesn't heard packets on port UDP 500 and that was the cause of the problem, but in the debug i see some lines like

2012-09-12 11:54:45    Local4.Debug    192.168.202.2    %ASA-7-713236:  IP = 190.190.190.190, IKE_DECODE RECEIVED Message (msgid=0) with  payloads : HDR + KE (4) + NONCE (10) + NONE (0) total length : 184

which makes me think that im receiving  vpn negotiation packets from the remote site, so NAT-T is not the problem, im a bit confussed about it..

Julio,

Yes, even with a one-to-one translation NAT-T is required.

What does the remote site report?

Thanks.

Javier

The remote site reports no VPN negotiation packets received, however i think they didn't really look. also they said that cannont enable NAT-T beacuase there are another clients connected.

So in this scenario with my side requering NAT-T and the remote site refusing to enabling, is there a way to make the VPN s2s work??

thanks

NAT-T is NOT required. The only reason NAT-T was invented is to give appliances a way to differentiate between peers using the same public IP (ie, clients behind the same NAT device). If the ASA is the only device connecting to the CheckPoint from your public IP, you're fine.

Also, your debugs look incomplete. Please re-post full debug which will include a Peer Terminate reason.

Thanks

As long as one of the devices is behind NAT then NAT-T must be enabled, for this scenario it is required.

You can disable NAT-T and try to establish the tunnel, but you may experience issues when passing traffic.

To disable NAT-T:

no crypto isakmp nat-traversal

* This will affect Remote Access connections.

Do you experience the same issue even with NAT-T disabled?

Could you please include the complete debug output?

Thanks.

Hi Julio,

Nat-t was created to encapsulte the ESP packets (encrypted packets) when they go through PAT. ESP is a portless protocol therefore you don't have a way to PAT this traffic, Also if this feature is not enable on the other end the VPN tunnel is not going to be able to use it.

If yopu have a one to one translation the connection could work fine depending on what is on the path to the other end, if the traffic needs to go through PAT somewhere over this path the encrypted traffic will be drop.

If you still want to disable Nat-t you can use the command: (this command does not affect the VPN clients, disabling Nat-t globally doesn't affect site to stie tunnels)

crypto map OUTSIDE_MAP 10 set nat-t-disable

Again I just want to make really clear that if the traffic needs to be able to go through PAT somewhere on your network or your ISP network the tunnel will be able to come up but not pass traffic correctly.

Hope this helps.

Regards,

Luis Ramirez

VPN Team

Cisco TAC Support Engineer

Yes i tried with NAT-T disabled and the vpn didn't work.

in the router facing to internet there is a static PAT like

ip nat inside source static udp 500 "private-asa-ip" "public-router-ip" 500 extendible

ip nat inside source static udp 4500 "private-asa-ip" "public-router-ip" 4500 extendible

so i think that if i disable NAT-T the vpn packets wouldn't go further the router.

anyway i'll get and post the debug output with the NAT-T enabled and disabled, and will see what is really happen.

Thanks for your answers

Hi

Attached is the debug output, the remote peer ip address was changed to 190.190.190.190

Julio,

As per the debugs looks like your pre-shared-key is not matching what the remote end is sending. please double check the key and let me know. You can use the command "more system:running | be tunnel-group" to check the key on your ASA.

Also I just wanted to mention that you are absolutely right if you are just forwarding the ports to the ASA this will not work without Nat-t.

Regards,

Luis Ramirez

VPN Team

Cisco TAC Support Engineer

Thanks for answering

we checked the pre-shared-keys on both sides, and are ok.

also i noted this:

Ciscoasa# sh crypto isakmp sa

3   IKE Peer: 190.190.190.190

    Type    : L2L             Role    : initiator

    Rekey   : no              State   : MM_WAIT_MSG6

and reamains there, but just for a time until the entry dissapear.

i was looking for the code NM_WAIT_MSG6 and found it can be two things, a password mismatch as Luis indicated, or a NAT-T problem, im going to put a 1-to-1 NAT on the internet router, and going to disable NAT-T for the crypto map, hope that solve the problem,

Regards,

Julio,

That is the best action plan now. I hope you don't find any PAT process on the path so this can work as you want it.

Regards,

Luis Ramirez

VPN Team

Cisco TAC Support Engineer

Hi

i configured a static NAT in the router and the VPN went up.

Ciscoasa#show crypto isakmp sa detail

6   IKE Peer: 190.190.190.190

    Type    : L2L             Role    : initiator

    Rekey   : no              State   : MM_ACTIVE

    Encrypt : 3des            Hash    : SHA      

    Auth    : preshared       Lifetime: 86400

however i dont have connectivity with the remote end,

Ciscoasa#show crypto ipsec sa

     Crypto map tag: outside_map, seq num: 1, local addr: 192.168.202.2

      access-list OO_temp_outside_map1 extended permit ip host 192.168.202.2 host 190.190.190.190

      local ident (addr/mask/prot/port): (192.168.202.2/255.255.255.255/0/0)

      remote ident (addr/mask/prot/port): (190.190.190.190/255.255.255.255/0/0)

      current_peer: 190.190.190.190

      #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0

      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

      #pkts compressed: 0, #pkts decompressed: 0

      #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0

      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0

      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

      #send errors: 0, #recv errors: 0

      local crypto endpt.: 192.168.202.2, remote crypto endpt.: 190.190.190.190

      path mtu 1500, ipsec overhead 58, media mtu 1500

      current outbound spi: 1E3685EF

      current inbound spi : 94858D52

im not sure if there is a problem on our side or in the remote side..

im very new on vpns, so any help would be great

thanks

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: