# pfSense Interface Types - PPPoE, GRE, GIF, LAGG, QinQ

> Configuring pfSense interface types - PPPoE connections, GRE and GIF tunnels, LAGG link aggregation (LACP), QinQ double tagging, and interface groups

Source: https://opennix.org/en/docs/pfsense/interfaces/pfsense-interface-types/


pfSense provides a range of virtual interface types for various networking tasks: from ISP connectivity via PPPoE to combining physical links into a fault-tolerant group via LAGG. Each virtual interface, once assigned in the system, functions identically to a physical one - receiving its own IP address, firewall ruleset, and access to network services. This guide covers the configuration of each interface type, typical use cases, and troubleshooting procedures.

## PPPoE

PPPoE (Point-to-Point Protocol over Ethernet) is used by ISPs to authenticate subscribers and assign network parameters. The protocol encapsulates PPP frames within Ethernet, adding a PPPoE header to each packet.

### PPPoE Configuration

To create a PPPoE connection, navigate to **Interfaces > Assignments**, select the **PPPs** tab, click **Add**, and choose **PPPoE** as the link type.

Key parameters:

- **Link Interface** - the physical interface through which the PPPoE session is established (typically WAN)
- **Username** - the username provided by the ISP (usually in email format, e.g., `user@isp.com`)
- **Password** - the authentication password
- **Service Name** - the ISP service name (most ISPs leave this blank). Some ISPs require sending a NULL value instead of an empty string

After creating the PPP interface, assign it to WAN through **Interfaces > Assignments** and select PPPoE as the IPv4 configuration type.

### MTU and MSS Clamping

PPPoE adds 8 bytes of header overhead to each packet, reducing the effective MTU from 1500 to 1492 bytes. This can cause fragmentation issues and loss of large packets, particularly when traversing routers that block ICMP Path MTU Discovery messages.

pfSense automatically applies TCP MSS Clamping - a mechanism that adjusts the Maximum Segment Size field in TCP SYN packets. MSS Clamping reduces the requested segment size to a value compatible with the interface MTU, preventing fragmentation at the TCP level.

The **Force MTU** parameter allows overriding the ISP-negotiated MTU. This violates RFC 1661 and may break connectivity - use only when explicitly necessary.

### PPPoE Backend

pfSense supports two backends for PPPoE:

- **MPD** - the default backend, operating in userspace
- **if_pppoe** - a kernel-based backend providing higher performance by processing PPPoE directly in the kernel

For high-speed connections, `if_pppoe` is recommended since MPD can become a bottleneck due to single-queue packet processing.

## GRE Tunnels

GRE (Generic Routing Encapsulation) creates an unencrypted tunnel between two endpoints by encapsulating packets of one protocol within another. GRE can carry both IPv4 and IPv6 traffic simultaneously through a single tunnel. The protocol was designed by Cisco and is widely supported across networking equipment from various vendors.

### Creating a GRE Tunnel

To create a GRE tunnel, navigate to **Interfaces > Assignments**, select the **GRE** tab, and click **Add**.

| Parameter | Description |
|---|---|
| Parent Interface | Physical interface (typically WAN) through which the tunnel is established |
| Remote Address | Routable external IP address of the remote device |
| Local Tunnel Address | Internal IPv4 address of the tunnel on the local side |
| Remote Tunnel Address | Internal IPv4 address of the tunnel on the remote side |
| Tunnel Subnet | Subnet mask for tunnel addresses (typically /30) |

After creation, assign the GRE interface through **Interfaces > Assignments** and enable it. The system automatically creates a dynamic gateway for routing traffic through the tunnel.

### Routing Through GRE

To direct remote subnet traffic through the GRE tunnel, add static routes in **System > Routing > Static Routes**, specifying the GRE tunnel's dynamic gateway as the next hop. Create [firewall rules](/docs/pfsense/firewall/pfsense-firewall-rules/) on the GRE interface to permit the required traffic.

## GIF Tunnels

GIF (Generic tunnel InterFace) is similar to GRE but has several distinctions. GIF supports tunneling IPv6 over IPv4 and vice versa, making it the primary tool for obtaining IPv6 connectivity through tunnel brokers (such as Hurricane Electric). Unlike GRE, GIF cannot carry IPv4 and IPv6 simultaneously through a single tunnel, but it supports Layer 2 bridging.

### Creating a GIF Tunnel

Configuration is performed in **Interfaces > Assignments** on the **GIF** tab. Parameters are similar to GRE:

- **Parent Interface** - physical interface for the tunnel
- **Remote Address** - external address of the remote side
- **Local Tunnel Address** - internal tunnel address (typically /64 for IPv6)
- **Remote Tunnel Address** - remote side tunnel address

### IPv6 via Tunnel Broker

To obtain IPv6 connectivity through Hurricane Electric:

1. Register at tunnelbroker.net and create a tunnel
2. Create a GIF interface with the parameters provided by the broker
3. Assign the GIF interface and configure the IPv6 address
4. Add a default IPv6 route through the tunnel gateway

## LAGG (Link Aggregation)

LAGG combines multiple physical network interfaces into a single logical link. Depending on the selected protocol, LAGG provides increased throughput, failover capability, or a combination of both.

### Supported Protocols

| Protocol | Description | Requires Switch Configuration |
|---|---|---|
| LACP | IEEE 802.3ad, negotiation with switch, failover and load balancing | Yes |
| Failover | All traffic through primary interface, backup activates on failure | No |
| Load Balance | Static outbound traffic distribution without link-state monitoring | Yes |
| Round Robin | Sequential transmission across interfaces | Yes |
| None | Disables traffic while keeping the logical interface active | - |

