Go to System/Advanced/Adminaccess then disable the "WebGUI redirect".
That is still receiving traffic on *:80 and redirecting to the webgui port..
Bob McClure Jr schreef op 20-4-2015 om 19:09:
On Mon, Apr 20, 2015 at 09:52:20AM -0400, ED Fochler wrote:
You may be getting overruled by the self protecting hidden rules of pfsesne.
System -> Advanced -> [Admin Access] -> Anti-lockout
That sounds like what I want, but the text for that option gives a
dire warning that it could lock me out if I don't have the right
firewall rule in place, but I'm unclear what rule I should use. I
have all the rules that are associated with the WAN->OPT1 NAT
forwards.
Alternatively, Services -> DNS Forwarder -> host overrides … could
point internal machines to the DMZ address instead of the outside
address when they lookup the name.
I didn't see that option. Bear in mind that I'm not using the pfsense
DHCP or DNS. I'm using dnsmasq on the LAN.
Since I've determined that I can get to the DMZ via the internal IP, I
may just toss in the towel and list all the web sites in my local
DNS. Ugh. That's so unclean.
It is possible that you are just trying to do too many things with a
single IP address to safely make them all happen. Disabling
PFSense’s idiot-proofing features may be your best path forward.
Some sage said that any system that keeps you from doing something
stupid will also keep you from doing something clever.
And do your link testing with wget or checklink. Web browsers often
cache a http_redirect in a kind of permanent manner, not even look
at the server for changes. wget doesn’t have enough of a brain to
suffer from such brain damage.
ED.
On 2015, Apr 19, at 11:13 PM, Bob McClure Jr <[email protected]> wrote:
On Sun, Apr 19, 2015 at 07:51:24PM -0700, Kenward Vaughan wrote:
On 04/19/2015 06:37 PM, Bob McClure Jr wrote:
...
Now if anyone has a clue about this apparent Firefox brain damage, I'm
all ears. I just restarted Firefox, and it's still hosed.
Well, I take back what I took back, that is, Firefox brain damage. I
just discovered that two other applications fail the same way. The
other affected apps are wget and checklink. The latter is a Perl link
checker from W3C that uses the LWP::RobotUA, LWP::UserAgent, and
Net::HTTP::Methods modules. I can work around the wget problem, but a
checklink failure is a show-stopper. We use that to check for broken
links in new and modified web pages. Those two apps are run from the
file server on the LAN to the web sites on the DMZ (OPT1). The
Firefox problem is on my workstation on the LAN. Both of those are
Linux CentOS machines. Interestingly enough, my wife's Win7 Firefox,
also on the LAN, does not have a problem.
I'm lobbing this back into pfsense's court.
My first check is to hide the default user profile (make a new one
to use without copying over anything from the old), and see if that
takes care of things. If it does, then selectively pull back in
Good Things (passwords, etc).
Thanks for the hint, but it appears not to be (just) a Firefox
problem.
Kenward
--
In a completely rational society, the best of us would aspire to be
_teachers_ and the rest of us would have to settle for something less,
because passing civilization along from one generation to the next
ought to be the highest honor and the highest responsibility anyone
could have. - Lee Iacocca
Cheers,
--
Bob McClure, Jr.
Cheers,
_______________________________________________
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold
