From owner-freebsd-questions@FreeBSD.ORG Thu Jun 18 18:38:25 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B79E61065672 for ; Thu, 18 Jun 2009 18:38:25 +0000 (UTC) (envelope-from tajudd@gmail.com) Received: from mail-qy0-f173.google.com (mail-qy0-f173.google.com [209.85.221.173]) by mx1.freebsd.org (Postfix) with ESMTP id 72DE08FC17 for ; Thu, 18 Jun 2009 18:38:25 +0000 (UTC) (envelope-from tajudd@gmail.com) Received: by qyk3 with SMTP id 3so1659443qyk.3 for ; Thu, 18 Jun 2009 11:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ymebGakNMDHvOek7s5q6aff4HxOAWLyeYKBSzWQ/PI4=; b=dH/eufpHFDWH1TJV24VuJYJ1k64pU/oC81ruOADVOedxx0UvN5D/2lcPIP+LA4qqjE 5lRBcoZmy4kDSTPxvQAQOFagEJGcSqsyRNIdqU6MPcf1HdOZ/ZR2NNbmhytAVn++0TI5 0QMdoB8Sl2bh4cvTAvAWcqGmcDm7EP09WF3nc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kgZ2lmO5Q7d9C4Mtalm1Cq4GO9OETcTMZxYxe04eEAT8JUJt+I4Q/rAdyVJ9Vbn6fq 7RTTGp2GsspfPDL8Q4NAbKIFWDgwvvO8yWYI3KC3q1syZGTicK+98vpk61xHbEMg+Tu2 rXYEFdFJ3Qk8j4Hc6+KDKAxvYcKVvkqDdJTMs= MIME-Version: 1.0 Received: by 10.220.71.10 with SMTP id f10mr2005331vcj.13.1245350304292; Thu, 18 Jun 2009 11:38:24 -0700 (PDT) In-Reply-To: <17838240D9A5544AAA5FF95F8D5203160638ABE2@ad-exh01.adhost.lan> References: <17838240D9A5544AAA5FF95F8D5203160638ABE2@ad-exh01.adhost.lan> Date: Thu, 18 Jun 2009 12:38:24 -0600 Message-ID: From: Tim Judd To: Mike Sweetser - Adhost Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org Subject: Re: PF Routing to VPN Device X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 18:38:26 -0000 On 6/17/09, Mike Sweetser - Adhost wrote: > Hello, > > We have a network with a VPN device sitting beside a PF server, both > connected to an internal network. > > PF Server: 10.1.4.1 > VPN Device: 10.1.4.200 > > The VPNs are set up for 10.1.1.0/24 and 10.1.2.0/24, so any traffic to > these networks should be routed to 10.1.4.200. We've set up routes on > the PF server as such. > > We've set up the following rules: > > block in log > pass in on $int_if route-to 10.1.4.200 from 10.1.4.0/24 to { 10.1.1.0/24 > 10.1.2.0/24) > > However, the block in log is catching the return traffic. From pflog > when somebody on the VPN (10.1.2.105) tries to connect to 10.1.4.25 on > port 80: > > 000000 rule 28/0(match): block in on bge1: 10.1.4.25.80 > > 10.1.2.105.3558: [|tcp] > > If we remove the block in log, the traffic works. > > What are we missing? > > Thanks, > Mike Mike, I know the typical firewall rules that are googleable are one of two basic starting policies.. -- 1. block in all pass out all -- 2. block all They've become a headache to me to configure a firewall and I now start with this base. In this example, fxp0 is facing the Internet, and xl0 is facing the trusted network. -- 3. block in on fxp0 all pass out This adds the benefit that VPN connections, TUNs, GIFs, and all other ethernet devices aren't blindly evaluated to a simple block in rule, rather it's just the fxp0 interface public Internet traffic that is being blocked, while TUNs, GIFs, and the like are exempt from that rule entry line. Might you try by editing your rules to just block your public IP firewall interface? Good luck.