Most broadband firewalls apply both network address and port address translation to outgoing TCP/UDP traffic (NAT...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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 LANs (Local Area Networks)
Related Q&A from Lisa Phifer
Learn the difference between a site-to-site VPN and a remote-access VPN, as well as the protocols used for each one.continue reading
Need to send an email, check your flight's status or get ready for a presentation? You can do it all on your smartwatch, thanks to a slew of Apple ...continue reading
New and improved management features have made Android devices more suitable for enterprise use, and API and EMM tools can streamline the device ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.