Bug #3666: PMTUD is broken for NATed traffic - pfSense - pfSense bugtracker

Actions

Copy link

Bug #3666

closed

PMTUD is broken for NATed traffic

Added by Chris Buechler over 10 years ago. Updated about 10 years ago.

Status:

Resolved

Priority:

High

Assignee:

Ermal Luçi

Category:

Operating System

Target version:

2.2

Start date:

05/17/2014

Due date:

% Done:

Estimated time:

Plus Target Version:

Release Notes:

Affected Version:

2.2

Affected Architecture:

Description

Where you have an interface on a system with a lower MTU than other interfaces, send traffic larger than the MTU of the egress interface, and have pf enabled, you end up with a PMTUD black hole.

For example, simple LAN and WAN setup:
- set LAN to 1500 MTU and WAN to 1000
- send something from a host on LAN destined to something on WAN that's bigger than WAN's MTU with DF set, such as with hping:
hping3 -y -d 1400 -2 -p 12345 $dest_IP

where 12345 is the port and $dest_IP is an IP or hostname to send the traffic.

With pf enabled, the packet just disappears, the client gets nothing back. Disable pf, and you get back the appropriate "frag needed, DF set" ICMP error.

The above description and symptoms are specific to 2.2/10-STABLE, as of the most recent snapshot available at the time of this writing.

Files

Download all files

broken-rules.debug (6.43 KB) broken-rules.debug		Chris Buechler, 06/11/2014 05:59 AM
broken-pfctl-vvsr.txt (19.2 KB) broken-pfctl-vvsr.txt		Chris Buechler, 06/11/2014 05:59 AM
broken-pfctl-vvsn.txt (2.09 KB) broken-pfctl-vvsn.txt		Chris Buechler, 06/11/2014 05:59 AM

Actions

Copy link

Updated by Ermal Luçi over 10 years ago

Status changed from New to Feedback

Patch put in to try to handle this case.

For record this is happening due to NAT being applied on packets and the generated ICMP is targeted to the pfSense machine itself.

Actions

Copy link

Updated by Chris Buechler over 10 years ago

Subject changed from enabling pf breaks PMTUD to PMTUD is broken for NATed traffic
Status changed from Feedback to New

no change. I did confirm it's specific to NATed traffic and updated subject accordingly. Send any packet > egress interface's MTU with pf enabled where it's NATing the traffic, and you get no reply (and it doesn't leave any other interface on the box either). Turn off NAT, or disable pf, and you get the appropriate dest unreachable, frag needed reply.

Actions

Copy link

Updated by Chris Buechler over 10 years ago

Additional data point. This seemingly isn't an issue in stock FreeBSD 10-STABLE. One I had handy:

FreeBSD m6600-vbox-10stable 10.0-STABLE FreeBSD 10.0-STABLE #0 r265018: Sun Apr 27 19:01:41 UTC 2014     root@grind.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

Same scenario with NAT, that system works fine. Seems a regression related to changes we make.

Actions

Copy link

Updated by Ermal Luçi over 10 years ago

You used the same ruleset on stock FreeBSD as pfSense?

Actions

Copy link

Updated by Chris Buechler over 10 years ago

not identical, no. Had the same basic components - scrub all, pass all, nat on. I can throw the completely identical ruleset on there if that'd help. Can't reach that system at this instant to try it.

Actions

Copy link

Updated by Chris Buechler over 10 years ago

File broken-rules.debug broken-rules.debug added
File broken-pfctl-vvsr.txt broken-pfctl-vvsr.txt added
File broken-pfctl-vvsn.txt broken-pfctl-vvsn.txt added

I think you're on to something there. This:

scrub all 

nat on em0 from 192.168.0.0/16 to any -> (em0)

pass in all 
pass out all

seems to work fine.

The attached, a pretty stock allow all ruleset for what we generate, doesn't work. I haven't tried to narrow it down any further, suggestions on likely culprits?

Actions

Copy link