Date: Wed, 23 Mar 2011 07:21:36 +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.1103230712030.14052@mail.time-domain.co.uk> In-Reply-To: <4D886EA2.2070000@my.gd> References: <Pine.GSO.4.64.1103220830580.4247@mail.time-domain.co.uk> <4D886EA2.2070000@my.gd>
next in thread | previous in thread | raw e-mail | index | archive | help
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? >> 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. > Possible issues to investigate: > > 1/ lack of a default gateway on your sonicwall This is definitely configured correctly. > 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. >> 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). Thanks for your prompt reply. Andy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1103230712030.14052>