Tenant Session Tracking and Abuse Attribution in Multi-Family WiFi: Mapping Meraki Flows to Purple iPSK Identity

To attribute abuse on a single-public-IP MDU network, you join two records. The Meraki MX flow export maps the public IP, translated source port and timestamp back to an internal IP, MAC and VLAN. Purple's iPSK identity and RADIUS accounting records map that MAC and VLAN to an apartment. Keep both for 365 days, subject to legal advice.

What does abuse attribution actually do on an MDU network?

Purple Multi-Tenant WiFi gives every resident in a multi-dwelling unit (MDU), Multi-Family block or Student Housing residence a private network that feels like home broadband. Behind that experience sits one hard architectural fact. Every resident leaves the building through the same public WAN address, using port address translation (PAT). PAT is a form of NAT where many internal hosts share one public IP, distinguished only by the source port the gateway assigns. When a copyright holder, an abuse desk or a police officer looks you up, they see one IP. They expect one subscriber behind it. You have hundreds.

Abuse attribution rebuilds that lost mapping. It does this from two independent data planes: the gateway's network flows and Purple's identity records. Neither one is enough alone. Joined on MAC address, VLAN and time, they take you from a public IP and port to a named apartment.

Why one public IP breaks attribution

A typical notice under the US Digital Millennium Copyright Act (DMCA), 17 U.S.C. § 512, carries three fields: public IP, source port and timestamp. RFC 6302, the IETF's guidance for internet-facing servers, recommends logging the source port and an accurate timestamp precisely because shared addressing makes the IP alone ambiguous. Your job is to honor that design. If your logs hold the translated port and a disciplined clock, the notice becomes answerable. If they do not, you can identify the building and nothing more.

What iPSK contributes

This guide assumes you already know what iPSK (Identity Pre-Shared Key) is. Purple's guides "Implementing iPSK for secure IoT" and "iPSK vs 802.1X: a comparison" cover the prerequisite. In short, iPSK issues each tenant a unique passphrase on a shared SSID, and the RADIUS server binds that key to an identity. RADIUS (Remote Authentication Dial-In User Service, RFC 2865) authenticates the session. RADIUS Accounting (RFC 2866) logs when it starts, how long it lasts and when it stops. This guide covers the operational layer on top: turning those identity records into evidence you can hand to counsel.

What do you need before you start?

You need four things in place before the first notice arrives. Building them after the fact does not work, because the evidence you need is already gone.

1. A VLAN-per-iPSK design. Each tenant's key drops their devices into a dedicated layer-3 segment before the NAT boundary.
2. A flow export from the Meraki MX carrying pre-NAT and post-NAT addressing with timestamps.3. Purple RADIUS Accounting enabled, plus a regular export of the iPSK-to-tenant map.
3. A retention policy signed off by legal counsel, and NTP running on every device in the chain.

Why VLAN-per-iPSK beats a flat shared SSID

A VLAN (virtual LAN) is a logical layer-2 segment, defined in IEEE 802.1Q, that isolates one group of devices from another. Purple's RADIUS response can assign a VLAN per iPSK, so each apartment lands in its own subnet. That subnet becomes a second, independent identifier. Even if a MAC is spoofed or randomized, the internal source IP still names the apartment's segment.

Design	Attribution granularity	Survives MAC randomization	Tenant isolation	Who it suits
Flat shared SSID, one PSK	Building only	No	None by default	Small cafe or lobby guest network, not residential
Shared SSID, iPSK, no VLANs	Device MAC to tenant	Partly, via accounting record at session time	Client isolation only	Interim step during migration
iPSK with VLAN per tenant	Apartment subnet and MAC	Yes, the subnet still identifies the apartment	Layer-3 segmentation per apartment	Multi-Family, MDU, Student Housing, serviced apartments
802.1X with per-person credentials	Named individual	Yes	Per-user policy	Corporate multi-tenant offices with managed devices

For residential estates, VLAN-per-iPSK is the right default. It gives you two identifiers that must agree: the VLAN and the MAC. 802.1X (the IEEE port-based access control standard) reaches the individual. However, it struggles with game consoles, smart TVs and other devices residents bring.

