Il est par définition impossible de récupérer l'URL en https ou http/2.
L'IP locale (en 192.168.x.x) a peu d’intérêt, non ?

Tu pourrais par contre enregistrer :
- L'IP cible
- Le protocole de niveau 4 (TCP, UDP, ICMP,...)
- Le port cible si TCP/UDP
- Le port source si TCP/UDP
- L'adresse Mac source faut de pouvoir mieux identifier le client
- La date et l'heure

En HTTPS, à défaut d'avoir l'URL complète t'auras au moins la destination au niveau DNS plutôt qu'une IP.

Sous Squid par exemple ça donne : blabla CONNECT safebrowsing.google.com:443 - HIER_DIRECT/2a00:1450:400c:c09::88

Pour IP et MAC, conserves-les à part ainsi que les logs DHCP. Tu te fais une table MAC/IP/HEURE et un journal pour le trafic HTTP/HTTPS/Autre.

Iptables permet de faire un log complet (par contre c'est dans /var/log/messages donc un vrai bazar pour s'y retrouver) et pour les logs http il faudra utiliser autre chose

le bout de code à rajouter à son firewall (utiliser pour le DROP, à modifier pour ACCEPT et rajouter la variante ip6tables au besoin) :

iptables -N LOG_DROP
iptables -A LOG_DROP -j LOG --log-prefix '[IPTABLES DROP]:'
iptables -A LOG_DROP -j DROP
iptables -t filter -A INPUT -j LOG_DROP
iptables -t filter -A OUTPUT -j LOG_DROP
iptables -t filter -A FORWARD -j LOG_DROP

ça permet dans cet exemple de loguer tous les paquets rejetés sans devoir le spécifier dans toutes les règles. Je pense que le contraire doit être possible. A absolument parser le résultat est illisible

Voici un exemple avec quelques infos masquées:

Jan 18 22:11:13 vpsxxxxx kernel: [1383105.821026] [IPTABLES DROP]:IN=eth0 OUT= MAC=fa:16:3e:c7:d4:1d:58:00 SRC=220.134.140.___ DST=___ LEN=29 TOS=0x00 PREC=0x00 TTL=49 ID=17404 DF PROTO=UDP SPT=39724 DPT=53413 LEN=9
Jan 18 22:11:15 vpsxxxxx kernel: [1383107.742037] [IPTABLES DROP]:IN=eth0 OUT= MAC=fa:16:3e:c7:d4:1d:56::00 SRC=220.134.140.___ DST=___ LEN=29 TOS=0x00 PREC=0x00 TTL=49 ID=17405 DF PROTO=UDP SPT=39724 DPT=53413 LEN=9
Jan 18 22:11:18 vps2xxxxx kernel: [1383110.588777] [IPTABLES DROP]:IN=eth0 OUT= MAC=fa:16:3e:c7:d4:1d:08:00 SRC=220.134.140.___ DST=___ LEN=29 TOS=0x00 PREC=0x00 TTL=49 ID=17406 DF PROTO=UDP SPT=39724 DPT=53413 LEN=9
Jan 18 22:11:53 vpsxxxxx kernel: [1383145.335773] [IPTABLES DROP]:IN=eth0 OUT= MAC=fa:16:3e:c7:d4:1d:56:5:08:00 SRC=125.93.79.___ DST=___ LEN=132 TOS=0x00 PREC=0x00 TTL=49 ID=39710 PROTO=UDP SPT=53 DPT=62207 LEN=112
Jan 18 22:12:30 vpsxxxxx kernel: [1383182.646835] [IP6TABLES DROP]:IN=eth0 OUT= MAC= SRC=fe80:0000:0000:0000:f816:3eff:fec7:d41d DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=120 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=134 CODE=0
Jan 18 22:12:32 vpsxxxxx kernel: [1383184.618421] [IPTABLES DROP]:IN=eth0 OUT= MAC=fa:16:3e:c7:d4:1d:8:00 SRC=93.20.26.___ DST=___ LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=1 PROTO=ICMP TYPE=8 CODE=0 ID=46801 SEQ=0
Jan 18 22:12:34 vpsxxxxx kernel: [1383186.110494] [IPTABLES DROP]:IN=eth0 OUT= MAC=fa:16:3e:c7:d4:1d:08:00 SRC=93.20.26.___ DST=___ LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=18562 PROTO=ICMP TYPE=8 CODE=0 ID=1894 SEQ=0
Jan 18 22:14:41 vpsxxxxx kernel: [1383313.967651] [IPTABLES DROP]:IN=eth0 OUT= MAC=fa:16:3e:c7:d4:1d::5f:08:00 SRC=59.45.79.___ DST=___ LEN=40 TOS=0x00 PREC=0x00 TTL=234 ID=54321 PROTO=TCP SPT=37352 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0
Jan 18 22:17:47 vpsxxxxx kernel: [1383499.213842] [IPTABLES DROP]:IN=eth0 OUT= MAC=fa:16:3e:c7:d4::5f:08:00 SRC=71.6.165.___ DST=___ LEN=40 TOS=0x00 PREC=0x00 TTL=114 ID=2861 PROTO=TCP SPT=34680 DPT=8888 WINDOW=42959 RES=0x00 SYN URGP=0
Jan 18 22:18:14 vpsxxxxx kernel: [1383527.041147] [IPTABLES DROP]:IN=eth0 OUT= MAC=fa:16:3e:c7:d4:1d08:00 SRC=162.210.193.___ DST=___ LEN=444 TOS=0x00 PREC=0x00 TTL=52 ID=0 DF PROTO=UDP SPT=5949 DPT=5060 LEN=424

