The VPN proxy built by PPTP is slow to access the Internet. Solution

Problem: PPTP is used to build a VPN Server on the Linux platform. After dial-in, the Intranet FTP is accessed. downloading files is extremely slow. When using PPTP as a gateway to access the Internet, most websites except Baidu are extremely slow to access, almost inaccessible. Solution: Add-I forward-P TCP -- SYN to the * filter table of iptables of the Linux service where PPTP is located.
-I ppp +-J tcpmss -- Set-MSS 1356/sbin/iptables-I forward-p tcp -- syn-I PPP +-J tcpmss -- Set-MSS 1356 Cause Analysis

===== When the VPN connection is disconnected:

In Windows XP, Ping-F-l xxxxxx 192.168.0.1 for One-Step testing (xxxxxxx is the MTU size, which can be gradually reduced from 1500, and can be pinged)

We can obtain that the maximum pinging MTU is 1426;

===== When connecting to a VPN

In Windows XP, Ping-F-l xxxxxx 192.168.0.1 for One-Step testing (xxxxxxx is the MTU size, which can be gradually reduced from 1500, and can be pinged)

We can see that the maximum pinging MTU is 1372. If the number is exceeded,

==== Dial the VPN and use netstat-I to view the interface on the server.

Iface MTU met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR flg

Eth0 1500 0 102528561 0 0 194391413 0 0 0 bru

Eth1 1500 0 519820535 954 11553 924 0 0 0 bru

Lo 16436 0 151062 0 0 151062 0 0 0 LRU

Ppp0 1396 0 19 0 0 0 8 0 0 0 0 opru we know that the maximum MTU of PPP is 1396, of course, the corresponding MSS should be (mtu-20 byte IP header + 20 byte TCP Header =) 1356 [Knowledge 1] MSS in computer networks:

MSS: Maximum Segment Size

The abbreviation of the Maximum Transmission size of MSS is a concept in TCP.

MSS is the maximum data segment that TCP data packets can transmit each time. In order to achieve optimal Transmission Performance, TCP usually needs to negotiate the MSS value of both parties when establishing a connection, this value is often replaced by the MTU value when the TCP protocol is implemented (the size of the IP packet header must be reduced by 20 bytes and the packet header of the TCP data segment is 20 bytes). Therefore, the MSS is usually 1460. Both parties will determine the maximum MSS value for this connection based on the MSS value provided by both parties.

[Tips 2] MTU is the largest packet package for network transmission.

MSS is the maximum value for data transmission over the network.

The value of MSs header data is MTU.

To put it simply, take the TCP package as an example.

If the message transmits 1400 bytes of data, then MSS is 1400, plus 20 bytes of IP header and 20 bytes of TCP Header, then MTU is 1400 + 20 + 20.

Of course, some headers need to be added to other protocols during transmission. In short, MTU is the total size of the final sent packets. MSS is the data size you need to send. [Knowledge 3] http://www.cnpaf.net/Class/TCPANDIP/200511/9898.html assume that the PC has established an HTTP connection to the server, the PC wants to download a large web page from the server. After the server receives a PC request, it starts to send a large web page file. The DF position of its IP address is 1, which cannot be split. The IP packet length is 1500 bytes. After arriving at the Internet port (Ethernet) of VPN gateway 2, VPN gateway 2 finds that its length exceeds 1500 bytes, so it is dropped
Discard, send back an ICMP message that the destination address cannot be reached to the server, and specify "MTU of Next Hop: 1500 ". After the PC receives the message, it sends the message 1500 bytes and discards it. As a result, it forms a loop and cannot communicate.

According to the above analysis, it is easy to obtain the following solution: Set MTU to 1500-4-20 = 1476 on the outbound interface of VPN gateway 2, in this way, "MTU of Next Hop: 1476" will be given when VPN gateway 2 returns an ICMP inaccessible message ". The server uses 1476 as its maximum MTU for external sending. When it reaches VPN gateway 1, the GRE and outer IP address headers are encapsulated and no more than 1500 is sent to the peer end. -I forward-p tcp -- syn-I PPP +-J tcpmss -- Set-MSS 1356 because MSS is at the beginning of TCP connection establishment, data is transmitted through an IP packet with the SYN flag. Therefore, we stipulate in iptables that when data is forwarded
When a packet with a SYN mark in a PPT * is set to 1356 bytes, the MSS matches the path MTU of the ppp0 interface, and the data is naturally unobstructed. (Note: If a VPN is selected, a virtual device named PPT * is created. You can use ifcpnfig in Linux to see that the first is ppt1, and the second is ppt2 ......)

