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 <a...@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
_______________________________________________
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
