[Openswan Users] Getting there....
Chris Thomas
cthomas at harkinsbuilders.com
Mon Mar 17 12:29:44 EDT 2008
OK, thanks. Here it is......
From: Peter McGill [mailto:petermcgill at goco.net]
Sent: Monday, March 17, 2008 11:50 AM
To: Chris Thomas; users at openswan.org
Subject: RE: [Openswan Users] Getting there....
I suggest doing a new ipsec barf, and see if someone else can figure out
the problem, maybe Paul or one of the developers can see what I'm not.
Peter McGill
________________________________
From: Chris Thomas [mailto:cthomas at harkinsbuilders.com]
Sent: March 17, 2008 11:44 AM
To: petermcgill at goco.net; users at openswan.org
Subject: RE: [Openswan Users] Getting there....
Wow, talk about going above and beyond. I really appreciate you
taking the time to put together those step by step directions for me.
The install seemed to go fine and when I run IPSEC verify, it shows that
I am now on U2.4.11/K2.6.22-14-server. Unfortunately, my logs are still
showing the same errors as before.
One thing I thought of was that, when I started this project a
month or so ago, I had a Linksys WRVS4400N at the remote site, same as I
do now, and a Linksys WRV54G VPN router at the HQ side. I was using all
the same IPs that I am now and I was able to create the tunnel no
problem. I decided to do away with the WRV54G because it wouldn't keep
the tunnel up for more than an hour or so and also I knew it would not
handle the throughput of the 20 or 30 sites I would eventually
(hopefully) have up on the VPN. If I am correct, this means that the IP
configuration of all devices involved should be OK. As you said though,
it seems that the packets never get back to the Linksys. This is very
strange.
Thanks again for your help.
-Chris
From: Peter McGill [mailto:petermcgill at goco.net]
Sent: Monday, March 17, 2008 10:55 AM
To: Chris Thomas; users at openswan.org
Subject: RE: [Openswan Users] Getting there....
It's often the case that distribution package maintainers do not
keep
up with the source package maintainers releases. This is
generally
not a problem unless you need a newer bugfix or feature.
If you want to keep up yourself, you'll need to manage that
package
locally yourself, either creating a local updated distribution
package
or simply installing directly from the source package.
It's simpler to install direct from the source package, however
this
is done separate from your distributions package management
system
and so the package will not be tracked, upgraded or anything
with
your package management system (apt).
First download the compiler, build tools, etc... needed to build
the package...
sudo apt-get build-dep openswan
Second download the openswan source...
wget -nH -nd -N
http://openswan.org/download/openswan-2.4.11.tar.gz
Third extract the source...
tar -xvzf openswan-2.4.11.tar.gz
cd openswan-2.4.11
Fourth compile the program...
make programs
Fifth install the program (Note you should uninstall your old
copy using apt first.)
sudo make install
The following howto further explains the basics of installing
source packages.
http://www.linux.org/docs/ldp/howto/Software-Building-HOWTO.html
Peter McGill
________________________________
From: Chris Thomas [mailto:cthomas at harkinsbuilders.com]
Sent: March 16, 2008 4:09 PM
To: petermcgill at goco.net; users at openswan.org
Subject: RE: [Openswan Users] Getting there....
I don't want to sound like a completely clueless noob,
but I've only ever installed/updated stuff in Linux with apt. It
appears that I am running OpenSwan 1:2.4.6+dfsg.2-1.1build2 but when I
attempt to update/upgrade, I am told that there is nothing to update. I
have the universe and multiverse repositories enabled but I'm guessing
they don't contain the most up to date version of OpenSwan. Does anyone
know a repository I could add to get it to work, or an alternative way
to update my OpenSwan install?
Thanks
-Chris
________________________________
From: Peter McGill [mailto:petermcgill at goco.net]
Sent: Fri 3/14/2008 5:00 PM
To: Chris Thomas; users at openswan.org
Subject: RE: [Openswan Users] Getting there....
It seems like your packets never get from Ubuntu back to
linksys. Try upgrading to the latest stable version,
2.4.11 I believe at http://openswan.org/code/
And since it didn't help, I suggest removing the
leftnexthop line.
Peter McGill
> -----Original Message-----
> From: Chris Thomas [
mailto:cthomas at harkinsbuilders.com]
> Sent: March 14, 2008 4:28 PM
> To: petermcgill at goco.net; users at openswan.org
> Subject: RE: [Openswan Users] Getting there....
>
> Dang. I made the change, restarted the server and
tried to
> establish the tunnel from the Linksys device again. I
got
> this in my logs, which appears to be the same as
before:
>
> Mar 14 16:19:13 gatekeeper pluto[4146]: packet from
> 66.225.x.x:500: ignoring unknown Vendor ID payload
> [4f4540454371496d7a684644]
> Mar 14 16:19:13 gatekeeper pluto[4146]: packet from
> 66.225.x.x:500: received Vendor ID payload [Dead Peer
Detection]
> Mar 14 16:19:13 gatekeeper pluto[4146]: packet from
> 66.225.x.x:500: received Vendor ID payload [RFC 3947]
> meth=110, but port floating is off
> Mar 14 16:19:13 gatekeeper pluto[4146]: packet from
> 66.225.x.x:500: received Vendor ID payload
> [draft-ietf-ipsec-nat-t-ike-03] meth=108, but port
floating is off
> Mar 14 16:19:13 gatekeeper pluto[4146]: packet from
> 66.225.x.x:500: received Vendor ID payload
> [draft-ietf-ipsec-nat-t-ike-02] meth=107, but port
floating is off
> Mar 14 16:19:13 gatekeeper pluto[4146]: packet from
> 66.225.x.x:500: ignoring Vendor ID payload
> [draft-ietf-ipsec-nat-t-ike-00]
> Mar 14 16:19:13 gatekeeper pluto[4146]:
"pax_square"[1]
> 66.225.x.x #1: responding to Main Mode from unknown
peer 66.225.x.x
> Mar 14 16:19:13 gatekeeper pluto[4146]:
"pax_square"[1]
> 66.225.x.x #1: transition from state STATE_MAIN_R0 to
state
> STATE_MAIN_R1
> Mar 14 16:19:13 gatekeeper pluto[4146]:
"pax_square"[1]
> 66.225.x.x #1: STATE_MAIN_R1: sent MR1, expecting MI2
> Mar 14 16:19:23 gatekeeper pluto[4146]: packet from
> 66.225.x.x:500: ignoring unknown Vendor ID payload
> [4f4540454371496d7a684644]
> Mar 14 16:19:23 gatekeeper pluto[4146]: packet from
> 66.225.x.x:500: received Vendor ID payload [Dead Peer
Detection]
> Mar 14 16:19:23 gatekeeper pluto[4146]: packet from
> 66.225.x.x:500: received Vendor ID payload [RFC 3947]
> meth=110, but port floating is off
> Mar 14 16:19:23 gatekeeper pluto[4146]: packet from
> 66.225.x.x:500: received Vendor ID payload
> [draft-ietf-ipsec-nat-t-ike-03] meth=108, but port
floating is off
> Mar 14 16:19:23 gatekeeper pluto[4146]: packet from
> 66.225.x.x:500: received Vendor ID payload
> [draft-ietf-ipsec-nat-t-ike-02] meth=107, but port
floating is off
> Mar 14 16:19:23 gatekeeper pluto[4146]: packet from
> 66.225.x.x:500: ignoring Vendor ID payload
> [draft-ietf-ipsec-nat-t-ike-00]
> Mar 14 16:19:23 gatekeeper pluto[4146]:
"pax_square"[1]
> 66.225.x.x #2: responding to Main Mode from unknown
peer 66.225.x.x
> Mar 14 16:19:23 gatekeeper pluto[4146]:
"pax_square"[1]
> 66.225.x.x #2: transition from state STATE_MAIN_R0 to
state
> STATE_MAIN_R1
> Mar 14 16:19:23 gatekeeper pluto[4146]:
"pax_square"[1]
> 66.225.x.x #2: STATE_MAIN_R1: sent MR1, expecting MI2
> Mar 14 16:19:43 gatekeeper pluto[4146]: packet from
> 66.225.x.x:500: ignoring unknown Vendor ID payload
> [4f4540454371496d7a684644]
> Mar 14 16:19:43 gatekeeper pluto[4146]: packet from
> 66.225.x.x:500: received Vendor ID payload [Dead Peer
Detection]
> Mar 14 16:19:43 gatekeeper pluto[4146]: packet from
> 66.225.x.x:500: received Vendor ID payload [RFC 3947]
> meth=110, but port floating is off
> Mar 14 16:19:43 gatekeeper pluto[4146]: packet from
> 66.225.x.x:500: received Vendor ID payload
> [draft-ietf-ipsec-nat-t-ike-03] meth=108, but port
floating is off
> Mar 14 16:19:43 gatekeeper pluto[4146]: packet from
> 66.225.x.x:500: received Vendor ID payload
> [draft-ietf-ipsec-nat-t-ike-02] meth=107, but port
floating is off
> Mar 14 16:19:43 gatekeeper pluto[4146]: packet from
> 66.225.x.x:500: ignoring Vendor ID payload
> [draft-ietf-ipsec-nat-t-ike-00]
> Mar 14 16:19:43 gatekeeper pluto[4146]:
"pax_square"[1]
> 66.225.x.x #3: responding to Main Mode from unknown
peer 66.225.x.x
> Mar 14 16:19:43 gatekeeper pluto[4146]:
"pax_square"[1]
> 66.225.x.x #3: transition from state STATE_MAIN_R0 to
state
> STATE_MAIN_R1
> Mar 14 16:19:43 gatekeeper pluto[4146]:
"pax_square"[1]
> 66.225.x.x #3: STATE_MAIN_R1: sent MR1, expecting MI2
> Mar 14 16:20:23 gatekeeper pluto[4146]:
"pax_square"[1]
> 66.225.x.x #1: max number of retransmissions (2)
reached STATE_MAIN_R1
> Mar 14 16:20:33 gatekeeper pluto[4146]:
"pax_square"[1]
> 66.225.x.x #2: max number of retransmissions (2)
reached STATE_MAIN_R1
> Mar 14 16:20:53 gatekeeper pluto[4146]:
"pax_square"[1]
> 66.225.x.x #3: max number of retransmissions (2)
reached STATE_MAIN_R1
> Mar 14 16:20:53 gatekeeper pluto[4146]:
"pax_square"[1]
> 66.225.x.x: deleting connection "pax_square" instance
with
> peer 66.225.x.x {isakmp=#0/ipsec=#0}
>
>
> Thanks
> -Chris
>
> -----Original Message-----
> From: Peter McGill [mailto:petermcgill at goco.net]
> Sent: Friday, March 14, 2008 3:54 PM
> To: Chris Thomas; users at openswan.org
> Subject: RE: [Openswan Users] Getting there....
>
> Hmm, I see that your lan (10.5..), not your wan
(66.225..)
> is your default route. Since leftnexthop defaults to
your
> default route, this might be your problem.
> I suggest setting the following in ipsec.conf
> conn central-site
> left=66.225.Ubuntu
> + leftnexthop=66.225.Cisco2950
> leftsubnet=192.168.0.0/24
> leftsourceip=192.168.0.20
>
>
> Peter McGill
>
>
> > -----Original Message-----
> > From: Chris Thomas [
mailto:cthomas at harkinsbuilders.com]
> > Sent: March 14, 2008 3:43 PM
> > To: petermcgill at goco.net; users at openswan.org
> > Subject: RE: [Openswan Users] Getting there....
> >
> > Good to hear my configs are OK, although I guess it
would
> > have been better if there was something wrong, so it
would be
> > easier to diagnose this.
> >
> > Yeah, my key is specified in that format and no, my
Cisco
> > router isn't NAT'ing or filtering any traffic. I'm
stumped.
> >
> > My ipsec barf is attached, if anyone out there wants
to
> > really help me out. I really do appreciate the
assistance
> > here. Hopefully I (we) can get this up and running
soon.
> >
> > Thanks very much, and have a great weekend.
> > -Chris
> >
> > From: Peter McGill [mailto:petermcgill at goco.net]
> > Sent: Friday, March 14, 2008 3:17 PM
> > To: Chris Thomas; users at openswan.org
> > Subject: RE: [Openswan Users] Getting there....
> >
> > I cannot find anything wrong with your setup.
> >
> > Yes your correct the Ubuntu firewall is
blocking/altering nothing.
> > (This is as it should be if you turned it off.)
> > When you get things working you should be able to
turn the firewall
> > back on, so long as it allows -p 50 and -p 17 -d 500
> inbound/outbound,
> > and excludes your remote subnet from NAT
MASQUERADE/SNAT.
> > iptables -t nat -I POSTROUTING -d 192.168.36.0/24 -j
ACCEPT
> >
> > The pictures cleared a few questions up.
> > Your linksys configs look just fine to me.
> >
> > You put your key in the Ubuntu in
/etc/ipsec.secrets, like
> this right?
> > 66.225.UbuntuIP : PSK "my secret text key"
> >
> > Your Cisco 2950 Series isn't by any chance firewall
filtering or
> > network address translating the IPSec traffic, or
trying to
> > intercept it?
> >
> > My only other suggestion is to do an ipsec barf and
post it's output
> > to the list, in an attachment.
> > Maybe someone else can see what your problem is.
> > Best to post in plain text, not everyone can read
html mail, and
> > the list digests strip out html mail to links...
which I
> never used to
> > bother to read, others might do the same.
> >
> > Peter McGill
> >
> >
> > ________________________________________
> > From: Chris Thomas [
mailto:cthomas at harkinsbuilders.com]
> > Sent: March 14, 2008 2:19 PM
> > To: users at openswan.org; petermcgill at goco.net
> > Subject: RE: [Openswan Users] Getting there....
> > Sorry about that. Here's the info:
> >
> > When I run the command you gave me below, I get
this:
> >
> > root at gatekeeper:/home/administrator# iptables -t
filter -L -n -v
> > Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
> > pkts bytes target prot opt in out
source
> > destination
> >
> > Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
> > pkts bytes target prot opt in out
source
> > destination
> >
> > Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
> > pkts bytes target prot opt in out
source
> > destination
> > root at gatekeeper:/home/administrator# iptables -t nat
-L -n -v
> > Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
> > pkts bytes target prot opt in out
source
> > destination
> >
> > Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
> > pkts bytes target prot opt in out
source
> > destination
> >
> > Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
> > pkts bytes target prot opt in out
source
> > destination
> > root at gatekeeper:/home/administrator# iptables -t
mangle -L -n -v
> > Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
> > pkts bytes target prot opt in out
source
> > destination
> >
> > Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
> > pkts bytes target prot opt in out
source
> > destination
> >
> > Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
> > pkts bytes target prot opt in out
source
> > destination
> >
> > Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
> > pkts bytes target prot opt in out
source
> > destination
> >
> > Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
> > pkts bytes target prot opt in out
source
> > destination
> > root at gatekeeper:/home/administrator#
> >
> > I guess this is telling me that nothing is blocked
and there
> > are no rules?
> >
> > I am connecting through the internet. My company is
actually
> > the ISP for other companies in our building and the
building
> > next to us, so I am using a separate IP space
outside of our
> > network to put the Linksys box and set up my test
remote
> > site. My Linux server is using an IP in the same
subnet as
> > my Check Point firewall, but it is going "around"
the
> > firewall. To help explain all of this, I have
thrown
> > together a quick diagram of everything. You can
access it
> > here:
> >
http://www.imagehosting.com/show.php/1630007_OpenSwanDiagram.j
> > pg.html. If I have left something out, please let
me know.
> >
> > The Ubuntu server and the Linksys router do indeed
have their
> > own external IP addresses. Here is my Linksys
config:
> >
http://www.imagehosting.com/show.php/1630052_linksyscfgPage1.j
> > pg.html and
> >
http://www.imagehosting.com/show.php/1630053_linksyscfgPage2.j
> > pg.html.
> >
> > I am hoping these pics look OK. If you need me to
provide
> > additional information, please let me know.
> >
> > Thanks again for all of your help.
> > -Chris
> >
> > From: Peter McGill [mailto:petermcgill at goco.net]
> > Sent: Friday, March 14, 2008 12:50 PM
> > To: Chris Thomas; users at openswan.org
> > Subject: RE: [Openswan Users] Getting there....
> >
> > Firewall was merely a place to check, not guaranteed
to be
> > the problem.
> > If you can get a console on your Ubuntu, you can
check
> > firewall with...
> > iptables -t filter -L -n -v
> > iptables -t nat -L -n -v
> > iptables -t mangle -L -n -v
> >
> > Are you connecting through the internet, or are you
testing
> > internally?
> > Do both the Ubuntu server and linksys router have
public
> > internet ip addresses?
> > (Not 172.16...172.32... or 10... or 192.168...,
etc...)
> > I cannot tell as you completely edited them from
your posts.
> > Next time try just masking the end like: 66.11.x.x
> > Testing internally sometimes needs different
settings than
> > production internet.
> >
> > Is linksys using DES or 3DES? Should be 3DES & MD5
matching
> > your openswan.
> > Can you show us your linksys ipsec configuration?
> >
> > Peter McGill
> >
> >
> > ________________________________________
> > From: users-bounces at openswan.org
> > [mailto:users-bounces at openswan.org] On Behalf Of
Chris Thomas
> > Sent: March 14, 2008 12:19 PM
> > To: users at openswan.org
> > Subject: Re: [Openswan Users] Getting there....
> > OK, I have hit a brick wall here and it's getting a
bit
> > frustrating. I have disabled the Linux firewall and
the
> > Shoreline firewall on my server and I'm still
getting the
> > same error below when I attempt to establish the
tunnel. Is
> > this absolutely positively due to a firewall issue
or is it
> > possible that I've got something else incorrectly
configured
> > somewhere? I am fairly new to Linux so I am
administering my
> > Ubuntu server with Webmin. That is what I am using
to verify
> > that the firewall(s) are turned off.
> >
> > I have also disabled the firewall on the Linksys box
and have
> > examined it's logs. This is what shows up after I
hit
> > "connect" to initiate the tunnel:
> >
> > Mar 14 09:33:34 - [VPN Log]: "pax_square" #2:
initiating Main Mode
> > Mar 14 09:33:43 - [VPN Log]: initiate on demand from
> > 192.168.36.100:0 to 192.168.0.30:0 proto=0 state:
fos_start
> > because: acquire
> > Mar 14 09:34:44 - [VPN Log]: "pax_square" #2: max
number of
> > retransmissions (2) reached STATE_MAIN_I1. No
response (or no
> > acceptable response) to our first IKE message
> > Mar 14 10:08:54 - [VPN Log]: "pax_square" #3:
initiating Main Mode
> > Mar 14 10:10:04 - [VPN Log]: "pax_square" #3: max
number of
> > retransmissions (2) reached STATE_MAIN_I1. No
response (or no
> > acceptable response) to our first IKE message
> > Mar 14 10:53:58 - [VPN Log]: "pax_square" #4:
initiating Main Mode
> > Mar 14 10:55:08 - [VPN Log]: "pax_square" #4: max
number of
> > retransmissions (2) reached STATE_MAIN_I1. No
response (or no
> > acceptable response) to our first IKE message
> >
> > If it helps, this is my ipsec.conf file on the
Ubuntu server
> > running OpenSwan:
> >
> > version 2.0 # conforms to second version
of
> > ipsec.conf specification
> >
> > config setup
> > interfaces=%defaultroute
> > uniqueids=yes
> >
> > include /etc/ipsec.d/examples/no_oe.conf
> >
> > conn pax_square
> > also=central-site
> > right=%any
> > rightid=@pax_square
> > rightsubnet=192.168.36.0/24
> > also=linksys-policy
> > auto=add
> >
> > conn central-site
> > left=(external IP of Linux server)
> > leftsubnet=192.168.0.0/24
> > leftsourceip=192.168.0.20
> >
> > conn linksys-policy
> > ike=3des-md5-modp1024
> > esp=3des-md5
> > compress=no
> > authby=secret
> >
> >
> > If it's definitely the firewall, I'll go back to the
drawing
> > board and see what I can see.
> >
> > As before, I appreciate the help and patience.
> > Thanks
> > -Chris
> >
> >
> >
> >
> > From: Peter McGill [mailto:petermcgill at goco.net]
> > Sent: Thursday, March 13, 2008 4:14 PM
> > To: Chris Thomas; users at openswan.org
> > Subject: RE: [Openswan Users] Getting there....
> >
> > Check your firewall(s) on both ends, and check the
linksys logs.
> > You must allow ipsec (and ipsec encapsulated
traffic) in your
> > firewalls.
> > protocol port description
> > 17 500 udp:isakmp
> > 50 esp
> > You must allow the above inbound and outbound on
your
> > internet interfaces.
> > You must also allow the subnet-to-subnet traffic.
> >
> > Peter McGill
> >
> >
> > ________________________________________
> > From: users-bounces at openswan.org
> > [mailto:users-bounces at openswan.org] On Behalf Of
Chris Thomas
> > Sent: March 13, 2008 4:06 PM
> > To: users at openswan.org
> > Subject: Re: [Openswan Users] Getting there....
> > OK, I changed my Linksys box to 1024 bit and I now
have this:
> >
> > Mar 13 16:01:48 gatekeeper pluto[11850]: packet from
(remote
> > site IP):500: ignoring unknown Vendor ID payload
> > [4f4540454371496d7a684644]
> > Mar 13 16:01:48 gatekeeper pluto[11850]: packet from
(remote
> > site IP):500: received Vendor ID payload [Dead Peer
Detection]
> > Mar 13 16:01:48 gatekeeper pluto[11850]: packet from
(remote
> > site IP):500: received Vendor ID payload [RFC 3947]
meth=110,
> > but port floating is off
> > Mar 13 16:01:48 gatekeeper pluto[11850]: packet from
(remote
> > site IP):500: received Vendor ID payload
> > [draft-ietf-ipsec-nat-t-ike-03] meth=108, but port
floating is off
> > Mar 13 16:01:48 gatekeeper pluto[11850]: packet from
(remote
> > site IP):500: received Vendor ID payload
> > [draft-ietf-ipsec-nat-t-ike-02] meth=107, but port
floating is off
> > Mar 13 16:01:48 gatekeeper pluto[11850]: packet from
(remote
> > site IP):500: ignoring Vendor ID payload
> > [draft-ietf-ipsec-nat-t-ike-00]
> > Mar 13 16:01:48 gatekeeper pluto[11850]:
"pax_square"[5]
> > (remote site IP) #9: responding to Main Mode from
unknown
> > peer (remote site IP)
> > Mar 13 16:01:48 gatekeeper pluto[11850]:
"pax_square"[5]
> > (remote site IP) #9: transition from state
STATE_MAIN_R0 to
> > state STATE_MAIN_R1
> > Mar 13 16:01:48 gatekeeper pluto[11850]:
"pax_square"[5]
> > (remote site IP) #9: STATE_MAIN_R1: sent MR1,
expecting MI2
> > Mar 13 16:02:28 gatekeeper pluto[11850]:
"pax_square"[5]
> > (remote site IP) #7: max number of retransmissions
(2)
> > reached STATE_MAIN_R1
> >
> > Thanks
> > -Chris
> >
> >
> > From: Peter McGill [mailto:petermcgill at goco.net]
> > Sent: Thursday, March 13, 2008 3:50 PM
> > To: Chris Thomas; users at openswan.org
> > Subject: RE: [Openswan Users] Getting there....
> >
> > There is a mismatch in your options, specifically
your
> DH/modp Group.
> > Diffie-Hellman (DH) Group needs to match openswan's
ike=*-modp????
> > I'm guessing that your linksys is sending
Diffie-Hellmen (DH)
> > Group 1 (768-bit).
> > Openswan will not allow this because it's too weak
of security.
> > If you have ike=3des-md5-modp1024 or
ike=aes-sha1-modp1024 as
> > I suggested,
> > then change your linksys to use Group 2 (1024-bit)
to match it.
> >
> > Peter McGill
> >
> >
> > ________________________________________
> > From: users-bounces at openswan.org
> > [mailto:users-bounces at openswan.org] On Behalf Of
Chris Thomas
> > Sent: March 13, 2008 3:40 PM
> > To: users at openswan.org
> > Subject: [Openswan Users] Getting there....
> > Hello again, everyone. I have configured my Linksys
box to
> > connect to my Ubuntu server running OpenSwan, but
when I
> > attempt to initiate the connection, my logs on the
server at
> > HQ get full of this stuff:
> >
> >
> > Mar 13 15:31:54 gatekeeper pluto[11850]: packet from
(remote
> > site external IP):500: ignoring unknown Vendor ID
payload
> > [4f4540454371496d7a684644]
> > Mar 13 15:31:54 gatekeeper pluto[11850]: packet from
(remote
> > site external IP):500: received Vendor ID payload
[Dead Peer
> > Detection]
> > Mar 13 15:31:54 gatekeeper pluto[11850]: packet from
(remote
> > site external IP):500: received Vendor ID payload
[RFC 3947]
> > meth=110, but port floating is off
> > Mar 13 15:31:54 gatekeeper pluto[11850]: packet from
(remote
> > site external IP):500: received Vendor ID payload
> > [draft-ietf-ipsec-nat-t-ike-03] meth=108, but port
floating is off
> > Mar 13 15:31:54 gatekeeper pluto[11850]: packet from
(remote
> > site external IP):500: received Vendor ID payload
> > [draft-ietf-ipsec-nat-t-ike-02] meth=107, but port
floating is off
> > Mar 13 15:31:54 gatekeeper pluto[11850]: packet from
(remote
> > site external IP):500: ignoring Vendor ID payload
> > [draft-ietf-ipsec-nat-t-ike-00]
> > Mar 13 15:31:54 gatekeeper pluto[11850]:
"pax_square"[1]
> > (remote site external IP) #1: responding to Main
Mode from
> > unknown peer (remote site external IP)
> > Mar 13 15:31:54 gatekeeper pluto[11850]:
"pax_square"[1]
> > (remote site external IP) #1: only
OAKLEY_GROUP_MODP1024 and
> > OAKLEY_GROUP_MODP1536 supported. Attribute
OAKLEY_GROUP_DESCRIPTION
> > Mar 13 15:31:54 gatekeeper pluto[11850]:
"pax_square"[1]
> > (remote site external IP) #1: no acceptable Oakley
Transform
> > Mar 13 15:31:54 gatekeeper pluto[11850]:
"pax_square"[1]
> > (remote site external IP) #1: sending notification
> > NO_PROPOSAL_CHOSEN to (remote site external IP):500
> > Mar 13 15:31:54 gatekeeper pluto[11850]:
"pax_square"[1]
> > (remote site external IP): deleting connection
"pax_square"
> > instance with peer (remote site external IP)
{isakmp=#0/ipsec=#0}
> >
> > I am assuming that it has something to do with the
Preshared
> > key that I am using, but I am not too sure how to go
about
> > fixing it. I do not want to be a nuisance, but can
anyone
> > give me a (another) push in the right direction?
> >
> > I appreciate your patience.
> > -Chris
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20080317/8f12bf8f/attachment-0001.html
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ipsecbarf_3_17_08.txt
Url: http://lists.openswan.org/pipermail/users/attachments/20080317/8f12bf8f/attachment-0001.txt
More information about the Users
mailing list