Date: Fri, 25 Mar 2011 06:15:05 +0000 (GMT) From: andy thomas <andy@time-domain.co.uk> To: Damien Fleuriot <ml@my.gd> Cc: freebsd-pf@freebsd.org Subject: Re: PF port forward problem with Sonicwall VPN (revisited) Message-ID: <Pine.GSO.4.64.1103250557360.27212@mail.time-domain.co.uk> In-Reply-To: <4D89C74C.7010502@my.gd> 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> <4D89C74C.7010502@my.gd>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 23 Mar 2011, Damien Fleuriot wrote: > > > 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. Thank you for all your helpful suggestions - I am collecting the Sonicwall VPN device from the remote location next Wednesday and will try the above rules and suggestions with an identical spare firewall I have here. Once it's all working here I'll take the Sonicwall back to the customer's site and update the firewall rules there and make sure they work. I'm not sure the Sonicwall can be configured to use port 444 - its configuration options are quite limited and accessible only through a web interface (which uses frames, meaning I can't use the lynx text browser installed on the firewall to configure it remotely). I'll post my progress with this here next week. Thanks again for your help, it is much appreciated. Andy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1103250557360.27212>