Project

General

Profile

Actions
Copy link

Bug #7801

closed

UDP fragments received over IPsec tunnel are not properly reassembled and forwarded

Added by Chris Linstruth over 7 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Viktor Gurov
Category:
IPsec
Target version:
2.6.0
Start date:
08/22/2017
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
22.01
Release Notes:
Default
Affected Version:
2.3.4_1
Affected Architecture:

Description

I used this to generate the large UDP datagrams on Host J1:
nping —udp —source-port 5060 —dest-port 5060 —data-length 2000 172.31.200.100
or
nping —udp —source-port 5060 —dest-port 5060 —data-length 2000 172.31.202.100

With pf enabled on both H and J

Into J LAN
01:12:22.571417 IP 172.31.201.100.5060 > 172.31.200.100.5060: UDP, length 2000
01:12:22.571425 IP 172.31.201.100 > 172.31.200.100: ip-proto-17
01:12:23.599657 IP 172.31.201.100.5060 > 172.31.200.100.5060: UDP, length 2000
01:12:23.599666 IP 172.31.201.100 > 172.31.200.100: ip-proto-17
01:12:24.603630 IP 172.31.201.100.5060 > 172.31.200.100.5060: UDP, length 2000
01:12:24.603639 IP 172.31.201.100 > 172.31.200.100: ip-proto-17

Into IPsec on J
01:13:29.451155 (authentic,confidential): SPI 0xc99a1e36: IP 172.31.201.100.5060 > 172.31.200.100.5060: UDP, length 2000
01:13:30.463517 (authentic,confidential): SPI 0xc99a1e36: IP 172.31.201.100.5060 > 172.31.200.100.5060: UDP, length 2000
01:13:31.482213 (authentic,confidential): SPI 0xc99a1e36: IP 172.31.201.100.5060 > 172.31.200.100.5060: UDP, length 2000

Out of IPsec on H
01:15:00.971973 (authentic,confidential): SPI 0xc99a1e36: IP 172.31.201.100.5060 > 172.31.200.100.5060: UDP, length 2000
01:15:01.997529 (authentic,confidential): SPI 0xc99a1e36: IP 172.31.201.100.5060 > 172.31.200.100.5060: UDP, length 2000
01:15:03.029548 (authentic,confidential): SPI 0xc99a1e36: IP 172.31.201.100.5060 > 172.31.200.100.5060: UDP, length 2000

Out H LAN
01:16:09.025710 IP 172.31.201.100.5060 > 172.31.202.100.5060: UDP, length 2000
01:16:09.025715 IP 172.31.201.100 > 172.31.202.100: ip-proto-17
01:16:10.047232 IP 172.31.201.100.5060 > 172.31.202.100.5060: UDP, length 2000
01:16:10.047239 IP 172.31.201.100 > 172.31.202.100: ip-proto-17
01:16:11.066202 IP 172.31.201.100.5060 > 172.31.202.100.5060: UDP, length 2000
01:16:11.066209 IP 172.31.201.100 > 172.31.202.100: ip-proto-17

(Note that ICMP unreachables were returned by 172.31.202.100 since there is nothing
listening on udp/5060. They were received by nping. This verifies good end-to-end
connectivity.)

Disable pf on pfSense J to avoid fragment reassembly / scrubbing

With pf enabled on H and disabled on J

Into J LAN
01:21:32.108916 IP 172.31.201.100.5060 > 172.31.200.100.5060: UDP, length 2000
01:21:32.108982 IP 172.31.201.100 > 172.31.200.100: ip-proto-17
01:21:33.132073 IP 172.31.201.100.5060 > 172.31.200.100.5060: UDP, length 2000
01:21:33.132135 IP 172.31.201.100 > 172.31.200.100: ip-proto-17
01:21:34.153074 IP 172.31.201.100.5060 > 172.31.200.100.5060: UDP, length 2000
01:21:34.153133 IP 172.31.201.100 > 172.31.200.100: ip-proto-17

Into IPsec on J
01:22:13.844357 (authentic,confidential): SPI 0xc99a1e36: IP 172.31.201.100.5060 > 172.31.200.100.5060: UDP, length 2000
01:22:13.844409 (authentic,confidential): SPI 0xc99a1e36: IP 172.31.201.100 > 172.31.200.100: ip-proto-17
01:22:14.853298 (authentic,confidential): SPI 0xc99a1e36: IP 172.31.201.100.5060 > 172.31.200.100.5060: UDP, length 2000
01:22:14.853390 (authentic,confidential): SPI 0xc99a1e36: IP 172.31.201.100 > 172.31.200.100: ip-proto-17
01:22:15.857681 (authentic,confidential): SPI 0xc99a1e36: IP 172.31.201.100.5060 > 172.31.200.100.5060: UDP, length 2000
01:22:15.857729 (authentic,confidential): SPI 0xc99a1e36: IP 172.31.201.100 > 172.31.200.100: ip-proto-17

Out of IPsec on H
01:23:08.108706 (authentic,confidential): SPI 0xc99a1e36: IP 172.31.201.100.5060 > 172.31.200.100.5060: UDP, length 2000
01:23:08.108729 (authentic,confidential): SPI 0xc99a1e36: IP 172.31.201.100 > 172.31.200.100: ip-proto-17
01:23:09.109471 (authentic,confidential): SPI 0xc99a1e36: IP 172.31.201.100.5060 > 172.31.200.100.5060: UDP, length 2000
01:23:09.109493 (authentic,confidential): SPI 0xc99a1e36: IP 172.31.201.100 > 172.31.200.100: ip-proto-17
01:23:10.115393 (authentic,confidential): SPI 0xc99a1e36: IP 172.31.201.100.5060 > 172.31.200.100.5060: UDP, length 2000
01:23:10.115415 (authentic,confidential): SPI 0xc99a1e36: IP 172.31.201.100 > 172.31.200.100: ip-proto-17

Out H LAN
[No packets captured]

Note that removing the BINAT on IPsec on H changes this behavior. These captures
are the same (Replacing destination with 172.31.202.100 because no more BINAT):

Into J LAN
Into IPsec on J
Out of IPsec on H

But the following is captured on H LAN
01:41:02.519981 IP 172.31.201.100.5060 > 172.31.202.100.5060: UDP, length 2000
01:41:03.524742 IP 172.31.201.100.5060 > 172.31.202.100.5060: UDP, length 2000
01:41:04.528723 IP 172.31.201.100.5060 > 172.31.202.100.5060: UDP, length 2000

Note: Not fragmented according to the interface’s mtu 1500. This is similar to
what has been reported on #7779 for OpenVPN.

Upgraded J to 2.4-RC - Same behavior
Upgraded H to 2.4-RC - Same behavior

Files

pfSense+VPN copy 2.png (45.5 KB) pfSense+VPN copy 2.png Test Network Diagram Chris Linstruth, 08/22/2017 09:16 PM

Related issues

Related to Bug #7779: Traffic crossing a site-to-site OpenVPN tunnel fails to fragment.New08/16/2017

Actions
Actions
Copy link

Also available in: Atom PDF