[Openswan Users] Getting there....

Chris Thomas cthomas at harkinsbuilders.com
Fri Mar 14 12:18:46 EDT 2008


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/20080314/0e29468f/attachment-0001.html 


More information about the Users mailing list