Communication with a internet host without pass the captive portal. Wrong setup?
-
Hello community, :o
i have setup a captive portal on our testserver for our guest. A the moment the captive portal is running only in testmode and at this time vouchers are not given to the public guest. Today, no users with vouchers are logged in but i can see a communication from the internet to one of a unknown device. How the hell can a ip from the internet communication to the device without pass the captive portal ? If i read the protocol there is an SYN and ACK. So the device from the HOTSPOT must first make a connection to the ip from the internet. Is there anything in the firewall rule, that i have forgotten or wrong?
Log from the firewall:
Act Time If Source Destination Proto block Jul 17 19:37:52 HOTSPOT 192.168.100.106 192.168.100.1 ICMP block Jul 17 19:37:51 HOTSPOT 192.168.100.106 192.168.100.1 ICMP block Jul 17 19:37:50 HOTSPOT 192.168.100.106 192.168.100.1 ICMP block Jul 17 19:30:37 HOTSPOT 192.168.100.106 192.168.100.1 ICMP block Jul 17 19:30:36 HOTSPOT 192.168.100.106 192.168.100.1 ICMP block Jul 17 19:30:35 HOTSPOT 192.168.100.106 192.168.100.1 ICMP block Jul 17 19:28:47 HOTSPOT 192.168.100.106:137 192.168.100.1:137 UDP block Jul 17 19:28:44 HOTSPOT 192.168.100.106:137 192.168.100.1:137 UDP pass Jul 17 19:28:42 HOTSPOT 192.168.100.106:1081 192.168.100.1:8000 TCP:S pass Jul 17 19:28:41 HOTSPOT 174.133.30.218:80 192.168.100.106:1080 TCP:SA block Jul 17 19:28:40 HOTSPOT 192.168.100.106:137 192.168.100.1:137 UDP block Jul 17 19:28:38 HOTSPOT 192.168.100.106:137 192.168.100.1:137 UDP block Jul 17 19:28:28 HOTSPOT 192.168.100.106:137 192.168.100.1:137 UDP block Jul 17 19:28:26 HOTSPOT 192.168.100.106:137 192.168.100.1:137 UDP block Jul 17 19:28:25 HOTSPOT 192.168.100.106:137 192.168.100.1:137 UDP block Jul 17 19:28:23 HOTSPOT 192.168.100.106:137 192.168.100.1:137 UDP pass Jul 17 19:28:19 HOTSPOT 192.168.100.106:1079 192.168.100.1:8000 TCP:S pass Jul 17 19:28:19 HOTSPOT 74.86.232.38:80 192.168.100.106:1078 TCP:SA pass Jul 17 19:28:12 HOTSPOT 192.168.100.106:1077 192.168.100.1:8000 TCP:S pass Jul 17 19:28:12 HOTSPOT 178.63.82.23:80 192.168.100.106:1076 TCP:SA pass Jul 17 19:28:09 HOTSPOT 192.168.100.106:1075 192.168.100.1:8000 TCP:S pass Jul 17 19:28:09 HOTSPOT 74.86.232.34:80 192.168.100.106:1074 TCP:SA pass Jul 17 19:28:05 HOTSPOT 192.168.100.106:1073 192.168.100.1:8000 TCP:S pass Jul 17 19:28:05 HOTSPOT 87.248.217.253:80 192.168.100.106:1072 TCP:SA pass Jul 17 19:28:02 HOTSPOT 192.168.100.106:1071 192.168.100.1:8000 TCP:S pass Jul 17 19:28:01 HOTSPOT 46.4.28.79:80 192.168.100.106:1070 TCP:SA pass Jul 17 19:27:54 HOTSPOT 192.168.100.106:1069 192.168.100.1:8000 TCP:S pass Jul 17 19:27:53 HOTSPOT 85.17.24.203:80 192.168.100.106:1068 TCP:SA pass Jul 17 19:27:49 HOTSPOT 192.168.100.106:1067 192.168.100.1:8000 TCP:S pass Jul 17 19:27:49 HOTSPOT 78.46.74.70:80 192.168.100.106:1066 TCP:SA pass Jul 17 19:27:45 HOTSPOT 192.168.100.106:1065 192.168.100.1:8000 TCP:S pass Jul 17 19:27:45 HOTSPOT 208.43.71.157:80 192.168.100.106:1064 TCP:SA pass Jul 17 19:27:42 HOTSPOT 192.168.100.106:1063 192.168.100.1:8000 TCP:S pass Jul 17 19:27:41 HOTSPOT 207.218.232.82:80 192.168.100.106:1062 TCP:SA pass Jul 17 19:27:38 HOTSPOT 192.168.100.106:1061 192.168.100.1:8000 TCP:S pass Jul 17 19:27:37 HOTSPOT 88.198.60.105:80 192.168.100.106:1060 TCP:SA pass Jul 17 19:27:34 HOTSPOT 192.168.100.106:1059 192.168.100.1:8000 TCP:S pass Jul 17 19:27:33 HOTSPOT 46.165.196.138:80 192.168.100.106:1058 TCP:SA pass Jul 17 19:27:28 HOTSPOT 192.168.100.106:1057 192.168.100.1:8000 TCP:S pass Jul 17 19:27:28 HOTSPOT 208.43.71.132:80 192.168.100.106:1056 TCP:SA pass Jul 17 19:27:18 HOTSPOT 192.168.100.106:1055 192.168.100.1:8000 TCP:S pass Jul 17 19:27:18 HOTSPOT 174.120.185.186:80 192.168.100.106:1054 TCP:SA pass Jul 17 19:26:58 HOTSPOT 192.168.100.106:1053 192.168.100.1:8000 TCP:S pass Jul 17 19:26:58 HOTSPOT 174.120.185.186:80 192.168.100.106:1052 TCP:SA pass Jul 17 19:26:56 HOTSPOT 192.168.100.106:1051 192.168.100.1:8000 TCP:S pass Jul 17 19:26:56 HOTSPOT 82.192.95.92:80 192.168.100.106:1050 TCP:SA block Jul 17 19:26:51 HOTSPOT 192.168.100.106:137 192.168.100.1:137 UDP block Jul 17 19:26:46 HOTSPOT 192.168.100.106:137 192.168.100.1:137 UDP block Jul 17 19:26:45 HOTSPOT 192.168.100.106:137 192.168.100.1:137 UDP block Jul 17 19:26:43 HOTSPOT 192.168.100.106:137 192.168.100.1:137 UDP pass Jul 17 19:26:38 HOTSPOT 192.168.100.106:1049 192.168.100.1:8000 TCP:S pass Jul 17 19:26:38 HOTSPOT 208.43.71.132:80 192.168.100.106:1048 TCP:SA pass Jul 17 19:26:36 HOTSPOT 192.168.100.106:1047 192.168.100.1:8000 TCP:S pass Jul 17 19:26:35 HOTSPOT 174.36.159.199:80 192.168.100.106:1046 TCP:SA pass Jul 17 19:26:24 HOTSPOT 74.55.53.50:80 192.168.100.106:1041 TCP:SA pass Jul 17 19:26:21 HOTSPOT 65.54.52.62:1863 192.168.100.106:1040 TCP:SA pass Jul 17 19:26:20 HOTSPOT 65.54.165.179:443 192.168.100.106:1039 TCP:SA pass Jul 17 18:27:54 HOTSPOT 192.168.100.106:1132 192.168.100.1:8000 TCP:S pass Jul 17 18:27:54 HOTSPOT 207.46.210.107:80 192.168.100.106:1131 TCP:SA pass Jul 17 18:26:46 HOTSPOT 65.54.52.254:1863 192.168.100.106:1130 TCP:SA pass Jul 17 18:26:46 HOTSPOT 65.54.165.169:443 192.168.100.106:1129 TCP:SAfirewall rules:
and that are the aliases
-
i can see a communication from the internet to one of a unknown device. How the hell can a ip from the internet communication to the device without pass the captive portal ?
So where is the communication from the internet to one of an unknown device? Your firewall log shows a bunch of activity on the HOTSPOT interface. Is that your interface to the Internet? Do you mean the "TCP:SA" entries such as
pass Jul 17 19:26:38 HOTSPOT 208.43.71.132:80 192.168.100.106:1048 TCP:SA
Perhaps a system connected to the HOTSPOT interface is also connected to the internet.
Your firewall rules suggest these "TCP:SA" packets should have been blocked (but you don't provide a definition of HOTSPOT net). Perhaps a previous firewall ruleset on the interface allowed such traffic and you didn't reset firewall states after changing the rules. (See Diagnostics -> States , click on Reset States tab and read the explanation.)
The TCP:SA packets in normal TCP operation are the response to a previous connection attempt. That these appear in the firewall log indicate the firewall hasn't seen that previous connection attempt. I imagine captive portal is only interested in connection attempts ("TCP:S" packets).
-
Hi wallabybob,
at this time we test the pfsense captive portal with 4 users. All our test-devices on the hotpspot net must first pass through the captive portal and authentificat with a voucher. The "uknown device" isn´t a device from the 4 testusers.
Your firewall log shows a bunch of activity on the HOTSPOT interface. Is that your interface to the Internet?
no, this is our wlan net only. The devices must pass the captive portal and will then routet to the internet gateway (192.168.1.1).
Perhaps a previous firewall ruleset on the interface allowed such traffic and you didn't reset firewall states after changing the rules.
there whas no previous firewall ruleset bevor, that allowed the such traffic. The firewall whas updated 1 hour bevor and has rebootet. So all firewall states was killed.
pass Jul 17 18:26:46 HOTSPOT 65.54.165.169:443 192.168.100.106:1129 TCP:SA
pass Jul 17 18:26:46 HOTSPOT 65.54.52.254:1863 192.168.100.106:1130 TCP:SA
pass Jul 17 18:27:54 HOTSPOT 207.46.210.107:80 192.168.100.106:1131 TCP:SAWhat i didn´t understand. If there is a TCP:SA state, then the device must first start a connect like
pass Jul 17 18:26:xx HOTSPOT 192.168.100.106:1129 65.54.165.169:443 TCP:Sbut there are no connection from the device to the destination ip in the firewall log. The first log entry i can see is that above from 18:26:46.
The TCP:SA packets in normal TCP operation are the response to a previous connection attempt.
yes i understand, but how can the device make a connection attempt, if he didn´t have vouchers or a login for the captive portal. If the setup is right, he must firstly pass the captive portal?
Again. There are no firewall rulesets bevor that allow connection without pass the captive portal. All firewall states whas resetet one hour bevor.
-
I'm puzzled, but that may be because I don't understand the interactions between captive portal and firewall. In particular the firewall log contains entries such as :
pass Jul 17 18:26:46 HOTSPOT 65.54.165.169:443 192.168.100.106:1129 TCP:SA
pass Jul 17 18:26:46 HOTSPOT 65.54.52.254:1863 192.168.100.106:1130 TCP:SA
pass Jul 17 18:27:54 HOTSPOT 207.46.210.107:80 192.168.100.106:1131 TCP:SAHow did a packet from 65.54.165.169 get to arrive on the HOTSPOT interface? (Shouldn't the source address be in the HOTSPOT subnet?) How did this packet pass the firewall rules for the HOTSPOT interface?
-
Hi wallabybob,
i´m puzzled, too ;D
Yes, the question is how the Source 65.54.165.169:443 can pass the firewall and go to the device, when the device on the hotspot didn´t come out because he has no pass for captive portal.
I´m confused.
-
Hi wallabybob,
do you think the problem comes from the dns firewall rule? i think i will change the dns rule to a other dns, that is not the gateway to the internet. As example opendns.
-
-
Hi wallabybob,
you are right. Changing the dns rule didn´t will fix the problem. Today, i have checked the problem with one of our device. If i didn´t enter a voucher ticket and try to catch mail or do other communication to the internet, so transfer will blocked. If i will go to a www url over port 80, the captive portal catch me and ask me for a voucher. Looks all ok. Only the firewall log makes me crazy.
