From kasahara@elvenbow.cc.kyushu-u.ac.jp  Fri Feb 26 05:54:45 2010
Return-Path: <kasahara@elvenbow.cc.kyushu-u.ac.jp>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id D10551065670
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 26 Feb 2010 05:54:45 +0000 (UTC)
	(envelope-from kasahara@elvenbow.cc.kyushu-u.ac.jp)
Received: from elvenbow.cc.kyushu-u.ac.jp (unknown [IPv6:2001:200:905:1407:21b:21ff:fe52:5260])
	by mx1.freebsd.org (Postfix) with ESMTP id 6D4FC8FC25
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 26 Feb 2010 05:54:44 +0000 (UTC)
Received: from elvenbow.cc.kyushu-u.ac.jp (kasahara@localhost [127.0.0.1])
	by elvenbow.cc.kyushu-u.ac.jp (8.14.4/8.14.4) with ESMTP id o1Q5shSt034781
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 26 Feb 2010 14:54:43 +0900 (JST)
	(envelope-from kasahara@elvenbow.cc.kyushu-u.ac.jp)
Received: (from kasahara@localhost)
	by elvenbow.cc.kyushu-u.ac.jp (8.14.4/8.14.4/Submit) id o1Q5shXa034780;
	Fri, 26 Feb 2010 14:54:43 +0900 (JST)
	(envelope-from kasahara)
Message-Id: <201002260554.o1Q5shXa034780@elvenbow.cc.kyushu-u.ac.jp>
Date: Fri, 26 Feb 2010 14:54:43 +0900 (JST)
From: Yoshiaki Kasahara <kasahara@nc.kyushu-u.ac.jp>
Reply-To: Yoshiaki Kasahara <kasahara@nc.kyushu-u.ac.jp>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: massive ICMP storm on lo0 occurs when using pf(4) 'reply-to'
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         144311
>Category:       kern
>Synopsis:       [pf] [icmp] massive ICMP storm on lo0 occurs when using pf(4) 'reply-to'
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    gnn
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Feb 26 06:00:09 UTC 2010
>Closed-Date:    
>Last-Modified:  Sun May 18 05:01:29 UTC 2014
>Originator:     Yoshiaki Kasahara
>Release:        FreeBSD 8.0-STABLE amd64
>Organization:
Kyushu University
>Environment:
System: FreeBSD elvenbow.cc.kyushu-u.ac.jp 8.0-STABLE FreeBSD 8.0-STABLE #1: Fri Feb 19 16:44:40 JST 2010 root@elf2.nc.kyushu-u.ac.jp:/usr/obj/usr/src/sys/GENERIC amd64


	
>Description:

A massive amount of 'ICMP unreachable - fragmentation needed' observed
on lo0 when pf(4) 'reply-to' is used for policy routing, which
degrades the overall performance of the system severely.

I have a web server with two NIC connected to different outgoing
networks.  Each network has a spoof filter, so I need to reply back to
the I/F where the connection came from.

+-----+
|    em0(IP1.IP1.IP1.IP1) -- ISP1(GW1.GW1.GW1.GW1)
|     |
|    em1(IP2.IP2.IP2.IP2) -- ISP2(GW2.GW2.GW2.GW2)
+-----+

So I use pf(4)'s 'reply-to' rule and noticed the symptom.

The simplified pf.conf which show the symptom is as follows (IP
addresses are masked):

-------------
if_isp1="em0"
isp1_router="GW1.GW1.GW1.GW1"
if_isp2="em1"
isp2_router="GW2.GW2.GW2.GW2"

pass in all
pass in reply-to ( $if_isp1 $isp1_router ) from any to $if_isp1
pass in reply-to ( $if_isp2 $isp2_router ) from any to $if_isp2
pass out all
-------------

Then access the web server on IP1 from a client (SIP.SIP.SIP.SIP) and
retrieve a large file such as a picture. While doing so, tcpdump -n -i
lo0 shows a massive amount of ICMP packets flowing like this:

