Captive portal stopped working after 1.2.2 upgrade
-
Got a weird one. Was running v1.2.0 with a captive portal setup with DHCP on OPT1. LAN was connected to an internal management network, and WAN was connected to a segment connected to another firewall. The OPT1 was NAT'd to the WAN interface which was a static address, which through routing was then forced out to the Internet.
This was working happily.
After the upgrade it no longer worked. Checking the logs on the pfSense box, I saw that the rules were still accepted, and on the edge firewall device, it to was also being accepted. Running a packet sniffer on both boxes, I found what was happening. It was going from the captive portal, out the other firewall, across the internet and back to the pfSense box and that was it. The traffic instead of being passed back into the captive portal network was just disappearing.
All the routes are still correct, and there is nothing in the logs.
I've tried auto NAT and manual NAT rules and that didn't make any difference. All the logs still show up correctly, but the pfSense box is dropping the returning packet.
Now, it is running authentication from an AD box, and I have verified this is all working (i.e You can log in to the portal and access port 80 and DNS - the latter I think is a proxied request also, so not all the way through)
I installed Squid into pfSense, which allows web traffic on port 80 happily - proxied requests, so nothing passes completely through, which is what I expected, but everything else (IPSEC, HTTPS, PPTP, etc) just goes out and never returns.
Does any one have an ideas on how I can solve this?
-
Hello all,
Same problem here, 1.2 worked as I expected but when I upgrade my box to 1.2.2
the I can't setup the captive portal properly.
I guess I'll be waiting for a patch or something. -
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.
