[Openswan Users] No ipsec0 interfaces in routeing table

jack jrlowry376 at adelphia.net
Wed Jul 5 15:59:55 CEST 2006

ted leslie wrote:
> i have never actually used the --route option, i'll have to see what it does.
> maybe you should skip it, maybe its breaking something.
> you should probably post your configs, and network topo here so people can examine it.
> When ever i have had the problem you just discribed it was because i was doing a 
> SNAT, and thus it didnt match the policy of the vpn and routed it non-vpn.
> you should also check that you are not simply blocking yourself with a iptables rule.
> remember about port 4500  NAT-T if you are traversing.
> if your iptables has logs hooked up, just  dmesg  to see the rejects.
> you say your clearing iptables, but   "iptables -L" to be sure.
> you can do a tcpdump and see if its routing the packets to your default gw non-ESP'd, or
> where ever else it might.
> do you have multiple interfaces, maybe that is factoring in.
> -tl
> On Wed, 05 Jul 2006 13:38:17 -0400
> jack <jrlowry376 at adelphia.net> wrote:
>> ted leslie wrote:
>>> unless you put the Klips patch in, the 2.6 kernel version of freeswan/openswan
>>> don't have ipsecX interfaces
>>> thats not to say that this is your problem, if yuor doing a DNAT and SNAT translation
>>> in your setup , then it could be.
>>> -tl
>>> On Tue, 04 Jul 2006 11:06:51 -0400
>>> Jack Lowry <jrlowry376 at adelphia.net> wrote:
>>>> I've been using freeswan 1.99 for years and I've decided
>>>> to upgrade to openswan 2.4.6 on kernel 2.6.17.
>>>> I fairly certain I'm getting connected to my peer
>>>> (a checkpoint 4.1 firewall) as ipsec auto --status gives
>>>> me a message "500 STATE_MAIN_I4 (ISAKMP SA established)"
>>>> among other things (but nothing that sicks out a problem.
>>>> I can't connect to a host on the remote end.
>>>> On thing that I find odd is the routing table does not include
>>>> routes for the network behind the peer that I am trying to connect
>>>> to using ipsec0 as the interface.
>> I'm not doing DNAT or SNAT, the IP  addresses in use on both side don't 
>> conflict, and both sides know
>> how to route to the other sides private IP address space.
>> I tried to bring up the tunnel after having done a iptables -F to clear 
>> any firewall rules. Same results tunnel comes up but no esp traffic.
>> I guess the question is "How does the Openswan 2.4.6rc1/linux 2.6.17 
>> network stack know to encrypt a specific
>> combination of source and  destination packets?"
>> I think I have a functional understanding of how freeswan 1.99(based on 
>> traffic entering a IPSEC interface based on a systems routing table) and 
>> Checkpoint 4.1 (based on matching up encryption domains and rules) work. 
>> I clearly don't understand how it's supposed to happen with Openswan 
>> 2.4.6rc1/linux 2.6.17 maybe I'm missing a step in openswan startup.
>> I do:
>> ipsec setup --start
>> ipsec auto --add rfd # add the remote site I'm trying to get working
>> ipsec auto --up rfd # initate the tunnel negotiate keys SA and stuff.
>> ipsec auto --route rfd # I'm guessing this is supposed to tell the 
>> kernel what to encrypt the traffic.
A network diagram is here http://home.adelphia.net/~jrlowry376/topology.gif

and Ipsec.conf is

# /etc/ipsec.conf - Openswan IPsec configuration file
# RCSID $Id: ipsec.conf.in,v 2005/11/14 20:10:27 paul Exp $

# This file:  /usr/local/share/doc/openswan/ipsec.conf-sample
# Manual:     ipsec.conf.5

version 2.0     # conforms to second version of ipsec.conf specification

# basic configuration
config setup
        # plutodebug / klipsdebug = "all", "none" or a combation from below:
        # "raw crypt parsing emitting control klips pfkey natt x509 private"
        # eg:
        #       interfaces="ipsec0=eth0"
        # Only enable klipsdebug=all if you are a developer
        # NAT-TRAVERSAL support, see README.NAT-Traversal
        # nat_traversal=yes
        # virtual_private=%v4:,%v4:,%4:

# Add connections here

# sample VPN connection
#conn sample
#               # Left security gateway, subnet behind it, nexthop 
toward right.
#               left=
#               leftsubnet=
#               leftnexthop=
#               # Right security gateway, subnet behind it, nexthop 
toward left.
#               right=
#               rightsubnet=
#               rightnexthop=
#               # To authorize this connection, but not actually start it,
#               # at startup, uncomment this.
#               #auto=start

conn rfd

#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf

I am pretty sure ipsec.secrets is okay as I get the tunnel up

More information about the Users mailing list