Le 22/09/2018 à 13:11, Joe a écrit :
On Sat, 22 Sep 2018 10:38:52 +0200
Pascal Hambourg <pas...@plouf.fr.eu.org> wrote:
Le 22/09/2018 à 09:39, Joe a écrit :
Two layers of NAT work just fine, for anything but IPSec.
1) Even one single layer of NAT can cause trouble with other
applications that IPSec : FTP, SIP...
Yes, but one can reasonably expect NAT hardware to also deal with
tracking of multiple port/protocol communications. Pretty much the same
basic code does both jobs, as well as stateful firewalling.
Each complex protocol requires specific handling by both NAT and
connection tracking. You can always work around the lack of connection
tracking support with static firewall rules (at the cost of weaker
security), but you cannot always work around the lack of NAT support
with static NAT rules.
2) IPSec works through NAT, provided that you enable UDP
encapsulation aka NAT-T.
Yes, there's more to go wrong, though.
Like what ?
IPSec is commonly used to
provide pretty much fixed communication between organisations, so
terminating it on the Internet interface rather than on an internal
machine makes sense, as well as keeping it simple with just the public
IP addresses.
IPSec is also commonly used by organisations for remote access by
travelling employees.
Other VPNs such as PPTP are more commonly used from
internal workstations. PPTP will pass through two* layers of NAT at
each end without special provision being made, apart from forwarding of
course.
PPTP does require specific NAT support for the GRE protocol.
Use case : two clients of the same PPTP server share the same public IP
address.
The server sends a GRE packet to the public IP address. How does the NAT
device know which client the packet must be forwarded to ?
