Captive portal allows communication between guests
-
@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.