How do you set up the two data captures?

Capture 1: network flows from the Meraki MX

The Meraki MX can send event and flow data by Syslog (RFC 5424) and export traffic records by NetFlow version 9 (RFC 3954). Configure both in the Meraki Dashboard under the appliance's reporting settings. Follow Cisco Meraki's own documentation for the current menu paths.

What matters is the field set reaching your collector. For each translated connection you need:

• Internal source IP and source port
• Client MAC address, or a reliable IP-to-MAC binding from DHCP logs
• VLAN or source subnet
• Post-NAT public IP and translated source port
• Start and end timestamps, at millisecond resolution where the exporter supports it

The post-NAT port is the field operators most often find missing. In IPFIX (RFC 7011), the relevant information elements are postNATSourceIPv4Address and postNAPTSourceTransportPort, both defined in the IANA IPFIX registry. Before you rely on the export, capture a sample. Confirm your firmware populates the translated port. If it does not, your fallback is the MX firewall and flow Syslog combined with a NAT translation log from an upstream device that does record it. Settle this before you need it. Pair the flow data with DHCP lease logs. Leases give you a time-bounded IP-to-MAC binding. That binding is your safety net when a flow record carries IP but not MAC.

Capture 2: identity from Purple

Purple contributes the identity half of the join. RADIUS Accounting records carry the client MAC in the Calling-Station-Id attribute, the access point in Called-Station-Id, and session start and stop times. Accounting is a standard part of Purple's RADIUS configuration on every supported vendor. The Purple support article for Avaya shows a typical setup, with accounting enabled and an interim accounting interval set.

That same article flags a detail that will trip your join. Vendors format MAC addresses differently: upper-case hyphenated on one, lower-case colon-separated on another. Normalize every MAC to one format at ingest, on both data planes.

The second identity input is the iPSK-to-tenant map: which key belongs to which apartment, and which VLAN it assigns. Export this daily from Purple. Then you hold a dated snapshot of who held each key on the day in question, not just who holds it today. Leases change. A key that belongs to apartment 4.12 today may have belonged to a previous resident six months ago.

Building the pipeline yourself

If you do not already centralize Meraki Syslog, a lightweight open-source pipeline covers it. A small Linux virtual machine is enough for most single-site properties.

1. Collector. Run Fluentd or Logstash. Listen on UDP 514, the IANA-assigned Syslog port, and on your chosen NetFlow port; UDP 2055 is the common convention. Logstash parses NetFlow v9 and IPFIX with its netflow codec.
2. Normalize at ingest. Convert all timestamps to UTC. Convert all MACs to one format. Tag every record with site and VLAN.
3. Store. Route into Elasticsearch or Grafana Loki. In Elasticsearch, an Index Lifecycle Management (ILM) policy rolls indices daily and deletes them at your retention limit. In Loki, the compactor enforces a retention period. Either way, deletion is automatic and auditable.
4. Identity snapshot. Schedule a daily cron job that pulls the active iPSK-to-tenant map from Purple. Write it to a dated local lookup table. Keep the snapshots on the same retention schedule as the flows.
5. Access control. Restrict query access to named staff. Log every search. These records identify residents, so treat them as personal data under CCPA/CPRA.

The result: at subpoena time, you run the join offline, against your own data, without waiting on any third party.

How do you answer an abuse notice?

When a notice arrives, run the same workflow every time.

Abuse notice
(public IP, source port, timestamp)
        |
        v
[1] Meraki flow log
    match post-NAT IP + translated port
    within +/- clock tolerance
        |
        v
(internal IP, MAC, VLAN)
        |
        v
[2] Purple RADIUS Accounting
    match MAC with session active at timestamp
        |
        v
[3] Dated iPSK-to-tenant snapshot
    match iPSK + VLAN on that date
        |
        v
Apartment / registered occupant

Three checks keep the result defensible:

• Time-zone discipline. Convert the notice timestamp to UTC first. Many notices arrive in the sender's local time.
• Agreement between identifiers. The VLAN from the flow record must match the VLAN the iPSK assigns. A mismatch means something is wrong. Stop and investigate before you name anyone.
• Counsel decides disclosure. Your output is an internal attribution record. Whether and how to disclose, notify the resident or push back is a legal decision.

