Captive portal - fwd connection does not work. (Resolved)
-
Hello, I'm running 2.0-RC3 (i386) built on Wed Jun 29 21:29:39 EDT 2011 nanobsd and I'm trying to get the Captive portal to work.
I'm having trouble narrowing down where the error is happening.
The client behind the CP can get an IP just fine, and can access the login page directly http://192.168.1.1:8000, but a request for an outside page just times out.
I see the packets hitting the fwd rule, but only the request packet, no connection every gets made to lighty-CaptivePortal on port 8000.
The next rule (65532) down does not get accessed, which is to allow packets from lighty back to the client.I enabled logging for lighty-CaptivePortal.conf by editing /etc/inc/system.inc and adding accesslog.use-syslog = 'enable', but that doesn't show that a connection is being made.
ipfw show
$ ipfw show 65291 0 0 allow pfsync from any to any 65292 0 0 allow carp from any to any 65301 2 74 allow ip from any to any layer2 mac-type 0x0806 65302 0 0 allow ip from any to any layer2 mac-type 0x888e 65303 0 0 allow ip from any to any layer2 mac-type 0x88c7 65304 0 0 allow ip from any to any layer2 mac-type 0x8863 65305 0 0 allow ip from any to any layer2 mac-type 0x8864 65306 0 0 allow ip from any to any layer2 mac-type 0x888e 65307 0 0 deny ip from any to any layer2 not mac-type 0x0800 65310 1 56 allow ip from any to { 255.255.255.255 or 192.168.1.1 } in 65311 1 136 allow ip from { 255.255.255.255 or 192.168.1.1 } to any out 65312 0 0 allow icmp from { 255.255.255.255 or 192.168.1.1 } to any out icmptypes 0 65313 0 0 allow icmp from any to { 255.255.255.255 or 192.168.1.1 } in icmptypes 8 65314 0 0 allow ip from table(3) to any in 65315 0 0 allow ip from any to table(4) out 65316 0 0 pipe tablearg ip from table(5) to any in 65317 0 0 pipe tablearg ip from any to table(6) out 65318 0 0 allow ip from any to table(7) in 65319 0 0 allow ip from table(8) to any out 65320 0 0 pipe tablearg ip from any to table(9) in 65321 0 0 pipe tablearg ip from table(10) to any out 65322 0 0 allow ip from table(1) to any in 65323 0 0 allow ip from any to table(2) out 65531 15 720 fwd 127.0.0.1,8000 tcp from any to any in 65532 0 0 allow tcp from any to any out 65533 0 0 deny ip from any to any 65534 0 0 allow ip from any to any layer2 65535 0 0 allow ip from any to anyThe captive portal interface is a vlan, in case that has any effect? I removed all traces of my traffic shaper + dummynet pipes + floating rules just in case. I also disabled all rules on the interface except for an allow all, and removed the bogon and private networks blocks.
When I do a tcpdump on the CP interface, I see the initial DNS request which works just fine, and then I see a syn packet to the remote site's IP, but I never see the ACK that should be next, the client just keeps retrying to start the connection. Any way I can peer into the ipfw after it fwd's the packet to localhost?
pftop shows no state created for the connection.
I cannot see any other obvious blocking going on with pftop view: rules - the Default deny rule is getting hit, but that should be logged, it seems to just be the garbage packets from my wan side.
I attached my captive portal config along with the output of pfctl -sa, and also the /tmp/ipfw.cp.rules files.
When I disable the CP the client has no trouble making connections.
I also noticed that I cannot use nc on the firewall itself to connect to the lighty port 8000 connection.. nc -v 127.0.0.1 8000 says that it connects but nothing is returned if I request a page "GET / \n\n"
Please let me know what else may be of use.
Thanks
Joshcaptiveportal-config-nr-firewall.nwrlib.org-20110630143859.xml.txt
ipfw.cp.rules.txt
pfctl-all.txt -
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