Captive portal - fwd connection does not work. (Resolved)
-
Check that the dns of the client is either allowed or pointing to pfsense.
And firewall rules on the vlan interface are allowing traffic. -
@ermal:
Check that the dns of the client is either allowed or pointing to pfsense.
And firewall rules on the vlan interface are allowing traffic.Hello Ermal, the DNS traffic is being allowed through without any trouble. The client is using the firewall as it's DNS server as specified by DHCP on the firewall. I can nslookup all day on the client with no problem, and tcpdump shows the request and the response on the CP vlan interface.
When I disable the captive portal, I have no trouble making connections to outside hosts. I removed every firewall rule on the vlan interface except for an allow all.
Is there a way to see where the system is sending a packet after it hits the ipfw fwd rule?.. That is enabled for the nanobsd image.
Thanks
Josh -
Show me a pfctl -vvsr of your ruleset.
-
I attached the output of pfctl -vvsra
vr1_vlan12 is the CP interface.
When I try to make a http connection to Google from the client, the counter for the IPFW fwd rule increments every time the initial syn packet is sent, but the pf rule that I think is supposed to allow the port 8000 traffic, does not seem to match the packet. Is PF seeing the packet after IPFW changes it's destination, or before?
I enabled logging for the pass all rule on vr1_vlan12, but the syn packet to a google server does not generate a log entry from the allow all rule? A direct connection from the client to 192.168.1.1:8000 does get allowed and is logged.
Thanks for taking a look at this Ermal.
Josh -
I think I'm getting closer to figuring out what the issue is.
I started with the default config and setup the most basic captive portal setup I could with the Vlan settings that I needed. Then I started to restore each section of the config I'm having trouble with one by one, rebooting and testing the Captive Portal. After I restored the system tunables from my orig config, the problem started again. After I restored that to the defaults, no problem again. Some there is something in my orig sysctl config that is breaking the captive portal.
Could having net.ip.fastforwarding enabled cause the CP fwd to not work?
I attached both my old and the default sysctl config files.
(Can someone fix this forum so I can upload xml without needing to change the extension please.).
Josh
-
When I enable net.ip.fastforwarding (=1) it does indeed keep the cp forwarding to the cp page from working.
Should their be a check in the CP setup code that detects if ip.fastforwarding is enabled and warns the user that it isn't compatible?
Thanks
Josh -
fastforwarding breaks ipfw fwd (and possibly other things, it's off by default for a reason). There are a probably unlimited number of ways to break things if you start messing with sysctls. If you'd like to submit a patch to detect fastforwarding when enabling CP, just attach to a feature ticket at redmine.pfsense.org or make a merge request on github and we'll get it pulled in for 2.1.
-
Hmmi have disabled fast forwarding since its not anymore an optimization as far as pfSense is concerned.
The performance is the same and fast forwarding has issues in some cases. -
Chris & Ermal, Thanks for confirming that the fastforwarding was the problem. As far as I can remember I have never modified any sysctls, which is why this caught me by surprise. It must have been enabled in a snapshot I tried once, and I have been carrying it forward in my config backups. I'll just make a note on the captive portal troubleshooting page since it sounds like having that option set is probably pretty rare.
Josh
-
Just one more note. It looks like ipfastforward is required to be enable for the CP to work with older snapshots. I just checked a machine with a dec 2010 snapshot. When I set ipfastforward to 0, it breaks the forwarding to the cp page on that snapshot… so I'll just have to be careful when upgrading from older snapshots.
Josh