[Openswan Users] Getting there....
Chris Thomas
cthomas at harkinsbuilders.com
Fri Mar 14 16:27:30 EDT 2008
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
>
More information about the Users
mailing list