Most broadband firewalls apply both network address and port address translation to outgoing TCP/UDP traffic (NAT...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
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.
Related Q&A from Lisa Phifer
The enterprise mobility management market for wearable devices is in its infancy, but IT can still use existing EMM tools to manage wearables.continue reading
Wireless expert Lisa A. Phifer explains to what extent WEP cracking remains a worrisome issue. It all depends on your company's WLAN security policy.continue reading
Wireless expert Lisa A. Phifer explains why you shouldn't stop using 802.1X authentication methods for enterprise WLAN access control.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.