# Conforms to second version of ipsec.conf specification:
version	2.0

config setup
	# plutodebug = "all", "none" or a combation from below:
	# "raw crypt parsing emitting control klips pfkey natt x509 private":
	#plutodebug=control
		# This is the default, so it's not needed:
		#interfaces=%defaultroute

conn Intranet
	# We use aggresive mode just as the LVC (Lucent VPN Client for
	# Windows) does (as per what we sniffed under Windows):
	aggrmode=yes
	# We use the transform we know the LVG (Lucent VPN Gateway)
	# accepts (as per what we sniffed under Windows):
	ike=3des-sha1-modp1024
		# This is not necesary even though it's specified
		# as mandatory for this kinda config:
		#esp=3des-sha1
	# We now set the lifetimes as high as possible (in fact, LVC sets them
	# to 240hs, as seen sniffing its negotiation under Windows):
	keylife=24h
	ikelifetime=24h
		# This is the default value so we don't need to set it:
		#type=tunnel
	# We need this as the LVG is configured for PSK (Pre-Shared Key):
	authby=secret
	# and we also need to disable PFS:
	pfs=no
	# *********** These are the paremeters for our own, local PC:
	left=%defaultroute
	# We need this as the LVG is configured for XAUTH (OpenSwan will
	# request us our username and password when bringing up the connection):
	leftxauthclient=yes
	# We need to get the config from the LVG, I don't know how LVC handles
	# this but I guess it's done by means of the 3 "ISAKMP Informational"
	# messages the LVC and the LVG exchange before the ones for Quick Mode.
	# Therefore, we configure our side to pull the configuration with below
	# two lines; we'll then have seven "ISAKMP Transaction (Config Mode)"
	# packets exchanged between us and the LVG that don't show up with the
	# LVC:
	leftmodecfgclient=yes
	modecfgpull=yes
	# We configure the same user ID the LVC does (as per what we sniffed
	# under Windows). Other values don't work so don't change it:
	leftid="!@#$%"
	# *********** These are the parameters for the remote end, the LVG:
	right=AAA.BBB.CCC.DDD
	# If we want all the traffic sent out of our PC pushed into the tunnel,
	# we should configure this:
	#rightsubnet=0.0.0.0/0
	# but as I just want to reach AAA.0.0.0/8, I configure this one only:
	rightsubnet=AAA.0.0.0/8
	# Later releases of OSW support multiple subnets at once (this is 2.4.13):
	# rightsubnets="A.0.0.0/8 A.B.0.0/16 A.b.0.0/13"
	auto=add

# Disable Opportunistic Encryption:
include /etc/ipsec/ipsec.d/examples/no_oe.conf

# Now, as the IP address for the LVG (AAA.BBB.CCC.DDD) falls into the same
# subnet (AAA.0.0.0/8) we reach through it, its IP has to be "excluded" from
# that subnet (this also applies if configuring "rightsubnet=0.0.0.0/0" above).
# So, we need to tell OSW (OpenSwan) to forward traffic to the LVG directly
# out of our PC to our PC's default gateway:
conn passthrough
	left=%defaultroute
	leftnexthop=%defaultroute
	right=AAA.BBB.CCC.DDD
		# This is not needed but if it were, it should be:
		#rightsubnet=AAA.BBB.CCC.DDD/32
	type=passthrough
	authby=never
	auto=route
	# As per this three lines above, OSW will setup a route for the LVG
	# to our default gateway. It can be checked with "route -n" just after
	# we start or restart IPSec on our PC (with /etc/init.d/ipsec restart)