[Openswan Users] Getting there....
Chris Thomas
cthomas at harkinsbuilders.com
Sun Mar 16 16:08:51 EDT 2008
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/20080316/f64661b2/attachment-0001.html
More information about the Users
mailing list