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