Date: Wed, 23 Mar 2011 11:11:24 +0100 From: Damien Fleuriot <ml@my.gd> To: andy thomas <andy@time-domain.co.uk> Cc: freebsd-pf@freebsd.org Subject: Re: PF port forward problem with Sonicwall VPN (revisited) Message-ID: <4D89C74C.7010502@my.gd> In-Reply-To: <Pine.GSO.4.64.1103230712030.14052@mail.time-domain.co.uk> References: <Pine.GSO.4.64.1103220830580.4247@mail.time-domain.co.uk> <4D886EA2.2070000@my.gd> <Pine.GSO.4.64.1103230712030.14052@mail.time-domain.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <andy@time-domain.co.uk> >>> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D89C74C.7010502>