VPN Protocol 47

Home Forums Discussions Support Portal VPN Protocol 47

This topic contains 4 replies, has 2 voices, and was last updated by  gianniszrf 10 years, 10 months ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #5058

    gianniszrf
    Participant

    What can i do with packets of protocol 47 (VPN).
    I am OK with protocols TCP,UDP,ICMP and NAT but i have problems to handle these packets with NAT.
    Any ideas?

    Thanks

    #6142

    Vadim Smirnov
    Moderator

    IP type 47 corresponds PPTP GRE protocol. You can read a nice overview of PPTP protocol issues here:

    http://www.microsoft.com/technet/community/columns/cableguy/cg0103.mspx

    Below is the most importand NAT relative quote from the link above:

    PPTP uses the Sequence Number and Acknowledgement Number fields to detect dropped data packets.

    The use of a separate mechanism for PPTP data encapsulation has an interesting side effect for network address translators (NATs). For more information about NATs, see Windows 2000 Network Address Translator (NAT) (the March 2001 Cable Guy article). Most NATs can translate TCP-based traffic for PPTP tunnel maintenance. However, PPTP data packets with the GRE header are not typically translated without using either a static address mapping or a PPTP NAT editor.

    When a PPTP server is behind a NAT, the NAT must be manually configured with a static address mapping that maps all the traffic for a specific public address to a specific private address. In this case, only the addresses in the IP header are modified.

    When a PPTP client is behind a NAT, a PPTP NAT editor is typically used. A NAT editor is an additional software component on the NAT that performs translation services beyond IP addresses, TCP ports, and UDP ports. Although it is a simple matter for the PPTP NAT editor to monitor incoming packets for GRE payloads and translate the IP addresses in the IP header, there might be multiple PPTP clients behind the NAT. In this case, the NAT is unable to determine to which private client the incoming PPTP data packet is destined, because the same public address is being used for multiple private clients. To determine the private client to which an incoming packet is destined, the PPTP NAT editor uses the Call ID field in the GRE header. However, when two different PPTP clients use the same Call ID, the NAT is unable to determine to which private client the packet is destined.

    To provide correct multiplexing of GRE-encapsulated traffic to different private clients, the PTPP NAT editor monitors the PPTP control connection setup and translates both the PPTP client’s Call ID field in the PPTP messages and the GRE-encapsulated data packets in the same way that it translates TCP or UDP source ports. By translating the PPTP client Call ID field, the NAT ensures that a unique Call ID is used for each PPTP tunnel, and for each PPTP client.

    #6143

    gianniszrf
    Participant

    After the IP translation in the IP header and perhaps the CallerID translation is there any checksum that must be calculated?

    Thanks

    #6144

    Vadim Smirnov
    Moderator

    Of course IP checksum should be recalculated if IP header was altered. PPTP GRE header never has the checksum field (Checksum Present flag is always set to 0 for PPTP).

    #6145

    gianniszrf
    Participant

    Thanks for your help

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.