[Openswan Users] Cannot establish VPN connection

Ted Kaczmarek tedkaz at optonline.net
Wed Dec 29 07:35:07 CET 2004


On Tue, 2004-12-28 at 23:21 -0500, Thomas Simmons wrote:
> Ted Kaczmarek wrote:
> > On Mon, 2004-12-27 at 16:30 -0500, Thomas Simmons wrote:
> > 
> >>I'm trying to establish a vpn between two locations, and having some 
> >>problems. I'm calling the local location left and the remote right. The 
> >>right location is running smoothwall and smoothwall reports that 
> >>everything is good on it's end. Ipsec is running.
> >>
> >>Right Setup
> >>
> >>/etc/ipsec.conf
> >>config setup
> >>        interfaces=%defaultroute
> >>        klipsdebug=none
> >>        plutodebug=none
> >>        plutoload=%search
> >>        plutostart=%search
> >>        plutowait=no
> >>        uniqueids=yes
> >>
> >>conn %default
> >>        keyingtries=0
> >>
> >>conn net
> >>        left=68.0.1.1
> >>        leftsubnet=10.10.65.0/24
> >>        leftnexthop=%defaultroute
> >>        right=68.230.1.1
> >>        rightsubnet=192.168.1.0/24
> >>        rightnexthop=%defaultroute
> >>        compress=no
> >>        auto=start
> >>
> >>/etc/ipsec.secrets
> >>68.0.1.1 68.230.1.1 : PSK "pass"
> >>
> >>The left location is running debian sarge with openswan. This is also 
> >>the router/firewall for this network. The debian kernel already has 
> >>ipsec support so no patches should be required.
> >>Also, this setup does not like the plutowait, plutostart, and plutoload 
> >>options under the config section of the ipsec.conf. According to
> >>openswan this has been removed so that's expected. Here are the config 
> >>files for the left location.
> >>
> >>Left Setup
> >>
> >>/etc/ipsec.conf
> >>config setup
> >>        interfaces=%defaultroute
> >>        klipsdebug=none
> >>        plutodebug=none
> >>        uniqueids=yes
> >>
> >>conn %default
> >>        keyingtries=0
> >>
> >>conn net
> >>        left=68.0.1.1
> >>        leftsubnet=10.10.65.0/24
> >>        leftnexthop=%defaultroute
> >>        right=68.230.1.1
> >>        rightsubnet=192.168.1.0/24
> >>        rightnexthop=%defaultroute
> >>        compress=no
> >>        auto=start
> >>
> >>/etc/ipsec.secrets
> >>68.0.1.1 68.230.1.1 : PSK "pass"
> >>
> >>output of "route" with ipsec stopped.
> >>
> >>Destination     Gateway         Genmask         Flags Metric Ref    Use 
> >>Iface
> >>localnet        *               255.255.255.0   U     0      0        0 eth0
> >>10.10.66.0      *               255.255.255.0   U     0      0        0 eth1
> >>68.0.16.0       *               255.255.240.0   U     0      0        0 eth2
> >>default         ip68-0-16-1.hr. 0.0.0.0         UG    0      0        0 eth2
> >>
> >>
> >>to ensure that there are no firewall problems i reset iptables with this 
> >>script
> >>
> >>#!/bin/sh
> >>
> >>IPTCMD="/sbin/iptables"
> >>PUB="eth2"
> >>PRV="eth0"
> >>DMZ="eth1"
> >>
> >>
> >>$IPTCMD -F
> >>$IPTCMD -X
> >>$IPTCMD -F -t nat
> >>$IPTCMD -P INPUT ACCEPT
> >>$IPTCMD -P OUTPUT ACCEPT
> >>$IPTCMD -P FORWARD ACCEPT
> >>$IPTCMD -t nat -A POSTROUTING -o $PUB -d ! 192.168.1.0/24 -j MASQUERADE
> >>
> >>Here's the problem. When I start ipsec (/etc/init.d/ipsec start) I lose 
> >>all network connectivity to and from this system. Now the output of
> >>"route" looks like this.
> >>
> >> 
> >>Destination     Gateway         Genmask         Flags Metric Ref    Use 
> >>Iface
> >>localnet        *               255.255.255.0   U     0      0        0 eth0
> >>192.168.1.0     68.0.16.1       255.255.255.0   UG    0      0        0 eth2
> >>10.10.66.0      *               255.255.255.0   U     0      0        0 eth1
> >>68.0.16.0       *               255.255.240.0   U     0      0        0 eth2
> >>default         68.0.16.1       128.0.0.0       UG    0      0        0 eth2
> >>128.0.0.0       68.0.16.1       128.0.0.0       UG    0      0        0 eth2
> >>default         68.0.16.1       0.0.0.0         UG    0      0        0 eth2
> >>
> >>Syslog shows
> >>
> >>Dec 27 10:50:47 lightning ipsec_setup: ...Openswan IPsec stopped
> >>Dec 27 10:50:47 lightning ipsec_setup: Stopping Openswan IPsec...
> >>Dec 27 10:50:47 lightning ipsec_setup: KLIPS ipsec0 on eth2 
> >>68.0.1.1/255.255.240.0 broadcast 68.0.31.255
> >>Dec 27 10:50:47 lightning ipsec_setup: ...Openswan IPsec started
> >>Dec 27 10:50:47 lightning ipsec_setup: Starting Openswan IPsec 
> >>U2.2.0/K2.4.27...
> >>Dec 27 10:50:49 lightning ipsec__plutorun: 104 "net" #1: STATE_MAIN_I1: 
> >>initiate
> >>Dec 27 10:50:49 lightning ipsec__plutorun: ...could not start conn "net"
> >>
> >>I have read elsewhere that changing interfaces=%defaultroute to 
> >>interfaces="ipsec0=eth2" in ipsec.conf may fix some problems. When I do this
> >>I do not lose the network connection to the system but the vpn 
> >>connection is not made and syslog reports:
> >>
> >>
> >>
> >>Dec 27 10:45:12 lightning ipsec_setup: KLIPS ipsec0 on eth2 
> >>68.0.1.1/255.255.240.0 broadcast 68.0.31.255
> >>Dec 27 10:45:12 lightning ipsec_setup: ...Openswan IPsec started
> >>Dec 27 10:45:12 lightning ipsec_setup: Starting Openswan IPsec 
> >>U2.2.0/K2.4.27...
> >>Dec 27 10:45:12 lightning ipsec__plutorun: ipsec_auto: fatal error in 
> >>"net": %defaultroute requested but not known
> >>Dec 27 10:45:12 lightning ipsec__plutorun: ipsec_auto: fatal error in 
> >>"packetdefault": %defaultroute requested but not known
> >>Dec 27 10:45:13 lightning ipsec__plutorun: ipsec_auto: fatal error in 
> >>"block": %defaultroute requested but not known
> >>Dec 27 10:45:13 lightning ipsec__plutorun: ipsec_auto: fatal error in 
> >>"clear-or-private": %defaultroute requested but not known
> >>Dec 27 10:45:13 lightning ipsec__plutorun: ipsec_auto: fatal error in 
> >>"clear": %defaultroute requested but not known
> >>Dec 27 10:45:13 lightning ipsec__plutorun: ipsec_auto: fatal error in 
> >>"private-or-clear": %defaultroute requested but not known
> >>Dec 27 10:45:13 lightning ipsec__plutorun: ipsec_auto: fatal error in 
> >>"private": %defaultroute requested but not known
> >>Dec 27 10:45:13 lightning ipsec__plutorun: 021 no connection named 
> >>"packetdefault"
> >>Dec 27 10:45:13 lightning ipsec__plutorun: ...could not route conn 
> >>"packetdefault"
> >>Dec 27 10:45:13 lightning ipsec__plutorun: 021 no connection named "block"
> >>Dec 27 10:45:13 lightning ipsec__plutorun: ...could not route conn "block"
> >>Dec 27 10:45:13 lightning ipsec__plutorun: 021 no connection named 
> >>"clear-or-private"
> >>Dec 27 10:45:13 lightning ipsec__plutorun: ...could not route conn 
> >>"clear-or-private"
> >>Dec 27 10:45:13 lightning ipsec__plutorun: 021 no connection named "clear"
> >>Dec 27 10:45:13 lightning ipsec__plutorun: ...could not route conn "clear"
> >>Dec 27 10:45:13 lightning ipsec__plutorun: 021 no connection named 
> >>"private-or-clear"
> >>Dec 27 10:45:13 lightning ipsec__plutorun: ...could not route conn 
> >>"private-or-clear"
> >>Dec 27 10:45:13 lightning ipsec__plutorun: 021 no connection named "private"
> >>Dec 27 10:45:13 lightning ipsec__plutorun: ...could not route conn "private"
> >>syslog ipsec0=eth2
> >>
> >>Output of "route"
> >>
> >>Destination     Gateway         Genmask         Flags Metric Ref    Use 
> >>Iface
> >>localnet        *               255.255.255.0   U     0      0        0 eth0
> >>10.10.66.0      *               255.255.255.0   U     0      0        0 eth1
> >>68.0.16.0       *               255.255.240.0   U     0      0        0 eth2
> >>default         ip68-0-16-1.hr. 0.0.0.0         UG    0      0        0 eth2
> >>
> >>Does anyone have any thoughts as to what might be going on?
> >>
> >>
> >>
> >>_______________________________________________
> > 
> > rightnexthop=%defaultroute
> > Have no idea how your box can possibly figure out what the remotes
> > gatway is, you probably don't need this as well, remove it.
> > 
> > tcpdump can be most helpful. Just because smoothwall says everything is
> > ok, does not mean it is configured properly :-), and make sure it is
> > doing 3des. Also try matching smoothwalls proposal on Openswan.
> > esp=3des-sha-96
> > or
> > esp=3des-md5-96
> > 
> > I have excellent success by running tcpdump and doing an
> > "ipsec auto --add net"
> > "ipsec auto --up net"
> > 
> > If I see it stuck in phase 1 it is typically a key mismatch, if its
> > stuck in phase 2 it typically a policy mis match.
> > 
> > Both peers have to agree on everything.
> > 
> > Ted
> > 
> > 
> > 
> > 
> I ran "tcpdump -i eth2 tcp" (eth2 is the external interface), and on a 
> second term ran "/etc/init.d/ipsec start ;  ipsec auto --add net ; ipsec 
> auto --up net", and no activity was reported by tcpdump. Like I say, I 
> lose connection to this box when starting ipsec. I also removed 
> "rightnexthop=%defaultroute". I setup a smoothwall box here and 
> successfully established the VPN connection to the remote smoothwall, so 
> now I can be sure the problem is on my end. I set up openswan on a 
> debian box at work today and attempted to connect to the remote network. 
> This resulted in the same error as I get here at home, loss of network 
> connection. I think I will try to set it up using an older version of 
> openswan, perhaps on slackware or redhat. Any other suggestions?
> 
> Thomas
> 
> 
You should not be losing network connection on a ipsec start/stop unless
you are going through an ipsec interface to get their. I would resolve
that first before doing anything else. 

Also, ipsec barf may provide you with some answers.

I use version 2.1.5 on FC1 with excellent results for PSK setups to
Checkpoint, Cisco's, Netscreens and Watchguard


Ted



More information about the Users mailing list