[Openswan Users] wrong eroutes with auto=route in version 2.4.7

[Matthias Haas]

> Paul Wouters schrieb:
>> On Fri, 24 Nov 2006, Matthias Haas wrote:
>>
>>
>>> I am currently facing a problem with subnet-subnet connection, that are
>>> create with auto=route at the responders side. Remote side is a dynamic
>>> IP.
>>> The subnet-subnet connection is created with two 24bit subnets. In case
>>> there is no valid sa, as the remote site is down there is already a
>>> eroute
>>> installed for these two networks in trap state. So far everything is
>>> ok.
>>> But as soon as a connection should be established from the responders
>>> network to the remote net an there is no valid connection established a
>>> new eroute arises that has two singlehost subnets installed that
>>> reflect
>>> the sender and recipient of this connection. Then this connection is
>>> set
>>> to hold state as there is a packet that should be sent out.
>>> The problem that comes up to this is that there will never be a sa even
>>> if
>>> the remote side connects that can handle this eroute. Therefore
>>> connections that apply to this invalid eroute will never be able to
>>> communicate despite there is a valid sa then, that fullfills the need
>>> of
>>> the complete two subnets.
>>> As soon as I apply auto=add to these connections at the reponders site
>>> everything works fine.
>>>
>>> Is this a bug or a feature?
>>>
>>
>> You should use auto=start or auto=add. Why are you using auto=route ?
>>
>> Paul
>>
>>
> Why not, what I achive with this is that I can already see possible
> routes. Or did I get the intention of this command wrong?
>
> Matthias
>
The bis advantage with route is that I have an additional security option.
Imagine that route would work and I have the responder which does not have
any currently setup tunnels. Despite of that the clients in the network
behind this responder do not know anything about the down tunnels (as vpn
is transparent to these hosts) and want to send packets to a host behind
an  another network of an initiator.
No imagine the tunnels are setup with the add method. This would lead to
the fact the the packets would be sent out to the defaultroute device as
long as there is no tunnel setup which can take these packets. The
firewall is now in the need to function correctly and to do a plausibility
check to all packages that want to leave the responder, whether they
should be in a tunnel or not.
In case I use the route method, packages that are sent by a client over
the none existing vpn tunnel are taken to the ipsec device. As the ipsec
device does not have a valid tunnel setup it now should drop the packet.
This is in my opinion a very handy way to assure even more that packages
that should leave the device only over a vpn tunnel are not sent out
unencrypted.

In addition to that the current situation with route entries leads to a
kind of denial of service method to the vpn system is I can setup eroutes
to all kinds of ip adresses that will never match an SA and therefore lead
to the situation that adresses tha have these wrong eroutes will be
unreachable.


In case I am wrong with this, please let me know.