[Openswan Users] Routing problem

[Paul Wouters]

On Wed, 7 Feb 2007, Ludovic wrote:

> conn %default
>        keyingtries=0
>        disablearrivalcheck=no

> and now when tunnel is "activated" like I said before:
>
> version 2
>
> config setup
>        interfaces=%defaultroute
>        klipsdebug=none
>        plutodebug=none
>        uniqueids=yes
>        nat_traversal=yes
>        virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!192.168.6.0/255.255.255.0,%v4:!192.168.2.0/255.255.255.0,%v4:!192.168.5.0/255.255.255.0
>
> conn %default
>        keyingtries=0
>        disablearrivalcheck=no
>
> conn testrsa
>        left=192.168.9.193
>        leftnexthop=%defaultroute
>        leftsubnet=192.168.6.0/255.255.255.0
>        leftcert=/var/ipcop/certs/hostcert.pem
>        right=192.168.9.235
>        rightcert=/var/ipcop/certs/testrsacert.pem
>        dpddelay=30
>        dpdtimeout=120
>        dpdaction=clear
>        authby=rsasig
>        auto=add

I guess "activated" means the tunnel is added to the configuration file,
though it does not yell me if the connection is actually loaded. I assume
it is, else itwould not make a difference.

> I've got a C program which run ipsec:
>
> system("/usr/sbin/ipsec tncfg --clear >/dev/null");

Not sure why that would be needed.

> system("/etc/rc.d/ipsec restart >/dev/null");
>
> With openswan 1.0.7, i don't have this problem, i always can reach the
> router interface but with openswan 2.4.7, i have the problem i have
> described in the previous mail.

Try adding to your config %default section:

	failureshunt=passthrough

> I hope that you have understand what i mean by "enabled" and "disabled".
> Do you have any new idea now?

Yes. But I think this is not what you really want. If you define a tunnel
for your LAN and the remote a.b.c.0 network, and the tunnel is not up,
you in general DON'T want to sent out packets in cleartext. For one, the
packets might not be routable without a tunnel (eg 192.168.*.*). Second,
the data might require privacy, so it MUST be send encrypted. Third, any
malicious hacker could cause you to "fallback" on unencrypted by sabotaging
the tunnel somehow (eg cause ESP packets or IKE packets to be dropped).

Why do you want to allow these unencrypted packets, for which you normally
have an IPsec tunne defined?

Paul
-- 
Building and integrating Virtual Private Networks with Openswan:
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155