Hotspot behind NAT/CGNAT
The hotspot uses its normal access provider exactly as before. It does not require a public or static address.
DEMO 4 · FOR ISPs AND NETWORK OPERATORS
Keep TaraSec security signals meaningful across NAT and CGNAT.
Demo 4 addresses a practical inter-ISP problem: a TaraSec hotspot or access network may sit behind another provider's NAT or CGNAT, so its visible public source address is shared, temporary or outside its control. TaraSec therefore separates the security path from the hotspot's ordinary Internet path.
THE ISP CHALLENGE
Public source IP is a poor long-term security identity.
A hotspot behind a mobile operator or broadband provider may have no stable public address of its own. Requiring static public IPs for every participating hotspot would be expensive, operationally difficult and unrealistic at scale.
At the same time, a receiving ISP needs a reliable way to distinguish ordinary Internet traffic from traffic that arrives through a recognized TaraSec security path carrying actionable threat information.
THE DEMO 4 MODEL
Normal traffic stays with the access ISP. Only TaraSec-selected security traffic uses the special path.
TaraSec selects the flow
Only traffic associated with the relevant TaraSec security state is selected. Ordinary browsing and normal customer traffic remain on the ordinary ISP path.
Selective encrypted egress
The selected traffic is sent through an automatically provisioned encrypted tunnel to a TaraSec egress router with a stable public address.
Receiving ISP recognizes the path
The receiving ISP sees a stable TaraSec egress source and can combine that transport provenance with the TaraSec security signal when applying its own policy.
NOT WHITELISTING
The objective is more reliable blocking and threat handling.
The fixed TaraSec egress address does not mean the traffic is trusted or should be accepted. It identifies that the traffic reached the receiving ISP through a recognized TaraSec security path.
The receiving ISP remains fully in control. It may block, rate-limit, investigate, log, correlate or ignore the signal according to its own policy. TaraSec is intended to improve the quality and provenance of negative security information, not to create a bypass around normal security controls.
STANDARD HOTSPOT INSTALLATION
The tunnel registration must be automatic.
A deployment model that requires manual VPN setup for each hotspot will not scale.
Install TaraSec hotspot
The standard hotspot install routine generates the required tunnel credentials automatically.
Register the hotspot
The hotspot registers its public tunnel key and TaraSec gateway identity with the TaraSec control plane.
Assign an egress router
TaraSec assigns an appropriate public egress router and an internal tunnel address.
Provision both ends
The egress router receives the hotspot peer automatically. The hotspot initiates the encrypted tunnel outward, so upstream NAT/CGNAT needs no inbound configuration.
WATCH A LIVE TEST
See the source IP received by TaraSec.org.
Run Demo 4 in the TaraSec app and open its shared viewer link on another screen. The website records the CLEAN and INFECTED requests as they arrive and displays their observed source IPs. The route must be configured to target this website for a change to appear.
WHAT THE RECEIVING ISP NEEDS
A small number of recognizable TaraSec egress paths.
The receiving ISP does not need to track the changing public addresses of thousands of hotspots. It only needs to recognize the comparatively small set of TaraSec egress routers used for this security signalling path.
The egress IP identifies the TaraSec transport path, not the end user. Unit-level attribution remains in TaraSec's technical identity and reporting model.
WHAT DEMO 4 MUST PROVE
Two similar flows from the same hotspot, deliberately taking different paths.
Ordinary traffic from the hotspot must continue to leave through the access ISP. A TaraSec-selected security flow must leave through the assigned TaraSec public egress router. The receiving network should therefore observe the normal access-provider source for ordinary traffic and the stable TaraSec egress source for selected security traffic.
This is the core ISP-facing test. If all hotspot traffic is tunneled, or if every destination requires manual route configuration, the design is solving a different problem.
WHY THIS MATTERS TO ISPs
Security cooperation without changing customer access architecture.
Demo 4 is intended to show that an ISP can participate in TaraSec even when the original traffic source sits behind another operator's NAT or CGNAT. The access provider can continue operating normally, while receiving networks get a recognizable path for TaraSec security-signalled traffic.
This allows TaraSec's cooperative blacklist and threat-state model to work across independently operated networks without requiring shared addressing, common ownership or a centralized firewall policy.
What if the partner stops tagging?
Demo 5 tests partner accountability using ordinary rejection reports, DB distribution and temporary receiver-side restrictions.