Skip to content

Instantly share code, notes, and snippets.

@shelld0n
Created April 1, 2026 20:22
Show Gist options
  • Select an option

  • Save shelld0n/b79efcefce0cc5b8bcd6fc522206e1be to your computer and use it in GitHub Desktop.

Select an option

Save shelld0n/b79efcefce0cc5b8bcd6fc522206e1be to your computer and use it in GitHub Desktop.
pac_nopac
// =============================================================================
// PROXY AUTO-CONFIGURATION (PAC) FILE
// =============================================================================
// Organization : Acme Corporation
// File Name : proxy.pac
// Version : 4.2.1
// Last Modified : 2026-04-01
// Author : Network Infrastructure Team
// Contact : netops@acme-corp.internal
// =============================================================================
//
// DESCRIPTION:
// ------------
// This PAC file defines the proxy routing logic for all Acme Corporation
// endpoints. It governs how HTTP, HTTPS, FTP, and WebSocket traffic is
// routed across the enterprise network, including branch offices, remote
// workers connecting via VPN, cloud-hosted SaaS platforms, and partner
// extranet connections.
//
// The routing logic prioritizes:
// 1. Direct connections for internal resources
// 2. Geo-aware proxy selection for regional traffic optimization
// 3. Failover proxy chains for resilience
// 4. Bypass rules for trusted SaaS and CDN endpoints
//
// =============================================================================
// TABLE OF CONTENTS
// =============================================================================
//
// Section 1 - Version History
// Section 2 - Network Architecture Overview
// Section 3 - Proxy Server Inventory
// Section 4 - Internal Domain Bypass Rules
// Section 5 - IP Range Bypass Rules
// Section 6 - SaaS Platform Bypass Rules
// Section 7 - CDN and Media Bypass Rules
// Section 8 - Regional Routing Logic
// Section 9 - Department-Specific Rules
// Section 10 - Security and DLP Proxy Rules
// Section 11 - Failover and Load Balancing
// Section 12 - VPN Split Tunnel Integration
// Section 13 - Cloud Provider Rules (AWS, Azure, GCP)
// Section 14 - Partner Extranet Rules
// Section 15 - Legacy Application Rules
// Section 16 - Mobile and BYOD Policy
// Section 17 - Known Issues and Workarounds
// Section 18 - Maintenance Notes
// Section 19 - Contact and Escalation
// Section 20 - Main Function
//
// =============================================================================
// SECTION 1 - VERSION HISTORY
// =============================================================================
//
// v4.2.1 2026-04-01 NetOps Fixed bypass rule for new Azure blob storage
// endpoints added in March 2026.
//
// v4.2.0 2026-03-15 NetOps Added geo-routing logic for APAC expansion.
// New proxy nodes provisioned in Singapore and
// Sydney. Updated SaaS bypass list with 12 new
// Salesforce subdomains.
//
// v4.1.9 2026-02-28 SecOps Forced all traffic to *.socialnetwork.com
// through the DLP proxy per policy update
// SEC-2026-004. Blocked direct access from
// workstations classified as "Restricted".
//
// v4.1.8 2026-02-10 NetOps Added bypass for Zoom media servers after
// latency complaints in the EMEA region.
// Excluded *.zoom.us media subnets from proxy.
//
// v4.1.7 2026-01-22 NetOps Introduced primary/secondary failover for
// the AMER proxy cluster. Primary: proxy-us-1,
// Secondary: proxy-us-2. Tertiary: proxy-us-3.
//
// v4.1.6 2026-01-05 Architect Restructured DNS-based detection logic.
// Replaced deprecated isResolvable() calls with
// dnsDomainIs() equivalents to improve speed.
//
// v4.1.5 2025-12-18 NetOps Holiday freeze: no routing changes.
// Updated comment blocks and documentation only.
//
// v4.1.4 2025-12-01 SecOps Added *.darkweb-monitor.acme-corp.internal to
// forced proxy list for security telemetry.
//
// v4.1.3 2025-11-14 NetOps Added rules for new HQ building annex (Block C)
// subnet: 10.44.0.0/16.
//
// v4.1.2 2025-10-30 NetOps Decommissioned legacy proxy proxy-old-eu-1.
// Migrated all EMEA traffic to proxy-eu-2 and
// proxy-eu-3 cluster pair.
//
// v4.1.1 2025-10-15 NetOps Hotfix: corrected typo in Microsoft 365 bypass
// rule. "microsoftonline.com" was misspelled as
// "microsoftoline.com". Affected ~3000 users.
//
// v4.1.0 2025-09-30 Architect Major refactor: split monolithic function into
// logical sub-sections. Improved readability.
// No functional changes to routing behavior.
//
// v4.0.5 2025-09-01 NetOps Added AWS us-east-2 IP ranges to cloud bypass.
//
// v4.0.4 2025-08-15 SecOps All *.pastebin.com traffic forced via DLP proxy
// per incident report INC-2025-8872.
//
// v4.0.3 2025-07-20 NetOps Added Tokyo office subnet 172.31.50.0/24.
//
// v4.0.2 2025-06-12 NetOps Added bypass for GitHub Copilot endpoints.
//
// v4.0.1 2025-05-30 NetOps Minor cleanup of APAC routing comments.
//
// v4.0.0 2025-05-01 Architect Major version: complete rewrite from v3.x.
// Introduced region detection, DLP enforcement,
// and modular SaaS bypass framework.
//
// =============================================================================
// SECTION 2 - NETWORK ARCHITECTURE OVERVIEW
// =============================================================================
//
// Acme Corporation operates a hub-and-spoke WAN with the following regions:
//
// AMER (Americas)
// ---------------
// HQ Location : New York, NY, USA
// Proxy Cluster : proxy-us-1.acme-corp.internal (primary)
// proxy-us-2.acme-corp.internal (secondary)
// proxy-us-3.acme-corp.internal (tertiary/DR)
// Subnet Range : 10.0.0.0/8
// Branch Offices : Chicago (10.10.0.0/16)
// Los Angeles (10.11.0.0/16)
// Toronto (10.12.0.0/16)
// Sao Paulo (10.13.0.0/16)
// Mexico City (10.14.0.0/16)
//
// EMEA (Europe, Middle East, Africa)
// ------------------------------------
// HQ Location : London, UK
// Proxy Cluster : proxy-eu-1.acme-corp.internal (primary)
// proxy-eu-2.acme-corp.internal (secondary)
// Subnet Range : 172.16.0.0/12
// Branch Offices : Paris (172.16.10.0/24)
// Frankfurt (172.16.11.0/24)
// Amsterdam (172.16.12.0/24)
// Dubai (172.16.13.0/24)
// Johannesburg (172.16.14.0/24)
// Warsaw (172.16.15.0/24)
//
// APAC (Asia-Pacific)
// --------------------
// HQ Location : Singapore
// Proxy Cluster : proxy-apac-1.acme-corp.internal (primary)
// proxy-apac-2.acme-corp.internal (secondary)
// Subnet Range : 192.168.0.0/16
// Branch Offices : Tokyo (192.168.10.0/24)
// Sydney (192.168.11.0/24)
// Mumbai (192.168.12.0/24)
// Seoul (192.168.13.0/24)
// Beijing (192.168.14.0/24)
//
// =============================================================================
// SECTION 3 - PROXY SERVER INVENTORY
// =============================================================================
//
// The following proxy servers are maintained by the Network Infrastructure team.
// Each proxy is a clustered pair running Squid 6.x behind an F5 LTM VIP.
//
// Name FQDN Port
// -------------------------------- --------------------------------- -----
// AMER Primary proxy-us-1.acme-corp.internal 8080
// AMER Secondary proxy-us-2.acme-corp.internal 8080
// AMER Tertiary (DR) proxy-us-3.acme-corp.internal 8080
// AMER DLP Proxy proxy-us-dlp.acme-corp.internal 8443
// EMEA Primary proxy-eu-1.acme-corp.internal 8080
// EMEA Secondary proxy-eu-2.acme-corp.internal 8080
// EMEA DLP Proxy proxy-eu-dlp.acme-corp.internal 8443
// APAC Primary proxy-apac-1.acme-corp.internal 8080
// APAC Secondary proxy-apac-2.acme-corp.internal 8080
// APAC DLP Proxy proxy-apac-dlp.acme-corp.internal 8443
// Global Fallback proxy-global.acme-corp.internal 8080
//
// DLP proxies run Symantec ProxySG with SSL inspection enabled.
// Standard proxies run Squid 6.12 with WCCP v2 redirect from Cisco ASR.
//
// Proxy authentication is handled via Kerberos SSO for domain-joined devices.
// Non-domain devices (BYOD) use NTLM fallback with AD credentials.
//
// =============================================================================
// SECTION 4 - INTERNAL DOMAIN BYPASS RULES
// =============================================================================
//
// All internal domains must bypass the proxy and connect DIRECT.
// Internal domains are identified by the following suffixes:
//
// *.acme-corp.internal - Primary internal AD domain
// *.acme-corp.local - Legacy NetBIOS namespace (being phased out)
// *.corp.acme.com - External-facing corporate intranet
// *.hr.acme-corp.internal - HR systems (Workday, BambooHR integration)
// *.finance.acme-corp.internal - Finance systems (SAP, Oracle ERP)
// *.dev.acme-corp.internal - Developer environments and CI/CD systems
// *.staging.acme-corp.internal - Staging and QA environments
// *.lab.acme-corp.internal - Network lab / sandbox environments
// *.pki.acme-corp.internal - Internal PKI and certificate services
// *.siem.acme-corp.internal - Security information and event management
// *.backup.acme-corp.internal - Backup and disaster recovery systems
// *.print.acme-corp.internal - Print servers
// *.voip.acme-corp.internal - VoIP infrastructure (Cisco CUCM)
// *.wifi.acme-corp.internal - Wireless LAN controllers
// *.mgmt.acme-corp.internal - Network management systems (SNMP, syslog)
// *.noc.acme-corp.internal - Network Operations Center tools
// localhost - Local loopback
// 127.0.0.1 - Local loopback IP
//
// Note: Any new internal domain must be registered with NetOps before going
// live. Unregistered internal domains will attempt to route through the proxy
// and fail, as the proxy has no route to .internal TLDs.
//
// =============================================================================
// SECTION 5 - IP RANGE BYPASS RULES
// =============================================================================
//
// The following IP ranges bypass the proxy entirely (DIRECT connection).
// These ranges represent internal subnets routable within the MPLS WAN.
//
// Range Location / Purpose
// ---------------------- --------------------------------------------------
// 10.0.0.0/8 All AMER internal subnets
// 10.0.0.0/16 New York HQ core
// 10.10.0.0/16 Chicago Branch
// 10.11.0.0/16 Los Angeles Branch
// 10.12.0.0/16 Toronto Branch
// 10.13.0.0/16 Sao Paulo Branch
// 10.14.0.0/16 Mexico City Branch
// 10.44.0.0/16 New York HQ annex (Block C) - added v4.1.3
// 10.99.0.0/16 AMER VPN concentrator pool
// 172.16.0.0/12 All EMEA internal subnets
// 172.16.10.0/24 Paris Branch
// 172.16.11.0/24 Frankfurt Branch
// 172.16.12.0/24 Amsterdam Branch
// 172.16.13.0/24 Dubai Branch
// 172.16.14.0/24 Johannesburg Branch
// 172.16.15.0/24 Warsaw Branch
// 172.20.0.0/16 EMEA VPN pool
// 192.168.0.0/16 All APAC internal subnets
// 192.168.10.0/24 Tokyo Branch
// 192.168.11.0/24 Sydney Branch
// 192.168.12.0/24 Mumbai Branch
// 192.168.13.0/24 Seoul Branch
// 192.168.14.0/24 Beijing Branch
// 192.168.254.0/24 APAC VPN pool
// 100.64.0.0/10 CGNAT shared address space (ISP upstream)
// 169.254.0.0/16 APIPA / link-local (never proxy)
// 127.0.0.0/8 Loopback range
// ::1 IPv6 loopback
// fc00::/7 IPv6 ULA (private)
//
// =============================================================================
// SECTION 6 - SAAS PLATFORM BYPASS RULES
// =============================================================================
//
// The following SaaS platforms are allowed to bypass the proxy and connect
// DIRECT. These services use certificate pinning or IP-based allowlisting that
// is incompatible with SSL inspection. Bypassing them reduces latency and
// avoids certificate errors.
//
// Microsoft 365 / Azure AD
// -------------------------
// *.microsoft.com
// *.microsoftonline.com
// *.office.com
// *.office365.com
// *.outlook.com
// *.sharepoint.com
// *.onedrive.com
// *.teams.microsoft.com
// *.skype.com
// *.lync.com
// *.azure.com
// *.azureedge.net
// *.msauth.net
// *.msauthimages.net
// *.msftauth.net
// *.msftauthimages.net
// *.msocdn.com
// *.onenote.com
// *.cdn.office.net
// login.microsoftonline.com (critical: auth endpoint)
// login.microsoft.com (critical: auth endpoint)
// graph.microsoft.com (Microsoft Graph API)
// *.blob.core.windows.net (Azure Blob Storage)
// *.table.core.windows.net (Azure Table Storage)
// *.queue.core.windows.net (Azure Queue Storage)
// *.file.core.windows.net (Azure File Shares)
//
// Salesforce
// ----------
// *.salesforce.com
// *.force.com
// *.sfdcstatic.com
// *.documentforce.com
// *.visualforce.com
// *.salesforceliveagent.com
// *.exacttarget.com
// *.pardot.com
// *.my.salesforce.com
// *.lightning.force.com
// *.content.force.com
// *.crmforce.com
// *.heroku.com
// *.herokussl.com
//
// Workday (HR)
// ------------
// *.workday.com
// *.workdaycdn.com
// *.wd5.myworkday.com
// *.wd12.myworkday.com
// *.myworkday.com
// *.wdcdn.net
// *.workdayjobs.com
//
// ServiceNow (ITSM)
// -----------------
// *.service-now.com
// *.servicenow.com
// acme.service-now.com (our tenant FQDN)
// acme-sandbox.service-now.com (sandbox tenant)
//
// Zoom (Video Conferencing)
// -------------------------
// *.zoom.us
// *.zoom.com
// *.zoomgov.com
// *.zoomcdn.com
// zmw.*.zoom.us (media relay nodes)
// *.zmtel.com
//
// Slack
// -----
// *.slack.com
// *.slack-edge.com
// *.slack-files.com
// *.slack-imgs.com
// *.slack-redir.net
// *.slack-core.com
// *.slackb.com
// *.api.slack.com
//
// GitHub / GitHub Enterprise
// --------------------------
// *.github.com
// *.githubusercontent.com
// *.githubassets.com
// *.github.io
// *.copilot.github.com (GitHub Copilot - added v4.0.2)
// *.githubcopilot.com
//
// Atlassian (Jira / Confluence)
// -----------------------------
// *.atlassian.com
// *.atlassian.net
// *.jira.com
// *.confluence.com
// *.atlassianops.com
// *.bitbucket.org
// *.atlassian-helpdesk.com
//
// DocuSign
// --------
// *.docusign.com
// *.docusign.net
// *.echosign.com
//
// Box
// ---
// *.box.com
// *.boxcdn.net
// *.boxcloud.com
//
// Okta (Identity Provider)
// ------------------------
// *.okta.com
// *.okta-emea.com
// *.oktacdn.com
// *.okta-preview.com
// *.okta.eu
//
// Duo Security (MFA)
// ------------------
// *.duo.com
// *.duosecurity.com
// *.duo.us
//
// CrowdStrike (EDR)
// -----------------
// *.crowdstrike.com
// *.falcon.us-2.crowdstrike.com
// *.cloudsink.net
// *.laggar.gcw.crowdstrike.com
//
// Zscaler (ZIA/ZPA - used by remote workers not on VPN)
// ------------------------------------------------------
// *.zscaler.com
// *.zscaler.net
// *.zscalerx.net
// *.zscloud.net
// *.zsdemo.net
// *.zscalerone.net
// *.zscalertwo.net
// *.zscalerthree.net
//
// Splunk Cloud
// ------------
// *.splunkcloud.com
// input-*.cloud.splunk.com
// *.splunk.com
//
// Snowflake (Data Warehouse)
// --------------------------
// *.snowflakecomputing.com
// *.snowflake.com
// *.snowflakecdn.com
//
// Tableau (BI / Analytics)
// ------------------------
// *.tableau.com
// *.tableausoftware.com
// *.online.tableau.com
//
// Datadog (Monitoring)
// --------------------
// *.datadoghq.com
// *.datadoghq.eu
// *.datadog-browser-agent.com
// *.logs.datadoghq.com
// *.agent.datadoghq.com
//
// PagerDuty (Incident Management)
// --------------------------------
// *.pagerduty.com
// *.pageduty.com
//
// Coupa (Procurement)
// -------------------
// *.coupahost.com
// *.coupa.com
//
// SAP SuccessFactors
// ------------------
// *.successfactors.com
// *.successfactors.eu
// *.successfactors.cn
// *.sap.com
// *.sapcloud.io
//
// =============================================================================
// SECTION 7 - CDN AND MEDIA BYPASS RULES
// =============================================================================
//
// Content Delivery Networks (CDNs) are bypassed because:
// a) Traffic is already TLS-encrypted end-to-end
// b) SSL inspection causes certificate errors with pinned certs
// c) CDN nodes are geographically close; proxying adds unnecessary latency
// d) High-bandwidth media traffic would saturate proxy egress links
//
// Akamai
// -------
// *.akamai.com
// *.akamaihd.net
// *.akamaized.net
// *.akamaiedge.net
// *.akamaistream.net
// *.akamaitechnologies.com
// *.akamaized-staging.net
//
// Cloudflare
// ----------
// *.cloudflare.com
// *.cloudflaressl.com
// *.cloudflarestorage.com
// *.cloudflare-dns.com
// *.workers.dev
// *.pages.dev
//
// Fastly
// ------
// *.fastly.net
// *.fastlylb.net
// *.fastlyinsights.io
//
// AWS CloudFront
// --------------
// *.cloudfront.net
// *.cloudfront.com
//
// Azure CDN
// ---------
// *.azurefd.net
// *.azureedge.net
// *.vo.msecnd.net
//
// Google CDN / Firebase
// ---------------------
// *.googlevideo.com
// *.gstatic.com
// *.firebaseapp.com
// *.firebase.com
// *.firebaseio.com
//
// StackPath / MaxCDN
// ------------------
// *.stackpath.com
// *.stackpathcdn.com
// *.maxcdn.com
// *.netdna-cdn.com
//
// =============================================================================
// SECTION 8 - REGIONAL ROUTING LOGIC
// =============================================================================
//
// Regional routing is based on the client's resolved IP address prefix,
// determined at PAC evaluation time by the client's local DNS resolution.
//
// The logic works as follows:
//
// 1. Check if the destination is internal or on the bypass list -> DIRECT
// 2. Check which region the CLIENT is in (based on IP prefix):
// - 10.x.x.x -> AMER
// - 172.16-31.x.x -> EMEA
// - 192.168.x.x -> APAC
// 3. Route through the appropriate regional proxy cluster
// 4. If primary is unavailable, fall through to secondary
// 5. If all regional proxies fail, route through global fallback
//
// AMER Routing:
// -------------
// Primary : PROXY proxy-us-1.acme-corp.internal:8080
// Secondary : PROXY proxy-us-2.acme-corp.internal:8080
// Tertiary : PROXY proxy-us-3.acme-corp.internal:8080
// Fallback : PROXY proxy-global.acme-corp.internal:8080
// Last Resort: DIRECT
//
// EMEA Routing:
// -------------
// Primary : PROXY proxy-eu-1.acme-corp.internal:8080
// Secondary : PROXY proxy-eu-2.acme-corp.internal:8080
// Fallback : PROXY proxy-global.acme-corp.internal:8080
// Last Resort: DIRECT
//
// APAC Routing:
// -------------
// Primary : PROXY proxy-apac-1.acme-corp.internal:8080
// Secondary : PROXY proxy-apac-2.acme-corp.internal:8080
// Fallback : PROXY proxy-global.acme-corp.internal:8080
// Last Resort: DIRECT
//
// Unknown Region (fallback):
// --------------------------
// Route via : PROXY proxy-global.acme-corp.internal:8080
// Last Resort: DIRECT
//
// =============================================================================
// SECTION 9 - DEPARTMENT-SPECIFIC RULES
// =============================================================================
//
// Finance Department
// ------------------
// All traffic from finance subnets (10.0.50.0/24 and 172.16.50.0/24) destined
// for external banking portals and payment processors must be routed through
// the DLP proxy with SSL inspection enabled. This is required by PCI-DSS
// compliance policy FIN-POL-2024-001.
//
// Affected destinations:
// *.swift.com
// *.swiftnet.com
// *.citi.com
// *.jpmorgan.com
// *.wellsfargo.com
// *.bankofamerica.com
// *.mastercard.com
// *.visa.com
// *.paypal.com
// *.stripe.com
// *.braintreepayments.com
// *.adyen.com
// *.worldpay.com
//
// Finance proxy: proxy-us-dlp.acme-corp.internal:8443
//
// Legal Department
// ----------------
// Legal workstations (10.0.55.0/24) have additional bypass rules for:
// *.lexisnexis.com
// *.westlaw.com
// *.thomsonreuters.com
// *.law360.com
// *.pacer.gov
// *.uscourts.gov
// *.sec.gov
// *.patentsearch.uspto.gov
//
// These bypass the DLP proxy since documents are privileged and attorney-client
// communications cannot be inspected. See legal hold LEGAL-2025-0034.
//
// Research & Development (R&D)
// ----------------------------
// R&D workstations (10.0.60.0/24 and 192.168.60.0/24) have bypass rules for:
// *.arxiv.org
// *.researchgate.net
// *.academia.edu
// *.springer.com
// *.elsevier.com
// *.ieee.org
// *.acm.org
// *.nature.com
// *.science.org
// *.cell.com
//
// Human Resources
// ---------------
// HR systems bypass the proxy:
// *.bamboohr.com
// *.icims.com
// *.greenhouse.io
// *.lever.co
// *.smartrecruiters.com
// *.hirevue.com
// *.cornerstone.com
//
// Executive (C-Suite)
// -------------------
// Executive workstations (10.0.5.0/28) are classified as "High-Trust" and
// bypass the proxy for all traffic. This is configured at the network level
// via policy-based routing, not via the PAC file, but noted here for reference.
//
// =============================================================================
// SECTION 10 - SECURITY AND DLP PROXY RULES
// =============================================================================
//
// The following destinations are FORCED through the DLP proxy regardless of
// client location. These sites require deep packet inspection for compliance.
//
// Social Media (Policy: SEC-2026-004)
// ------------------------------------
// *.facebook.com -> proxy-dlp:8443
// *.instagram.com -> proxy-dlp:8443
// *.twitter.com -> proxy-dlp:8443
// *.x.com -> proxy-dlp:8443
// *.tiktok.com -> proxy-dlp:8443
// *.reddit.com -> proxy-dlp:8443
// *.linkedin.com -> proxy-dlp:8443 (exception: HR bypass on hr subnet)
// *.snapchat.com -> proxy-dlp:8443
// *.pinterest.com -> proxy-dlp:8443
// *.tumblr.com -> proxy-dlp:8443
//
// File Sharing (Policy: DLP-2025-001)
// -------------------------------------
// *.dropbox.com -> proxy-dlp:8443
// *.wetransfer.com -> proxy-dlp:8443
// *.sendspace.com -> proxy-dlp:8443
// *.hightail.com -> proxy-dlp:8443
// *.4shared.com -> BLOCK
// *.mediafire.com -> BLOCK
// *.zippyshare.com -> BLOCK
// *.rapidshare.com -> BLOCK
//
// Pastebin / Code Sharing (Policy: SEC-INC-2025-8872)
// -----------------------------------------------------
// *.pastebin.com -> proxy-dlp:8443
// *.pastie.org -> proxy-dlp:8443
// *.gist.github.com -> proxy-dlp:8443 (note: github.com itself is BYPASS)
// *.hastebin.com -> proxy-dlp:8443
//
// BLOCKED Destinations (no access permitted):
// --------------------------------------------
// *.torproject.org -> BLOCK (Tor network)
// *.onion -> BLOCK (Tor hidden services)
// *.freenet.org -> BLOCK (anonymization network)
// *.i2p -> BLOCK (I2P anonymization)
// *.proxify.com -> BLOCK (web proxy circumvention)
// *.anonymouse.org -> BLOCK (web proxy circumvention)
// *.hidemyass.com -> BLOCK (VPN/proxy circumvention)
// *.kproxy.com -> BLOCK (web proxy circumvention)
//
// =============================================================================
// SECTION 11 - FAILOVER AND LOAD BALANCING
// =============================================================================
//
// PAC file failover is implemented using the PAC return string syntax:
//
// "PROXY primary:8080; PROXY secondary:8080; DIRECT"
//
// The browser attempts each option left-to-right. If the primary proxy does
// not respond within ~30 seconds (browser-dependent timeout), it moves to
// the secondary, then finally falls back to DIRECT.
//
// IMPORTANT: PAC-level failover is slow (30s timeout by default in most
// browsers). Network-level failover via F5 LTM VIPs is preferred for speed.
// The PAC failover serves as an application-layer safety net only.
//
// Load Balancing Strategy:
// ------------------------
// The F5 LTM in front of each proxy cluster handles load balancing using
// Least Connections algorithm. The PAC file always points to the VIP FQDN,
// not to individual proxy nodes. This ensures that adding/removing proxy
// nodes from the cluster does not require a PAC file update.
//
// proxy-us-1.acme-corp.internal -> F5 VIP -> [us-squid-01, us-squid-02,
// us-squid-03, us-squid-04]
// proxy-eu-1.acme-corp.internal -> F5 VIP -> [eu-squid-01, eu-squid-02]
// proxy-apac-1.acme-corp.internal -> F5 VIP -> [apac-squid-01, apac-squid-02]
//
// Health Check:
// -------------
// The F5 performs HTTP health checks every 5 seconds against each Squid node:
// GET http://squid-node:3128/squid-internal-mgr/info
// If a node fails 3 consecutive checks, it is removed from the pool.
// It re-enters the pool after 2 successful checks.
//
// =============================================================================
// SECTION 12 - VPN SPLIT TUNNEL INTEGRATION
// =============================================================================
//
// Remote workers connect via Cisco AnyConnect VPN with split tunneling enabled.
// When connected to VPN, remote workers receive a 10.99.x.x IP (AMER) or
// 172.20.x.x (EMEA) or 192.168.254.x (APAC).
//
// Split tunnel routes (pushed via VPN profile):
// 10.0.0.0/8 -> VPN tunnel (internal AMER resources)
// 172.16.0.0/12 -> VPN tunnel (internal EMEA resources)
// 192.168.0.0/16 -> VPN tunnel (internal APAC resources)
// All other traffic -> Local internet breakout (split tunnel)
//
// PAC file behavior for VPN users:
// ---------------------------------
// When on VPN, the PAC file detects the VPN IP range (10.99.x.x etc.) and
// routes accordingly:
// - Internal destinations -> DIRECT (routed via VPN tunnel)
// - SaaS/CDN on bypass -> DIRECT (via local internet breakout)
// - All other internet -> via regional proxy (via VPN tunnel to proxy,
// then proxy egresses to internet)
//
// Note: Some users on high-latency VPN links (satellite, international roaming)
// are placed in a "lightweight" routing group that routes SaaS traffic DIRECT
// and only forces BLOCK-listed sites through the VPN proxy. This is managed
// via a separate PAC file: proxy-lite.pac
//
// =============================================================================
// SECTION 13 - CLOUD PROVIDER RULES (AWS, AZURE, GCP)
// =============================================================================
//
// Amazon Web Services (AWS)
// --------------------------
// Acme Corp uses AWS for production workloads. EC2 instances in the Acme
// AWS VPC connect back to on-prem via AWS Direct Connect.
//
// AWS regions used:
// us-east-1 (primary production)
// us-east-2 (DR)
// eu-west-1 (EMEA production)
// ap-southeast-1 (APAC production)
//
// AWS management console and API endpoints are bypassed:
// *.amazonaws.com
// *.aws.amazon.com
// *.awsstatic.com
// *.cloudfront.net (see CDN section)
// *.s3.amazonaws.com
// *.s3-website.amazonaws.com
// console.aws.amazon.com
// signin.aws.amazon.com
//
// Microsoft Azure
// ---------------
// *.azure.com
// *.azure.net
// *.azurewebsites.net
// *.azurefd.net
// *.azureedge.net
// *.blob.core.windows.net
// *.table.core.windows.net
// *.queue.core.windows.net
// *.servicebus.windows.net
// *.database.windows.net
// *.vault.azure.net
// *.azurecontainerapps.io
// *.azurecr.io
// portal.azure.com
// management.azure.com
//
// Google Cloud Platform (GCP)
// ----------------------------
// GCP is used for ML/AI workloads by the Data Science team.
// *.googleapis.com
// *.google.com
// *.gcp.gvt2.com
// *.gcr.io
// *.pkg.dev
// *.cloudfunctions.net
// *.run.app
// *.appspot.com
// cloud.google.com
// console.cloud.google.com
// storage.cloud.google.com
//
// =============================================================================
// SECTION 14 - PARTNER EXTRANET RULES
// =============================================================================
//
// Acme Corp maintains secure extranet connections with the following partners.
// Traffic to these destinations is routed DIRECT (via MPLS or SD-WAN peering),
// not through the proxy.
//
// Partner Domain Connection Type
// ------------------------ ---------------------------- ---------------
// GlobalLogistics Inc. *.globallogistics.partner MPLS peer
// FastFreight Ltd *.fastfreight-acme.net SD-WAN
// TechSuppliers Co. *.techsuppliers.portal.net IPSec VPN
// PharmaPartner AG *.pharmapartner-acme.eu MPLS peer
// FinancialClear LLC *.financialclear.com TLS tunnel
// AuditFirm Partners LLP *.auditfirm-acme.client.net MPLS peer
// CloudPrint Services *.cloudprint-acme.io SD-WAN
//
// Partner connections are maintained by the Network team and onboarded via
// the Partner Network Onboarding process (PROC-NET-007). New partners must
// submit a request at least 6 weeks before go-live to allow time for:
// - BGP route advertisement
// - Security review and approval
// - PAC file update and testing
// - Change management approval
//
// =============================================================================
// SECTION 15 - LEGACY APPLICATION RULES
// =============================================================================
//
// The following applications are legacy systems with special proxy requirements.
//
// LegacyERP (SAP R/3)
// --------------------
// The on-premises SAP R/3 system predates modern HTTP proxying. It uses RFC
// connections over TCP port 3200-3299. These connections MUST be DIRECT and
// are excluded from any proxy routing. They are handled at the network layer
// via dedicated VLAN (VLAN 320).
//
// OldPortal (Intranet, pre-2015)
// -------------------------------
// The old intranet portal at portal-legacy.acme-corp.internal runs on HTTP
// (port 80) without SSL. Since DLP proxy requires HTTPS, this is excluded
// from DLP inspection and routed DIRECT.
//
// IBM Mainframe Web Services
// ---------------------------
// The mainframe exposes CICS web services at:
// mainframe.acme-corp.internal:8091
// mainframe-dr.acme-corp.internal:8091
// These use a non-standard TLS stack that is incompatible with the proxy's
// SSL inspection. They are bypassed.
//
// Oracle Forms (Client-Server)
// ----------------------------
// Oracle Forms applications connect via Jinitiator/Java WebStart on
// non-standard ports. These connections are excluded from proxy routing.
// oracleforms.finance.acme-corp.internal:9001
//
// =============================================================================
// SECTION 16 - MOBILE AND BYOD POLICY
// =============================================================================
//
// Mobile devices and BYOD (Bring Your Own Device) systems use a separate PAC
// file: proxy-mobile.pac
//
// Key differences from the standard corporate PAC:
// - No Kerberos SSO; NTLM fallback used for proxy auth
// - Stricter DLP enforcement (all traffic via DLP proxy)
// - Social media blocked entirely (no DLP inspection - simply BLOCK)
// - Higher proxy timeout values (mobile networks can be slow)
// - Zscaler ZIA endpoints bypassed (BYOD uses Zscaler client connector)
//
// BYOD devices are identified by:
// a) MDM enrollment status (Jamf/Intune)
// b) Network: BYOD SSID (VLAN 200) - IP range 10.200.0.0/16
//
// Corporate-managed iOS and Android devices use:
// Proxy host: proxy-mobile.acme-corp.internal
// Proxy port: 8080
// PAC URL : https://pac.acme-corp.internal/proxy-mobile.pac
//
// =============================================================================
// SECTION 17 - KNOWN ISSUES AND WORKAROUNDS
// =============================================================================
//
// Issue #1: Microsoft Teams media degradation behind proxy
// ---------------------------------------------------------
// Symptom : Teams video/audio quality is degraded when routed via proxy.
// Root Cause: Teams media (UDP) cannot traverse HTTP proxy. Only signaling
// uses HTTP. Media must be DIRECT or via UDP relay.
// Workaround: Teams media subdomains are fully bypassed. The Teams client
// uses STUN/TURN to find the best media path, bypassing the proxy
// at the application layer for media streams.
// Domains bypassed: *.teams.microsoft.com, *.skype.com, *.lync.com
// Status: Resolved in v4.0.0. Monitor for new Teams subdomains quarterly.
//
// Issue #2: Chrome browser ignoring PAC for QUIC/HTTP3
// -----------------------------------------------------
// Symptom : Chrome sends QUIC (UDP/443) traffic directly, bypassing PAC.
// Root Cause: QUIC uses UDP. PAC files only apply to TCP-based proxies.
// Workaround: Blocked QUIC on the perimeter firewall (UDP 443) to force
// fallback to HTTPS/TLS over TCP, which respects the PAC file.
// Policy ref: FW-RULE-2024-0341
// Status: Ongoing - monitor Chrome release notes for changes.
//
// Issue #3: Slow PAC file evaluation on first browser launch
// ----------------------------------------------------------
// Symptom : First browser launch after login takes 20-30 seconds.
// Root Cause: PAC file is fetched from the web server on first launch.
// DNS resolution of pac.acme-corp.internal occasionally times out
// on DHCP-slow links (some wireless clients).
// Workaround: Deployed PAC file via DHCP option 252 as secondary delivery.
// Also pushed via GPO as HKCU registry key (AutoConfigURL).
// Status: Mitigated. Monitoring DHCP option adoption rate.
//
// Issue #4: Firefox not respecting Windows proxy settings
// -------------------------------------------------------
// Symptom : Firefox uses its own proxy settings, ignoring the GPO PAC URL.
// Root Cause: Firefox maintains an independent proxy configuration by default.
// Workaround: Deployed Firefox policy via mozilla.cfg and policies.json via
// GPO software deployment. Forces Firefox to use system proxy.
// Policy ref: ENDPOINT-POL-2023-088
// Status: Resolved. Firefox 115+ ESR policy enforced org-wide.
//
// Issue #5: Zscaler Client Connector conflicts with PAC on BYOD
// -------------------------------------------------------------
// Symptom : BYOD users with Zscaler installed get double-proxied.
// Root Cause: Zscaler intercepts traffic at the OS level BEFORE PAC is
// evaluated. PAC then tries to send Zscaler-tunnelled traffic
// to the corporate proxy again.
// Workaround: BYOD PAC file (proxy-mobile.pac) bypasses all Zscaler endpoints.
// Zscaler policy applied to BYOD to bypass corporate proxy IPs.
// Status: Resolved in proxy-mobile.pac v2.1.0.
//
// Issue #6: Safari on macOS not honoring PAC bypass for .local domains
// --------------------------------------------------------------------
// Symptom : Safari on corporate Macs fails to resolve .local domains.
// Root Cause: Safari on macOS sends .local mDNS queries differently; the
// PAC bypass for *.acme-corp.local does not apply consistently.
// Workaround: Migrated all .local services to .acme-corp.internal. Deployed
// a mDNS suppression profile via Jamf to prevent conflicts.
// Status: In progress - estimated completion Q3 2026.
//
// Issue #7: PAC file not applied after Windows fast startup
// ---------------------------------------------------------
// Symptom : After resume from hibernate (fast startup), some processes bypass
// the proxy until a full reboot occurs.
// Root Cause: The WinHTTP proxy service does not re-read the PAC URL on
// resume from hibernate in some Windows 11 builds.
// Workaround: GPO startup script forces proxy reset on logon:
// netsh winhttp import proxy source=ie
// Policy ref: GPO-STARTUP-0012
// Status: Reported to Microsoft - tracking MSFT support case #2025-88723.
//
// =============================================================================
// SECTION 18 - MAINTENANCE NOTES
// =============================================================================
//
// PAC File Delivery Infrastructure
// ----------------------------------
// The PAC file is hosted on a highly available web cluster:
// Primary : pac-web-1.acme-corp.internal (NGINX)
// Secondary : pac-web-2.acme-corp.internal (NGINX)
// VIP FQDN : pac.acme-corp.internal -> F5 LTM VIP
// URL : https://pac.acme-corp.internal/proxy.pac
//
// The PAC file is version-controlled in GitLab:
// Repository: https://gitlab.acme-corp.internal/netops/pac-files
// Branch : main
// CI/CD : Automated lint + syntax check on every commit
// Automated deployment to staging PAC server on merge to main
// Manual approval required for production deployment
//
// Testing Procedure:
// ------------------
// Before deploying a new PAC file:
// 1. Lint with pacparser (https://github.com/manugarg/pacparser)
// Command: pacparser -p proxy.pac -u https://example.com
// 2. Test all bypass rules manually using a test client
// 3. Test all proxy routes manually
// 4. Test failover by blocking primary proxy temporarily
// 5. Deploy to staging PAC server
// 6. Monitor for 30 minutes using test user group (NetOps team)
// 7. Submit change request in ServiceNow
// 8. Deploy to production after change approval
//
// Rollback Procedure:
// -------------------
// 1. Revert PAC file on pac-web-1 and pac-web-2 to previous version
// 2. Clients fetch new PAC file on next browser launch or TTL expiry
// 3. Force immediate refresh via GPO if emergency rollback is needed
// (GPO: Computer Config -> Windows Settings -> Scripts -> Startup)
//
// PAC File TTL / Caching:
// -----------------------
// The PAC file is served with:
// Cache-Control: max-age=3600
// Expires: [1 hour from now]
// This means clients refresh the PAC file every 60 minutes.
// For emergency changes, the GPO can force a proxy settings refresh
// via IE/Edge proxy reset command.
//
// Monitoring:
// -----------
// PAC file availability is monitored by:
// - Datadog synthetic tests (every 60 seconds from 5 global locations)
// - Splunk alert on HTTP 5xx from pac.acme-corp.internal
// - PagerDuty on-call rotation: netops-oncall@acme-corp.com
//
// Quarterly Review Tasks:
// -----------------------
// Every quarter, the NetOps team should:
// 1. Review Microsoft 365 endpoint changes (published by Microsoft monthly)
// URL: https://endpoints.office.com/endpoints/worldwide
// 2. Review new SaaS platform bypass requests from IT Service Desk
// 3. Audit DLP-forced list against current SecOps policy
// 4. Verify all proxy server FQDNs resolve correctly
// 5. Test PAC file delivery from all regional offices
// 6. Review and update partner extranet section
// 7. Check for decommissioned proxy nodes still referenced
// 8. Update version history and changelog
//
// =============================================================================
// SECTION 19 - CONTACT AND ESCALATION
// =============================================================================
//
// Primary Contact:
// Team : Network Infrastructure
// Email : netops@acme-corp.internal
// Slack : #netops-team
// Oncall : PagerDuty rotation "netops-proxy"
//
// Secondary Contact (Security):
// Team : Security Operations
// Email : secops@acme-corp.internal
// Slack : #secops-team
// Oncall : PagerDuty rotation "secops-dlp"
//
// Escalation Path:
// L1 -> Service Desk (1-800-ACME-HLP)
// L2 -> Network Infrastructure team
// L3 -> Network Architect (John Doe, john.doe@acme-corp.internal)
// L4 -> VP of Infrastructure (Jane Smith, jane.smith@acme-corp.internal)
//
// Change Management:
// All PAC file changes require a ServiceNow change request.
// Emergency changes use the Emergency Change template (ECH).
// Standard changes follow the Normal Change process (14-day lead time).
// Change advisory board (CAB) meets every Tuesday at 14:00 ET.
//
// SLA:
// PAC file availability : 99.99% uptime
// Incident response : P1 = 15min, P2 = 1hr, P3 = 4hr, P4 = 24hr
// Change deployment : Emergency = 1hr, Standard = 14 days
//
// =============================================================================
// SECTION 20 - APPENDIX A: PROXY AUTHENTICATION DETAILS
// =============================================================================
//
// Kerberos SSO (Domain-Joined Devices)
// --------------------------------------
// Domain-joined Windows devices authenticate to the proxy transparently using
// Kerberos tickets. The process works as follows:
//
// 1. User logs into Windows with their AD credentials.
// 2. A Kerberos TGT (Ticket Granting Ticket) is issued by the KDC.
// 3. When the browser connects to the proxy, it requests a service ticket
// for the proxy's SPN: HTTP/proxy-us-1.acme-corp.internal
// 4. The browser presents the Kerberos token in the Proxy-Authorization
// header using the "Negotiate" scheme.
// 5. The proxy validates the token against AD via GSSAPI.
// 6. The user is authenticated without entering any credentials.
//
// Supported browsers for Kerberos SSO:
// - Microsoft Edge (Chromium): Supported natively
// - Google Chrome: Requires AuthServerAllowlist GPO policy
// - Mozilla Firefox: Requires network.negotiate-auth.trusted-uris preference
// - Internet Explorer 11: Supported natively (deprecated)
//
// GPO settings for Chrome SSO:
// Policy: AuthServerAllowlist
// Value : proxy-us-1.acme-corp.internal,proxy-us-2.acme-corp.internal,
// proxy-us-3.acme-corp.internal,proxy-eu-1.acme-corp.internal,
// proxy-eu-2.acme-corp.internal,proxy-apac-1.acme-corp.internal,
// proxy-apac-2.acme-corp.internal,proxy-global.acme-corp.internal
//
// NTLM Fallback
// -------------
// If Kerberos fails (e.g., clock skew > 5 minutes, SPN mismatch, or non-domain
// machine), the proxy falls back to NTLM challenge-response authentication.
// NTLM is less secure than Kerberos and should only be used as a fallback.
// SecOps monitors for excessive NTLM authentications via Splunk dashboard
// "Proxy Auth Anomalies" - alert triggers if NTLM exceeds 5% of auth volume.
//
// Basic Auth (Emergency Only)
// ---------------------------
// Basic authentication over HTTPS is disabled on all proxies except
// proxy-global.acme-corp.internal, which allows it for emergency break-glass
// scenarios. Credentials are the user's standard AD username and password.
// Usage must be approved by the CISO and logged in the security ticketing
// system (ticket type: PRIV-ACCESS-EMERGENCY).
//
// Service Accounts
// ----------------
// Automated systems and service accounts that require proxy access use
// dedicated service account credentials. These are stored in CyberArk PAM
// and rotated every 90 days. Service accounts are subject to the same
// proxy policy as human users unless explicitly exempted.
//
// Service Account System Proxy Exemption
// ------------------------ ------------------------- ----------------
// svc-jenkins@acme-corp CI/CD pipeline (Jenkins) None
// svc-ansible@acme-corp Ansible automation None
// svc-monitoring@acme-corp Datadog agent Partial (agent endpoints)
// svc-backup@acme-corp Veeam backup Full bypass
// svc-antivirus@acme-corp CrowdStrike sensor Full bypass
//
// =============================================================================
// SECTION 20 - APPENDIX B: PAC FILE DEBUGGING GUIDE
// =============================================================================
//
// How to test the PAC file manually:
// ------------------------------------
//
// Method 1: Browser DevTools (Chrome/Edge)
// 1. Open DevTools (F12)
// 2. Go to: chrome://net-internals/#proxy
// 3. Click "Re-apply settings" to force PAC re-evaluation
// 4. Go to: chrome://net-internals/#events
// 5. Filter by "PAC_FILE" to see PAC evaluation logs
//
// Method 2: pacparser CLI tool
// Install: pip install pacparser
// Usage : pacparser -p /path/to/proxy.pac -u https://example.com
// Output : DIRECT or PROXY <host:port>
//
// Method 3: PowerShell (Windows)
// $ie = New-Object -ComObject InternetExplorer.Application
// $ie.navigate("about:blank")
// # Check proxy settings applied to WinHTTP:
// netsh winhttp show proxy
//
// Method 4: JavaScript evaluation (browser console)
// Paste the FindProxyForURL function into the browser console, then call:
// FindProxyForURL("https://example.com", "example.com")
// This allows rapid testing without deploying the PAC file.
//
// Common Debugging Scenarios:
// ---------------------------
//
// Scenario A: User reports a site is slow
// 1. Check if the site is on the bypass list (should be DIRECT)
// 2. If not bypassed, check proxy logs for the connection
// 3. Check if the proxy is adding significant latency
// 4. Consider adding the site to the bypass list if appropriate
// 5. Test with: pacparser -p proxy.pac -u <site-url>
//
// Scenario B: User cannot reach an internal site
// 1. Check if the internal domain is in the bypass list (Section 4)
// 2. Verify the domain resolves internally (nslookup <domain>)
// 3. Check if the site is routed through the proxy by mistake
// 4. Add the domain to Section 4 if missing
// 5. Submit a change request for the PAC update
//
// Scenario C: Authentication pop-up appearing unexpectedly
// 1. The proxy is receiving a request it should have bypassed
// 2. Check the PAC logic for the affected domain
// 3. Verify Kerberos SSO is working (klist command on the client)
// 4. Check proxy access logs for the client IP and URL
//
// Scenario D: PAC file not loading at all
// 1. Verify pac.acme-corp.internal resolves (nslookup pac.acme-corp.internal)
// 2. Check HTTP response: curl -I https://pac.acme-corp.internal/proxy.pac
// 3. Verify the NGINX servers are running on pac-web-1 and pac-web-2
// 4. Check F5 VIP health: log into F5 management console
// 5. Escalate to NetOps if unresolved
//
// =============================================================================
// SECTION 20 - APPENDIX C: REGULATORY AND COMPLIANCE REFERENCES
// =============================================================================
//
// The proxy architecture and PAC file rules are governed by the following
// regulatory frameworks and internal policies:
//
// PCI-DSS (Payment Card Industry Data Security Standard)
// -------------------------------------------------------
// Requirement 1.3: Restrict inbound and outbound traffic to that which is
// necessary for the cardholder data environment.
// Requirement 10.2: Implement audit trails to reconstruct network events.
// Impact on PAC : Finance subnet DLP proxy enforcement (Section 9).
// All financial platform traffic logged at the proxy.
//
// SOX (Sarbanes-Oxley Act)
// -------------------------
// Section 302/404: Controls over financial reporting systems.
// Impact on PAC : Finance and ERP system traffic monitored via DLP proxy.
// Access to external financial data sources controlled.
//
// GDPR (General Data Protection Regulation)
// ------------------------------------------
// Article 32: Security of processing.
// Impact on PAC: SSL inspection of traffic involving EU citizen data requires
// disclosure in the employee privacy notice. HR and Legal
// subnets have reduced inspection scope.
//
// HIPAA (Health Insurance Portability and Accountability Act)
// -----------------------------------------------------------
// Applies to Acme Corp's benefits administration systems.
// Impact on PAC: *.benefitsadmin.acme-corp.internal routed DIRECT to
// prevent PHI from traversing the proxy where feasible.
//
// ISO 27001
// ---------
// Annex A.13: Communications security.
// Impact on PAC: Proxy enforces acceptable use policy for internet access.
// All internet traffic (except bypass list) logged.
//
// Internal Policies
// -----------------
// AUP-2024-001 : Acceptable Use Policy for Internet Access
// SEC-2026-004 : Social Media Access Control Policy
// DLP-2025-001 : Data Loss Prevention - File Sharing Controls
// FIN-POL-2024-001: Finance Systems Internet Access Policy
// LEGAL-2025-0034: Legal Department Network Exemptions
// ENDPOINT-POL-2023-088: Endpoint Browser Proxy Enforcement
//
// =============================================================================
// SECTION 20 - MAIN FUNCTION
// =============================================================================
//
// NOTE: The implementation below intentionally returns DIRECT for all traffic.
// This is a TEST/PLACEHOLDER version of the PAC file used to validate that
// the AutoConfigURL registry key is correctly set without affecting any traffic.
// Replace the function body with the full routing logic above when ready to
// go live.
//
// =============================================================================
function FindProxyForURL(url, host) {
return "DIRECT";
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment