> Source: [sk179965](https://support.checkpoint.com/results/sk/sk179965)

# sk179965 - Traffic stops passing in Site-to-Site VPN tunnel, IKE is successful, VPN tunnel is up and uses NAT-T

| Property | Value |
|----------|-------|
| Solution ID | sk179965 |
| Date Created | 2022-09-18 |
| Last Modified | 2023-07-24 |
| Technical Level | General |
| Products | Security Gateway |
| Versions | R81.20, R81.10 (EOS), R81 (EOS) |
| OS | Gaia |

## Symptoms

- * Traffic stops passing between two Site-to-Site VPN Gateways.
* IKE is successful. The VPN tunnel is up and uses NAT-T. On the CLI of a Check Point VPN Gateway, output of `[Expert@HostName]# vpn tu tlist -p ` shows a "`Tunnel-created`" timestamp.
* In the encryption domain of a VPN Gateway, a Security Gateway with a PPPoE interface sends traffic to the encryption domain of the peer VPN Gateway, but does not receive a reply.
* On the Security Gateway with the PPPoE-Interface, the FW-Monitor Utility shows:  

  ```
  1. Incoming in clear and going through the pre-inbound and post-inbound chains ('Small 'i', Big 'I').
  2. Going out and getting encrypted on the pre-outbound and post-outbound chains ('Small 'o', Big 'O', Encrypt-before 'Oe', Encrypt-After 'OE').
  [Protip: Use the '-p all' flag with FW-Monitor to view the full chains of inspection]
  ```

* "tcpdump" (OSI Layer 2) does not show NAT-T traffic leaving the Security Gateway with a PPoE interface. "tcpdump" also does not show NAT-T traffic entering the the peer VPN Gateway.
* Kernel-level debugs on the Security Gateway with a PPPoE interface show this syntax:   

  ```
  [cpu_1];[fw4_0];fw_ipsec_encrypt_on_tunnel_instance: encryption successful;
  [cpu_1];[fw4_0];skbuff_packet_update_dev_ex: replacing eth0 with pppoe1;
  [cpu_1];[fw4_0];fwlinux_netfilter_deliver_packet: delivering packet: 
  [cpu_1];[fw4_0];Device pppoe1 ,(PPPoE-Interface Gateway's external IP)->(Peer-Gateway IP), UDP 4500->4500;
  ```

## Cause

As part of the routing decision in the NAT-Traversal (NAT-T) mechanism, the Security Gateway adds a MAC Address header to the packet.   

In a point-to-point setup, the Security Gateway with a PPPoE Driver adds a MAC header to the packet before it sends it to the external interface. This causes a duplicate MAC header and thus a corrupted packet. As a result, the packet is encrypted but does not leave the interface as expected.

## Solution

[Contact Check Point Support](https://www.checkpoint.com/support-services/contact-support/) to get a Hotfix for this issue.

A Support Engineer will make sure the Hotfix is compatible with your environment before providing the Hotfix.  
For faster resolution and verification, collect [CPinfo](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk92739) files from the Management Server and Security Gateways / Cluster Members involved in the case.

**Hotfix installation instructions:**   
Refer to [sk168597 - How to install a Hotfix](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk168597).

For faster resolution and verification, please collect *CPinfo* files from the Security Management Server and Security Gateways involved in the case.  
Refer to [sk92739 - The CPInfor utility](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk92739).

---

# Agent Instructions

This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products.

## Navigating This Knowledge Base

- **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt)
- **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml)
- **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}`
- **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content