Answer

Can features such as VPN pass-through on routers be abused to dump traffic onto a NAT'd LAN?

Lisa Phifer
By
Published: 14 Apr 2004
Can features such as VPN pass-through on SOHO routers be abused to dump traffic onto a NAT'd LAN? For example, could I craft an unencrypted forged encapsulated VPN packet such that it would be marked as VPN traffic by a router and be forwarded to the LAN? The ability to drop an arbitrary broadcast packet to the LAN side of a NAT/PAT home router would be a serious chink in the armor. How does the router check traffic to make sure it's actually encapsulated for a VPN? Is it just a flag set in the packet somewhere? Can this be abused to bypass NAT/PAT? What about other routers developed by other companies with similar features?
VPN pass-through usually refers to the ability for broadband firewalls to translate VPN protocols (for example, IPsec ESP/AH or PPTP GRE) that would otherwise be dropped. To understand security risks, consider why these VPN pass-throughs are required in the first place.

Most broadband firewalls apply both network address and port address translation to outgoing TCP/UDP traffic (NAT and PAT, or NAPT). First, the packet's private source IP address is translated to the firewall's public IP address. Because there may be more than one device behind the firewall, the packet's private source port is then translated to an unused ephemeral port. When a response packet for the translated IP address and port is received, the firewall translates the public IP/port back into the private IP/port that sent the original request packet. This has the effect of hiding private addresses used behind the firewall, while letting many devices share one public IP address. These dynamic NAT bindings are typically short-lived, lasting only a few minutes in the absence of traffic.

When a VPN-encrypted packet, like an IPsec VPN ESP packet or a PPTP VPN GRE packet, hits the firewall, the source IP address is unencrypted and can be translated by NAT. However, the source TCP/UDP port is hidden inside the encrypted part of the packet and can't be translated. Other fields in the encrypted packet, like the TCP checksum, are also hidden and can't be modified by NAT. Furthermore, the firewall's rules may only apply to TCP/UDP traffic (protocols 6 and 17) and drop any other protocol, including protocol 47 (GRE) and 50 (ESP).

Some firewalls let you configure a 1-to-1 static NAT that lets any packet reach a specified private source IP address, no matter what the protocol type or port. As you point out, a 1-to-1 static NAT could be abused to send malicious packets through the firewall to the host with that IP address, even when there is no active VPN tunnel. So you should never use 1-to-1 static NAT without applying some kind of protection on the host itself (e.g., personal firewall software).

As an alternative, some firewalls support VPN pass-throughs. A VPN pass-through can translate just the source IP address and not the source port. This can be limited to a single VPN tunnel, or some other (unencrypted) field can be used for tunnel multiplexing, like the IPsec Security Parameter Index (SPI) carried in ESP packets. Typically, the only packets that are allowed to "pass through" to the host are VPN packets (protocol 50 for IPsec pass-through, protocol 47 for PPTP pass-through), and the pass-through may activated only when the host initiates an outbound VPN tunnel. Details depend on the product. Some firewalls may inspect the packet to verify that it's a correctly formed ESP or GRE packet, but they can't look inside the encrypted packet, so it's always possible to send malicious payload to the VPN client. Once again, measures like personal firewalls should always be used on VPN clients to filter incoming traffic once that traffic has been decrypted at the tunnel endpoint.

Dig Deeper on Network infrastructure