From owner-freebsd-pf@FreeBSD.ORG Wed Mar 23 10:11:30 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E49721065670 for ; Wed, 23 Mar 2011 10:11:30 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7BF6C8FC15 for ; Wed, 23 Mar 2011 10:11:27 +0000 (UTC) Received: by bwz12 with SMTP id 12so7562558bwz.13 for ; Wed, 23 Mar 2011 03:11:27 -0700 (PDT) Received: by 10.204.126.131 with SMTP id c3mr6151314bks.104.1300875087119; Wed, 23 Mar 2011 03:11:27 -0700 (PDT) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id v21sm5790847bkt.11.2011.03.23.03.11.25 (version=SSLv3 cipher=OTHER); Wed, 23 Mar 2011 03:11:26 -0700 (PDT) Message-ID: <4D89C74C.7010502@my.gd> Date: Wed, 23 Mar 2011 11:11:24 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: andy thomas References: <4D886EA2.2070000@my.gd> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: PF port forward problem with Sonicwall VPN (revisited) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 10:11:31 -0000 On 3/23/11 8:21 AM, andy thomas wrote: > On Tue, 22 Mar 2011, Damien Fleuriot wrote: > >> On 3/22/11 9:58 AM, andy thomas wrote: >>> ---------- Forwarded message ---------- >>> Date: Fri, 28 Jan 2011 08:49:27 +0000 (GMT) >>> From: andy thomas >>> To: freebsd-pf@freebsd.org >>> Subject: PF port forward problem with Sonicwall VPN >>> >>> I'm maintaining some OpenBSD-based firewalls and have been really >>> stumped with a problem when trying to add a Sonicwall VPN appliance >>> behind the firewall, and thought I'd ask here for help. >>> >>> The Sonicwall device uses SSL on port 443 for it's external VPN traffic >>> and listens on other ports for internal LAN traffic and it uses a single >>> network interface for this. On our installation, there is a webmail >>> server behind the firewall listening on port 443 and the existing PF >>> rule for this is (abbreviated for clarity): >>> >>> ext_if="vr0" >>> int_if="vr1" >>> >>> webmail="192.168.30.14" >>> >>> rdr pass log on $ext_if proto tcp from any to $ext_if port 443 -> >>> $webmail port 443 >>> >> >> Ok >> >> >>> This works fine so as external port 443 is already in use for webmail, I >>> decided to use external port 444 for the Sonicwall and added these two >>> extra rules: >>> >>> sonicwall="192.168.30.28" >>> >>> rdr pass log on $ext_if proto tcp from any to $ext_if port 444 -> >>> $sonicwall port 443 >>> >> >> This rule rewrites the destination IP address so that it is now the >> sonicwall's instead of your PF's public IP. >> This rule rewrites the destination TCP port so that it is now port 443 >> instead of the original port 444. >> >> Take good note that the source address remains unchanged so your >> sonicwall needs to know a route back to the client. > > Presuably using a NAT rule rather than RDR will provide this return path? > A NAT rule will not provide any better route, however it will replace the *source* IP address with your PF's . Before RDR: 88.190.13.60:28052 -> 212.163.10.24:444 After RDR: 88.190.13.60:28052 -> 192.168.30.28:443 Before NAT: 88.190.13.60:28052 -> 212.163.10.24:444 After NAT: 192.168.30.21:61209 -> 192.168.30.28:444 Notice how the destination port remained unchanged ! So you will have to either use both a RDR and a NAT rule, or just change the HTTPS port on your sonicwall to 444 to only use a NAT rule. NAT explained: http://www.openbsd.org/faq/pf/nat.html#works >>> However, the Sonicwall cannot be accessed from the external port 444 >>> although it can be accessed internallt on port 443 of course. I have >>> tested this rule by changing it to point to the webmail server like >>> this: >>> >>> rdr pass log on $ext_if proto tcp from any to $ext_if port 444 -> >>> $webmail port 443 >>> >> >> Seeing you can access your webmail just fine on port 444 but not the >> sonicwall clearly shows the problem is with the sonicwall, not PF. > > This is what I thought initially but after I found I could not ping the > external interface from the Sonicwall, it started to look like a PF > problem. > Well, you want to investigate a bit then. Set your rules on the PF to log passed/blocked packets. Then run: tcpdump -nei pflog0 ip and host 192.168.30.28 Then from the sonicwall try to ping the external interface. You'll see if your packet is blocked and by what rule number. Issue pfctl -vvsr to dump your firewall rules and check what rule blocked your packet. >> Possible issues to investigate: >> >> 1/ lack of a default gateway on your sonicwall > > This is definitely configured correctly. > Can you reach external hosts from the sonicwall, for example 88.190.222.254 ? >> 2/ misconfigured security rules on your sonicwall not allowing the >> traffic. > > No security rules have been set up, only the basic network configuration > has been carried out so far to get the device onto the network. > But perhaps there are default values that would block things ? >>> and this works fine as I can access webmail on port 444. But why can't I >>> access the Sonicwall on port 444? Does anyone know if the Sonicwall uses >>> additional ports or has anyone got this device to with with a PF-based >>> firewall? >>> >>> Thanks in advance for any suggestions, >>> >> >> I would advise you change your RDR rule to a NAT rule, so that traffic >> will be seen coming from the PF's interface (choose which) and the >> sonicwall will have a direct connection with this network. > > I'm not an expert on PF so will need to read up on this - is it simply a > case or replacing 'RDR' with 'NAT' in the existing rule? I must also be > careful not to make any changes that may affect anything else on the > internal network as this would be catastrophic for the organisation > concerned (it's a remote site). > See if you can change the sonicwall's HTTPS port to 444, then set up a NAT rule like this: nat pass on $extif inet proto tcp from any to $extif port 444 -> ($internal_if) This should do the trick nicely. Later on, you'll be able to refine the nat rule a bit to only allow trusted IPs to connect to your sonicwall.