Athena SWG (Secure Web Gateway)

Athena SWG (formerly Internet Access Gateway) ensures visibility and control across the network, detecting risks like unauthorized access, non-compliant activities, and data leaks to manage endpoints.
{{ $t('productDocDetail.guideClickSwitch') }}
{{ $t('productDocDetail.know') }}
{{ $t('productDocDetail.dontRemind') }}
13.0.120
{{sendMatomoQuery("Athena SWG (Secure Web Gateway)","Protocol Extension")}}

Protocol Extension

{{ $t('productDocDetail.updateTime') }}: 2025-12-29

In some network environments, packets are encapsulated using a series of special protocols such as PPPoE and Multiprotocol Label Switching (MPLS). Compared with common IP packets, these protocol packets are added with a specific header so that common devices with the protocol analysis function cannot parse these packets.

The Sangfor IAG peels off the special protocol headers, analyzes these packets' characteristics, and matches the packets with embedded special protocol rules. Then the device can authenticate, audit, and control the raw data.

Currently, the Sangfor IAG can peel off packet headers of the following protocols: VLAN, MPLS, PPPoE, L2TP, LWAPP, CAPWAP, WLTP, and user-defined protocols.

Example: A PC needs to connect to the PPPoE server through dialup and access the Internet after authentication. The Sangfor IAG is deployed in bridge mode between the PC and the PPPoE server and needs to audit and control the online behaviors of the PC.

The procedure is as follows:

Navigate to System > Network > Protocol Extension. The Network Protocol Extension pane is on the right, as shown in the following figure.

In Protocols, Select PPPoE de-encapsulation and click Commit to enable PPPoE de-encapsulation. After configuring the corresponding audit and control policies, the IAG can audit and control the PC that accesses the network through PPPoE dialup.

If packets of a special protocol not in the protocol de-encapsulation list exist, select Custom Protocol Stripping and define the de-encapsulation of this type of packet. In Ethernet Header, specify the start position and characteristics of the header in the entire packet (including the Ethernet header). In IP Header Start Position, specify the start position of an IP header after the packet is encapsulated using this special protocol.

If the special protocol is in the protocol de-encapsulation list but does not use the default port for communication, for example, L2TP does not use the default port 1701 for communication, double-click the protocol rule and edit port information. The information about ports can be separated by a comma (,).

If multiple special protocols exist in the protocol de-encapsulation list, select the corresponding protocol rules.

1. Protocol de-encapsulation is not supported in route mode.

2. Protocol de-encapsulation is supported in bridge mode. Data can be authenticated, audited, and controlled after protocol de-encapsulation. Some functions are unavailable in special environments, such as:

  • Web authentication, Ingress authentication, rejection page, and intelligent reminder page that involve redirection.
  • SSL content identification.
  • MSN file transfer control.
  • Kerberos authentication or SSO.
  • Mail filtering and gateway virus removal involve a proxy.

3. Protocol de-encapsulation is supported in bypass mode. After protocol de-encapsulation is enabled, automatic authentication and audit are supported, and control is not supported.

4. In an environment with protocol de-encapsulation enabled, you cannot use a computer name or MAC address as the username or bind a MAC address.

5. Some data may have two IP headers after being encapsulated by a special protocol such as L2TP. After protocol de-encapsulation, the outer IP header (lower layer) is peeled off. Therefore, authentication, audit, and control are performed based on the inner IP header (upper layer). The Internet access policies of the device should not block the communication that is performed based on the outer IP header.

6. By default, the device supports the de-encapsulation of single-layer 802.1q VLAN headers regardless of whether protocol de-encapsulation is enabled. If 802.1q is used together with other protocols, such as PPPoE, VLAN (Q-in-Q) de-encapsulation, and PPPoE de-encapsulation need to be selected.

7. After protocol de-encapsulation is enabled, protocol data cannot be compressed or encrypted.