1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

WRV200 <-> Openswan site-to-site vpn

Discussion in 'Cisco Small Business Routers and VPN Solutions' started by cherzberg, Nov 8, 2007.

  1. cherzberg

    cherzberg LI Guru Member

    Hi,

    I´m using several WRV200 to conenct to an openswan gateway.
    All wrv200 connect to the openswan with no problem but after the the rekeying time I got this messages from the openswan.

    Nov 8 09:30:48 DB1 pluto[28946]: "Peine" #103: starting keying attempt 30 of an unlimited number
    Nov 8 09:30:48 DB1 pluto[28946]: "Peine" #109: initiating Main Mode to replace #103
    Nov 8 09:30:48 DB1 pluto[28946]: packet from 80.152.211.131:500: ignoring informational payload, type NO_PROPOSAL_CHOSEN
    Nov 8 09:30:48 DB1 pluto[28946]: packet from 80.152.211.131:500: received and ignored informational message
    Nov 8 09:30:53 DB1 pluto[28946]: packet from 80.152.215.59:500: ignoring informational payload, type NO_PROPOSAL_CHOSEN
    Nov 8 09:30:53 DB1 pluto[28946]: packet from 80.152.215.59:500: received and ignored informational message
    Nov 8 09:30:58 DB1 pluto[28946]: "Verwaltung" #104: max number of retransmissions (20) reached STATE_MAIN_I1. No response (or no acceptable response) to our first IKE message


    I have no Idea what´s wrong with the configuration.
    Here is the openswan config:

    conn Verwaltung
    authby=secret
    auto=add
    esp=aes-128-md5!
    left=xx.xx.xxx.xx
    leftid=xx.xx.xxx.xx
    leftsubnet=10.0.10.0/24
    right=yy.yyy.yyy.yy
    #rightid=yy.yyy.yyy.yy
    rightsubnet=192.168.122.0/24
    type=tunnel
    pfs=yes
    compress=no
    ikelifetime=240m
    keylife=60m
    keyexchange=ike

    Many thanks for any replay.

    Christian
     
  2. HughR

    HughR LI Guru Member

    First of all, WRV200 is running an old release of Openswan. So you are attempting an Openswan to Openswan connection.

    This means that the side you are calling "Openswan" is trying to rekey the IKE SA #103. The new IKE SA will be known as #109. It corresponds to conn "Peine" which you have not shown us. Why have you not shown it to us? This makes your report very misleading.
    This means that the side you are calling "Openswan" received a notification from the WRV200 side that the Openswan side ignored. That is assuming 80.152.211.131 is the WRV200

    The notification from the WRV200 said: no proposal chosen. This means that the Openswan side proposed SA characteristics that the WRV200 side was unwilling to accept.

    More complete information about what the WRV200 doesn't like ought to be available on that side's log. I say "ought to" because I don't know what logging settings are being used.
    Wait a second, we are getting complaints from 80.152.215.59. You never said that there were two peers to this node.

    It is hard for me to guess what is going on with such a misleadingly incomplete report.
     
  3. cherzberg

    cherzberg LI Guru Member

    Hi HughR,

    thank you for your answer. I am sorry you are right. With the half of information is not good answer possible.

    Here the complit configuration.

    Openswan IP:xx.xx.xx.xx<--------->Peine IP:yy.yy.yy.yy
    |-------->Celle IP: aa.aa.aa.aa
    |-------->Braunschweig bb.bb.bb.bb
    |-------->Berlin ss.ss.ss.ss
    |----- and so on.

    All destionations have a fix IP address and the same congiguration and the same preSharedKey. I am using as encryption aes-128-md5.

    Wenn I restart ipsec all wrv200 are connectig after some second without any error message. I guess it is a problem of rekeying after the lifetime is over.
    Could it be that it is not really a good idea to use the same presharedkey for every connection? Ok. is is not a really good idea for security reason, but for config?

    Thanks
    Christian
     
  4. HughR

    HughR LI Guru Member

    There is still lots of information missing.

    Note: even if you provided enough information, I am certainly not promising that I will take the time to analyze it. Sadly, it all too often takes a fair bit of time.

    FreeS/WAN has a command "ipsec barf" to capture most of the information needed to understand what is going on on that end. It tried to censor information that should not be public from the report. I would assume that Openswan has it too. Consider using it and putting the result in pastebin.ca or some such place.

    But remember: the problem is being detected in the WRV200. That is where you need to concentrate your investigation.

    You really have not explained everything. Are all remote sites WRV200 boxes?
    It isn't safe to guess, but my guess is that keying initiated from the remote sites is working and that keying initiated from the local ("Openswan") site is failing.

    If this is true, it would be nice to know what the WRV200 sites are proposing, what the local site is accepting, and what the local site is proposing.

    The failure seems to be in Phase 1 (IKE SA negotiation) not (yet?) Phase 2 (IPSec SA negotiation). Normally that is the easiest negotiation, assuming authentication is working.
    It should not be a problem, other than bad security.

    Aggressive Mode has bad security. Openswan was trying to use Main Mode. Were the WRV200s using Main Mode when they initiated?

    Repeat: the real problems are detected on the WRV200 side. Does anything useful show up in the logs there?

    Other sources of help: the Openswan mailing list; Xelerance.com will do support work on Openswan (their product) for a fee; Linksys (I'm joking).
     

Share This Page