# tcpdump -n -i lo0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo0, link-type NULL (BSD loopback), capture size 96 bytes
12:53:59.784441 IP 127.0.0.1 > IP1.IP1.IP1.IP1: ICMP SIP.SIP.SIP.SIP unreachable - need to frag (mtu 1500), length 48
12:53:59.784772 IP 127.0.0.1 > IP1.IP1.IP1.IP1: ICMP SIP.SIP.SIP.SIP unreachable - need to frag (mtu 1500), length 48
12:53:59.785001 IP 127.0.0.1 > IP1.IP1.IP1.IP1: ICMP SIP.SIP.SIP.SIP unreachable - need to frag (mtu 1500), length 48
12:53:59.785288 IP 127.0.0.1 > IP1.IP1.IP1.IP1: ICMP SIP.SIP.SIP.SIP unreachable - need to frag (mtu 1500), length 48
12:53:59.785482 IP 127.0.0.1 > IP1.IP1.IP1.IP1: ICMP SIP.SIP.SIP.SIP unreachable - need to frag (mtu 1500), length 48
.....(omit)

The SIP host can retrieve the file, but the throughput is very
poor.

netstat(1) also shows an abnormal number of packet counts (irrelevant
lines removed).

% netstat -ni
Name    Mtu Network       Address              Ipkts Ierrs Idrop    Opkts Oerrs  Coll
em0    1500 <Link#1>      00:1c:c0:fa:c4:6a    79142     0     0    80093     0     0
em0    1500 IP1.IP1.IP1.9 IP1.IP1.IP1.IP1   2090652887     -     -      472     -     -
em1    1500 <Link#2>      00:1b:21:52:52:60   141017     0     0    59392     0     0
em1    1500 IP2.IP2.IP2.0 IP2.IP2.IP2.IP2      83355     -     -    58112     -     -
lo0   16384 <Link#6>                        2090617974     0     0 2090617950     0     0
lo0   16384 127.0.0.0/8   127.0.0.1            35119     -     - 2090610857     -     -

Some hardware combination didn't seem to exhibit the symptom.
Actually I recently replaced the server and suddenly the problem
started to occur.  I examined the old server and noticed that I could
also reproduce the symptom on the old server when I changed the
default route.  Old system runs FreeBSD 8.0R-p1 amd64.

FreeBSD elf2.nc.kyushu-u.ac.jp 8.0-RELEASE-p1 FreeBSD 8.0-RELEASE-p1 #4: Wed Dec 16 15:49:14 JST 2009     root@elvenbow.cc.kyushu-u.ac.jp:/usr/obj/usr/src/sys/GENERIC  amd64

On the old system, msk(4) and vge(4) are used for ISP connections.
Default route to msk(4) is okay, but change it toward vge(4) exhibits
the problem. Exchanging NIC for ISP1 and ISP2 doesn't matter, so it is
more related to hardware (driver?) than network configuration, I
guess.

>How-To-Repeat:

Explained in the Description section.

>Fix:

Unknown.  I don't understand what is the source of these ICMP packets
and why they are generated.
>Release-Note:
>Audit-Trail:

From: Yoshiaki Kasahara <kasahara@nc.kyushu-u.ac.jp>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/144311: massive ICMP storm on lo0 occurs when using pf(4)
 'reply-to'
Date: Fri, 26 Feb 2010 17:33:42 +0900 (JST)

 I changed the rule to use 'route-to' instead of 'reply-to' and the
 ICMP storm stopped.
 
 ----------
 if_isp1="em0"
 isp1_router="GW1.GW1.GW1.GW1"
 if_isp2="em1"
 isp2_router="GW2.GW2.GW2.GW2"
 
 pass in all no state
 pass out all
 pass out route-to ( $if_isp1 $isp1_router ) from $if_isp1
 pass out route-to ( $if_isp2 $isp2_router ) from $if_isp2
 ----------
 
 I'm not sure about the implementation difference of 'reply-to' and
 'route-to'.

