Bug #1107
closed
mpd on AMD64 generates invalid checksums with NAT
0%
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
Updated by Ermal Luçi almost 14 years ago
Does you vpn have lower mtu than openvpn?
That would explain it with that DF bit set on packets.
Updated by Andreas Winge almost 14 years ago
Sorry for not answering sooner. The MTU for the PPTP is 1456 and the MTU for the openVPN is 1500. May this be a part of the problem?
Updated by Ermal Luçi almost 14 years ago
- Status changed from New to Feedback
You should be able to fix this by setting a MSS or lowering the mtu on openvpn interface. MTU seems to be your problem.
Updated by Andreas Winge over 13 years ago
I tried this with the same result as before. Lowered the MTU on the OpenVPN interface to match the MTU of the PPTP interface.
Updated by Chris Buechler over 13 years ago
- Status changed from Feedback to New
- Target version deleted (
2.0)
Updated by Chris Buechler over 13 years ago
- Affected Architecture amd64 added
- Affected Architecture deleted (
)
Updated by Chris Buechler over 13 years ago
- Subject changed from NAT PPTP VPN to OpenVPN client to PPTP on AMD64 generates invalid checksums in some circumstances
Updated by Jason R. Coombs almost 13 years ago
This issue is a blocker for us. We have an IPSEC VPN between two datacenters, and our VPN clients are unable to reach any hosts in the non-local datacenters.
Why isn't this ticket, which is akin to "VPN corrupts packets", not a blocker for pfSense? Is there a workaround? What can we do to provide an incentive to get this fixed? Would a commercial-support contract cover this sort of bug?
Updated by Jim Pingle almost 13 years ago
It's not blocking because:
1. It only affects PPTP - IPsec and OpenVPN work fine
2. It only affects amd64 - i386 works fine.
If someone needs to use PPTP for this, they could still use i386. If they require amd64, then they can still use OpenVPN or IPsec.
It would be worth trying a pfSense 2.1 snapshot based off FreeBSD 8.3. It's possible it was an issue in the OS and it has been fixed since then upstream.
Updated by Jason R. Coombs almost 13 years ago
That makes sense. Thanks for the quick response.
(1) isn't really an option for us - implementing a new VPN solution for all our users is quite an undertaking. We actually started going down that road, but it's a long-term fix.
(2) This is the approach we're heading down now. We don't have the luxury of swapping out the firewall box, but we'll probably deploy a separate 32-bit instance beside our 64-bit instance and handle our PPTP traffic with it.
Updated by Chris Buechler over 12 years ago
- Subject changed from PPTP on AMD64 generates invalid checksums in some circumstances to PPTP and PPPoE server on AMD64 generates invalid checksums in some circumstances
PPPoE server also impacted.
Updated by Chris Buechler over 11 years ago
- Subject changed from PPTP and PPPoE server on AMD64 generates invalid checksums in some circumstances to mpd on AMD64 generates invalid checksums with NAT
- Target version set to 2.2
Updated by Tavo Lopez over 10 years ago
hi all,
2.2 was release and still issue with AMD64 VPN out.
do we have a new target date for this fix?
thx
Updated by Chris Buechler over 10 years ago
2.2 is not released. This needs to be tested on 2.2 and this ticket updated accordingly.
Updated by Jim Pingle over 10 years ago
- Status changed from New to Feedback
This does appear to be fixed on 2.2 snapshots. I connected up a PPTP client to and amd64 VM running 2.2 and it could NAT out WAN without issue. Ran a long capture and not a single bad checksum packet was observed.
Updated by Andreas Winge over 10 years ago
Your description of what you did is something that has worked all along.
It was when the pfsense had an outgoing OpenVPN connection as well that it did not work to NAT from the incoming PPTP connection to the outgoing OpenVPN connection.
I tried to connect the same scenario again, but I could not get the pptp connection up and running yet.
Updated by Andreas Winge over 10 years ago
Oh 2.1.3 that I am running now is so much worse than when I reported this. As said in 2.1.3 NAT out to the WAN wasn't even working. I'll see if I can get up to a 2.2 alpha snapshot and test this. Both out to WAN and out to a OpenVPN tunnel.
Updated by Jim Pingle over 10 years ago
As long as this problem has existed, NAT out WAN via PPTP on amd64 has been broken, that was the easiest problem to replicate and the most common one reported to us as being broken (though less so these days as more and more people wake up and stop using PPTP)
Updated by Andreas Winge over 10 years ago
When I look back at what I wrote and on the logs, I see that all NAT have the checksum error. But for some reason the WAN output and the OpenVPN output treated the broken packet differently. WAN ignored or recalculated the checksum and OpenVPN dropped the packet. I did not realize that until now. Today my setup has changed and the WAN packets are dropped as well. That is why I though there were a change for the worse.
So if you tested that it actually NAT without errors to the WAN interface I will leave it at that. If you need someone else to actually verify your results I can do it when I dare (a bit closer to the release) to put the 2.2 in my production firewall.
(I have no intention of running PPTP when there is OpenVPN support for more or less all devices.)
Updated by Bianco Veigel over 10 years ago
I'm also affected by this Issue.
I'm using a multilink L2TP Tunnel to bond my two V-DSL Lines, so I guess it's a blocker Issue for pfSense and no only affecting deprecated PPTP-Users.