Captive portal allows communication between guests
-
Hey guys! I have a request, so that two guests connected to the captive portal, in the same zone, can communicate. Analyzing, I didn't find anything firewall about this. When curling http://IP2, from IP1, the message is displayed that there is no route to that destination. On the guest with IP2 there is an http service on port 80. When capturing with tcpdump, the packet arrives at the firewall, but is not forwarded. Something related to ARP. Has anyone ever had a request like this? I don't know where to adjust to allow this communication between two guests. The aps for wireless network are unifi uap-ac-pro. In their configuration, the isolation option is not activated. Thank you for any help.
-
@robsonvitorm
Are we talking about hosts in the same vlan (broadcast domain) ? -
@michmoor yep, in the same broadcast domain, same vlan...thanks
-
@robsonvitorm
So there is no routing here therefore nothing to do with the firewall.
Hosts cant talk on the same vlan i would make sure that- IP subnet masks are the same or correct (we're not crossing boundaries due to misconfig)
- If Windows machines, ensure the Windows firewall is disabled for troubleshooting
-
@robsonvitorm said in Captive portal allows communication between guests:
I have a request, so that two guests connected to the captive portal, in the same zone, can communicate.
The important missing info is : get a pfSense, or whatever router you have laying around, hook up a switch, some access points and connect everything togerher.
As soon as every device has a DHCP lease, you can remove the pfSense (router).
You'll notice that traffic from to the internet isn't possible anymore. And I presume that I don't have to explain why.
You'll notice also that all your network devices can still communicate among each other just fine.
This is because : example : device on 192.168.1.2 doesn't need a router to interaction with for example 192.168.1.3.This is something you don't want on networks like a captive portal network.
So, check your access points, and activate AP Isolation Mode. This mode will make inter device communication impossible. Devices can only communicate with the gateway == the router.This mode is very comparable with what Microsoft "Windows" calls Private versus Public network mode. When Public mode is active, you can't share anything, neither see other shares. The only thing that works is the Internet access.
** Actually : on a captive portal, you don't care. It's a non trusted network, full with unknown devices, and they are connected just to have an internet access. If Billy with device X want to attack Willy with device Z on the portal network, then that is their affair ^^
Also : hosting a web server on a captive portal ? Are you sure ?
@robsonvitorm said in Captive portal allows communication between guests:
When curling http://IP2, from IP1, the message is displayed that there is no route to that destination. On the guest with IP2 there is an http service on port 80. When capturing with tcpdump, the packet arrives at the firewall, but is not forwarded. Something related to ARP.
What ARP does : device with IP1 uses the arp protocol on the local network to ask : who has IP2 ?
IP2 then will reply : It's me : here is my MAC.
And then IP1 connect to IP2 directly using their MAC addresses, and all of this doesn't involve the firewall at all. proof : power down the firewall, and you can still connect.
If IP2 (the web server) doesn't reply, go talk again to the admin (you didn't fire him yet ?) and ask him to finish his work.@robsonvitorm said in Captive portal allows communication between guests:
I don't know where to adjust to allow this communication between two guests
Very basic "your very first network ever" == two PC and a cross Ethernet cable.
Assign a static IP and /mask to the first PC. Example 192.168.1.10/24
Assign a static IP and /mask to the second PC Example 192.168.1.11/24.
Now your network works : they can communicate. No firewall. No router / nos witch : nothing. Try it !?!@robsonvitorm said in Captive portal allows communication between guests:
he aps for wireless network are unifi uap-ac-pro. In their configuration, the isolation option is not activated.
Ah, ok, so you know about Isolation mode .....
-
@robsonvitorm Both guests are Linux without firewall rules and policies like ACCEPT. In pfsense, I created a rule allowing everything (protocol, port and src and dst). What I forgot to mention is that the APs network is different, and is in another VLAN and broadcast. However, I pass the VLANS of each SSID, including guests. The netmasks on both are correct, as it is a medium network, using /22, delivered via DHCP on pfsense itself.
-
@robsonvitorm said in Captive portal allows communication between guests:
In pfsense, I created a rule allowing everything (protocol, port and src and dst).
why? traffic doesn't go through pfsense if they are in the same vlan?
There is something blocking on the hosts themselves.APs having different management IPs is fine. traffic is not routed across the management interface
-
This post is deleted! -
@michmoor just to rule out any possibility of the firewall blocking these connections... but there is still something blocking this communication.
-
@robsonvitorm
tcpdump on the IP2 host and you'll understand what happens ^^edit : Who listens on port '80' :
netstat -naptul | grep ':80'Check also the firewall on that IP2 device.
-
@robsonvitorm
I agree. wireshark/tcpdump on each client. Perhaps application-related.
Are you able to ping each client?
Can you see other mac addresses from your client?For example, on my linux hosts
arp -a ? (10.105.1.15) at 28:8a:1c:45:fa:c0 [ether] on ens192 ? (10.105.1.27) at <incomplete> on ens192 ? (10.205.1.90) at 00:94:a1:12:39:82 [ether] on ens160 ? (10.205.1.32) at <incomplete> on ens160 ? (10.105.1.112) at 00:13:c6:01:5c:7d [ether] on ens192 ? (10.105.1.23) at 00:01:d7:ed:5e:c1 [ether] on ens160 ? (10.105.1.118) at 00:cc:34:56:59:12 [ether] on ens192 ? (10.205.1.90) at 00:94:a1:12:39:82 [ether] on ens192 -
@robsonvitorm the firewall is disabled in both iptables without any rules and policies in accept
-
-
@robsonvitorm tcpdump
tcpdump does not capture anything on the ICMP target host, as if nothing reached it.
root@XXX54:~# tcpdump -i wls2 host 10.17.200.14 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on wls2, link-type EN10MB (Ethernet), snapshot length 262144 bytes ^C 0 packets captured 0 packets received by filter 0 packets dropped by kernel -
@robsonvitorm
You dont need to obfuscate private addresses (RFC1918) or mac addresses generally.
If you don't see packets leaving then you have a problem on the host level. Either your network stack on the host is corrupted or you got something else going on.
