Does this same criteria apply to traffic shaping? I.e. if we enable
IPSEC_FILTERGIF, can we apply traffic shaping rules to VPN tunnel
traffic as well? Applying filters to tunnels is a bonus, but doing
shaping _and_ filtering makes it all the more sweet.
Regarding the spoof potential, the primary exposure would likely be 'one
hit kills', where a single packet (such as malformed DNS reply or ICMP
packet) does the deed. If any two way communication is required, the
reply traffic would be routed back over the tunnel to the remote side
(right?), who would in all likelihood summarily drop the response.
I'd say it's worth an alternate build (or checkbox!!!) if we can play
Manuel Kasper wrote:
>On 27.01.2005 06:22 -0800, Angus Jordan wrote:
>>I can't say for sure that this is directly related to the fact that
>>ipfilter and ipfw are used in conjunction. In theory, the afore
>>mentioned scenario should work.
>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.
>>I know there is a way (according to the FreeBSD handbook) to put all
>>this IPSEC traffic through a virtual network interface (gif0, gif1,
>>etc). Similar to how the PPTP server works with the ng0, ng1
>>interfaces. If this was how things were done then traffic could
>>easily be filtered.
>I haven't looked into using gif interfaces in conjunction with IPsec
>tunnels, but if anyone can propose a secure (resistant to spoofing)
>and interoperable (with other IPsec implementations) solution, that
>would be very interesting.
>To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch