After much searching, I realized that in wpa_supplicant/hostapd there is a feature called `ap_isolate` which is supposed to do exactly what I needed. I tried it to set this flag with `wpa_cli` which is a command line interface for wpa_supplicant. That didn't work unfortunately. But creating the entire Access Point with hostapd and `ap_isolate` enabled worked for me : http://lists.infradead.org/pipermail/hostap/2020-June/038542.html I still believe netfilter tables should be able to manage such packets even though these packets are probably forwarded by the wifi interface directly. I know that tcpdump/eBPF can view and filter these packets and I think not being able to manipulate or drop such packets could be a security issue, since these are packets that you can't really manage through iptables/ebtables (think of firewalls). So I leave it to this community to decide whether netfilter should be able to manage such packets. -Hooman On 6/20/20 5:48 PM, Hooman wrote: > Hi > > On 6/19/20 1:38 PM, Hooman wrote: >> Hi, >> >> On 6/16/20 6:09 AM, G.W. Haywood wrote: >>> Hi there, >>> >>> On Mon, 15 Jun 2020, Hooman wrote: >>> >>>> I am using WiFi hotspot feature of Ubuntu 18.04 to create a hotspot for >>>> my devices. I need to prevent different devices on the network from >>>> contacting each other. >>>> >>>> More specifically, I have two phones on the network, I would like them >>>> not to be able to send any packets to each other. Right now if phone 1 >>>> is using IP address 10.42.0.172 and phone 2 is using 10.42.0.59, I can >>>> use phone 1 to ping 10.42.0.59. >>>> >>>> I would like to disable connections between different hosts on the >>>> network created by the hotspot. >>>> >>>> I tried using iptables to drop local traffic. However, it seems like >>>> the >>>> iptables don't have any effect on these packets. >>>> >>>> I do see local packets on wireshark though. I'm wondering if local >>>> packets are forwarded directly without hitting the iptable rules. >>> That's _almost_ what is happening, I think. It isn't totally clear to >>> me but I'm going to assume that all your devices can communicate with >>> your Ubuntu box over your local network. >>> >>> The word 'forward' has a specific meaning in networking. It means >>> that the connection goes via a router which is responsible for traffic >>> which crosses network boundaries, and in that case the router can do >>> things with the traffic (like block it, NAT and so on). But in your >>> case the devices are on the SAME network; traffic doesn't need to pass >>> through a router, a switch or hub will do, but a switch or hub doesn't >>> meddle with the traffic like a router can. I guess you have all the >>> devices and your Ubuntu box connected via the same Ethernet switch, in >>> which case the Ubuntu box won't even see the traffic between the two >>> other devices when they talk to each other. If you have a hub and not >>> a switch the Ubuntu box will see it, but even then it won't be able to >>> do much about it, as the packets would not be addressed to the Ubuntu >>> box - they would effectively just be network noise, and ignored. >>> >>>> Is it possible to use iptables or ebtables to filter these packets? >>> Not as things stand, you need to force the traffic through a router. >>> Your Ubuntu box can be the router. >>> >>>> Is there any other solution to this? >>> To force all the traffic through your Ubuntu box you could put each of >>> the other hosts on a separate subnet. For example, assuming that you >>> set up each subnet as a /16, for the two devices you could have: >>> >>> 10.43.0.2 instead of 10.42.0.59 and >>> 10.44.0.2 instead of 10.42.0.172 >>> >>> You will then need to add IPs 10.43.0.1 and 10.44.0.1 to the interface >>> on the Ubuntu box, and also to tell the Ubuntu box to forward packets, >>> which can sometimes have interesting side-effects. As root, something >>> like >>> >>> echo 1 > /proc/sys/net/ipv4/ip_forward >>> >>> or >>> >>> sysctl -w net.ipv4.ip_forward=1 >>> >>> will do the trick for IPv4 packets. >>> >>> If you _did_ want the two devices to talk to each other sometime, then >>> you'd need to set up routes in each device, which is normally an extra >>> complication when you set up subnets so that the subnets can talk to >>> each other. But since you specifically don't want that to happen then >>> you don't need to do that normally (at least to me) irritating part. >>> You can then have rules on the Ubuntu box which block traffic between >>> the two devices. >>> >>> There's nothing really special about the IP numbers I've chosen which >>> would mean that 10.42.0.59 and 10.42.0.172 are on the same subnet and >>> the 10.43 and 10.44 numbers are not. The thing which determines that >>> is the network mask. Most of the time on a 10.x.x.x network the mask >>> will be /8 (or 255.0.0.0) for example, and on a 192.168.x.x network it >>> will be /16 (or 255.255.0.0), but you could for example have a mask of >>> /25 (255.255.128.0), which would mean that 10.42.0.59 and 10.42.0.172 >>> are actually on separate networks and need to be routed. The thinking >>> is a bit more tricky though, so that's why I chose the numbers in my >>> examples. The documentation on the Netfilter Website goes into a >>> great deal more detail than I can here. It will take you some time to >>> wade through it but it will be worth the effort. >>> > > Maybe I wasn't clear enough. Here's it again. I am using Ubuntu 18.04 > default hotspot feature to create a wifi access point. The Ubuntu > machine is also connected via ethernet to the Internet (inet > 25.02.224.105 netmask 255.255.252.0). > > The hotspot creates a network on subnet on my wifi interface ( inet > 10.42.0.1 netmask 255.255.255.0 ): > > >> root@myuser:~# ifconfig >> eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 >> inet 25.02.224.105 netmask 255.255.252.0 broadcast 25.02.227.255 >> inet6 fe80::3521:18e2:11d9:7c70 prefixlen 64 scopeid 0x20<link> >> ether 2e:61:a5:b2:3d:88 txqueuelen 1000 (Ethernet) >> RX packets 1144162 bytes 508133990 (508.1 MB) >> RX errors 0 dropped 0 overruns 0 frame 0 >> TX packets 89831 bytes 7271961 (7.2 MB) >> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 >> device interrupt 17 memory 0xb1200000-b1220000 > >> wlan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 >> inet 10.42.0.1 netmask 255.255.255.0 broadcast 10.42.0.255 >> inet6 fe80::c112:bd92:d15:ea96 prefixlen 64 scopeid 0x20<link> >> ether ac:6f:d2:2a:1b:9a txqueuelen 1000 (Ethernet) >> RX packets 0 bytes 0 (0.0 B) >> RX errors 0 dropped 0 overruns 0 frame 0 >> TX packets 92 bytes 11830 (11.8 KB) >> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > Now using this hotspot, I connect two other machines to this access > point. Machine A is on 10.42.0.34 and Machine B is on 10.42.0.57. > > Some other info about the setup: > >> root@myuser:~# ip link show >> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN > mode DEFAULT group default qlen 1000 >> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 >> 2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel > state UP mode DEFAULT group default qlen 1000 >> link/ether 2e:61:a5:b2:3d:88 brd ff:ff:ff:ff:ff:ff >> 3: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP > mode DORMANT group default qlen 1000 >> link/ether ac:6f:d2:2a:1b:9a brd ff:ff:ff:ff:ff:ff > >> root@myuser:~# ip rule show >> 0: from all lookup local >> 32766: from all lookup main >> 32767: from all lookup default > >> root@myuser:~# ip route show >> default via 25.02.224.1 dev eth1 proto dhcp metric 100 >> 10.42.0.0/24 dev wlan1 proto kernel scope link src 10.42.0.1 metric 600 >> 25.02.224.0/22 dev eth1 proto kernel scope link src 25.02.224.105 > metric 100 >> 169.254.0.0/16 dev eth1 scope link metric 1000 >> root@myuser:~# ip netconf >> ipv4 dev lo forwarding on rp_filter off mc_forwarding off proxy_neigh > off ignore_routes_with_linkdown off >> ipv4 dev eth1 forwarding on rp_filter loose mc_forwarding off > proxy_neigh off ignore_routes_with_linkdown off >> ipv4 dev wlan1 forwarding on rp_filter strict mc_forwarding off > proxy_neigh off ignore_routes_with_linkdown off >> ipv4 all forwarding on rp_filter strict mc_forwarding off proxy_neigh > off ignore_routes_with_linkdown off >> ipv4 default forwarding on rp_filter strict mc_forwarding off > proxy_neigh off ignore_routes_with_linkdown off >> ipv6 dev lo forwarding off mc_forwarding off proxy_neigh off > ignore_routes_with_linkdown off >> ipv6 dev eth1 forwarding off mc_forwarding off proxy_neigh off > ignore_routes_with_linkdown off >> ipv6 dev wlan1 forwarding off mc_forwarding off proxy_neigh off > ignore_routes_with_linkdown off >> ipv6 all forwarding off mc_forwarding off proxy_neigh off > ignore_routes_with_linkdown off >> ipv6 default forwarding off mc_forwarding off proxy_neigh off > ignore_routes_with_linkdown off > >> root@myuser:~# brctl show >> bridge name bridge id STP enabled interfaces > >> root@myuser:~# arp -a >> ? (25.02.224.104) at 2e:61:a5:b2:3e:25 [ether] on eth1 >> ? (10.42.0.57) at f6:2e:23:4b:72:ae [ether] on wlan1 >> ? (25.02.224.1) at 00:00:0c:9f:f0:e0 [ether] on eth1 > > The hotspot feature creates some iptable rules: > > >> root@myuser:~# iptables -vL -t filter >> Chain INPUT (policy ACCEPT 284K packets, 89M bytes) >> pkts bytes target prot opt in out source > destination >> 0 0 ACCEPT udp -- wlan1 any anywhere > anywhere udp dpt:bootps >> 0 0 ACCEPT tcp -- wlan1 any anywhere > anywhere tcp dpt:bootps >> 0 0 ACCEPT udp -- wlan1 any anywhere > anywhere udp dpt:domain >> 0 0 ACCEPT tcp -- wlan1 any anywhere > anywhere tcp dpt:domain >> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) >> pkts bytes target prot opt in out source > destination >> 0 0 ACCEPT all -- any wlan1 anywhere > 10.42.0.0/24 state RELATED,ESTABLISHED >> 0 0 ACCEPT all -- wlan1 any 10.42.0.0/24 > anywhere >> 0 0 ACCEPT all -- wlan1 wlan1 anywhere > anywhere >> 0 0 REJECT all -- any wlan1 anywhere > anywhere reject-with icmp-port-unreachable >> 0 0 REJECT all -- wlan1 any anywhere > anywhere reject-with icmp-port-unreachable >> Chain OUTPUT (policy ACCEPT 13186 packets, 1539K bytes) >> pkts bytes target prot opt in out source > destination >> >> root@myuser:~# iptables -vL -t nat >> Chain PREROUTING (policy ACCEPT 110K packets, 27M bytes) >> pkts bytes target prot opt in out source > destination >> Chain INPUT (policy ACCEPT 110K packets, 27M bytes) >> pkts bytes target prot opt in out source > destination >> Chain OUTPUT (policy ACCEPT 1309 packets, 99285 bytes) >> pkts bytes target prot opt in out source > destination >> Chain POSTROUTING (policy ACCEPT 1276 packets, 96891 bytes) >> pkts bytes target prot opt in out source > destination >> 33 2394 MASQUERADE all -- any any 10.42.0.0/24 > !10.42.0.0/24 >> >> root@myuser:~# iptables -vL -t mangle >> Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) >> pkts bytes target prot opt in out source > destination >> Chain INPUT (policy ACCEPT 0 packets, 0 bytes) >> pkts bytes target prot opt in out source > destination >> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) >> pkts bytes target prot opt in out source > destination >> Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) >> pkts bytes target prot opt in out source > destination >> Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) >> pkts bytes target prot opt in out source > destination >> >> root@myuser:~# iptables -vL -t raw >> Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) >> pkts bytes target prot opt in out source > destination >> Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) >> pkts bytes target prot opt in out source > destination >> >> root@myuser:~# iptables -vL -t security >> Chain INPUT (policy ACCEPT 0 packets, 0 bytes) >> pkts bytes target prot opt in out source > destination >> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) >> pkts bytes target prot opt in out source > destination >> Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) >> pkts bytes target prot opt in out source > destination > > There are no ebatbles rules: > >> root@myuser:~# ebtables -t broute -L >> Bridge table: broute >> >> Bridge chain: BROUTING, entries: 0, policy: ACCEPT >> >> >> root@myuser:~# ebtables -t filter -L >> Bridge table: filter >> >> Bridge chain: INPUT, entries: 0, policy: ACCEPT >> >> Bridge chain: FORWARD, entries: 0, policy: ACCEPT >> >> Bridge chain: OUTPUT, entries: 0, policy: ACCEPT >> >> >> root@myuser:~# ebtables -t nat -L >> Bridge table: nat >> >> Bridge chain: PREROUTING, entries: 0, policy: ACCEPT >> >> Bridge chain: OUTPUT, entries: 0, policy: ACCEPT >> >> Bridge chain: POSTROUTING, entries: 0, policy: ACCEPT >> > > Now as I said, Machine A is on 10.42.0.34 and Machine B is on 10.42.0.57. > > Machine A (10.42.0.34) can ping Machine B (10.42.0.57) and can also > ping 8.8.8.8 (external:Google). > > These ebtables rules don't have any effect: > > >> sudo ebtables -t broute -F >> sudo ebtables -t broute -P BROUTING DROP >> >> >> sudo ebtables -t nat -F >> sudo ebtables -t nat -P PREROUTING DROP >> sudo ebtables -t nat -P OUTPUT DROP >> sudo ebtables -t nat -P POSTROUTING DROP >> >> >> sudo ebtables -t filter -F >> sudo ebtables -t filter -P INPUT DROP >> sudo ebtables -t filter -P OUTPUT DROP >> sudo ebtables -t filter -P FORWARD DROP > > The following iptables rules stop packets from Machine A to Google but > not from Machine A to B: > >> sudo iptables -t mangle -I PREROUTING -j DROP >> sudo iptables -t filter -I FORWARD -j DROP >> sudo iptables -t raw -I PREROUTING -j DROP > > The only way I can stop packets from machine A to B for a few second is > to flush arp cache by running: > >> sudo ip -s -s neigh flush all > So basically, iptable and ebtable rules have no effect on packets from A > to B. However, I see those packets on wireshark and they definitely go > through the Ubuntu machine that is hosting the access point. And that's > exactly my dilemma, how to block those packets from going through. >
