Re: Making FreeS/WAN harder to use, INTENTIONALLY.

"D. Hugh Redelmeier" <[email protected]> Sat, 1 Mar 2003 22:58:17 -0500 (EST)
Newsgroups gmane.network.freeswan.devel,gmane.network.freeswan.user
Message-ID <[email protected]>
What's going on behind the scenes?  Perhaps an explanation would show
a logic to this behaviour.

Remember that a (conventional, old fashioned) route is chosen base
only upon the destination address of the packet.  An eroute (a FreeS/WAN
mechanism) is chosen based upon the source and destination address of
the packet.

FreeS/WAN will install a default route using the ipsecN device to
support the default policy group.  This lets FreeS/WAN capture all
outbound packets and process them.

Processing will be controlled by eroutes.  eroutes are managed by
Pluto.

If the sysadmin doesn't arrange for an eroute for the clients behind
the Security Gateway there will be no eroute that applies to them.  So
a packet outbound from a client subnet will get the default behaviour.
The default behaviour is controlled by the packetdefault option of
ipsec.config's "config setup" section -- "drop", by default.  This
seems like the right default behaviour for security.

If there is a client subnet, the sysadmin must specify what is to be
done with packets from those clients.

- it is possible (but scary) to specify that packets without an eroute
  are to be passed "packetdefault=pass"

- it is better to add appropriate conns (passthrough or otherwise) for
  the subnet(s) behind the gateway.

  Here's how you could add a new policy group for a subnet protected
  by this machine:

	# this goes in /etc/ipsec.conf
	conn client-private-or-clear
		leftsubnet=10.9.8.0/7
		also=private-or-clear

	# this goes in /etc/ipsec.d/policies/client-private-or-clear
	# Alternatively:
	# 	cd /etc/ipsec.d/policies
	#	ln -s private-or-clear client-private-or-clear
	0.0.0.0/0

  If you really just wish to pass stuff from the clients, base your
  new conn on the implicit "clear" conn rather than
  "private-or-clear".

  Of course you could have more complicated policies for the subnet.

This all makes sense to me, but then it would, wouldn't it?

Hugh Redelmeier
[email protected]  voice: +1 416 482-8253