Project

General

Profile

Actions

Bug #1107

closed

mpd on AMD64 generates invalid checksums with NAT

Added by Andreas Winge almost 14 years ago. Updated about 10 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
PPTP
Target version:
Start date:
12/15/2010
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.0
Affected Architecture:
amd64

Description

The issue is that I think that the checksum for some reason is calculated wrong or byte swapped when routing (with NAT) from PPTP VPN to an OpenVPN client. At least it is not working. Well, this is my analysis. I highlighted what I think is interesting in the logs below (***).

re0 - WAN
pptpd0 - PPTP VPN
ovpnc1 - OpenVPN client

If you route with NAT from PPTP VPN to WAN it looks like this (working):

[2.0-BETA4][admin@xxx]/root(9): tcpdump -v -n -i pptpd0 host 80.164.152.75
tcpdump: listening on pptpd0, link-type NULL (BSD loopback), capture size 96 bytes
19:14:00.582416 IP (tos 0x0, ttl 64, id 22594, offset 0, flags [DF], proto TCP (6), length 64)
    192.168.40.10.60061 > 80.164.152.75.80: Flags [S], cksum 0x5702 (correct), seq 2355487667, win 65535, options [mss 1404,nop,wscale 2,nop,nop,TS val 192849934 ecr 0,sackOK,eol], length 0
19:14:00.607126 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    80.164.152.75.80 > 192.168.40.10.60061: Flags [S.], cksum 0x314c (correct), seq 3530199231, ack 2355487668, win 5792, options [mss 1460,sackOK,TS val 450339280 ecr 192849934,nop,wscale 2], length 0

[2.0-BETA4][admin@xxx]/root(11): tcpdump -v -n -i re0 host 80.164.152.75
tcpdump: listening on re0, link-type EN10MB (Ethernet), capture size 96 bytes
19:15:01.082856 IP (tos 0x0, ttl 64, id 54817, offset 0, flags [DF], proto TCP (6), length 64, ***bad cksum 0 (->86b3)!)***
    83.248.xxx.xxx.38454 > 80.164.152.75.80: Flags [S], cksum 0x3885 (correct), seq 799974578, win 65535, options [mss 1404,nop,wscale 2,nop,nop,TS val 192850538 ecr 0,sackOK,eol], length 0
19:15:01.108328 IP (tos 0x0, ttl 57, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    80.164.152.75.80 > 83.248.xxx.xxx.38454: Flags [S.], cksum 0x1756 (correct), seq 3603864442, ack 799974579, win 5792, options [mss 1460,sackOK,TS val 450399785 ecr 192850538,nop,wscale 2], length 0

However if you route it into the OpenVPN tunnel it looks like this (not working):

[2.0-BETA4][admin@xxx]/root(12): tcpdump -v -n -i pptpd0 host 80.164.152.75
tcpdump: listening on pptpd0, link-type NULL (BSD loopback), capture size 96 bytes
19:16:20.063720 IP (tos 0x0, ttl 64, id 50453, offset 0, flags [DF], proto TCP (6), length 64)
    192.168.40.10.60095 > 80.164.152.75.80: Flags [S], cksum 0xde5e (correct), seq 129882988, win 65535, options [mss 1404,nop,wscale 2,nop,nop,TS val 192851327 ecr 0,sackOK,eol], length 0
19:16:21.023063 IP (tos 0x0, ttl 64, id 43348, offset 0, flags [DF], proto TCP (6), length 64)
    192.168.40.10.60095 > 80.164.152.75.80: Flags [S], cksum 0xde55 (correct), seq 129882988, win 65535, options [mss 1404,nop,wscale 2,nop,nop,TS val 192851336 ecr 0,sackOK,eol], length 0

[2.0-BETA4][admin@xxx]/root(13): tcpdump -v -n -i ovpnc1 host 80.164.152.75
tcpdump: listening on ovpnc1, link-type EN10MB (Ethernet), capture size 96 bytes
19:19:01.519112 IP (tos 0x0, ttl 64, id 59600, offset 0, flags [DF], proto TCP (6), length 64, ***bad cksum 89e8 (->e889)!)***
    178.73.xxx.xxx.5577 > 80.164.152.75.80: Flags [S], cksum 0x52a0 (correct), seq 3367230755, win 65535, options [mss 1404,nop,wscale 2,nop,nop,TS val 192852939 ecr 0,sackOK,eol], length 0
19:19:02.453933 IP (tos 0x0, ttl 64, id 45269, offset 0, flags [DF], proto TCP (6), length 64, ***bad cksum 8520 (->2085)!)***
    178.73.xxx.xxx.5577 > 80.164.152.75.80: Flags [S], cksum 0x5297 (correct), seq 3367230755, win 65535, options [mss 1404,nop,wscale 2,nop,nop,TS val 192852948 ecr 0,sackOK,eol], length 0

As reference it looks like this when you route from LAN into the OpenVPN tunnel (working):

[2.0-BETA4][admin@xxx]/root(14): tcpdump -v -n -i re1 host 80.164.152.75
tcpdump: listening on re1, link-type EN10MB (Ethernet), capture size 96 bytes
19:21:45.356301 IP (tos 0x0, ttl 128, id 11321, offset 0, flags [DF], proto TCP (6), length 48)
    192.168.0.102.50076 > 80.164.152.75.80: Flags [S], cksum 0xcbff (correct), seq 3195103939, win 8192, options [mss 1460,nop,nop,sackOK], length 0
19:21:45.405411 IP (tos 0x0, ttl 53, id 0, offset 0, flags [DF], proto TCP (6), length 48, ***bad cksum 0 (->9bca)!)***
    80.164.152.75.80 > 192.168.0.102.50076: Flags [S.], cksum 0x4bac (correct), seq 4025588220, ack 3195103940, win 5840, options [mss 1336,nop,nop,sackOK], length 0

[2.0-BETA4][admin@xxx]/root(15): tcpdump -v -n -i ovpnc1 host 80.164.152.75
tcpdump: listening on ovpnc1, link-type EN10MB (Ethernet), capture size 96 bytes
19:23:34.604946 IP (tos 0x0, ttl 128, id 11493, offset 0, flags [DF], proto TCP (6), length 48)
    178.73.xxx.xxx.5294 > 80.164.152.75.80: Flags [S], cksum 0xf281 (correct), seq 3316722832, win 8192, options [mss 1460,nop,nop,sackOK], length 0
19:23:34.644355 IP (tos 0x0, ttl 54, id 0, offset 0, flags [DF], proto TCP (6), length 48)
    80.164.152.75.80 > 178.73.xxx.xxx.5294: Flags [S.], cksum 0x41e4 (correct), seq 4147233542, ack 3316722833, win 5840, options [mss 1336,nop,nop,sackOK], length 0

I run the following version:
2.0-BETA4 (amd64)
built on Sun Dec 12 18:37:49 UTC 2010

Actions

Also available in: Atom PDF