From nobody@FreeBSD.org  Tue Aug  3 15:35:32 2004
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 99D9616A4CE
	for <freebsd-gnats-submit@FreeBSD.org>; Tue,  3 Aug 2004 15:35:32 +0000 (GMT)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 8E39143D5C
	for <freebsd-gnats-submit@FreeBSD.org>; Tue,  3 Aug 2004 15:35:32 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.12.11/8.12.11) with ESMTP id i73FZV2O007056
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 3 Aug 2004 15:35:31 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.12.11/8.12.11/Submit) id i73FZVEq007055;
	Tue, 3 Aug 2004 15:35:31 GMT
	(envelope-from nobody)
Message-Id: <200408031535.i73FZVEq007055@www.freebsd.org>
Date: Tue, 3 Aug 2004 15:35:31 GMT
From: Lawrence Farr <l.farr@epcdirect.co.uk>
To: freebsd-gnats-submit@FreeBSD.org
Subject: PF Nat with a PPP connection uses wrong addresses
X-Send-Pr-Version: www-2.3

>Number:         69954
>Category:       kern
>Synopsis:       PF Nat with a PPP connection uses wrong addresses
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    mlaier
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Aug 03 15:40:19 GMT 2004
>Closed-Date:    Mon Nov 08 12:53:29 GMT 2004
>Last-Modified:  Mon Nov 08 12:53:29 GMT 2004
>Originator:     Lawrence Farr
>Release:        -CURRENT
>Organization:
EPC Direct
>Environment:
FreeBSD mollie.epcdirect.co.uk 5.2-CURRENT FreeBSD 5.2-CURRENT #0: Fri Jul 23 01:48:06 BST 2004     root@buildhost.int.epcdirect.co.uk:/usr/obj/usr/src/sys/ROUTER  i386
>Description:
      When using PF's NAT with a PPP dialup, the wrong outgoing address is used by NAT in a round robin form. 
PF rule
nat on $ext_if from $internal_net to any -> ($ext_if)

(Where $ext_if=tun0)


PPP config line:
set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.255 0.0.0.0

Becomes
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
        inet 10.0.0.1 --> 10.0.0.2 netmask 0xffffffff

And when connected:
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
        inet 213.122.204.66 --> 213.120.208.171 netmask 0xffffffff

A tcpdump of a succesful connection shows:
21:40:53.176154 IP 213.122.204.66.61726 > 195.10.242.32.110: . ack 82 win 17296
21:40:53.176325 IP 213.122.204.66.61726 > 195.10.242.32.110: F 7:7(0) ack 82 win 17296

But the next connection shows:
21:40:58.187545 IP 10.0.0.1.62059 > 195.10.242.32.110: S 2862758557:2862758557(0) win 16384 <mss 1460,nop,nop,sackOK>
21:41:01.174007 IP 10.0.0.1.62059 > 195.10.242.32.110: S 2862758557:2862758557(0) win 16384 <mss 1460,nop,nop,sackOK>

Note the source address has become the original address for the
PPP connection.
>How-To-Repeat:
      Connect with the ppp config line as shown above and the pf rule and try sequential connections through the NAT router.
>Fix:
      Set NAT to use a specific address rather than tun0
nat on $ext_if from $internal_net to any -> 213.122.204.66
and the problem stops. This is a problem if you get a dynamic IP address.
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->mlaier 
Responsible-Changed-By: mlaier 
Responsible-Changed-When: Tue Aug 3 17:31:41 GMT 2004 
Responsible-Changed-Why:  
I asked for it, I'll take it. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=69954 
State-Changed-From-To: open->feedback 
State-Changed-By: mlaier 
State-Changed-When: Fri Aug 6 09:47:00 GMT 2004 
State-Changed-Why:  
See followup, please use "($ext_if:0)" in order to avoid the use of aliases. 

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