From: Yoshiaki Kasahara <kasahara@nc.kyushu-u.ac.jp>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/144311: massive ICMP storm on lo0 occurs when using pf(4)
 'reply-to'
Date: Fri, 26 Feb 2010 18:27:17 +0900 (JST)

 I'm sorry that my previous follow-up was incorrect.
 
 It seems that I need 'no state' for both 'route-to' lines or they are
 ignored.  After that, packets are redirected to correct interfaces,
 and ICMP storm also revived.
Responsible-Changed-From-To: freebsd-bugs->freebsd-pf 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Fri Feb 26 11:23:27 UTC 2010 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=144311 

From: Yoshiaki Kasahara <kasahara@nc.kyushu-u.ac.jp>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/144311: massive ICMP storm on lo0 occurs when using pf(4)
 'reply-to'
Date: Fri, 19 Mar 2010 16:09:18 +0900 (JST)

 I found a workaround for the problem.
 
 The problem won't happen when I removed TSO support from the interface
 which is used for the default route.
 
 About my old server, only msk(4) has TSO support, so the problem only
 happend when I used msk(4) for the default route.  (My original post
 was a bit confused and incorrect, sorry).
 
 I guess there is something wrong with TSO related code (ip_output.c or
 tcp_output.c ?), but it is too much for me to understand them....

From: Max Laier <max@love2party.net>
To: bug-followup@freebsd.org,
 kasahara@nc.kyushu-u.ac.jp
