Re: typical IPsec-based VPNs incl. modecfg vs. DHCP

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 In your previous mail you wrote:

   I have a question about the IPsec SPD.. I had worked a long time back on
   Linux freeswan.. What I do remember from that is that each tunnel on the
   outbound side was represented as a virtual interface like ipsec0. So the
   ipsec engine would insert routes in the routing tables on setup ( I wasn't
   doing IKE) for these entries leading to my question in the first place
   because I got the impression that IP routing is necessary and the most
   typical demultiplexing method to insert packets into different tunnels.. i.e
   somehow SPD policies map to a routing entry which would mean the destination
   address being the sole criterion for tunnel selection. 
   
=> first routes are not enough because they work only on destinations.
Second there is nothing about the nature (i.e., interface or not) of
IPsec tunnels in RFCs.

   But I guess this is not what RFC2401 says and it leaves it open for various
   implementations to have different SPD methodology.. Can you update me on
   what other ways SPD entries are looked up for tunnel selection.

=> usually SPD entries are standard filters (i.e., same than for QoS)
on the 5-tuple (addresses, protocol, ports) with some restrictions
for forwarded packets (because deep parts of the 5-tuple can be hard
or impossible to get, for instance for fragments).

   I am more
   interested in the source address or some source parameter being included as
   the criteria for tunnel selection or an SPD interface that lets me make
   policies based on the source of the packets.. Is it possible?

=> yes. For instance if you'd like to encode the SPD for a mobile VPN,
a source=<my VPN address> destination=<everything> protocol=<any> ports=<any>
will do the job: any packet using the VPN address (i.e., not the local address)
will be encapsulated.

Thanks

Francis.Dupont@enst-bretagne.fr