https://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162015-05-21T16:43:28ZpfSense bugtrackerpfSense - Bug #4723: Can't forward UDP fragmented packets with scrubbing enabled.https://redmine.pfsense.org/issues/4723?journal_id=185022015-05-21T16:43:28ZDominic Blaisdblais@interplex.ca
<ul></ul><p>Just thought that random-id will apply to all packets incoming another interface (LAN..etc..) prior to exit WAN. So, if there's no need to randomize PFSense's own packets "scrub in on" could be used...</p> pfSense - Bug #4723: Can't forward UDP fragmented packets with scrubbing enabled.https://redmine.pfsense.org/issues/4723?journal_id=190852015-07-08T10:17:59ZJD -jan@agetty.de
<ul></ul><p>I can somewhat confirm this with the following scenario:</p>
<ul>
<li><strong>Central Office</strong>
<ul>
<li>OVPN Server (TCP, AES-256-CBC, LZO, PSK, IF:ovpns2)</li>
<li>SNMP management console in connected LAN/DMZ</li>
<li>Version 2.2.2</li>
</ul>
</li>
<li><strong>Office Branch</strong>
<ul>
<li>OVPN Client</li>
<li>SNMP agent (listening on 161/udp)</li>
<li>Version 2.1.5</li>
</ul></li>
</ul>
<p>Connecting to the WebUI, ssh or any TCP related services on the branch firewall from a LAN connected to the central office works just fine.</p>
<p>However, when the SNMP management console (or any host within a connected LAN) tries to connect to the SNMP agent via 161/udp packets seem to get scrubbed when returning from the branch firewall through the ovpn interface (ovpns2):</p>
<pre>
[2.2.2-RELEASE][root@central]/root: tcpdump -nettti pflog0 host X.X.X.X
tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 65535 bytes
00:00:28.658768 rule 9..16777216/0(match): block in on ovpns2: IP0 bad-len 0
00:00:01.003378 rule 9..16777216/0(match): block in on ovpns2: IP14 bad-len 0
00:00:00.999763 rule 9..16777216/0(match): block in on ovpns2: IP9 bad-len 0
</pre>
<p>The ovpns2 interfaces is assigned its own logical OPT interface. Now, when creating a firewall rule on that interface explicitly allowing return traffic to pass from the SNMP agent ip address to the SNMP management console everything works as expected.</p> pfSense - Bug #4723: Can't forward UDP fragmented packets with scrubbing enabled.https://redmine.pfsense.org/issues/4723?journal_id=190932015-07-09T06:43:12ZPhillip Davisphil@jankaritech.com
<ul><li><strong>File</strong> <a href="/attachments/1293">VM-network.png</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1293/VM-network.png">VM-network.png</a> added</li></ul><p>Maybe my situation is also related to this in some way. We do not get big ping (or I guess other big packets) from branch office LAN to Main office LAN across an OpenVPN site-to-site link. I posted recently in the forum:<br /><a class="external" href="https://forum.pfsense.org/index.php?topic=96043.0">https://forum.pfsense.org/index.php?topic=96043.0</a><br />That post was a bit of a wall of text, so understandably no response :)</p>
<p>I have recreated in a (mostly) VM situation, as per the attached diagram. The pfSense-A VM 10.49.35.37/22 is sitting on our real LAN. Behind that is pfSense-B real VM and behind that my VirtualBox host-only network with my laptop 192.168.56.1 to pfSense-B LAN 192.168.56.2 pfSense-A VM has hybrid NAT and I have told it to NAT 192.168.56.0/24 out on WAN so that I can ping from my laptop 192.168.56.1 through all this to devices on 10.49.32.0/22 and it gets NATed out and the real things like 10.49.32.9 can answer easily.</p>
<p>With pings up to 1472 bytes I get good packets back and forth:<br />From Client-B 192.168.56.1<br />ping 10.49.32.9 -l 1472 -t</p>
<p>pfSense-B OpenVPN packet capture:<br />17:08:08.257718 IP 192.168.56.1 > 10.49.32.9: ICMP echo request, id 1, seq 15517, length 1480<br />17:08:08.260448 IP 10.49.32.9 > 192.168.56.1: ICMP echo reply, id 1, seq 15517, length 1480</p>
<p>pfSense-A OpenVPN packet capture:<br />17:08:54.247187 IP 192.168.56.1 > 10.49.32.9: ICMP echo request, id 1, seq 15562, length 1480<br />17:08:54.248338 IP 10.49.32.9 > 192.168.56.1: ICMP echo reply, id 1, seq 15562, length 1480</p>
<p>pfSense-A front-side packet capture:<br />17:06:33.947095 IP 10.49.35.37 > 10.49.32.9: ICMP echo request, id 50743, seq 15422, length 1480<br />17:06:33.948408 IP 10.49.32.9 > 10.49.35.37: ICMP echo reply, id 50743, seq 15422, length 1480</p>
<p>Increase the ping to 1473 bytes and it has to be fragmented. This is the result:<br />ping 10.49.32.1 -l 1473 -t</p>
<p>pfSense-B OpenVPN packet capture:<br />17:10:49.271944 IP 192.168.56.1 > 10.49.32.9: ICMP echo request, id 1, seq 15677, length 1480<br />17:10:49.271966 IP 192.168.56.1 > 10.49.32.9: ip-proto-1<br />17:10:49.274387 IP 172.16.0.1 > 192.168.56.1: ICMP host 10.49.32.9 unreachable, length 36</p>
<p>pfSense-A OpenVPN packet capture:<br />17:09:45.039423 IP 192.168.56.1 > 10.49.32.9: ICMP echo request, id 1, seq 15610, length 1480<br />17:09:45.039486 IP 172.16.0.1 > 192.168.56.1: ICMP host 10.49.32.9 unreachable, length 36<br />17:09:45.039517 IP 192.168.56.1 > 10.49.32.9: ip-proto-1</p>
<p>pfSense-A front-side packet capture:<br />17:10:23.128146 IP 10.49.35.37 > 10.49.32.9: ICMP echo request, id 50743, seq 15650, length 1481</p>
<p>2 problems here:<br />a) pfSense-A OpenVPN sends an "unreachable" response back to 192.168.56.1 - seemingly before it even receives the 2nd fragment to reassemble.</p>
<p>b) pfSense-A front side at least claims to send a 1481 byte payload packet out to 10.49.32.9 - why would it even send anything onwards if it has sent an "unreachable" response? And then an over-size packet has been sent out, I guess because "scrub on WAN fragment reassemble" is in effect.</p>
<p>Maybe if this test environment example is sorted out, then other things will also start working?</p>
<p>I will try some variations with "scrub in on WAN" ...</p> pfSense - Bug #4723: Can't forward UDP fragmented packets with scrubbing enabled.https://redmine.pfsense.org/issues/4723?journal_id=206422015-09-15T02:14:41ZChris Buechlercbuechler@gmail.com
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/20642/diff?detail_id=14761">diff</a>)</li><li><strong>Category</strong> changed from <i>Unknown</i> to <i>Operating System</i></li><li><strong>Status</strong> changed from <i>New</i> to <i>Confirmed</i></li><li><strong>Assignee</strong> set to <i>Chris Buechler</i></li><li><strong>Target version</strong> set to <i>2.2.5</i></li><li><strong>Affected Version</strong> changed from <i>2.2.2</i> to <i>2.2.x</i></li></ul><p>I hit this issue with a customer last week. Worked fine after disabling scrub. I have pcaps from their traffic (UBZ-69510) and should be able to replicate.</p> pfSense - Bug #4723: Can't forward UDP fragmented packets with scrubbing enabled.https://redmine.pfsense.org/issues/4723?journal_id=217832015-10-20T19:19:11ZChris Buechlercbuechler@gmail.com
<ul><li><strong>Target version</strong> changed from <i>2.2.5</i> to <i>2.3</i></li></ul> pfSense - Bug #4723: Can't forward UDP fragmented packets with scrubbing enabled.https://redmine.pfsense.org/issues/4723?journal_id=244472016-01-26T04:43:34ZJim Thompsonjim@netgate.com
<ul><li><strong>Assignee</strong> changed from <i>Chris Buechler</i> to <i>Luiz Souza</i></li><li><strong>Priority</strong> changed from <i>High</i> to <i>Normal</i></li></ul> pfSense - Bug #4723: Can't forward UDP fragmented packets with scrubbing enabled.https://redmine.pfsense.org/issues/4723?journal_id=255852016-03-05T16:19:16ZLuiz Souzaluiz@netgate.com
<ul><li><strong>Target version</strong> changed from <i>2.3</i> to <i>2.3.1</i></li></ul> pfSense - Bug #4723: Can't forward UDP fragmented packets with scrubbing enabled.https://redmine.pfsense.org/issues/4723?journal_id=263862016-04-15T22:08:18ZChris Buechlercbuechler@gmail.com
<ul><li><strong>Target version</strong> changed from <i>2.3.1</i> to <i>2.3.2</i></li></ul> pfSense - Bug #4723: Can't forward UDP fragmented packets with scrubbing enabled.https://redmine.pfsense.org/issues/4723?journal_id=282082016-07-12T13:16:35ZChris Buechlercbuechler@gmail.com
<ul><li><strong>Target version</strong> changed from <i>2.3.2</i> to <i>2.4.0</i></li></ul> pfSense - Bug #4723: Can't forward UDP fragmented packets with scrubbing enabled.https://redmine.pfsense.org/issues/4723?journal_id=284082016-07-22T02:47:03ZRemko Lodder
<ul></ul><p>Chris Buechler wrote:</p>
<blockquote>
<p>I hit this issue with a customer last week. Worked fine after disabling scrub. I have pcaps from their traffic (UBZ-69510) and should be able to replicate.</p>
</blockquote>
<p>I see similiar issues with:</p>
<p>GIF interface over IPSEC (mtu1280), reading the pflog0 output it constantly states 'bad-len', and any packet going out on the internet (mostly TCP btw) return a : ICMP Unreachable notice when the Syn/Ack comes back.</p> pfSense - Bug #4723: Can't forward UDP fragmented packets with scrubbing enabled.https://redmine.pfsense.org/issues/4723?journal_id=291502016-10-31T12:19:13ZDominic Blaisdblais@interplex.ca
<ul></ul><p>Remko Lodder wrote:</p>
<blockquote>
<p>Chris Buechler wrote:</p>
<blockquote>
<p>I hit this issue with a customer last week. Worked fine after disabling scrub. I have pcaps from their traffic (UBZ-69510) and should be able to replicate.</p>
</blockquote>
<p>I see similiar issues with:</p>
<p>GIF interface over IPSEC (mtu1280), reading the pflog0 output it constantly states 'bad-len', and any packet going out on the internet (mostly TCP btw) return a : ICMP Unreachable notice when the Syn/Ack comes back.</p>
</blockquote>
<p>I think the fix is quite simple, just replace the two lines in /etc/inc/filter.inc that starts with "scrub on" by "scrub in on". Just add the "in" and everything will be fine for every case... I haven't found a reason to keep it scrubing out..</p> pfSense - Bug #4723: Can't forward UDP fragmented packets with scrubbing enabled.https://redmine.pfsense.org/issues/4723?journal_id=291592016-11-01T10:19:31ZLuiz Souzaluiz@netgate.com
<ul></ul><p>Remko Lodder wrote:</p>
<blockquote>
<p>Chris Buechler wrote:</p>
<blockquote>
<p>I hit this issue with a customer last week. Worked fine after disabling scrub. I have pcaps from their traffic (UBZ-69510) and should be able to replicate.</p>
</blockquote>
<p>I see similiar issues with:</p>
<p>GIF interface over IPSEC (mtu1280), reading the pflog0 output it constantly states 'bad-len', and any packet going out on the internet (mostly TCP btw) return a : ICMP Unreachable notice when the Syn/Ack comes back.</p>
</blockquote>
<p>I fixed the issue with pflog0 output (corrupted output in tcpdump - 'bad-len').</p>
<p>That was a different issue, but it is now fixed in 2.4.</p> pfSense - Bug #4723: Can't forward UDP fragmented packets with scrubbing enabled.https://redmine.pfsense.org/issues/4723?journal_id=291602016-11-01T10:22:41ZLuiz Souzaluiz@netgate.com
<ul><li><strong>Status</strong> changed from <i>Confirmed</i> to <i>Feedback</i></li></ul><p>I tested the forwarding of fragmented ICMP and UDP packets and they seem to be working as expected on 2.4.</p>
<p>Could someone else who is affected by this issue confirm that ?</p>
<p>Thanks!</p>
<p>PS: 2.4 is almost reaching beta state, so beware...</p> pfSense - Bug #4723: Can't forward UDP fragmented packets with scrubbing enabled.https://redmine.pfsense.org/issues/4723?journal_id=322692017-03-17T11:46:36ZRichard Gaterichard.gate@communig8.com
<ul></ul><p>Hi, I've hit this problem with UDP packets for RADIUS authentication when using a pfSense IPSec tunnel from an AP doing 802.1X EAP/TLS.<br />I found that applying the changes to /etc/inc/filter.inc, as described by Dominic Blais (many thanks for that by the way), fixed the problem.<br />I just wondered if there was an official pfSense patch available for this.<br />Thanks to all.</p> pfSense - Bug #4723: Can't forward UDP fragmented packets with scrubbing enabled.https://redmine.pfsense.org/issues/4723?journal_id=322702017-03-17T13:08:09ZLuiz Souzaluiz@netgate.com
<ul></ul><p>Richard Gate wrote:</p>
<blockquote>
<p>Hi, I've hit this problem with UDP packets for RADIUS authentication when using a pfSense IPSec tunnel from an AP doing 802.1X EAP/TLS.<br />I found that applying the changes to /etc/inc/filter.inc, as described by Dominic Blais (many thanks for that by the way), fixed the problem.<br />I just wondered if there was an official pfSense patch available for this.<br />Thanks to all.</p>
</blockquote>
<p>Richard, which pfSense version are you running ?</p> pfSense - Bug #4723: Can't forward UDP fragmented packets with scrubbing enabled.https://redmine.pfsense.org/issues/4723?journal_id=322862017-03-20T03:30:19ZRichard Gaterichard.gate@communig8.com
<ul></ul><p>Luiz Otavio O Souza wrote:</p>
<blockquote>
<p>Richard, which pfSense version are you running ?</p>
</blockquote>
<p>Latest 2.3.3_1</p> pfSense - Bug #4723: Can't forward UDP fragmented packets with scrubbing enabled.https://redmine.pfsense.org/issues/4723?journal_id=326372017-04-30T01:41:24Zryon m
<ul></ul><p>I'm having this issue with 2.4:</p>
<p>- v2.4.0.b.20170429.0121 running on both firewalls<br />- local pf is virtualized, official virtual appliance upgraded to 2.4<br />- remote pf is, Netgate SG-8860</p>
<p>OpenVPN tunnel settings (on both sides):<br />tun-mtu 1500;<br />fragment 1400;<br />mssfix;</p>
<p>From a local windows system (10.3.70.40) to remote windows system (10.11.2.15):</p>
<p>TEST #1</p>
<p>ping -l 1500 10.11.2.15</p>
<p>Pinging 10.11.2.15 with 1500 bytes of data:<br />Request timed out.<br />Request timed out.<br />Request timed out.<br />Request timed out.</p>
<p>Ping statistics for 10.11.2.15:<br /> Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),</p>
<p>TEST <a class="issue tracker-1 status-3 priority-4 priority-default closed parent" title="Bug: Gateway not added when switching from DHCP to static (Resolved)" href="https://redmine.pfsense.org/issues/2">#2</a></p>
<p>ping 10.11.2.15</p>
<p>Pinging 10.11.2.15 with 32 bytes of data:<br />Reply from 10.11.2.15: bytes=32 time=10ms TTL=126<br />Reply from 10.11.2.15: bytes=32 time=8ms TTL=126<br />Reply from 10.11.2.15: bytes=32 time=10ms TTL=126<br />Reply from 10.11.2.15: bytes=32 time=10ms TTL=126</p>
<p>Ping statistics for 10.11.2.15:<br /> Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),<br />Approximate round trip times in milli-seconds:<br /> Minimum = 8ms, Maximum = 10ms, Average = 9ms</p>
<p>PCAP (local pf):</p>
<p>23:29:41.289185 AF IPv4 (2), length 1504: (tos 0x0, ttl 127, id 6070, offset 0, flags [+], proto ICMP (1), length 1500)<br /> 10.3.70.40 > 10.11.2.15: ICMP echo request, id 1, seq 117, length 1480<br />23:29:41.289211 AF IPv4 (2), length 52: (tos 0x0, ttl 127, id 6070, offset 1480, flags [none], proto ICMP (1), length 48)<br /> 10.3.70.40 > 10.11.2.15: ip-proto-1<br />23:29:46.051239 AF IPv4 (2), length 1504: (tos 0x0, ttl 127, id 6087, offset 0, flags [+], proto ICMP (1), length 1500)<br /> 10.3.70.40 > 10.11.2.15: ICMP echo request, id 1, seq 118, length 1480<br />23:29:46.051253 AF IPv4 (2), length 52: (tos 0x0, ttl 127, id 6087, offset 1480, flags [none], proto ICMP (1), length 48)<br /> 10.3.70.40 > 10.11.2.15: ip-proto-1<br />23:29:51.051842 AF IPv4 (2), length 1504: (tos 0x0, ttl 127, id 6090, offset 0, flags [+], proto ICMP (1), length 1500)<br /> 10.3.70.40 > 10.11.2.15: ICMP echo request, id 1, seq 119, length 1480<br />23:29:51.051892 AF IPv4 (2), length 52: (tos 0x0, ttl 127, id 6090, offset 1480, flags [none], proto ICMP (1), length 48)<br /> 10.3.70.40 > 10.11.2.15: ip-proto-1<br />23:29:56.051842 AF IPv4 (2), length 1504: (tos 0x0, ttl 127, id 6119, offset 0, flags [+], proto ICMP (1), length 1500)<br /> 10.3.70.40 > 10.11.2.15: ICMP echo request, id 1, seq 120, length 1480<br />23:29:56.051863 AF IPv4 (2), length 52: (tos 0x0, ttl 127, id 6119, offset 1480, flags [none], proto ICMP (1), length 48)<br /> 10.3.70.40 > 10.11.2.15: ip-proto-1<br />23:30:07.883817 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 6135, offset 0, flags [none], proto ICMP (1), length 60)<br /> 10.3.70.40 > 10.11.2.15: ICMP echo request, id 1, seq 121, length 40<br />23:30:07.893752 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 14684, offset 0, flags [none], proto ICMP (1), length 60)<br /> 10.11.2.15 > 10.3.70.40: ICMP echo reply, id 1, seq 121, length 40<br />23:30:08.886027 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 6139, offset 0, flags [none], proto ICMP (1), length 60)<br /> 10.3.70.40 > 10.11.2.15: ICMP echo request, id 1, seq 122, length 40<br />23:30:08.893659 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 14685, offset 0, flags [none], proto ICMP (1), length 60)<br /> 10.11.2.15 > 10.3.70.40: ICMP echo reply, id 1, seq 122, length 40<br />23:30:09.889025 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 6142, offset 0, flags [none], proto ICMP (1), length 60)<br /> 10.3.70.40 > 10.11.2.15: ICMP echo request, id 1, seq 123, length 40<br />23:30:09.898638 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 14686, offset 0, flags [none], proto ICMP (1), length 60)<br /> 10.11.2.15 > 10.3.70.40: ICMP echo reply, id 1, seq 123, length 40<br />23:30:10.892094 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 6146, offset 0, flags [none], proto ICMP (1), length 60)<br /> 10.3.70.40 > 10.11.2.15: ICMP echo request, id 1, seq 124, length 40<br />23:30:10.901171 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 14687, offset 0, flags [none], proto ICMP (1), length 60)<br /> 10.11.2.15 > 10.3.70.40: ICMP echo reply, id 1, seq 124, length 40</p>
<p>PCAP (remote pf)</p>
<p>23:29:41.290461 AF IPv4 (2), length 1504: (tos 0x0, ttl 127, id 6070, offset 0, flags [+], proto ICMP (1), length 1500)<br /> 10.3.70.40 > 10.11.2.15: ICMP echo request, id 1, seq 117, length 1480<br />23:29:41.290560 AF IPv4 (2), length 52: (tos 0x0, ttl 127, id 6070, offset 1480, flags [none], proto ICMP (1), length 48)<br /> 10.3.70.40 > 10.11.2.15: ip-proto-1<br />23:29:46.051719 AF IPv4 (2), length 1504: (tos 0x0, ttl 127, id 6087, offset 0, flags [+], proto ICMP (1), length 1500)<br /> 10.3.70.40 > 10.11.2.15: ICMP echo request, id 1, seq 118, length 1480<br />23:29:46.051820 AF IPv4 (2), length 52: (tos 0x0, ttl 127, id 6087, offset 1480, flags [none], proto ICMP (1), length 48)<br /> 10.3.70.40 > 10.11.2.15: ip-proto-1<br />23:29:51.053010 AF IPv4 (2), length 1504: (tos 0x0, ttl 127, id 6090, offset 0, flags [+], proto ICMP (1), length 1500)<br /> 10.3.70.40 > 10.11.2.15: ICMP echo request, id 1, seq 119, length 1480<br />23:29:51.053098 AF IPv4 (2), length 52: (tos 0x0, ttl 127, id 6090, offset 1480, flags [none], proto ICMP (1), length 48)<br /> 10.3.70.40 > 10.11.2.15: ip-proto-1<br />23:29:56.053048 AF IPv4 (2), length 1504: (tos 0x0, ttl 127, id 6119, offset 0, flags [+], proto ICMP (1), length 1500)<br /> 10.3.70.40 > 10.11.2.15: ICMP echo request, id 1, seq 120, length 1480<br />23:29:56.053142 AF IPv4 (2), length 52: (tos 0x0, ttl 127, id 6119, offset 1480, flags [none], proto ICMP (1), length 48)<br /> 10.3.70.40 > 10.11.2.15: ip-proto-1<br />23:30:07.884171 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 6135, offset 0, flags [none], proto ICMP (1), length 60)<br /> 10.3.70.40 > 10.11.2.15: ICMP echo request, id 1, seq 121, length 40<br />23:30:07.885574 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 14684, offset 0, flags [none], proto ICMP (1), length 60)<br /> 10.11.2.15 > 10.3.70.40: ICMP echo reply, id 1, seq 121, length 40<br />23:30:08.886693 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 6139, offset 0, flags [none], proto ICMP (1), length 60)<br /> 10.3.70.40 > 10.11.2.15: ICMP echo request, id 1, seq 122, length 40<br />23:30:08.887459 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 14685, offset 0, flags [none], proto ICMP (1), length 60)<br /> 10.11.2.15 > 10.3.70.40: ICMP echo reply, id 1, seq 122, length 40<br />23:30:09.889196 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 6142, offset 0, flags [none], proto ICMP (1), length 60)<br /> 10.3.70.40 > 10.11.2.15: ICMP echo request, id 1, seq 123, length 40<br />23:30:09.892332 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 14686, offset 0, flags [none], proto ICMP (1), length 60)<br /> 10.11.2.15 > 10.3.70.40: ICMP echo reply, id 1, seq 123, length 40<br />23:30:10.893031 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 6146, offset 0, flags [none], proto ICMP (1), length 60)<br /> 10.3.70.40 > 10.11.2.15: ICMP echo request, id 1, seq 124, length 40<br />23:30:10.894837 AF IPv4 (2), length 64: (tos 0x0, ttl 127, id 14687, offset 0, flags [none], proto ICMP (1), length 60)<br /> 10.11.2.15 > 10.3.70.40: ICMP echo reply, id 1, seq 124, length 40</p>
<p>This problem is ultimately impacting my SIP phone system which sends jumbo UDP packets. I've tried numerous OpenVPN settings, and turning off pf scrubbing (via GUI which breaks my system) or via the hacks above (didn't help).</p> pfSense - Bug #4723: Can't forward UDP fragmented packets with scrubbing enabled.https://redmine.pfsense.org/issues/4723?journal_id=327362017-05-11T20:57:53Zryon m
<ul></ul><p>Conducted another test:</p>
<p>(From my workstation 10.3.70.40)<br />ping 10.11.2.15<br />ping -l 1500 10.11.2.15</p>
<p>(From my virtualized pfSense)</p>
<p>root: tcpdump -i ovpnc1 -nettti pflog0 -vv host 10.3.70.40</p>
<p>tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 262144 bytes</p>
<pre><code>00:00:00.000000 rule 362/0(match): pass in on vmx1: (tos 0x0, ttl 128, id 19745, offset 0, flags [none], proto ICMP (1), length 60)<br /> 10.3.70.40 > 10.11.2.15: ICMP echo request, id 1, seq 13, length 40</code></pre>
<pre><code>00:00:14.649977 rule 362/0(match): pass in on vmx1: (tos 0x0, ttl 128, id 19756, offset 0, flags [none], proto ICMP (1), length 1528, bad cksum 6bb0 (->8b94)!)<br /> 10.3.70.40 > 10.11.2.15: ICMP echo request, id 1, seq 17, length 1508</code></pre>
<p>2 packets captured<br />96 packets received by filter<br />0 packets dropped by kernel</p>
<p>I'm not sure why bad cksum is being generated. I've tried enabling "Disable hardware checksum offload" in System -> Advanced -> Networking, rebooted the firewall, I get the same result.</p> pfSense - Bug #4723: Can't forward UDP fragmented packets with scrubbing enabled.https://redmine.pfsense.org/issues/4723?journal_id=339822017-09-21T11:20:28Zryon m
<ul></ul><p>I am no longer able to troubleshoot this issue, I switched over to IPSec to resolve my SIP/UPD issue. I was working with Netgate Professional Support on this issue and was able to get it working at one point, but not due to any technical changes, we ended up rebooting several of my firewalls and it just stated working. So, it seems there may still be some intermittent or timing issue, possibly even something with my ISP's.</p>
<p>As far as I'm concerned this issue was resolved.</p>
<p>Maybe the creator of the ticket has an update.</p> pfSense - Bug #4723: Can't forward UDP fragmented packets with scrubbing enabled.https://redmine.pfsense.org/issues/4723?journal_id=341022017-09-29T09:57:33ZConstantine Kormashev
<ul><li><strong>File</strong> <a href="/attachments/2169">diagram.png</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/2169/diagram.png">diagram.png</a> added</li></ul><p>I made the lab in order to reproduce the issue. But could not reproduce one.<br />I tried to use 2KB frames, and the frames were correctly fragmented on all the way. I added small tcpdump output for each of nodes it made possible to see what happened on path between nodes.</p>
<p><img src="https://redmine.pfsense.org/attachments/download/2169/diagram.png" alt="" /></p>
<p>Moreover, I experimented with OpenVPN MTU it is possible to escape fragmentation between OpenVPN nodes, just setup proper MTU size with <code>tun-mtu</code> option, but in that case IP MTU between OpenVPN nodes has to be big enough because OpenVPN encapsulation increases packet size on 32B.</p> pfSense - Bug #4723: Can't forward UDP fragmented packets with scrubbing enabled.https://redmine.pfsense.org/issues/4723?journal_id=341062017-09-29T10:12:00ZRenato Botelhorenato@netgate.com
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Resolved</i></li></ul><p>Thanks!</p>