[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