LACP is the most commonly used protocol, providing both failover and increased throughput. Failover does not require switch support and is appropriate for scenarios where only redundancy matters.

### Creating a LAGG

Navigate to **Interfaces > Assignments**, select the **LAGGs** tab, and click **Add**:

1. Select member interfaces in the **Member Interfaces** field (interfaces must not be currently assigned)
2. Select the protocol in the **LAGG Protocol** field
3. For LACP and Load Balance, select the hashing algorithm
4. Add a description and click **Save**

After creation, assign the LAGG interface through **Interfaces > Assignments**. The LAGG interface can serve as a [VLAN](/docs/pfsense/vlans/pfsense-vlan-setup/) carrier - create VLANs on top of LAGG for segmentation with link aggregation.

### Requirements and Limitations

- Speed and MTU of all LAGG members must be identical
- All ports must operate in full-duplex mode
- A single flow (between two hosts) will not exceed the throughput of a single member, as hashing distributes flows rather than individual packets
- LAGG is incompatible with altq (traffic shaper). For traffic limiting on LAGG, use Limiters or create VLANs on top of LAGG
- LACP requires stackable switches for multi-switch operation

## QinQ (802.1ad)

QinQ (Q-in-Q, double tagging) adds a second VLAN tag to an already tagged frame. The outer tag (S-Tag, EtherType 0x88a8) identifies the provider's service VLAN, while the inner tag (C-Tag, EtherType 0x8100) preserves the customer's original VLAN. This enables transporting multiple customer VLANs through a single provider service link without identifier conflicts.

### Use Cases

- Transporting VLANs between sites through a provider link that does not support 802.1Q trunking
- Isolating customer VLANs in multi-tenant environments
- Extending the VLAN address space beyond 4094 identifiers

### QinQ Configuration

Navigate to **Interfaces > Assignments**, select the **QinQ** tab, and click **Add**:

- **Parent Interface** - physical interface for QinQ traffic
- **First level tag** - outer (service) VLAN identifier
- **Member VLANs** - inner VLAN identifiers (ranges can be specified, e.g., 100-150)

An automatic QinQ interface group is created by the system to simplify firewall rule management when dealing with a large number of tags. This group must not be edited manually.

## Wireless Interfaces

pfSense supports wireless interfaces when a compatible Wi-Fi adapter is present. Wireless interfaces are created in **Interfaces > Assignments > Wireless** and can operate in Access Point (hostap) or Infrastructure (BSS/client) modes. Once assigned, a wireless interface is configured similarly to a wired one: IP address, DHCP, and firewall rules.

For wireless client isolation, placing the wireless interface in a separate [VLAN](/docs/pfsense/vlans/pfsense-vlan-setup/) or using a [bridge](/docs/pfsense/bridging/pfsense-bridge-setup/) with filtering is recommended. For guest user authentication, attach [Captive Portal](/docs/pfsense/captive-portal/pfsense-captive-portal-setup/) to the wireless network interface.

## Interface Groups

Interface Groups combine multiple interfaces under a single name for applying common firewall rules. Instead of creating identical rules on each interface, a rule is created on the group and applied to all its members.

To create a group, navigate to **Interfaces > Assignments > Interface Groups**, click **Add**, specify the group name, and select members. After creation, the group appears as a separate tab in **Firewall > Rules**.

Group rules are processed before individual interface rules. This is important when planning security policy - a group rule can intercept traffic before it reaches rules on a specific interface.

## Assigning and Configuring Interfaces

All virtual interface types (PPPoE, GRE, GIF, LAGG, QinQ) must be assigned through **Interfaces > Assignments** after creation:

1. Select the created virtual interface from the **Available network ports** dropdown
2. Click **Add** to assign it
3. Navigate to the assigned interface page (**Interfaces > [OPTn]**)
4. Enable the interface and configure network parameters

After assignment, the interface receives a system name (OPT1, OPT2, etc.) that can be replaced with a descriptive name in the **Description** field. This name is used in firewall rules, NAT, and routing.

## Troubleshooting

### PPPoE Fails to Connect

- Verify credentials (username and password) are correct
- Ensure the physical WAN interface is active and connected to the ISP modem
- Check PPPoE logs in **Status > System Logs > PPP** for authentication errors
- Try specifying the Service Name if the ISP requires it
- For performance issues, switch the backend to `if_pppoe`

### GRE/GIF Tunnel Not Working

- Verify that external addresses on both sides are mutually reachable
- Check WAN firewall rules - GRE protocol (IP Protocol 47) or IP-in-IP (Protocol 4 for GIF) must be permitted
- Verify tunnel addresses do not conflict with existing subnets
- Ensure static routes point to the correct tunnel gateway

### LAGG Not Aggregating Links

- Verify LACP is configured on the switch for the corresponding ports
- Ensure speed and duplex settings match across all members
- Check LAGG status in **Interfaces > LAGG > [name]** - all members should show Active state
- For LACP debugging, use **Diagnostics > Command Prompt** with the command `ifconfig lagg0`

### QinQ Traffic Not Passing

- Verify that intermediate equipment is not stripping the outer tag
- Check that the parent interface passes frames with increased MTU (standard Ethernet MTU 1500 + 4 bytes per tag)
- Ensure switches along the path support jumbo frames or increased frame sizes