Thread Info
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Unable to established the IP_Sec VPN connection

yualme
Dear Team,

I have Check-Point Cluster & Asg 320 on other side

I have changed my internet link so , i change the live IP.Now I'm getting below error any clue.

ASG 8.308


Its stuck in the phase 1

2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: "S_ASTRO-2-CP-POL" #12032: Quick Mode message is unacceptable because it is for an incomplete ISAKMP SA
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: "S_ASTRO-2-CP-POL" #12032: sending encrypted notification PAYLOAD_MALFORMED to LIVE IP:500
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | **emit ISAKMP Message:
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | initiator cookie:
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | 3d 53 7e a2 69 d1 e1 9c
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | responder cookie:
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | a5 53 ed ff 0f ff 47 d3
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | next payload type: ISAKMP_NEXT_HASH
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | ISAKMP version: ISAKMP Version 1.0
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | exchange type: ISAKMP_XCHG_INFO
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | flags: ISAKMP_FLAG_ENCRYPTION
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | message ID: cf db f7 9f
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | ***emit ISAKMP Hash Payload:
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | next payload type: ISAKMP_NEXT_N
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | emitting 20 zero bytes of HASH into ISAKMP Hash Payload
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | emitting length of ISAKMP Hash Payload: 24
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | ***emit ISAKMP Notification Payload:
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | next payload type: ISAKMP_NEXT_NONE
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | DOI: ISAKMP_DOI_IPSEC
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | protocol ID: 1
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | SPI size: 0
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | Notify Message Type: PAYLOAD_MALFORMED
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | emitting 0 raw bytes of spi into ISAKMP Notification Payload
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | spi
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | emitting length of ISAKMP Notification Payload: 12
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | emitting 12 zero bytes of encryption padding into ISAKMP Message
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | emitting length of ISAKMP Message: 76
2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: | next event EVENT_RETRANSMIT in 6 seconds for #12032
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: |
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: | *received 380 bytes from LIVE IP:500 on eth1
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: | **parse ISAKMP Message:
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: | initiator cookie:
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: | 3d 53 7e a2 69 d1 e1 9c
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: | responder cookie:
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: | a5 53 ed ff 0f ff 47 d3
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: | next payload type: ISAKMP_NEXT_HASH
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: | ISAKMP version: ISAKMP Version 1.0
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: | exchange type: ISAKMP_XCHG_QUICK
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: | flags: ISAKMP_FLAG_ENCRYPTION
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: | message ID: d0 b3 ca fe
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: | length: 380
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: | ICOOKIE: 3d 53 7e a2 69 d1 e1 9c
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: | RCOOKIE: a5 53 ed ff 0f ff 47 d3
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: | peer: 7d 12 81 4a
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: | state hash entry 27
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: | state object not found
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: | ICOOKIE: 3d 53 7e a2 69 d1 e1 9c
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: | RCOOKIE: a5 53 ed ff 0f ff 47 d3
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: | peer: 7d 12 81 4a
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: | state hash entry 27
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: | state object #12032 found, in STATE_MAIN_I3
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: "S_ASTRO-2-CP-POL" #12032: Quick Mode message is unacceptable because it is for an incomplete ISAKMP SA
2013:05:04-01:04:04 TRP_USFW01 pluto[6894]: "S_ASTRO-2-CP-POL" #12032: sending encrypted notification PAYLOAD_MALFORMED to LIVE IP:500


This thread was automatically locked due to age.
    • 0
      Hi, you should probably open a support case, but did you make sure the VPN on both ends has the new IPs or hostnames set?

      Barry
      • 0
        No only one side's Live IP. Because I just want to sift tunnel to other Link & I have live IP LAN pool of old link. 

        So there is the router before Check Point Firewall who is doing the static nating(Old links LIVE IP with new links LIVE IP)(So i don't need to do any changes at checkpoint firewall).

        And my other side with Juniper firewall @ other end is working fine.
        • 0
          2013:05:04-01:04:00 TRP_USFW01 pluto[6894]: "S_ASTRO-2-CP-POL" #12032: Quick Mode message is unacceptable because it is for an incomplete ISAKMP SA

          The problem occured before your first line.  99 times out of 100, having "Debug" active just makes it harder to see what the problem is.

          So there is the router before Check Point Firewall who is doing the static nating(Old links LIVE IP with new links LIVE IP)(So i don't need to do any changes at checkpoint firewall).

          It's very tricky to get an IPsec tunnel to work if either end of a site-to-site is behind a NATting router.  Please post pictures of the IPsec Connection and the Remote Gateway and of the correspoding information for the other side.

          Cheers - Bob
           
          Sophos UTM Community Moderator
          Sophos Certified Architect - UTM
          Sophos Certified Engineer - XG
          Gold Solution Partner since 2005
          MediaSoft, Inc. USA
        • 0
          we require peer to have ID '125.18.129.74', but peer declares '203.201.208.38'

          In the ASG's Remote Gateway definition, put 203.201.208.38 into 'VPN ID (optional)'.  Everything else looks OK.

          If you have any other IPsec VPNs (Site-to-Site or Remote Access) that use a PSK, you should select 'Enable probing of pre-shared keys' on the 'Advanced' tab.

          Cheers - Bob
          PS You also should turn off 'IKE debugging' on the 'Debug' tab.  It just made this problem harder to find.
           
          Sophos UTM Community Moderator
          Sophos Certified Architect - UTM
          Sophos Certified Engineer - XG
          Gold Solution Partner since 2005
          MediaSoft, Inc. USA
          • 0 in reply to BAlfson
            Hey BobSir,

            Its done , just put 203.201.208.38 into 'VPN ID (optional)' and its its up in the flash.

            Thanks once again to be the life savior for me.[:D]
            • 0 in reply to yualme
              Hey BobSir,

              Its done , just put LIVE IP of check point into 'VPN ID (optional)' and tunnel came up in the flash.

              So my question is that we can't change the VPN IP of tunnel now(no issue if it remains the same , just for curiosity) ??

              Is is not mentioned by me when we established this tunnel , so its automatically taken by the devices it self??

              Thanks once again to be the life savior for me.[:D]
          • 0
            In IPsec, the packets sent are labeled with the IP of the sending interface.  If the receiver on the other end sees a different IP than expected, it ignores the packet.

            Since the packets coming from the other side are NATted, you have to prepare the UTM to accept packets labeled with the IP of the sending interface - otherwise, it expects to see the IP of the sending gateway (default).

            Cheers - Bob
             
            Sophos UTM Community Moderator
            Sophos Certified Architect - UTM
            Sophos Certified Engineer - XG
            Gold Solution Partner since 2005
            MediaSoft, Inc. USA
            • 0 in reply to BAlfson
              Hi Bobsir,

              Is it the default behavior of ASG ??

              Because i did the same thing with my other tunnel @ that time the remote firewall was Juniper & i only changed the natted IP in the juniper. No additional changes were needed there.
            • 0
              WebAdmin does not yet allow the admin to relabel the outgoing IP in an IPsec packet like the Juniper does.

              I expect the Checkpoint also allows this, so, instead of making the change in the ASG, you could have made a change in the Checkpoint to have it label packets with the gateway IP instead of the IP on its own interface.

              Cheers - Bob
               
              Sophos UTM Community Moderator
              Sophos Certified Architect - UTM
              Sophos Certified Engineer - XG
              Gold Solution Partner since 2005
              MediaSoft, Inc. USA
              Unfiltered HTML