Des obligations qui ont pour conséquences de vandaliser la neutralité du net sur l'accès : les ports accessibles sont 80 et 443 sur la majorité, ça procure par la même occasion une satisfaction aux ayants-droits, en conséquence les lobbyistes payent bien et tout le monde est content 
(sauf nous hein)

Faut pas se leurrer, celui qui voudra se servir de l'accès pour ses petites affaires anonymement saura contourner les proxys transparents et autres, il reste plus que l'honnête citoyen qui récupère des films de vacances et des distributions qui sera contraint d'avoir son traffic analysé.

Pour les plus curieux à l'aide du RIPE et avec de la documentation de certains blogueurs, on peut retrouver les plages IP des serveurs utilisés par des sous-traitants d'une célèbre institution envoyant quelques milliers de missives par an

Y'a rien dans les packages OpenWrt pour faire ca deja ?

Ta borne c'est un portail captif ou juste un VPN ?

les logs sont a stocker ou?

OpenWRT fait bien une sorte de TCPDump, mais je trouvais plus avantageux de le faire à la sortie du VPN, pour ne pas à avoir uploader les logs via un upload souvent assez faible (ADSL).
Ma borne à un portail captif : https://studentstartup.me/DEMO/ (ici c'est juste une démo il n'y a pas de système à proprement parlé)
Les utilisateurs accèdent au Web via ce portail captif et via le VPN.
Les logs peuvent-être stocké sur nos disques, il y a de la place. Ces serveurs se trouvent au même endroit que le serveur VPN.

Mais quel intérêt de garder des logs si tu ne sais pas remonter à l'utilisateur ?

Garder l'adresse MAC du client Wifi permet de faire quoi ? (a part des stats sur les marques)

En fait si, on peut remonter à l'utilisateur grâce aux informations qu'ils renseignent via le portail captif (nom, prénom, mél). On associe son IP locale à son nom en fonction de l'heure et on à les URLs qu'il visite à un temps X.
Ce n'est pas très facile mais bon, à défaut d'avoir mieux on s'en contente. Le but de cette borne WiFi est d'avoir le moins de contraintes possibles pour se connecter au Web.

Pour les @ MAC, aucune idée. Nous n'utilisons pas du tout les données récoltées. C'est l'ARCEP qui "l'impose".

Cdt,
DamienC