[Openswan Users] Cannot establish VPN connection

Thomas Simmons twsnnva at cox.net
Tue Dec 28 23:21:30 CET 2004


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




More information about the Users mailing list