What you're sewing is the proxy doing what you've told it to do. When the pc on
the lan side (any vlan) requests a connection to a server the proxy makes that
request on its behalf and returns the packets sent back from that request. In
order for that to happen on a secured connection the proxy must set up a secure
connection to he remote server (or in your case other interface server) as well
as a separate secure connection between the proxy and the originating client
pc. Doing it any other way requires either passing the traffic directly through
the firewall or breaking the secure connection. This is one of the
consequences of doing NAT. I'm guessing the main complaint is that the firewall
cert isn't trusted and triggers browsers.
div Original message /divdivFrom: Ryan Clough
ryan.clo...@dsic.com /divdivDate:12/12/2014 13:58 (GMT-05:00)
/divdivTo: pfSense Support and Discussion Mailing List
list@lists.pfsense.org /divdivSubject: Re: [pfSense] Traffic routing
issue /divdiv
/divOliver,
I apologize, I should have been more clear. The problem is exhibited from all
VLANs if I force the use of the web server's public IP. I only just discovered
it while testing the guest WiFi on the restricted VLAN.
To answer your questions:
The pfSense router is not aware of any VLANs, we use a layer 3 switch that
sits just inside from the pfSense router that routes traffic that must exit
the LAN to the pfSense router.
I have attached screen shots of my port forward rule and the auto-generated
firewall rule.
Thank you very much for your help.
Ryan Clough
Information Systems
Decision Sciences International Corporation
On Fri, Dec 12, 2014 at 9:15 AM, Oliver Hansen oliver.han...@gmail.com
wrote:What does the allow rule on the restricted vlan and the NAT rule look
like?
On Dec 11, 2014 11:24 PM, quot;Ryan Cloughquot; ryan.clo...@dsic.com
wrote:
I am hoping that one of you out there can assist me with this rather
interesting problem I am having. Let me set the stage.
I am running the latest stable version of pfSense:
2.1.5-RELEASE (amd64)
built on Mon Aug 25 07:44:45 EDT 2014
FreeBSD 8.3-RELEASE-p16
I am running transparent Squid and Squidguard, and all IP ranges have access
to use the proxy.
I have two WAN connections, each with a handful of public IPs. I have created
an IP alias virtual IP of one of my public IPs on WAN1, which is used to NAT
to a web server.
We have an internal DNS server that resolves the domain name of a web server
to the local LAN IP address. So, all computers on unrestricted VLANs access
the web server without having to hit the pfSense router at all. This works as
expected and the valid certificate is served and the web page loads.
We have one restricted VLAN that is used for guest WiFi access and this VLAN
is assigned external DNS servers and therefore resolve the domain name to the
public IP.
Now my problem. When connected to the guest WiFi on the restricted VLAN and
attempting to access the web server on its public IP, which is assigned to a
virtual IP on WAN1, I get served the certificate from the pfSense router. I
can tell that this is the pfSense self-signed certificate because of the
details of the certificate displayed in the warning. I also get this behavior
if I force a computer on an unrestricted VLAN, using the hosts file, to
resolve the host name of the web server to its public IP.
What is going on here? I can provide more information if needed. Thank you for
your time.
Ryan Clough
Information Systems
Decision Sciences International Corporation
This email and its contents are confidential. If you are not the intended
recipient, please do not disclose or use the information within this email or
its attachments. If you have received this email in error, please report the
error to the sender by return email and delete this communication from your
records.
___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list
___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list
This email and its contents are confidential. If you are not the intended
recipient, please do not disclose or use the information within this email or
its attachments. If you have received this email in error, please report the
error to the sender by return email and delete this communication from your
records.___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list
