>Okay, clear it is.
>But then, one question about the example placed here:
>http://www.netbsd.org/Documentation/network/ipsec/#sample_vpn
>Traffic from 20.0.0.1 to 20.0.0.2 and vice versa is being encrypted this
>way. Internally they use the 10 address space and no natting is done
>here. But are these machines from the internal network supposed to reach
>the internet and receive traffic back (not using ipsec) cause in that
>case natting needs to be done for the internal addresses.
>Or is natting only done in case traffic is destined/comming from addresses
>other then 20.0.0.1(2)?
>Or was this example just for a leased line between those networks?

	in the above example, outbound IPsec operation will be performed only
	for packets between 10.0.1.0/24 -> 10.0.2.0/24.  so if someone in
	10.0.1.0/24 tries to contact global address (like 30.0.0.1)
	IPsec will do nothing about the packet.  if you want NAT to
	take place, that's your choice.

	10.0.1.0/24 -> 10.0.1.0/24		IPsec takes place
	10.0.1.0/24 -> some other address	IPsec won't take place
		(if you do NAT, that's fine go ahead)

	of course there can be other places to look at.  for example,
	with the current code, you want to carefully check if ipfilter or
	IPsec looks at the packet first, to make your configuration work right.
	PR 11844 suggests to run ipfilter first in ip_input, but there are
	configuration/people favors to run ipsec first.

	what we have to do are:
	1. integrate IPsec policy lookup filter and ipfilter, into single
	   packet classifier.  also we may want to integrate ALTQ classifier
	   too.  if we have more than one classifier/filter/whatever we have
	   ordering problem, so make a single unified classifier.
	   (NOTE: IPsec has socket policy as well so we need to think about
	   ordering between socket policy and filter-like policy)
	2. make the packet classifier to understand tunnelled packets well.
	   tunnelled packets may visit classifier more than once (like ip_input
	   was invoked again), and we would like to run different rules on each
	   invocation.  to do this we need to keep encapsulation/decapsulation
	   history for each of the mbuf and make classifier aware of the
	   history table.

itojun