[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IPSEC Security Gateways & NAT
The ISP wants to muck around with the inner addresses to cater for
overlapping address ranges between different sites.
The trouble is that there have been various cases where ISPs have 'solved'
their customer's VPN problem with NAT prior to introducing security. This
means they've often used NAT to move datagrams over their network, as well
as to avoid overlapping subnets. I've also seen it used for more esoteric
purposes.
The above illustrates a scenario where the ISP has invested in NAT'ing the
customers addresses. When the ISP adds encryptors they expect the existing
network to need no change but IPSEC security gateways tunnel and break their
model. So the ISP will ask "can you use transport mode?", so they can
continue to NAT. However, I'm not convinced this would work as NAT ALGs
will still not have access to the TCP/UDP payloads for the application-level
NAT. Even without ALG, this would also require the transport headers to be
passed in clear.
Of course, as the IPSEC SG only needs one external address, there's little
point for NAT on the ISP side anymore. And the ISP is still required to
provide a transparent solution to the customer but isn't trusted with the
security.
Chris
> -----Original Message-----
> From: Riley, Susie [mailto:Susie_Riley@adc.com]
> Sent: 11 June 2001 13:23
> To: Chris Trobridge; Joern Sierwald; ipsec@lists.tislabs.com
> Subject: RE: IPSEC Security Gateways & NAT
>
>
>
> if you are trying to put an encryption/vpn box between the
> customes sites
> and the isp, the address assignment by the isp should be for the outer
> tunnel address (to be used by the vpn box to tunnel the
> traffic). in this
> case, as people suggest, esp+udp should work for nat, and
> it's the outside
> address the isp might muck with - not the inner address
> because as far as
> the isp is concerned, there's only one box behind it, and that's the
> ipsec/vpn box. as far as the isp is concerned all the boxes
> behind the
> ipsec/vpn box could be using private addresses and it should
> not care. can
> you describe a scenario where the isp would want to muck with
> both inside
> and outside addresses in a ipsec/vpn scenario, or are you
> talking about a
> different scenario altogether?
>
> susie
>
> -----Original Message-----
> From: Chris Trobridge [mailto:CTrobridge@baltimore.com]
> Sent: Thursday, June 07, 2001 10:25 AM
> To: Joern Sierwald; ipsec@lists.tislabs.com
> Subject: RE: IPSEC Security Gateways & NAT
>
>
> The scenario I'm talking about is where the service provider
> wants to NAT
> the private addresses, ie the inner addresses if tunnelling.
> Obviously this
> is completely contrary to the RFCs but ownership/management
> issues make it
> hard to place the NAT before encryption (when customer
> encrypts and service
> provider NATs).
>
> I don't think it can be done but I'm looking for some
> consensus or other
> evidence on this point.
>
> Chris
>
> > The consensus among IPsec vendors is ESPoUDP. You use tunnel mode,
> > and insert a UDP header in front of the ESP header. This is
> > dead simple and works with normal NAT boxes.
> >
> > Problems and solutions:
> >
> > - some NAT boxes drop fragmented UDP packets. You'll have to
> > mess around
> > with TCP segment sizes and/or encrypt fragments.
> >
> > - The NAT box does not affect any protocols, like FTP,
> > because it's modifying
> > the "outer" IP header and an artifical UDP header.
> >
> > - There might be address collisions. Two clients might be
> > behind firewalls
> > and have
> > the same address 192.168.98.6. Now they do quick mode to
> > the same GW.
> > Trouble ahead. You need some NAT here, be it at the GW or
> > at the client,
> > or private IP address by cfg-mode. Or something.
> >
> > J-rn
> >
> >
> > This footnote confirms that this email message has been swept by
> > MIMEsweeper for the presence of computer viruses.
> >
>
>
> --------------------------------------------------------------
> --------------
> -------------------------------------
> The information contained in this message is confidential and
> is intended
> for the addressee(s) only. If you have received this message
> in error or
> there are any problems please notify the originator immediately. The
> unauthorized use, disclosure, copying or alteration of this
> message is
> strictly forbidden. Baltimore Technologies plc will not be liable for
> direct,
> special, indirect or consequential damages arising from
> alteration of the
> contents of this message by a third party or as a result of
> any virus being
> passed on.
>
> In addition, certain Marketing collateral may be added from
> time to time to
> promote Baltimore Technologies products, services, Global
> e-Security or
> appearance at trade shows and conferences.
>
> This footnote confirms that this email message has been swept by
> Baltimore MIMEsweeper for Content Security threats, including
> computer viruses.
>