[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