[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec-tools-devel
Subject:    [Ipsec-tools-devel] Adding support scripts
From:       Philip Prindeville <philipp_subx () redfish-solutions ! com>
Date:       2010-09-22 1:53:54
Message-ID: 4C9961B2.4020601 () redfish-solutions ! com
[Download RAW message or body]

  I'd like to spend some time and contribute some ipsec-tools wrappers for doing \
various things, and include this in a future release (as scripts/ or contrib/), or \
possibly as an add-on tarball.

We had network-to-network (peer) IPsec tunnelling with PSK's and fixed addresses \
working pretty well, but that's the easiest case.

I'd like to add support for self-signed certificates using openssl to generate them.

Then add support for dynamic IP addresses so that one end-point can be on an ISP with \
non-static addresses.

Lastly, I'd like to add support for the following scenario:

The VPN concentrator in this case is on a public network, but has a directly attached \
subnet.  Say 192.168.1.0/24.

There are devices on that subnet, and maybe they are DHCP served, with DHCP addresses \
coming out of the range 128-191.

In my scenario, VPN clients would connect and get /32 addresses out of the \
192.168.1.192-223 range, and the VPN concentrator would proxy-ARP for them.

Further, using iptables, we'd mangle the apparent input interface of the decapsulated \
ESP (cleartext) packets so that they even looked (to applications and services and \
other iptables rules running on the VPN concentrator) like they were on the same \
physical subnet as the other machines on 192.168.1.x.

Does this seem reasonable?

It might require adding an additional scripting hook in Phase 2 so that the script \
might, for instance, add a permanent local ARP entry for the IPv4 address allocated \
to the remote end (i.e what happens on the *other* end when mode_cfg is used).

I was going to file 3 bugs to track requisite changes:

(1) add setkey support for netlink_xfrm and conditional compilation
(2) modify mode_cfg code in racoon to call script on *server* side, with \
INTERNAL_ADDR4 (etc) being exported into the script's environment as CLIENT_ADDR4, \
etc. (3) add phase_2 script support

waiting to get a trac account assigned to me before I do that.

If anyone wants to discuss this with me, please contact me offline (unless you think \
that this is of general interest, or that the changes that are required to the \
existing source to achieve this warrant group discussion).

I'd probably first integrate this into OpenWRT, and when it's working solidly, send \
the scripts upstream to ipsec-tools and the config hooks (to integrate the scripts \
themselves) to openwrt.

Thanks,

-Philip


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Ipsec-tools-devel mailing list
Ipsec-tools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel


[prev in list] [next in list] [prev in thread] [next in thread]