[Openswan Users] IP cache on ADSL Connections

Frederico Madeira fmadeira at gmail.com
Thu Nov 8 15:55:27 EST 2007


Hi Paul,

I added this parameter on both ipsec.conf, after this the tunnel didn't came up.

I got this in logs

Nov  8 17:04:33 vpn pluto[12245]: packet from 189.70.198.203:500:
initial Main Mode message received on 201.36.53.68:500 but no
connection has been authorized
Nov  8 17:05:13 vpn pluto[12245]: packet from 189.70.198.203:500:
ignoring unknown Vendor ID payload [4f455a7e4261425d725c705f]
Nov  8 17:05:13 vpn pluto[12245]: packet from 189.70.198.203:500:
received Vendor ID payload [Dead Peer Detection]
Nov  8 17:05:13 vpn pluto[12245]: packet from 189.70.198.203:500:
received Vendor ID payload [RFC 3947] meth=109, but port floating is
off
Nov  8 17:05:13 vpn pluto[12245]: packet from 189.70.198.203:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108,
but port floating is off
Nov  8 17:05:13 vpn pluto[12245]: packet from 189.70.198.203:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107,
but port floating is off
Nov  8 17:05:13 vpn pluto[12245]: packet from 189.70.198.203:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106,
but port floating is off
Nov  8 17:05:13 vpn pluto[12245]: packet from 189.70.198.203:500:
ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Nov  8 17:05:13 vpn pluto[12245]: packet from 189.70.198.203:500:
initial Main Mode message received on 201.36.53.68:500 but no
connection has been authorized

Bellow my ipsec.conf:

config setup
        # Debug-logging controls:  "none" for (almost) none, "all" for lots.
        # klipsdebug=none
        # plutodebug="control parsing"
        nat_traversal=yes

include /etc/ipsec.d/*.conf

conn client_to_server
    left=201.xx.xx.xx                # Local vitals
    leftsubnet=192.168.10.0/24       #
    leftid=@vpn.server         #
    leftrsasigkey=0sAQPMugwfC6uU.........
    leftnexthop=201.xx.xx.Xx      # correct in many situations
    right=host01.no-ip.org            # Remote vitals
    rightsubnet=192.168.20.0/24        #
    rightid=@client.server        #
    rightrsasigkey=0sAQOmxV.......
    rightnexthop=%defaultroute     # correct in many situations
    auto=start                       # authorizes but doesn't start this
                                   # connection at startup

Thanks.

-- 
Frederico Madeira
fmadeira at gmail.com
www.madeira.eng.br

2007/11/8, Paul Wouters <paul at xelerance.com>:
> On Thu, 8 Nov 2007, Frederico Madeira wrote:
>
> > No.
> > I'll add and test.
> >
> > What is the function of this parameter ?
>
>        rekey  whether  a connection should be renegotiated when it is about to
>               expire; acceptable values are yes (the default) and no. The  two
>               ends need not agree, but while a value of no prevents Pluto from
>               requesting renegotiation, it  does  not  prevent  responding  to
>               renegotiation  requested  from  the  other  end,  so  no will be
>               largely ineffective unless both ends agree on it.
>
> You cannot rekey to dynamic ip addresses.
>
> Paul
> --
> Building and integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>


More information about the Users mailing list