[ previous ] [ next ] [ threads ]
 
 From:  Robert Rich <rrich at gstisecurity dot com>
 To:  Manuel Kasper <mk at neon1 dot net>
 Cc:  Angus Jordan <angus dot jordan at gmail dot com>, m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] IPSEC Site-to-site VPN firewall
 Date:  Thu, 27 Jan 2005 16:45:59 -0500
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 
with it!

Thanks...

Bob





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.
>
>Greets,
>
>Manuel
>
>---------------------------------------------------------------------
>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
>
>  
>