Cc: Pyun YongHyeon <pyunyh@gmail.com>
Subject: Re: kern/144311: [pf] [icmp] massive ICMP storm on lo0 occurs when using pf(4) 'reply-to'
Date: Fri, 19 Mar 2010 14:35:05 +0100

 --Boundary-00=_J23oL/ZH/GBB7xo
 Content-Type: Text/Plain;
   charset="us-ascii"
 Content-Transfer-Encoding: 7bit
 
 Can you please test the attached patch (by Pyun YongHyeon) and let us know if 
 this fixes the situation for you?
 
 Thanks,
   Max Laier
 
 --Boundary-00=_J23oL/ZH/GBB7xo
 Content-Type: text/x-patch;
   charset="ISO-8859-1";
   name="pf.routeto.patch"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
 	filename="pf.routeto.patch"
 
 Index: sys/contrib/pf/net/pf.c
 ===================================================================
 --- sys/contrib/pf/net/pf.c	(revision 203960)
 +++ sys/contrib/pf/net/pf.c	(working copy)
 @@ -6375,6 +6375,7 @@
  	m0->m_pkthdr.csum_flags &= ifp->if_hwassist;
  
  	if (ntohs(ip->ip_len) <= ifp->if_mtu ||
 +	    (m0->m_pkthdr.csum_flags & ifp->if_hwassist & CSUM_TSO) != 0 ||
  	    (ifp->if_hwassist & CSUM_FRAGMENT &&
  		((ip->ip_off & htons(IP_DF)) == 0))) {
  		/*
 @@ -6449,7 +6450,7 @@
  	 * Too large for interface; fragment if possible.
  	 * Must be able to put at least 8 bytes per fragment.
  	 */
 -	if (ip->ip_off & htons(IP_DF)) {
 +	if (ip->ip_off & htons(IP_DF) || (m0->m_pkthdr.csum_flags & CSUM_TSO)) {
  		KMOD_IPSTAT_INC(ips_cantfrag);
  		if (r->rt != PF_DUPTO) {
  #ifdef __FreeBSD__
 
 --Boundary-00=_J23oL/ZH/GBB7xo--

From: Yoshiaki Kasahara <kasahara@nc.kyushu-u.ac.jp>
To: max@love2party.net
Cc: bug-followup@freebsd.org, pyunyh@gmail.com
Subject: Re: kern/144311: [pf] [icmp] massive ICMP storm on lo0 occurs when
 using pf(4) 'reply-to'
Date: Tue, 23 Mar 2010 14:39:35 +0900 (JST)

 I applied the patch on 8-STABLE (fetched today), rebuilt and installed
 the kernel and rebooted, but the problem still occured.
 
 -- 
 Yoshiaki Kasahara
 Research Institute for Information Technology, Kyushu University
 kasahara@nc.kyushu-u.ac.jp

From: Yoshiaki Kasahara <kasahara@nc.kyushu-u.ac.jp>
To: max@love2party.net
Cc: bug-followup@freebsd.org, pyunyh@gmail.com
Subject: Re: kern/144311: [pf] [icmp] massive ICMP storm on lo0 occurs when
 using pf(4) 'reply-to'
Date: Wed, 24 Mar 2010 17:55:18 +0900 (JST)

 I found a blog reporting a similar symptom using
 ipfw(4)+divert(4)+natd(8) on 8.0R and 7.2R (less severe on 7.2R).
 
 http://www.bsddiary.net/d/201002.html#09
 
 It is written in Japanese, but I guess you can still read
 configuration used for the test in the article.
 
 He also reported later that disabling TSO worked as a workaround.
 He used em(4) and fxp(4).
 
 I wonder if it might help locating the problem...

From: "Bjoern A. Zeeb" <bz@FreeBSD.org>
To: bug-followup@FreeBSD.org, kasahara@nc.kyushu-u.ac.jp
Cc:  
Subject: Re: kern/144311: [pf] [icmp] massive ICMP storm on lo0 occurs when
 using pf(4) 'reply-to'
Date: Sat, 21 Aug 2010 12:47:15 +0000 (UTC)

 Hey,
 
 have you re-tried with an updated kernel and this patch again?
 It seems to help other people. Could you give us an update?
 
 /bz
 
 -- 
 Bjoern A. Zeeb                       This signature is about you not me.

From: Yoshiaki Kasahara <kasahara@nc.kyushu-u.ac.jp>
To: bz@FreeBSD.org
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/144311: [pf] [icmp] massive ICMP storm on lo0 occurs when
 using pf(4) 'reply-to'
Date: Mon, 06 Sep 2010 12:33:56 +0900 (JST)

 I'm sorry for my late reply.
 
 I updated my test machine to 8.1-STABLE on Sep. 2nd and applied the
 patch, but the problem persists.
 
 --Y.Kasahara
Responsible-Changed-From-To: freebsd-pf->bz 
Responsible-Changed-By: bz 
Responsible-Changed-When: Thu Sep 9 15:29:52 UTC 2010 
Responsible-Changed-Why:  
Take to commit the patch, which will be half of the fix. 
Ermal has the other half as well that I'll need to review and 
follow-up with. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=144311 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/144311: commit references a PR
Date: Fri, 10 Sep 2010 00:00:26 +0000 (UTC)

 Author: bz
 Date: Fri Sep 10 00:00:06 2010
 New Revision: 212403
 URL: http://svn.freebsd.org/changeset/base/212403
 
 Log:
   When using pf routing options, properly handle IP fragmentation
   for interfaces with TSO enabled, otherwise one would see an extra
   ICMP unreach, frag needed pre matching packet on lo0.
   This syncs pf code to ip_output.c r162084.
   
   PR:		kern/144311
   Submitted by:	yongari via mlaier
   Reviewed by:	eri
   Tested by:	kib
   MFC after:	8 days
 
 Modified:
   head/sys/contrib/pf/net/pf.c
 
 Modified: head/sys/contrib/pf/net/pf.c
 ==============================================================================
 --- head/sys/contrib/pf/net/pf.c	Thu Sep  9 23:45:59 2010	(r212402)
 +++ head/sys/contrib/pf/net/pf.c	Fri Sep 10 00:00:06 2010	(r212403)
 @@ -6375,6 +6375,7 @@ pf_route(struct mbuf **m, struct pf_rule
  	m0->m_pkthdr.csum_flags &= ifp->if_hwassist;
  
  	if (ntohs(ip->ip_len) <= ifp->if_mtu ||
 +	    (m0->m_pkthdr.csum_flags & ifp->if_hwassist & CSUM_TSO) != 0 ||
  	    (ifp->if_hwassist & CSUM_FRAGMENT &&
  		((ip->ip_off & htons(IP_DF)) == 0))) {
  		/*
 @@ -6449,7 +6450,7 @@ pf_route(struct mbuf **m, struct pf_rule
  	 * Too large for interface; fragment if possible.
  	 * Must be able to put at least 8 bytes per fragment.
  	 */
 -	if (ip->ip_off & htons(IP_DF)) {
 +	if (ip->ip_off & htons(IP_DF) || (m0->m_pkthdr.csum_flags & CSUM_TSO)) {
  		KMOD_IPSTAT_INC(ips_cantfrag);
  		if (r->rt != PF_DUPTO) {
  #ifdef __FreeBSD__
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 

From: "Bjoern A. Zeeb" <bz@FreeBSD.org>
To: bug-followup@FreeBSD.org, kasahara@nc.kyushu-u.ac.jp
Cc:  
Subject: Re: kern/144311: [pf] [icmp] massive ICMP storm on lo0 occurs when
 using pf(4) 'reply-to'
Date: Fri, 10 Sep 2010 00:03:42 +0000 (UTC)

 Hey,
 
 as stated when taking the ticket, the suggested patch (which was now
 comitted to HEAD) is only half of the fix.  I'll try to review Ermal's
 patch the next days and follow-up with that for testing.  Just for
 your information, so you don't wonder why this is going in though it
 doesn't help you.
 
 /bz
 
 -- 
 Bjoern A. Zeeb                              Welcome a new stage of life.

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/144311: commit references a PR
Date: Mon, 20 Sep 2010 17:03:17 +0000 (UTC)

 Author: bz
 Date: Mon Sep 20 17:03:10 2010
 New Revision: 212905
 URL: http://svn.freebsd.org/changeset/base/212905
 
 Log:
   MFC r212403:
   
     When using pf routing options, properly handle IP fragmentation
     for interfaces with TSO enabled, otherwise one would see an extra
     ICMP unreach, frag needed pre matching packet on lo0.
     This syncs pf code to ip_output.c r162084.
   
     Submitted by: yongari via mlaier
     Reviewed by:  eri
     Tested by:    kib
   PR:           kern/144311
 
 Modified:
   stable/8/sys/contrib/pf/net/pf.c
 Directory Properties:
   stable/8/sys/   (props changed)
   stable/8/sys/amd64/include/xen/   (props changed)
   stable/8/sys/cddl/contrib/opensolaris/   (props changed)
   stable/8/sys/contrib/dev/acpica/   (props changed)
   stable/8/sys/contrib/pf/   (props changed)
   stable/8/sys/dev/xen/xenpci/   (props changed)
 
 Modified: stable/8/sys/contrib/pf/net/pf.c
 ==============================================================================
 --- stable/8/sys/contrib/pf/net/pf.c	Mon Sep 20 16:43:17 2010	(r212904)
 +++ stable/8/sys/contrib/pf/net/pf.c	Mon Sep 20 17:03:10 2010	(r212905)
 @@ -6375,6 +6375,7 @@ pf_route(struct mbuf **m, struct pf_rule
  	m0->m_pkthdr.csum_flags &= ifp->if_hwassist;
  
  	if (ntohs(ip->ip_len) <= ifp->if_mtu ||
 +	    (m0->m_pkthdr.csum_flags & ifp->if_hwassist & CSUM_TSO) != 0 ||
  	    (ifp->if_hwassist & CSUM_FRAGMENT &&
  		((ip->ip_off & htons(IP_DF)) == 0))) {
  		/*
 @@ -6449,7 +6450,7 @@ pf_route(struct mbuf **m, struct pf_rule
  	 * Too large for interface; fragment if possible.
  	 * Must be able to put at least 8 bytes per fragment.
  	 */
 -	if (ip->ip_off & htons(IP_DF)) {
 +	if (ip->ip_off & htons(IP_DF) || (m0->m_pkthdr.csum_flags & CSUM_TSO)) {
  		KMOD_IPSTAT_INC(ips_cantfrag);
  		if (r->rt != PF_DUPTO) {
  #ifdef __FreeBSD__
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/144311: commit references a PR
Date: Mon, 20 Sep 2010 18:26:42 +0000 (UTC)

 Author: bz
 Date: Mon Sep 20 18:26:37 2010
 New Revision: 212910
 URL: http://svn.freebsd.org/changeset/base/212910
 
 Log:
   MFC r212403:
   
     When using pf routing options, properly handle IP fragmentation
     for interfaces with TSO enabled, otherwise one would see an extra
     ICMP unreach, frag needed pre matching packet on lo0.
     This syncs pf code to ip_output.c r162084.
   
     Submitted by: yongari via mlaier
   
   PR:	kern/144311
 
 Modified:
   stable/7/sys/contrib/pf/net/pf.c
 Directory Properties:
   stable/7/sys/   (props changed)
   stable/7/sys/cddl/contrib/opensolaris/   (props changed)
   stable/7/sys/contrib/dev/acpica/   (props changed)
   stable/7/sys/contrib/pf/   (props changed)
 
 Modified: stable/7/sys/contrib/pf/net/pf.c
 ==============================================================================
 --- stable/7/sys/contrib/pf/net/pf.c	Mon Sep 20 18:20:35 2010	(r212909)
 +++ stable/7/sys/contrib/pf/net/pf.c	Mon Sep 20 18:26:37 2010	(r212910)
 @@ -6376,6 +6376,7 @@ pf_route(struct mbuf **m, struct pf_rule
  	m0->m_pkthdr.csum_flags &= ifp->if_hwassist;
  
  	if (ntohs(ip->ip_len) <= ifp->if_mtu ||
 +	    (m0->m_pkthdr.csum_flags & ifp->if_hwassist & CSUM_TSO) != 0 ||
  	    (ifp->if_hwassist & CSUM_FRAGMENT &&
  		((ip->ip_off & htons(IP_DF)) == 0))) {
  		/*
 @@ -6450,7 +6451,7 @@ pf_route(struct mbuf **m, struct pf_rule
  	 * Too large for interface; fragment if possible.
  	 * Must be able to put at least 8 bytes per fragment.
  	 */
 -	if (ip->ip_off & htons(IP_DF)) {
 +	if (ip->ip_off & htons(IP_DF) || (m0->m_pkthdr.csum_flags & CSUM_TSO)) {
  		ipstat.ips_cantfrag++;
  		if (r->rt != PF_DUPTO) {
  #ifdef __FreeBSD__
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 

From: Mark Cammidge <mark@peralex.com>
To: bug-followup@FreeBSD.org, kasahara@nc.kyushu-u.ac.jp
Cc:  
Subject: Re: kern/144311: [pf] [icmp] massive ICMP storm on lo0 occurs when
 using pf(4) &#39;reply-to&#39;
Date: Thu, 29 Aug 2013 17:01:47 +0200

 Just to add that I'm still seeing this issue. 
 
  9.1-STABLE FreeBSD 9.1-STABLE #0 r252282
 
 Network adapter:
 
 <Intel(R) PRO/1000 Network Connection 7.3.7>
 
 Disabling TSO4, or removing the route-to entry from pf solves the problem.
 
 
 
 Disclaimer: http://www.peralex.com/disclaimer.html
 
 
Responsible-Changed-From-To: bz->gnn 
Responsible-Changed-By: bz 
Responsible-Changed-When: Sun May 18 05:01:19 UTC 2014 
Responsible-Changed-Why:  
I shall not use bugzilla (at least until we will have a CLI). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=144311 
>Unformatted:
