Captive portal stopped working after 1.2.2 upgrade
-
tcpdump on your WAN - is the traffic actually making it back to you?
-
Excuse the text diagram… :P
______
+-------+ LAN +---------+ +--------+ / _ +--------+
| Guest +--------+ pfSense +--------+ Firewall +-----( Internet )-----+ Server +
+-------+ +---------+ +--------+ ______/ +--------+^ ^ ^ ^
A B C DAt points B, C, and D I can see the requests going out, and coming back in, but at point A I only see the traffic go from the guest out. You never see the response get from B back to A. When I said "running a packet sniffer on both boxes" in my original post - should have been more specific- with both boxes meaning pfSense and the firewall - tcpDump and snoop where applicable.
Now, if I do a NSLOOKUP on the client, with A as the name server, it works. I see the request go out and come back. But any request that doesn't involve the pfSense box to do the work (HTTP. HTTPS, IPSEC, PPTP, IBM Mobility client, etc etc) A -> B -> C -> D ... D -> C -> B -> Nothing.
I've also verified that NAT is the right addresses at each point i.e. Client hidden behind B and handed to the firewall wall... Firewall then NAT's to public IP, and unnatted coming back in as B's address.
The only thing I can think of is that for some reason pfSense not seeing the returned packet as the response to the original client request.
-
I've the same problem,
looking at ipfw rules on pfsense (used for captive portal) i seen that rule 19904 is hit, if you drop it (ipfw delete 19904) packets return properly
This means that, for some reason, the response packet allowed to pass
(look at ipfw rules using ipfw list or ipfw show)
-
rule 19904 = deny ip from any to any
This is the main stop gap, that makes the firewall saying "NO, except permitted" - killing it nearly means "stop firewalling".
Wouldn't it be more simple to install a working 1.2 - note the rule list, and then compare it with the rule list from 1.2.2 ?
-
What worked for me…
1. Do a clean install of 1.2 - YES 1.2
2. Apply the basic settings you need to have CP working - nothing more
3. Make sure it works fine with this base setup you have
4. Run the firmware upgrade to 1.2.2
5. It should now work - the CP
6. Go ahead and proceed with applying your other settings - i.e. additional FW rules, NAT settings, etc...I learned that instead of wasting my time trying to troubleshooting everything, that if I do a clean install and apply the settings I need at a bare minimum working setup, I can proceed with the rest...
Time spent troubleshooting = 80% of wasted time
Time w/clean install and applying settings I need = 20% of real timepfSense is VERY picky in terms of settings - doing things in order, certain ways, or it will not work...FTP for me was this way, setting AP mode only, having 1:1 was this way, and now CP....they all work great was done is proper order but heck to figure out first...
-
i don't think that this can resolve any problem for the simple reason that i had the same problem with a fresh installed 1.20 :\
-
Start with a CLEAN setup - none of your previous settings then proceed with below…
1. General Setup Settings Page's DNS should point to LAN's DNS (AD's DNS or router) not an external / Internet DNS like OpenDNS or ISP DNS
2. Wireless should already work in AP mode - without authentication (i.e. WEP, WAP, WAP2) - make sure the wireless works FIRST without CP - then proceed with next steps
3. ***** Setup of Captive Portal REQUIRES you to use the CORRECT Authentication (i.e. No Auth, Local User Manager, RADIUS Auth) - BEFORE you select SAVE option ******
4. Add the Users for Local Auth or for RADIUS depending on which you chose in #3 above
5. Reboot system
6. Connect the client systems -
pfSense is VERY picky in terms of settings - doing things in order, certain ways, or it will not work…
That's not true. Generally what happens is you have something misconfigured, and when you go through and do it again, you get it right. There is the possibility of doing something very, very unusual that doesn't come up properly, but a reboot will fix that in 100% of cases as it always brings everything up in the correct order. Even that's remote. I've configured literally hundreds of boxes in production environments around the world in every imaginable configuration, and never run into any particular "order" in which things have to be done. If you configure things correctly, it just works.
Virtually always, when people say a reinstall/reconfig fixed something, it's because it was configured right the second time, wrong the first. It's not a bad troubleshooting step to reset to factory defaults and start over if you find yourself with something you just can't figure out. Sometimes it is easier to completely reconfigure things than to figure out what you did to break it, if you aren't intimately familiar with the underlying software.
-
True, thus the problem lies in lack of "proper" documentation (pfSense with docs–-haaa---looking forward to the book). Yes, it's free and the forum is great but damnnnn, how much does one have to go through just to get certain pieces correct? FTP IS HELL if you don't know what to do (look it up via search). Terribly documented - same as wireless, CP, etc have similar lack of guides.
My point was that you have to scrap the configs and get order right - to get the right. Orders DO matter because it is part of the configuration process - proper configuration requires correct order of things. I.E. I can't start on Rules without my NAT or VIP, etc...it does matter.
You on the other hand have worked with this product LOOONG before any of us were here and you have deployed "hundreds" as you have said. You know the ins and outs the software - orders to go in depnding on configurations. You can't just say or indicate the the software just works - if that's the case the Forum would not be so littered with "issues" or questions. It doesn't just work - you have to know how this software works, - alot would be resolved with correct documentations.
but pfSense is GREAT once we do understand, and people like you for being very helpful....
-
I made the assumption that the backup and restore of the config would take care of that.
The 80/20 rule turned out to be true. I just got the version that was working, reloaded from scratch setting up the base config, and then imported that back in, and that worked perfectly. When I get some time, I will try the rebuild manually from scratch again and test it.
