Re: Linux v Dedicated NAT routers - secure remote differences

From:
Date: 09/29/02 

Date: Sun, 29 Sep 2002 21:25:30 GMT

Leonid Rosenboim wrote:
...
>
> NAT After IPSec
> ...
> When IPSec uses Authentication-Header (AH) mode for packet integrity, if
> one-to-one address translation occurs it will
> invalidate the signature checksum. Because the signature checksum is
> partially derived based on the AH packet's IP header
> contents, when the IP header changes, the signature checksum is
> invalidated. In this case, the packet will appear to have been
> modified in transit and will promptly be discarded when received by the
> remote peer.

I don't think this is the case - it was reported to me that my packets had
arrived within the internal company network, the problem was that the
return IP address was the internal address of my home network
(10.0.10.0/24)

I think the company changed the approach to this about a year ago, precisely
because of the problems caused by NAT and the encrypted packet headers
which didn't match the NATed version.

> However, when IPSec uses ESP, the
> devices will be able to successfully send packets over the VPN, even when
> one-to-one address translation occurs after
> encapsulation. This scenario is possible because ESP does not use the IP
> header contents to validate the integrity of the
> packets.

I am not about the ESP TLA, but my IKE settings are to Force UDP
encapsulation.

> In cases where many-to-one address translation occurs (aka port
> address translation), the IP address and source IKE
> port, normally User Datagram Protocol (UDP) port 500, will change. Some
> VPN devices do not support IKE requests sourced
> on ports other than UDP 500, and some devices performing many-to-one NAT
> do not handle ESP or AH correctly.

I am reverse NATing port 500 stuff back to my laptop

>Remember
> that ESP and AH are higher-layer protocols on top of IP that do not use
> ports.
> Because many-to-one address translation is commonplace in many
> environments where remote-access clients are deployed, a
> special mechanism called NAT transparency exists to overcome these NAT
> issues. NAT transparency reencapsulates the IKE
> and ESP packets into another transport layer protocol, such as UDP or TCP,
> which address-translating devices know how to
> translate correctly. This mechanism also allows the client to bypass
> access control in the network that allows TCP or UDP but
> blocks encrypted traffic.

See above 

-- 
Alan Chandler

Relevant Pages

  • Re: iptables: fake ip using DNAT and SNAT
    ... :I.e, the application receieves the real source address, so the ... the "ip rule add nat" command reports to be deprecated. ... what bothers me is why packets arriving via ... You can force the translation on machine A by routing packets out the ...
    (comp.os.linux.networking)
  • Re: how can i redirect traffic temporarily to another IP?
    ... > The DNAT HOWTO is your fwend. ... > esp section ... Make sure the packets are accepted on the INPUT or ... NAT is Network Address ...
    (comp.os.linux.security)
  • Is PF with NAT useless for filtering?
    ... I've spent a while reading about PF, and now I've reached the NAT ... "Also be aware that since translation occurs before filtering, ... So it seems that it's not possible to have the filtering rules act on ... the packets as the local network sees them, as is possible in IPFW using ...
    (comp.unix.bsd.freebsd.misc)
  • Re: packet filter : official documentation not enought, questions remain
    ... If you pass a connection which involves translation (nat, rdr, binat), ... this latter construct will apply _only_ to packets translated by the nat ...
    (comp.unix.bsd.openbsd.misc)
  • Re: VPN Passthrough with iptables
    ... >> it wants to be standards compatible, you simply can't NAT it. ... >> whereas NAT is definitly tampering with IP packets. ... > As I understand it, AH cannot be NATed, but ESP doesn't protect the ...
    (comp.security.firewalls)