Worked example: from notice to apartment

This chain uses documentation addresses (RFC 5737) and fictional values.

1. Notice. A rights holder reports a file-sharing event from 203.0.113.10, source port 41822, at 22:17:05 UTC on 03/14.
2. Flow query. You search the MX flow index for post-NAT IP 203.0.113.10 and translated port 41822, between 22:17:03 and 22:17:07. One record matches. Internal source 10.40.12.37, port 51544, VLAN 412.
3. IP to MAC. The DHCP lease log shows 10.40.12.37 bound to MAC 3C-22-FB-1A-7E-09 from 19:02 to 23:58 that day.
4. Identity query. Purple RADIUS Accounting shows that MAC with an active session from 19:02 to 00:41. The session authenticated with the iPSK assigned to VLAN 412.
5. Tenant lookup. The 03/14 iPSK snapshot maps that key and VLAN 412 to apartment 4.12. You hand the chain to counsel.

Each hop is a timestamped record from an independent system. That independence is what makes the chain credible.

How do you check the chain works?

Do not wait for a real notice to discover a gap. Run a quarterly drill:

• From a test device on a known iPSK, open a connection to an external server you control. Record the public IP, port and time from that server's logs.
• Run the full workflow blind, starting only from the server-side record.
• Confirm you land on the correct test apartment. Note how long it took.
• Check the oldest record in each index sits at your retention limit and no further. Over-retention is a CCPA/CPRA problem in its own right.

If the drill fails, the most common cause is a missing post-NAT port or a clock offset. Both are covered below.

What breaks the attribution chain, and how do you fix it?

Clock drift

The join depends on time. Translated ports are reused within seconds on a busy gateway, so a few seconds of drift can match the wrong flow. Point the MX, your access points, the collector and any upstream NAT device at the same NTP (Network Time Protocol, RFC 5905) sources. Log in UTC everywhere. Alert when any device's offset exceeds one second. If two flows match inside your tolerance window, report the ambiguity to counsel rather than choosing one.

Carrier-grade NAT upstream

Some ISPs place your WAN behind carrier-grade NAT (CGNAT, described in RFC 6888). Your MX's public address is then itself private. The notice will carry the ISP's shared address and port. Only the ISP can map that to your WAN, and only your logs can map your WAN to an apartment. Your records become the sole attribution record inside the building. Ask your ISP whether you sit behind CGNAT, and request a dedicated public IP where you can.

PSK sharing between tenants

If a resident gives their iPSK to a neighbor, both households appear as one apartment. Enforce device enrollment: cap devices per iPSK and require residents to register new devices through Purple. Review keys whose device count or concurrent sessions jump suddenly. Rotate a key on move-out the same day, as part of your joiners, movers and leavers process.

MAC randomization

Current iOS and Android releases present a private MAC per network by default, and some settings rotate it. This is why you join on the RADIUS Accounting record active at the timestamp, not on a static register of enrolled devices. With VLAN-per-iPSK, the subnet still names the apartment even when a MAC is new.

How long should you keep the logs?

Retention is a legal question. Agree it with local counsel before you configure anything. As a working floor, most operators keep flow and identity records for 365 days. That covers the time a civil subpoena or police request usually takes to arrive.

Two pressures pull in opposite directions. Under CCPA/CPRA, you may keep personal data only as long as the purpose requires. In the UK, the Investigatory Powers Act 2016 caps data retention notices at 12 months. In the US, DMCA § 512(h) subpoenas can arrive well after the event. Write the agreed period into your privacy notice and lease terms. Then let ILM or Loki retention enforce it automatically.

What does it cost, and what do you get back?

The DIY pipeline runs on one modest virtual machine plus storage. Size the storage by measuring one week of flow volume, multiplying by 52 and adding headroom. Purple's contribution, the iPSK identity layer and RADIUS Accounting, runs on the access points you already own. Purple is hardware-agnostic across Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet, with no rip and replace.

The return is measured in avoided disruption. Two illustrative scenarios show the difference.

Scenario 1: serviced apartments in a hospitality estate

