PS. This isn't a pf limitation. It was a FreeBSD limitation, for pf to filter the traffic, it has to be on an interface. OpenBSD "fixed" that with the enc(4) interface, all decrypted IPSec traffic appears to come in on that interface allowing us to block it _before_ it reaches the firewall routing table. The before part is important because once it hits the firewall routing table it can incorrectly get to daemons running on the firewall w/out inspection. Obviously all of this really depends on how you define your tunnels - if any of the firewall IPs are in the scope of the tunnel, yer screwed.
--Bill On 10/8/06, Bill Marquette <[EMAIL PROTECTED]> wrote:
On 10/8/06, Kristofer Kiik <[EMAIL PROTECTED]> wrote: > On 10/8/06, SDamron <[EMAIL PROTECTED]> wrote: > > All traffic coming in through a tunnel is encrypted. The only way to > > limit this traffic is to terminate it and pass it through some kinda > > of other firewall, or IDS. > > It is encrypted when it enters the pfSense. It is decrypted in pfSense > and leaves unencrypted through LAN interface. Can't it be firewalled > leaving pfSense to LAN? Technically yes. But we considered that and decided not to do a half ass job with it. Filtering outbound from pfSense may protect your network, but leaves your firewall (and it's management interface) open to attack. Exposing this filtering gives you a false sense of security that I'm not willing to hand out. Disabling filtering altogether until it can be done right was a better choice - it makes it apparent that you should do your IPSec on a different box than you do the firewalling on (for now). Unfortunately the enc(4) code came too late for 1.0 which has been in feature freeze for the better part of a year while we fix bugs in the current features. --Bill
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
