[Openswan Users] No ipsec0 interfaces in routeing table
ted leslie
tleslie at tcn.net
Wed Jul 5 16:32:04 CEST 2006
when you attempt your test conenction,
are you doing that from the openswan server or from one of the hosts on the
private-lan behind the VPN gateway?
explain what exactly you are doing to test this connection.
you might also want to post your barf
ipsec barf
as it has more info
-tl
On Wed, 05 Jul 2006 14:59:55 -0400
jack <jrlowry376 at adelphia.net> wrote:
> 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
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>
More information about the Users
mailing list