WebGUI access rule not workign for some reason.



  • Ok, just fired up a new pfsense (2.1.2 running on ESXi 5.5). But for some strange reason i get a behaviour I have not seen before.

    As there are only m2m-systems on the LAN side, I did the following.

    1. Install 2.2.1 (d'oh..)
    2. Set the WAN to 46.22.120.130/28, set my gateway
    3. Enabled shell
    4. pfctl -d
    5. logon to web gui
    6. Created a WAN rule that passes 443 and 22 (source any, dest WAN Address)

    but, this does still not allow access to the webGUI from WAN. I have a sneaking feeling I am missing something silly. I must be, since this is not rocket science and I've done it before.

    In my log i see that the traffic is indeed dropped. But why?



  • 1. Install 2.2.1 (d'oh..)

    That does not exist - I guess you installed 2.1.2 or maybe 2.2-ALPHA.

    Are you accessing directly to port 443? If you are going to port 80 by default, then I guess you should open port 80 also, then it can redirect to HTTPS on 443.



  • @phil.davis:

    1. Install 2.2.1 (d'oh..)

    That does not exist - I guess you installed 2.1.2 or maybe 2.2-ALPHA.

    Are you accessing directly to port 443? If you are going to port 80 by default, then I guess you should open port 80 also, then it can redirect to HTTPS on 443.

    2.1.2 of course. Sorry.

    Nope straight to 443, but even with an additional rule for 80 and trying redirect I get the same issue .

    As I said , this hasn't been a problem in the past.



  • I have been having similar issues with one I upgraded and 1 that was a clean install.

    I have a feeling there is some kind of bug which is preventing the web interface from functioning.



  • @kapara:

    I have been having similar issues with one I upgraded and 1 that was a clean install.

    I have a feeling there is some kind of bug which is preventing the web interface from functioning.

    This is interesting. I just did the following.

    Test 1:
    1. Set up an "exact copy" of the environemnt in my at-home vmware
    2. did the same procedure as in prod (Described in my original post)
    3. Same result, unable to create an access rule that allowed WebGUI-access from WAN.

    Test 2:
    1. Set up an "exact copy" of the environemnt in my at-home vmware
    2. Did it the "traditional way" and connected a client to the lan side, and created the very same WAN rule from there.
    3. Tadaaaa Success.

    Test 3:
    Repeat of "test 1" but with Pfsense 2.0.3…. Success, no problem creating a WAN-access rule.



  • What exactly are you seeing getting blocked? What does your firewall rule look like?

    @kapara:

    I have a feeling there is some kind of bug which is preventing the web interface from functioning.

    There isn't.



  • @cmb:

    What exactly are you seeing getting blocked? What does your firewall rule look like?

    Hello!

    I tried both

    Source Any, Dest WAN Address, Proto TCP, Port HTTPS

    Soruce Any, Dest Any, Proto TCP, Port HTTPS

    Soruce Any, Dest [Explicitly set IP of firewall WAN], Proto TCP, Port HTTPS

    Source Any, Dest Any, Proto Any, Port Any  (This failed as well).

    However, the strange fact was that rules to/from machines behind the box fired as expected.
    I dont have the logs any more, since I scrapped/reinstalled the box.

    In the end i ended up taking my lab machine (According to Test 2 in my previous post) and copying it to the prod environment. Still working :)



  • Found another one strange bug. During logging in webconfigurator stopped responding. I've used putty to restart web configurator - did not fixed the problem, rebooted pfsense and found in logs that firewall blocked traffic to 443 port, right before restarting pfsense and this is with anti-lockout rule created automatically. So I've created another one rule based on firewall log. You can see it on attached images.
    10.0.77.1 is LAN address. 10.0.77.3 machine that wants to access webgui on https.






  • click the red X in the log, what rule is blocking it? Your LAN rules there would not block that if it were initiated on LAN.



  • The rule that triggered this action is:

    @39 block drop in log quick proto tcp from webconfiguratorlockout:0to (self:7) port = https label "webConfiguratorlockout"</webconfiguratorlockout:0>



  • You tried logging in too many times with a bad username/password. Go to Diag>Tables, pick that table, delete your IP.



  • There is no my IP in table (deleted automatically?). I always use autocomplete in browser and this was first try, when it blocked in the morning. But… I have changed admin's password one day before.
    By the way the full story is that I have changed password and created new certs when 2.1.2 was released, same day. Yesterday I found that putty can not log me in with new password, but webgui can and WinSCP too. The password was "@\Q·Io)?©QOA BV2H?yi?o«R?", KeePass generated. I did not have time to research why putty can not correctly send this password to pfsense, so I decided simply to  change it to something like "xS0A46Uj4VM0UgDBGgxX". When I tried before to  log in with putty too many times then sshlockout triggered and I have disabled firewall completely via webgui issuing "pfctl -d" command and then changed password, enabled firewall and cleared sshlockout table.
    I have succefully logged then with new password via ssh and webgui and updated it in firefox autocomplete. Then I went to sleep and on next morning the first attempt to log in with webgui failed with standard reply from browser something like "Firefox can't find the server". I have restarted Webgui via putty shell - this did not help, so I rebooted pf and got access to webgui immediately after reboot, without clearing anything.
    I think that for some reason webConfiguratorlockout triggered but it must not. May be sometimes it does not detect password change.