From: Max Laier <max@love2party.net>
To: freebsd-gnats-submit@FreeBSD.org, l.farr@epcdirect.co.uk
Cc:  
Subject: Re: misc/69954: PF Nat with a PPP connection uses wrong addresses
Date: Fri, 6 Aug 2004 11:43:38 +0200

 Can you turn your rule into:
 	nat on $ext_if from $internal_net to any -> ($ext_if:0)
 			       (that's "colon zero" --------^)
 
 i.e. add the NO_ALIAS modifier to it (and any other rule that uses dynamic 
 syntax on $ext_if) and tell me if it helped? I'd expect so, was a bit 
 confused by the symptoms, but this is a really easy fix.
 
 It might turn out, however, that ppp decided to make the new (=correct) 
 address the alias in which case we have to fix ppp. Looking forward to your 
 feedback. Thanks.
 
 -- 
 /"\  Best regards,			| mlaier@freebsd.org
 \ /  Max Laier				| ICQ #67774661
  X   http://pf4freebsd.love2party.net/	| mlaier@EFnet
 / \  ASCII Ribbon Campaign		| Against HTML Mail and News

From: "Lawrence Farr" <l.farr@epcdirect.co.uk>
To: "'Max Laier'" <max@love2party.net>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: RE: misc/69954: PF Nat with a PPP connection uses wrong addresses
Date: Fri, 6 Aug 2004 12:14:51 +0100

 Hi Max,
 
 That stops the address from changing, but it always uses 10.0.0.1
 (The ppp.conf IP)instead of the real IP given by my provider.
 Changing it to :1 or :0 gave the same result.
 
 Lawrence Farr
 EPC Direct Limited  
 
 > -----Original Message-----
 > From: Max Laier [mailto:max@love2party.net] 
 > Sent: 06 August 2004 10:44
 > To: freebsd-gnats-submit@FreeBSD.org; l.farr@epcdirect.co.uk
 > Subject: Re: misc/69954: PF Nat with a PPP connection uses 
 > wrong addresses
 > 
 > Can you turn your rule into:
 > 	nat on $ext_if from $internal_net to any -> ($ext_if:0)
 > 			       (that's "colon zero" --------^)
 > 
 > i.e. add the NO_ALIAS modifier to it (and any other rule that 
 > uses dynamic 
 > syntax on $ext_if) and tell me if it helped? I'd expect so, was a bit 
 > confused by the symptoms, but this is a really easy fix.
 > 
 > It might turn out, however, that ppp decided to make the new 
 > (=correct) 
 > address the alias in which case we have to fix ppp. Looking 
 > forward to your 
 > feedback. Thanks.
 > 
 > -- 
 > /"\  Best regards,			| mlaier@freebsd.org
 > \ /  Max Laier				| ICQ #67774661
 >  X   http://pf4freebsd.love2party.net/	| mlaier@EFnet
 > / \  ASCII Ribbon Campaign		| Against HTML Mail and News
 > 
 

From: Max Laier <max@love2party.net>
To: freebsd-gnats-submit@FreeBSD.org, l.farr@epcdirect.co.uk
Cc:  
Subject: Re: misc/69954: PF Nat with a PPP connection uses wrong addresses
Date: Sat, 7 Aug 2004 11:04:33 +0200

 --Boundary-03=_isJFB4xRaaniDzq
 Content-Type: multipart/mixed;
   boundary="Boundary-01=_hsJFBbtfdCgSRyP"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline
 
 --Boundary-01=_hsJFBbtfdCgSRyP
 Content-Type: text/plain;
   charset="us-ascii"
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: inline
 
 Off band analyzation has revealed the following: When ppp gets a new addres=
 s=20
 via IPCP and has "set ifaddr" in ppp.conf it does not remove (SIOCDIFADDR)=
 =20
 the address used for negotiation, but only removes the route. Hence the=20
 superfluous address stays in the tun0 interfaces address list and is used b=
 y=20
 pf.
 
 The patch addresses this shortcoming. Not sure yet if it is a good idea for=
 =20
 all scenarios, though.
 
 =2D-
 Regards, Max
 
 --Boundary-01=_hsJFBbtfdCgSRyP
 Content-Type: text/x-diff;
   charset="us-ascii";
   name="check_RTF_UP.diff"
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: attachment;
 	filename="check_RTF_UP.diff"
 
 Index: pf_if.c
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/pf_if.c,v
 retrieving revision 1.3
 diff -u -r1.3 pf_if.c
 =2D-- pf_if.c	23 Jul 2004 03:37:05 -0000	1.3
 +++ pf_if.c	7 Aug 2004 09:00:42 -0000
 @@ -53,6 +53,7 @@
 =20
  #include <net/if.h>
  #include <net/if_types.h>
 +#include <net/route.h>
 =20
  #include <netinet/in.h>
  #include <netinet/in_var.h>
 @@ -636,6 +637,8 @@
  		af =3D ia->ifa_addr->sa_family;
  		if (af !=3D AF_INET && af !=3D AF_INET6)
  			continue;
 +		if (!(ia->ifa_flags & IFA_ROUTE))
 +			continue;
  		if ((flags & PFI_AFLAG_BROADCAST) && af =3D=3D AF_INET6)
  			continue;
  		if ((flags & PFI_AFLAG_BROADCAST) &&
 
 --Boundary-01=_hsJFBbtfdCgSRyP--
 
 --Boundary-03=_isJFB4xRaaniDzq
 Content-Type: application/pgp-signature
 Content-Description: signature
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.5 (FreeBSD)
 
 iD8DBQBBFJsiXyyEoT62BG0RAoDCAJ4yllsbmudSJDte2TKkmtqr5+QMigCfYGMy
 U08p5A/ey4/vXwh2t+Wr0pQ=
 =ra+3
 -----END PGP SIGNATURE-----
 
 --Boundary-03=_isJFB4xRaaniDzq--
State-Changed-From-To: feedback->analyzed 
State-Changed-By: mlaier 
State-Changed-When: Sat Aug 7 09:17:33 GMT 2004 
State-Changed-Why:  
Waiting for feedback from OpenBSD to close this. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=69954 
State-Changed-From-To: analyzed->closed 
State-Changed-By: mlaier 
State-Changed-When: Thu Aug 12 13:55:44 GMT 2004 
State-Changed-Why:  
Fix commited. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=69954 
State-Changed-From-To: closed->analyzed 
State-Changed-By: mlaier 
State-Changed-When: Mon Aug 16 19:56:42 GMT 2004 
State-Changed-Why:  
Patch had to be backed out after problems w/ IPv6, an alterative solution must 
be found. OpenBSD-bugs thread: 
http://marc.theaimsgroup.com/?l=openbsd-bugs&m=109253315810258&w=2 

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

From: Max Laier <max@love2party.net>
To: freebsd-gnats-submit@FreeBSD.org, l.farr@epcdirect.co.uk
Cc: yongari@freebsd.org, hennig@openbsd.org
Subject: Re: kern/69954: PF Nat with a PPP connection uses wrong addresses
Date: Sat, 11 Sep 2004 15:00:14 +0200

 --Boundary-00=_gbvQBSUDDOyfDcD
 Content-Type: text/plain;
   charset="us-ascii"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline
 
 More cautious fix attached or to be found at:
  http://people.freebsd.org/~mlaier/ppp_fix_take2.diff
 
 This should fix the ppp problem without breaking (any) legitimate cases. As 
 the ppp setup you describe is very common and fixing ppp is (unfortunately) 
 not possible without a major undertaking, I belive it is safe to put this in 
 to fix ppp this way. I know it's a hack, though.
 
 Note that you have to specify the NO_ALIAS modifier i.e. add ":0" (colon zero) 
 to your interface e.g.:
  nat on $ext_if from $internal_net to any -> ($ext_if:0)
 
 Please give it a whirl and let me know that it still works!
 
 Thanks.
 
 -- 
  Max
 
 --Boundary-00=_gbvQBSUDDOyfDcD
 Content-Type: text/x-diff;
   charset="us-ascii";
   name="ppp_fix_take2.diff"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
 	filename="ppp_fix_take2.diff"
 
 Index: pf_if.c
 ===================================================================
 RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/pf_if.c,v
 retrieving revision 1.5
 diff -u -r1.5 pf_if.c
 --- pf_if.c	16 Aug 2004 17:58:12 -0000	1.5
 +++ pf_if.c	11 Sep 2004 12:39:26 -0000
 @@ -638,8 +638,14 @@
  		af = ia->ifa_addr->sa_family;
  		if (af != AF_INET && af != AF_INET6)
  			continue;
 -#ifdef notyet
 -		if (!(ia->ifa_flags & IFA_ROUTE))
 +#ifdef __FreeBSD__
 +		/*
 +		 * XXX: For (ifname:0) and IPv4, jump over addresses without
 +		 *	a proper route to work around a problem with ppp not
 +		 *	fully removing the address used during IPCP.
 +		 */
 +		if (!(ia->ifa_flags & IFA_ROUTE) &&
 +		    (flags & PFI_AFLAG_NOALIAS) && (af == AF_INET))
  			continue;
  #endif
  		if ((flags & PFI_AFLAG_BROADCAST) && af == AF_INET6)
 
 --Boundary-00=_gbvQBSUDDOyfDcD--
State-Changed-From-To: analyzed->feedback 
State-Changed-By: mlaier 
State-Changed-When: Sat Sep 11 13:13:15 GMT 2004 
State-Changed-Why:  
Please test the reworked patch. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=69954 
State-Changed-From-To: feedback->patched 
State-Changed-By: mlaier 
State-Changed-When: Tue Sep 14 15:22:32 GMT 2004 
State-Changed-Why:  
An even more careful patch has been committed. Please check out CURRENT to 
see if it still works for you and report back as soon as possible, thanks. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=69954 
State-Changed-From-To: patched->closed 
State-Changed-By: mlaier 
State-Changed-When: Mon Nov 8 12:52:48 GMT 2004 
State-Changed-Why:  
Finally MFCed ... could have done this much earlier :-( Thanks for the report. 

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