Reference: 1. http://fanqiang.chinaunix.net/app/other/2005-09-13/3655.shtml 2. http://technet.microsoft.com/zh-cn/library/cc768084 (En-US). aspx 3. This is a complicated problem. First, the problem is discovered in this process: After a WINXP computer (host a) is successfully connected to the company's VPN, when you access a B/S-based CRM system (host B for short) on the Intranet, you can find that the homepage is displayed (the page is relatively simple and contains a small amount of data). After you enter your account and password to log in, only a little bit of content at the top of the page can be displayed, while
Most of the following content cannot be displayed. For another Win2000 computer, the content can be displayed completely. Log on to the Linux VPN host and use tcpdump to capture packets during data transmission. It is found that every time B transfers data larger than 1396 bytes to, the VPN host will report the following information: 10.87.0.200: IP address of the Intranet Nic of the VPN host

10.87.200.1: IP address of host

10.87.200.6: IP address obtained by host B through VPN

21:54:21. 953848 IP 10.87.0.200> 10.100.0.100: ICMP 556: 10.100.0.203 unreachable-

Need to frag (MTU 1396)

The VPN host returns an ICMP inaccessible error message to host B that provides Web Services. The meaning is that the VPN host receives a packet that needs to pass through the shard, and this packet is set in its IP header with a flag that cannot be split (DF. Therefore, this packet cannot pass through the VPN host.

According to the TCP/IP protocol, when establishing a TCP connection, both parties must specify their own MSS (maximum message length), and then select the smallest MSS of both parties, to avoid the case of multipart data packet transmission during subsequent data transmission. Through packet capture analysis, the mss of host B is 1460 bytes, and that of host a is 1357 bytes. Therefore, the two parties negotiate to determine that the MSS is 1357 bytes. That is to say, when TCP data is transmitted in the future, the maximum transmission unit of a data packet, MTU, cannot exceed 1397 (MSS + 20-byte IP header + 20-byte TCP Header), and the IP header is set with a flag that cannot be split (DF.

Run netstat-I on the VPN host to check the MTU value of each network interface. The observed results are as follows:

Iface MTU

Eth0 1500 // Internet Nic Interface

Eth1 1500 // intranet Nic Interface

Lo 16436 // local loopback interface

Ppp0 1396 // winxp vpn access channel interface

We can see that the path MTU of the ppp0 interface is 1396 bytes. That is to say, if a data packet wants to pass this interface, it must not exceed 1396 bytes. If it is greater than this value, two results will appear:

1. If the IP address header of the packet is not set with a flag that cannot be split (DF), the VPN host will split the packet so that the packet size is smaller than 1396 bytes, and then allow it to pass through.

2. If the IP header of the packet is set to a flag that cannot be split (DF), the VPN host will return an ICMP inaccessible error message. This packet is also discarded.

The problem is that the MSS negotiated between host a and host B is 1357 bytes, that is, the MTU of the TCP packet is 1397, while the MTU allowed by ppp0 is 1396, the MTU of host a is greater than that of ppp0! When host B sends a 1397-byte packet to host a, it cannot use the ppp0 interface. Back to the case where the problem was found, the reason why the first page was successfully displayed was that the home page contains a small amount of data, and only one IP packet with no more than 1396 bytes is required for transmission, therefore, the data contained in the page package after successful login is large and needs to be divided into multiple IP data packets for transmission. Here, we can assume that the first IP packet passes through because it does not exceed 1396 bytes, and the subsequent IP packet is large
It is 1397 bytes small and exceeds the MTU path. Therefore, the request is rejected. When it is reflected on the page, most of the content below the login page cannot be displayed.

Let's take a look at the situation of connecting to the VPN with the Win2000 host C installed? Through packet capture, it is found that the MSS proposed by host C is 1360 (the MTU can be calculated as 1400), while the execution of netstat-I, it is found that the MTU of ppp0 is 1496, if the path MTU is greater than the MTU of host C, the result is normal.

You will certainly ask why the MTU proposed by host B is smaller than the path MTU. This question can only be asked by Microsoft. I checked some English documents and said this is a problem in WINXP's system.

Now that you know how the problem works, let's take a look at how to solve it. The solution is simple, that is, using iptalbes to set the MSS proposed by host B for negotiation to 1356. Add a rule in iptables: iptables-a forward-p tcp -- syn-s 10.87.200.0/31-J tcpmss -- Set-MSS 1356 because the MSS starts when the TCP connection is established, it is transmitted through IP packets with SYN signs. Therefore, we stipulate in iptables that when forwarding data, as long as an IP packet with SYN signs and the source address is host B, set its MSS to 1356 bytes, so that it matches the MTU direction of the ppp0 interface, and the data is naturally unobstructed.
Because MSS transmits data through an IP packet with the SYN flag at the beginning of TCP connection establishment, we stipulate in iptables that when forwarding data, when an IP packet with the SYN mark and the source address is host B is found, the MSS is set to 1356 bytes, which matches the MTU direction of the ppp0 interface, data is naturally available.