Manuel Kasper wrote:
 >
 >The problem with filtering IPsec traffic is not that the decrypted
 >packets don't pass through ipfilter - they can be made to do that.
 >Actually, if IPSEC_FILTERGIF is set in the kernel config, IPsec
 >tunnel traffic passes through the filter twice - once when it comes
 >in as ESP packets (where it doesn't make much sense to filter yet
 >though), and again as decrypted packets on the same interface
 >(usually WAN). Unfortunately, AFAIK there's no way to distinguish
 >between successfully decrypted ESP packets and regular unencrypted
 >packets once they hit ipfilter, so you might actually permit
 >undesirable unencrypted packets as well. This is the reason why
 >IPSEC_FILTERGIF is not set in m0n0wall kernels.
 >Greets,
 >
 >Manuel

I was searching for a way to filter decrypted IPSec traffic in m0n0wall 
and found the above post on the list. (in the archive: 
http://m0n0.ch/wall/list/?action=show_msg&actionargs[]=130&actionargs[]=54)

Just evaluating m0n0wall to replace a Lancom 1611 (there are a lot of 
pros on both sides...)
Well, Lancom has the ability to filter decrypted traffic and I don't 
want to miss that.

Has it ever been discussed to use the "out" keyword of ipfilter to get a 
hand on the decrypted traffic?
If I remember the packet flow correctly it is:

	ipfilter->ipnat->ipsec->kernel/routing

for incoming traffic on each interface.

With filter_rules_ipsec_generate() you let in encrypted traffic. When 
the default pass out filter for lanif was left out, one had the ability 
to filter for the decrypted traffic leaving the lan interface.
Of course this would made rule setting more complicated but could be 
done in sth like advanced mode.
This would not affect RFC1918 blocking and spoof check on WAN.

Sorry if this already has been discussed, but I found nothing in the 
archives.

Regards

-Bjoern Euler