Since FreeS/WAN does not support NAT traversal (e.g. IPsec over UDP),
the requirement that the ISAKMP source port must be UDP/500 is not an
additional restriction, since you must establish a NAT passthrough for
the ESP packets (protocol 50) to a single internal host anyway. In
most NAT boxes this is solved by defining a default server where
all "exotic" protocols like ISAKMP, ESP and AH are mapped to.
Regards
Andreas
Roland Gafner wrote:
>
> Hi,
>
> >FreeS/WAN requires the source IKE port to be UDP 500, too:
> >
> > masq.firewall.ip.address:500======>217.162.69.72:500
> >
> >Therefore you must map port 500 of your NAT device transparently to port 500
> >to the host you want to start the IPsec tunnel from.
>
>
> Ok I understand that this is a limitation of FreeS/Wan, in my eyes a big show stopper,
> since many offices/branches/homeusers etc. are using some kind of nat (masquerading) boxes.
> And to my knowledge there is no easy solution for a masquerading box, where many internal ip
> addresses are translated to one single external address, to statically map source ports.
> Pls correct me if I'm wrong.
> Maybe someone can explain why FreeS/Wan needs to have ISAKMP requests coming from udp port 500 ??
>
> This is what I found in several ietf documents:
> http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-justification-00.txt
>
> "Since the IKE initiation is sent to the well known ISAKMP
> destination port 500, the receiver must use the UDP source port as
> the packet is received (inbound SA) to be the destination port of
> the return traffic (outbound SA). The source port of the return
> traffic must be the destination port observed when the inbound SA
> packet was received. This is to ensure that NAT port mappings are
> properly preserved. "
>
> Obviously there are other IPSec implementations available which don't have this limitation:
> http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-reqts-01.txt
>
> "Special treatment of port 500. Since some IKE implementations
> are unable to handle non-500 UDP source ports, some NATs
> do not translate packets with a UDP source port of 500. This
> means that these NATs are limited to one IPsec client per
> destination gateway, unless they inspect details of the
> ISAKMP header.
>
> Here is another one:
> http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-01.txt
>
> "The NAT is supposed to float the IKE UDP port, and recipients MUST be
> able to process IKE packets whose source port is different than 500.
> There are cases where the NAT does not have to float the source port
> (only one (IPsec) host behind the NAT or for the first IPsec host it can
> keep the port 500, and float only the following IPsec hosts).
>
> Recipients MUST reply back to the source address from the packet. This
> also means that when the original responder is doing rekeying, or
> sending notifications etc. to the original initiator it MUST send the
> packets from the same set of port and IP numbers that was used when the
> IKE SA was originally created (i.e the source and destination port and
> IP numbers must be same).
>
> For example the initiator sends packet having source and destination
> port 500, the NAT changes that to such packet which have source port
> 12312 and destination port 500, the responder must be able to process
> the packet whose source address is that 12312 and it must reply back
> with packet whose source address is 500 and destination address 12312,
> the NAT will then translate this packet to have source address 500 and
> destination address 500."
>
> rgds
> Roland
>
======================================================================
Andreas Steffen e-mail: andreas.steffen_at_zhwin.ch
Zuercher Hochschule Winterthur home: http://www.zhwin.ch/~sna/
CH-8401 Winterthur (Switzerland) phone: +41 76 340 25 56
===============================================================[ZHW]==
_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.3 : Mon Jul 29 2002 - 05:19:42 CEST