Date: Fri, 13 Oct 2000 09:46:00 -0500 From: Jim Gray <jim.gray@motorola.com> To: freebsd-questions@FreeBSD.ORG Subject: NAT and IPsec MVP Message-ID: <39E72027.E5D8A374@motorola.com>
next in thread | raw e-mail | index | archive | help
Hello,
First, many thanks for FreeBSD and the great online support! I have used
an old 386 box with FreeBSD to connect my home network to dial up ISP
and have now built a second box with two NIC cards running FreeBSD 4.0
in anticipation of cable modem sevice comming up. I rebuilt the kernal
and got NAT and DIVERT running with the OPEN option in the rc.firewall
template provided. I tested it end to end using an addonics web sharing
box as the DHCP host. Everything was working fine until my employer
announced they were changing the Virtual Private Network software we
have to use to a version that uses "IPsec". Now I cannot tunnel into my
corporate anymore(WWW access is ok). I have appended their PROPOSED
SOLUTION below, as well as a white paper describing NAT problems with
IPsec protocol.
My first and simplest question is:
How do I implement the ESP protocol and UDP port protocols suggested in
the PROPOSED SOLUTION(below) in the firewall rules?
I think the UDP rules should be:
$(fwcmd) add pass udp from any to 500
$(fwcmd) add pass udp from 500 to any
is this correct?
The IP ESP protocol has no ports associated with it so I am clueless.
Any suggestions?
My second question is: Do you think this plus the designated
subnet(below) will fix the NAT problem?
Thanks in advance for any help.
Best Regards,
Jim Gray
***************************************
**********PROPOSED SOLUTION:
Answer:
Users with cable, ISDN or DSL access to the Internet and have a
small home network connected with a generic firewall sitting
between network and Internet, will have to open following
protocols on the firewall.
IP protocol 50(ESP) to/from any
UDP port 500(IKE ) to/from any
The Home LAN solution
The Home LAN solution was developed to accommodate users who have a
network set up at home. In the past, users could not access the
resourceson their home network, such as printers, while they were using
MVP. This created problems for users who wanted to print to their local
network printer, for example.
By reserving a specific subnet, we were able to solve this problem.
With split tunneling technologies, users are now able to access the
intranet and the Internet through MVP as well as local resources on
their home network.
How do I set it up?
First, you must have a device that handles smart NAT (Network
Address Translation). An example of such a device is the LinkSys
Cable/DSL Router. You can get more information on the LinkSys Cable/DSL
Router and similar devices on the Remote Access - Personal Firewalls web
page.
Next, you must set up your home LAN with the appropriate
subnet. The following subnet is reserved for the Home LAN solution:
192.168.128.x
You must make sure that your LinkSys Cable/DSL Router or other
such device is configured appropriately with the reserved subnet.
Make sure that all of the other devices in your home LAN have
IP addresses in this reserved subnet as well.
********************************************
*************PROVIDED WHITE PAPER:
Question: How do I get MVP 4.0 to work with NAT?
Answer:
The Obstacles for NAT with IPsec
By Kate Pence
Network Address Translation (NAT) was originally implemented to
circumvent
the problem with IPV4 of running out of address space, but it has also
become
a solution for network designers that do not want to incur the costs
associated
with purchasing registered addresses. There are several issues with
using
Many-to-One NAT with IPsec, which utilizes either ESP or AH protocols.
This
paper will discuss the most common implementation of Many-to-One NAT,
and
the issues surrounding its use with IPsec. The scope of this document
is
limited to IPsec as implemented between the Contivity Extranet Switch
and its
Extranet Access Clients. Branch office support behind a NAT device is
not
discussed or recommended.
Many-to-One NAT, as its name implies, associates many addresses on a
private network with one address on the NAT device’s public interface.
Typically a NAT device has at least two interfaces. One has an Internet
assigned address, the other has a private address. Usually, the private
address is from one of the pools set aside for private use, for example
10.x.x.x.
There are Network Address Translators that allow static mapping of IP
addresses so that each private address maps to a unique public address.
The
issues with One-to-One NAT are out of the scope of this document.
The NAT device will receive a request from a client and map the
client’s
source port to one of its own and modify the packet to use its own
public
address and its own source (see Figures 1 and 2). The NAT device will
then
forward the packet to the destination device. The destination device
will
respond to the destination port and address of the NAT device. When the
NAT
device receives the response it will look in its table to see which IP
address
and port combination matches the destination port in its Network
Address
Translation table. It will then modify the packet with the appropriate
destination
IP address and port and ship the packet off to the client.
There is no RFC on how Many-to-One must be implemented, but the above
description is the most common implementation. Some protocols will not
function across a NAT device and in some instances, FTP for example,
Application Layer Gateway functionality is added to the NAT device to
account
for them [REK98]. Unfortunately at this time, there is no ALG that will
handle the
IPsec issues. The difficulty in building an ALG for IPsec on a box
external to the
IPsec peers, lies in the fact that it would have to modify data which
is encrypted
or otherwise protected by the dynamically-generated keys which are kept
(and
must be kept) as a secret between the IPsec peers.
The Contivity Extranet Switch can be configured to use either AH or ESP
encapsulation. ESP allows for encryption, authentication, and
integrity,
whereas AH is used for authentication and integrity only. AH does not
lend
itself to NAT because it was designed as an end-to-end protocol. "The
IP
Authentication Header seeks to provide security by adding
authentication
information to an IP datagram. This authentication information is
calculated
using all of the fields in the IP datagram (including not only the IP
Header but
also other headers and the user data) which do not change in transit."
[ATK95]
"So when NAT does what it is supposed to do by altering the address
information in the header of the packet, the destination host receives
the
altered packet and begins digesting the AH message. The AH routines at
this
host will invalidate the packet since the contents of the headers have
been
altered [HS98]." AH will not work through any type of device that
alters the
address including One-to-One NAT. See Figures 3 and 4 for AH packet
information.
Figure 3
BEFORE APPLYING AH
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING AH
---------------------------------
IPv4 |orig IP hdr | | | |
|(any options)| AH | TCP | Data |
---------------------------------
|<------- authenticated ------->|
except for mutable fields
Figure 4
Authentication Header Format:
[KA98c]
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Authentication Data (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When selecting DES or 3-DES encryption on the CES, ESP (protocol
50) is used. Making an IPsec connection to the CES using DES or
3-DES encryption is a two step process. The security association is
made using ISAKMP/Oakley Key Negotiation. The issue with NAT and
ISAKMP is that it requires that both the source and destination be UDP
port 500. Most Many-to-One NAT implementations map one of the
dynamic user ports of the NAT device to the client’s source port. Some
NAT implementations will allow static mapping of ports, and some use
the client’s source port when possible. In instances where the NAT
maps its own source port 500 to the client’s source port, one client
will
be able to authenticate through ISAKMP. If the first client is able to
connect, then the problem will arise when there is more than one client
making requests. The NAT device only has one port 500, so the second
request would most likely get mapped to a different port. The CES’
Public Interface filters out UDP packets that do not have a source port
of 500. If the request came in on the Private Interface of the CES,
which
does not have as many filter restrictions, the CES would respond back
to the NAT’s port 500, which would undoubtedly confuse a NAT device
not equipped to handle ISAKMP traffic. If the NAT vendor wants to
support IPsec then they will need to develop a method to handle the
multiple clients requesting the use of UDP port 500.
Note: The Contivity Extranet Switch does not imbed any IP addresses
requiring translation in the ISAKMP packets for Extranet Access
Clients, but
some implementations of ISAKMP do imbed IP addresses that may require
translation and this would be a further obstacle for NAT that may not
be
circumventable.
The second piece of the IPsec connection is the protocol 50 (ESP)
traffic that handles the encrypted/encapsulated packets. See Figure 5
for ESP packet information. Protocol 50 has no ports associated with
it,
again causing problems for the NAT device. The NAT implementation
would need to somehow be aware of the security associations so that
it could map the outbound SA to the inbound SA for a specific IP
address. Since the packets are encrypted this becomes a little
trickier.
However, each SA has an SPI associated with it, so if the NAT can
implement some way to keep track of the SPI’s and determine a valid
amount of time to keep them active then theoretically, a NAT device
could handle IPsec traffic.
Figure 5
[KA98b]
BEFORE APPLYING ESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING ESP
-------------------------------------------------
IPv4 |orig IP hdr | ESP | | | ESP | ESP|
|(any options)| Hdr | TCP | Data | Trailer |Auth|
-------------------------------------------------
|<----- encrypted ---->|
|<------ authenticated ----->|
The Nortel Networks’ Instant Internet and Nautica 200 products have
implemented a method of Many-to-One NAT that allows for Extranet Access
Clients to communicate with the Contivity Extranet Switch. There are
some
restrictions in the design that require only one connection to be
initiated at a
time. Several connections can exist at a time, but they must be
initiated
independently.
REFERENCES
[ATK95] R. Atkinson, "IP Authentication Header," RFC 1826, August 1995.
[EF94] K. Egevang, P. Francis, "The IP Network Address Translator
(NAT)",
RFC 1631, May 1994.
[HAI98] T. Hain, "Architectural Implications of NAT", Internet Draft,
July 1998.
[HS98] Matt Holdrege, Pyda Srisuresh, "IP Network Address Translator
(NAT)
Protocol Issues", Internet Draft, August 1998.
[KA98a] Steve Kent, Randall Atkinson, "Security Architecture for the
Internet
Protocol", Internet Draft, July 1998.
[KA98b] Steve Kent, Randall Atkinson, "IP Encapsulating Security
Payload
(ESP)", Internet Draft, July 1998.
[KA98c] Steve Kent, Randall Atkinson, "IP Authentication Header",
Internet
Draft, July 1998.
[REK98] Yakov Rekhter, "Implications of NAT’s on the TCP/IP
architecture",
Internet Draft, August 1998.
[SH98] P. Srisuresh, Matt Holdrege, "IP Network Address Translator
(NAT)
Terminology and Considerations", Internet Draft, July 1998.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39E72027.E5D8A374>