[Openswan Users] No ipsec0 interfaces in routeing table

[jack]

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 1.15.2.2 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
        interfaces=%defaultroute
        # plutodebug / klipsdebug = "all", "none" or a combation from below:
        # "raw crypt parsing emitting control klips pfkey natt x509 private"
        # eg:
        plutodebug="all"
        #       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:10.0.0.0/8,%v4:192.168.0.0/16,%4:172.16.0.0/12

# Add connections here

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

conn rfd
        keylife=60m
        ikelifetime=480m
        rekey=yes
        type=tunnel
        left=69.174.129.33
        leftsubnet=192.168.3.0/24
        leftnexthop=69.174.129.1
        right=206.107.146.8
        rightsubnet=172.16.24.0/21
        rightnexthop=206.107.146.1
        keyexchange=ike
        compress=no
        authby=secret
        auth=esp
        pfs=yes

#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