[Openswan Users] No ipsec0 interfaces in routeing table
ted leslie
tleslie at tcn.net
Wed Jul 5 17:54:57 CEST 2006
and you tcpdump from the VPN point?
and the packets show a source of 192.168.3.0/24
and a target/dest on 172.16.24.0/21
if it does, then it should match the rule and be routed,
i was thinking you were testing from the VPN machine, and thus you would need to have SNAT'd
I guess you have routing turned on? as that gateway routes non-vpn packets just fine?
you probably want to post your
"netstat -rn"
and
"ifconfig -a"
-tl
On Wed, 05 Jul 2006 16:11:50 -0400
jack <jrlowry376 at adelphia.net> wrote:
> I test from a linux box on the private lan behind the openswan VPN gateway.
> I use ssh and connect to 172.16.25.8.
>
> I'll submit a barf after I get home and switch gateways.
>
> ted leslie wrote:
> > 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
> >>
> >>
> > _______________________________________________
> > 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=28315
> >
> _______________________________________________
> 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