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 few clarifications regarding usage of IPsec for VPNs. I have been
   even going through the thread of Modecfg vs. DHCP and seem a little confused
   regarding the functionality.
    
   - This particular debate of Modecfg vs. DHCP relates only to remote access
   scenarios or does it extend to address management for site-to-site VPNs. I
   would distinguish the 2 using the following definitions- One tunnel per
   machine and address to be given out (whichever way - modecfg or DHCP) at
   tunnel setup time would be Remote Access. Site-to-site would be that tunnel
   is setup apriori between 2 gateways and both sides would be different
   private subnets. Users in site-to-site VPNs get addresses typically from
   their own subnet's DHCP servers. Please correct me if i am wrong..
    
=> this is less and less true because someone can use a home-to-office
VPN from a or a few home networks. This is not very common with IPv4
(not enough addresses -> NATs :-) but should be very common with IPv6
where a home user can get between a /64 and a /48.

   - Is it also possible that in a site-to-site VPN the address allocation is
   handled by only one of the private networks (subnets). ie. DHCP is tunneled
   over to this network from all other private networks and responses tunneled
   back? Is it a typical setup? Is the discussion of modecfg vs. DHCP relevant
   in this case? I assume that their might be some routing issues in this setup
   for tunneling the responses back to the DHCP requesters through the right
   tunnels. Maybe some state maintenance at the gateways. 
    
=> for IPv6 a prefix allocation/assignment should be used (DHPCv6-lite)
for instance.

   - Typical IPsec implementations. Most of them are bump in the stack
   (software ones).. Am I correct? Does it mean that IP routing is the only way
   to direct traffic into the right tunnels? i.e destination address based. Are
   their any implementations that do not follow this paradigm. Any pointers
   would be helpful. 
    
=> I disagree: at the initiator side the only needed thing is a SPD
with some entries to disable infinite recursive protection and an entry
for everything else. The SPD is used before routing so the routes are
the same in general with and without the VPN.
At the responder/SG side, the only problem is the reverse routing.
Proxy ARP/ND works well for VPNs to hosts but for VPNs to subnetworks
only reverse route injection does the job.

Regards

Francis.Dupont@enst-bretagne.fr