A 180-unit serviced-apartment block, run alongside a hotel operation, received repeated copyright notices on a flat shared network. With no way to attribute them, the operator emailed a warning to every resident. Complaints followed, and the ISP threatened suspension. The operator moved to VLAN-per-iPSK on its existing Meraki estate and stood up the Logstash pipeline above. The next notice resolved to a single apartment in under 20 minutes. Only that resident was contacted, and no further building-wide warnings were needed.

Scenario 2: public-sector key-worker housing

A council-owned block of 90 key-worker apartments near a hospital site received a police data request about one public IP and port. The housing team had iPSK and VLANs per apartment, but kept only 30 days of logs. The event fell outside that window. After legal review, the team extended retention to 365 days, added the daily identity snapshot and began quarterly drills. A later request was answered within one business day, naming one apartment, with every hop documented for counsel.

Where this fits in your wider estate

The same problem appears in corporate multi-tenant offices. A coworking operator, or a SaaS provider running shared infrastructure across client tenants, faces one public IP and many organizations behind it. Purple Staff WiFi applies the same identity-first model there, typically with 802.1X and Microsoft Entra ID, Okta or Google Workspace as the identity source. The flow join described here carries across unchanged. The same pattern serves mixed-use retail schemes with apartments above shops, and healthcare estates running staff accommodation.

For background, see Purple Multi-Tenant WiFi and Purple's iPSK guides, "Implementing iPSK for secure IoT" and "iPSK vs 802.1X: a comparison". If you are comparing cloud RADIUS providers for this role, read IronWiFi Alternatives for Enterprise Deployments.

Frequently asked questions

Do we need to replace our Meraki hardware to get tenant-level attribution?

No. Purple layers on top of your existing Cisco Meraki access points and MX appliances as a cloud overlay. You enable iPSK with VLAN assignment through Purple's RADIUS, turn on RADIUS Accounting, and configure flow export on the MX. The same approach works on HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. The gateway only needs to export pre-NAT and post-NAT addressing with timestamps.

Does Purple store the Meraki flow logs for us?

No. Purple holds the identity half of the chain: iPSK assignments, VLAN mapping and RADIUS Accounting sessions. The Meraki flow and NAT records stay in a collector you control, whether that is Elasticsearch, Grafana Loki or an existing SIEM. That split keeps you in charge of retention, access control and disclosure. Those are decisions your counsel should own, not a third party.

How long should we keep flow and identity logs?

Most operators keep both for 365 days, but retention is a legal decision for your counsel. CCPA/CPRA regulations limit retention to what is reasonably necessary and proportionate for the purpose. Whatever period you agree, publish it in your privacy notice and enforce automatic deletion with ILM or Loki retention.

Is logging resident traffic compatible with CCPA/CPRA?

Yes, provided you log connection metadata, not content, and handle it as personal data. Record a lawful basis, state the purpose and retention period in your privacy notice, and ensure residents have clear opt-out or disclosure rights where applicable. Restrict query access to named staff and audit every search. Purple is ISO 27001 certified and GDPR compliant, so the identity side already sits inside a certified control framework.

What if a resident shares their iPSK with a neighbor?

Shared keys collapse two households into one apartment record, so you must prevent them. Cap the number of devices per iPSK and require residents to register new devices through Purple. Watch for sudden jumps in device count or concurrent sessions. With VLAN-per-iPSK, the shared key still maps to one apartment's segment. That gives counsel a defensible starting point, with a documented caveat.

Can we answer a subpoena if our ISP uses carrier-grade NAT?

Yes, but only if your own logs are complete. Behind CGNAT, the notice carries the ISP's shared address. The ISP maps that to your WAN, and your records must map your WAN to an apartment. Your logs are then the only attribution record inside the building. Ask your ISP for a dedicated public IP where possible, and keep NTP discipline tight.

How much effort does a DIY logging pipeline take to deploy?

A competent network engineer can stand up the open-source pipeline on one Linux virtual machine. That covers a Fluentd or Logstash collector, Elasticsearch or Loki storage, an automated retention policy and a daily identity export from Purple. The larger effort is validation. Confirm your MX firmware exports the translated source port, then run a blind attribution drill before you rely on the pipeline for a live notice.