External Communications · Documentation

This page documents the external network communication that PacketSafari may initiate in the current on-prem runtime.

Use it as an operator reference for:

firewall and proxy reviews
security questionnaires
change review for new integrations
troubleshooting blocked outbound traffic

PacketSafari forces monitored application containers through the egress proxy. Direct outbound bypasses are rejected. See Local Models and External AI Approval for the enforcement model and custom host approval flow.

If the customer network requires a corporate outbound proxy, PacketSafari can chain egress-ironproxy through a standard HTTP proxy with packetsafari-ops config upstream-proxy. Backend and worker should still point at PacketSafari's internal egress proxy, not directly at the corporate proxy.

Scope

This inventory focuses on outbound traffic initiated by the application runtime and operator tooling that is represented in the current code and egress policy.

It does not try to restate:

normal browser traffic from an end user to the PacketSafari web UI
inbound customer integrations
one-off developer downloads during local builds outside the on-prem runtime

Classification meanings

Classification	Meaning
`required-core`	Expected in normal runtime when the corresponding core feature is in use.
`feature-optional`	Only used when the related product feature or integration is enabled.
`admin-only`	Expected during operator or admin maintenance flows, not ordinary user traffic.
`dynamic-config`	Destination is not fixed in code and is derived from administrator-provided configuration.

Core and feature-driven outbound traffic

Destination	Port	Owner containers	Classification	Purpose	Trigger / notes
`api.openai.com`	`443`	`backend`, `worker`	`required-core`	AI API traffic	Primary OpenAI API endpoint for Agent / Copilot when OpenAI is the configured provider.
`auth.openai.com`	`443`	`backend`, `worker`	`feature-optional`	AI auth	Used for Codex device login flows when that workflow is enabled.
Admin-configured AI provider host	usually `80` or `443`	`backend`, `worker`	`feature-optional`, `dynamic-config`	AI provider traffic	Derived from `admin_ai_settings.provider_base_url` when a non-OpenAI provider is configured. Requires explicit approval if outside the PacketSafari container network.
`email.eu-central-1.amazonaws.com`	`443`	`backend`, `worker`	`feature-optional`	Mail delivery	AWS SES HTTPS endpoint used by the active mail send path.
`api.paddle.com`	`443`	`backend`	`feature-optional`	Billing / account features	Production Paddle API.
`sandbox-api.paddle.com`	`443`	`backend`	`feature-optional`	Billing / account features	Sandbox Paddle API.
`github.com`	`443`	`backend`	`feature-optional`	User auth	Added only when the `ENABLE_SOCIAL_LOGIN_OAUTH` runtime feature flag is enabled for GitHub social login.
`api.github.com`	`443`	`backend`	`feature-optional`	User auth / GitHub-backed admin checks	Added only when the `ENABLE_SOCIAL_LOGIN_OAUTH` runtime feature flag is enabled.
`oauth2.googleapis.com`	`443`	`backend`	`feature-optional`	User auth	Added only when the `ENABLE_SOCIAL_LOGIN_OAUTH` runtime feature flag is enabled for Google social login.
`www.googleapis.com`	`443`	`backend`	`feature-optional`	User auth	Added only when the `ENABLE_SOCIAL_LOGIN_OAUTH` runtime feature flag is enabled for Google social login.
`www.openinfosecfoundation.org`	`443`	security-intelligence runtime	`feature-optional`	Security intelligence	Suricata source index for runtime intelligence refresh.
`sslbl.abuse.ch`	`443`	security-intelligence runtime	`feature-optional`	Security intelligence	abuse.ch SSL blacklist feed used by Suricata refresh.
Admin-configured intelligence feed hosts	usually `443`	security-intelligence runtime	`feature-optional`, `dynamic-config`	Security intelligence	Derived from configured `INTELLIGENCE_*_SOURCE_URL` values.

Admin-only outbound traffic

Destination	Port	Owner containers	Classification	Purpose	Trigger / notes
`raw.githubusercontent.com`	`443`	`backend`	`admin-only`	Admin dependency inventory	Included only in the `dev` egress profile for GitHub-hosted dependency inventory source checks.
`registry.npmjs.org`	`443`	`backend`	`admin-only`	Admin dependency inventory	Included only in the `dev` egress profile for npm package freshness checks.
`pypi.org`	`443`	`backend`	`admin-only`	Admin dependency inventory	Included only in the `dev` egress profile for Python package freshness checks.
`proxy.golang.org`	`443`	`backend`	`admin-only`	Admin dependency inventory	Included only in the `dev` egress profile for Go module freshness checks.
`hub.docker.com`	`443`	`backend`	`admin-only`	Admin dependency inventory	Included only in the `dev` egress profile for container image freshness checks.
`api.launchpad.net`	`443`	`backend`	`admin-only`	Admin dependency inventory	Included only in the `dev` egress profile for Launchpad package freshness checks for Suricata-related packages.

Notes on owners

The Owner containers column describes which runtime lane initiates the request:

backend: Flask/API runtime and admin actions
worker: background worker lanes such as AI or indexing tasks
security-intelligence runtime: the runtime path responsible for intelligence feed refresh and related security update flows

Current deployments may split that security-intelligence work differently depending on compose wiring. For firewall review, the important point is the destination and purpose, not whether the request originates from a dedicated security worker process or a fallback application process.

Dynamic destinations

Some destinations are intentionally not hard-coded:

Dynamic source	Examples	Why it is dynamic
AI provider base URL	`https://llm.company.example/v1`, `http://ai-gateway.internal.example:8000/v1`	PacketSafari supports OpenAI-compatible local, LAN, and on-prem model endpoints selected by an admin.
Intelligence feed source URLs	vendor-hosted Suricata or JA4 feed URLs	Admins can configure custom HTTPS feed sources in the intelligence settings UI.

These dynamic destinations should be documented in customer change control when they are added.

Corporate outbound proxy path

For Zscaler or similar enterprise proxy deployments, the expected path is:

backend / worker -> egress-ironproxy -> corporate HTTP proxy -> approved external destination

Configure the corporate proxy as an upstream hop for egress-ironproxy:

/opt/packetsafari/bin/packetsafari-ops config upstream-proxy \
  --proxy-url http://zscaler-proxy.customer.example:8080 \
  --no-proxy localhost,127.0.0.1,::1 \
  --restart

The command writes /opt/packetsafari/env/ironproxy.env.

If TLS inspection is enabled, install the inspection root CA at /opt/packetsafari/configuration/custom-ca/<name>.crt and restart egress-ironproxy. The destination allowlist still applies to the final destination host, even when the physical network hop is the corporate proxy.

Operational guidance

Question	Answer
Does saving a new AI base URL automatically open egress?	No. External destinations still require explicit host approval.
Does blank Suricata source configuration mean no outbound traffic?	No. Blank Suricata configuration still uses the built-in ET Open and abuse.ch sources.
Are all destinations contacted in every deployment?	No. Many rows are feature-optional or admin-only.
Is direct internet egress from app containers allowed?	No. Monitored containers are forced through the egress proxy and direct bypasses are rejected.
Can PacketSafari run behind Zscaler or another enterprise proxy?	Yes, when it exposes a standard HTTP proxy endpoint. Configure it with `packetsafari-ops config upstream-proxy ... --restart`.