Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 1 subscriber
  • Views 42734 views
  • Users 0 members are here
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

No_proposal_chosen

safesax2002
Hi all,
I have a weird problem going on. I have a IPSEC Site2Site VPN from my Astaro 220 to a Cisco 3000 Concentrator. Everything was going fine until a couple days ago. The remote end made some routing changes and now weird things are happening.

We got it going today once they fixed their routes but the error message I'm seeing continues and now the tunnel is down again. Here is an excerpt of the log file.

2012:07:25-11:29:15 AASG1 pluto[7073]: packet from 216.170.52.58:500: ignoring informational payload, type NO_PROPOSAL_CHOSEN
2012:07:25-11:29:35 AASG1 pluto[7073]: packet from 216.170.52.58:500: ignoring informational payload, type NO_PROPOSAL_CHOSEN
2012:07:25-11:29:39 AASG1 pluto[7073]: packet from 216.170.52.58:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
2012:07:25-11:29:39 AASG1 pluto[7073]: packet from 216.170.52.58:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
2012:07:25-11:29:39 AASG1 pluto[7073]: packet from 216.170.52.58:500: ignoring Vendor ID payload [RFC 3947]
2012:07:25-11:29:39 AASG1 pluto[7073]: packet from 216.170.52.58:500: ignoring Vendor ID payload [FRAGMENTATION c0000000]
2012:07:25-11:29:39 AASG1 pluto[7073]: "S_NHI" #2222: responding to Main Mode
2012:07:25-11:29:39 AASG1 pluto[7073]: "S_NHI" #2222: ignoring Vendor ID payload [Cisco-Unity]
2012:07:25-11:29:39 AASG1 pluto[7073]: "S_NHI" #2222: received Vendor ID payload [XAUTH]
2012:07:25-11:29:39 AASG1 pluto[7073]: "S_NHI" #2222: ignoring Vendor ID payload [8a1bb0d689754169ea4d8e671ba62f9a]
2012:07:25-11:29:39 AASG1 pluto[7073]: "S_NHI" #2222: ignoring Vendor ID payload [Cisco VPN 3000 Series]
2012:07:25-11:29:39 AASG1 pluto[7073]: "S_NHI" #2222: received Vendor ID payload [Dead Peer Detection]
2012:07:25-11:29:39 AASG1 pluto[7073]: "S_NHI" #2222: Peer ID is ID_IPV4_ADDR: '216.170.52.58'
2012:07:25-11:29:39 AASG1 pluto[7073]: "S_NHI" #2222: sent MR3, ISAKMP SA established
2012:07:25-11:29:39 AASG1 pluto[7073]: "S_NHI" #2222: ignoring informational payload, type IPSEC_INITIAL_CONTACT
2012:07:25-11:29:39 AASG1 pluto[7073]: "S_NHI" #2223: responding to Quick Mode
2012:07:25-11:29:39 AASG1 pluto[7073]: "S_NHI" #2223: IPsec SA established {ESP=>0x12b6e029 


You see in the middle section it finally reconnected and the local user was able to send over the tunnel but I still see the NO_PROPOSAL_CHOSEN error. The guy on the other side saw error messages on his concentrator as well but the tunnel was working so we left if for now as we both had other things going on.

Policy Settings
IKE: AES-256/MD5/7800/DH Group 5
IPSEC:AES-256/MD5/3600/None
Not Strict & No Compression

DPD[:$]n

I decided to check on it this afternoon and now it's down again. Any ideas?


This thread was automatically locked due to age.
  • 0
    FWIW,
    I had some problems with a Cisco 3030 after upgrading Astaro from 8.1 to 8.305; the solution was to disable NAT-T and DPD (dead peer detection) on the Astaro.

    Barry
  • 0
    NAT-T was disabled and and went ahead and disabled DPD. Doesn't look like it helped.

    @BarryG Did you have the connection setup as respond-only or initiate?
  • 0
    The two sides get through to "IPsec SA established," so it appears that the tunnel gets established.  What happens if you try it with NAT-T enabled?  Have you checked 'Support path MTU discovery'?

    If you still can't get it to work correctly, please [Go Advanced] below and attach pictures of edits of the 'IPsec Connection' and of the 'Remote Gateway' with 'Advanced' displayed.

    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 safesax2002
    NAT-T was disabled and and went ahead and disabled DPD. Doesn't look like it helped.

    @BarryG Did you have the connection setup as respond-only or initiate?


    Initiate.

    Barry
  • 0
    I figured it out. Our Phase 1 Authentication was set wrong. I'm not sure how it got changed (on their side) or why it worked for a short time but it works like it's supposed to now.
  • 0
    That's interesting.  Can you tell us exactly what the problem was - what change was made to make the tunnel work?

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