From nobody@FreeBSD.org  Sat Feb 23 07:53:22 2002
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id E5ED237B404
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 23 Feb 2002 07:53:21 -0800 (PST)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.6/8.11.6) id g1NFrLR31225;
	Sat, 23 Feb 2002 07:53:21 -0800 (PST)
	(envelope-from nobody)
Message-Id: <200202231553.g1NFrLR31225@freefall.freebsd.org>
Date: Sat, 23 Feb 2002 07:53:21 -0800 (PST)
From: Julian Noble <julian@precisium.com.au>
To: freebsd-gnats-submit@FreeBSD.org
Subject: unwanted stealth behaviour  (inbound icmp via ppp tun0 ttl not decremented ?)
X-Send-Pr-Version: www-1.0

>Number:         35245
>Category:       misc
>Synopsis:       unwanted stealth behaviour  (inbound icmp via ppp tun0 ttl not decremented ?)
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    brian
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Feb 23 08:00:03 PST 2002
>Closed-Date:    Tue Jun 29 10:46:18 GMT 2004
>Last-Modified:  Tue Jun 29 10:46:18 GMT 2004
>Originator:     Julian Noble
>Release:        
>Organization:
Precisium
>Environment:
FreeBSD sydr3.Junctionworld.net 4.4-STABLE FreeBSD 4.4-STABLE #0: Wed Jan 23 07:42:09 GMT 2002     root@sydr3.Junctionworld.net:/usr/src/sys/compile/P7  i386

>Description:
machine exhibits unwanted 'stealth' behaviour for inbound traceroutes to machines behind it even when no firewall enabled and IPSTEALTH kernel option not present.
Machine does however appear as a hop for outbound traceroutes from machines behind it.

      
>How-To-Repeat:
traceroute to a machine behind a FreeBSD box with a ppp wan link and with the following kernel options.  Hop is missing from trace even when you disable the firewall with sysctl or ipfw flush. 
No nat. All valid IP addresses. Connection is ADSL.
If this is the nature of tun interfaces or something - I couldn't find any documentation on it. Only documentation I could find anywhere was about enabling stealth behaviour - not disabling - and I certainly didn't expect it to be on by default. 
It may be obvious - but I'm also new to unix-like operating systems so make extra consideration of the fact that I might not know what I'm doing.
 
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=250
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPDIVERT
options NETGRAPH
options NETGRAPH_SOCKET
options NETGRAPH_ECHO
options NETGRAPH_TEE
options NETGRAPH_PPPOE
options NETGRAPH_ETHER

>Fix:

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->brian 
Responsible-Changed-By: dwmalone 
Responsible-Changed-When: Sat Feb 23 14:26:21 PST 2002 
Responsible-Changed-Why:  
Looks like brian would be able to handle this. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=35245 

From: <julian@precisium.com.au>
To: <freebsd-gnats-submit@FreeBSD.org>, <julian@precisium.com.au>
Cc:  
Subject: Re: misc/35245: unwanted stealth behaviour  (inbound icmp via ppp tun0 ttl not decremented ?)
Date: Sun, 24 Feb 2002 13:44:45 -0000

 I implied in my initial report that the ttl was not being decremented for
 inbound icmp only - but the behaviour is the same when tracerouting from
 either a unix or a windows based host so it looks like it affects udp as
 well - perhaps the ttl isn't being decremented for anything inbound.
 
 

From: <julian@precisium.com.au>
To: <freebsd-gnats-submit@FreeBSD.org>, <julian@precisium.com.au>
Cc:  
Subject: Re: misc/35245: unwanted stealth behaviour  (inbound icmp via ppp tun0 ttl not decremented ?)
Date: Mon, 25 Feb 2002 15:16:32 -0000

 I can get the correct behaviour for unix style traceroutes by blocking UDP
 to high ports using ipfw - and then handling those packets within a user
 level routing program. (Click Modular Router)
 Within 'Click', I decrement the TTL twice before forwarding and emit a TTL
 Exceeded ICMP if the TTL is now zero, and then I see my FreeBSD router as a
 hop in traceroutes as I'd expect.
 
 This suggests to me that maybe PPP/PPPoE is not doing the right thing with
 the TTL or that the problem is possibly not even in FreeBSD at all and is
 occuring in the upstream router.
 
 I'm not sure how to narrow the problem down further.
 
 
State-Changed-From-To: open->feedback 
State-Changed-By: brian 
State-Changed-When: Wed Feb 27 04:00:11 PST 2002 
State-Changed-Why:  
Email sent to originator saying that this problem is unlikely to be 
on the FreeBS end. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=35245 
State-Changed-From-To: feedback->closed 
State-Changed-By: brian 
State-Changed-When: Tue Jun 29 10:36:23 GMT 2004 
State-Changed-Why:  
There are no TTL issues here AFAICT. 

I have four machines: 

flame (NetBSD): 
ifconfig le0 inet 172.16.3.13 netmask 0xffffff00 alias 
route add -net 172.16.2.0 -netmask 0xffffff00 172.16.3.1 
gw (FreeBSD-stable): 
ppp pppoe (see config below) 
ifconfig fxp0 inet 172.16.3.1 netmask 0xffffff00 alias 
route add 172.16.2.0/24 172.16.1.5 
dev (FreeBSD-current): 
Running pppoed (see config below) 
ifconfig dc0 inet 172.16.2.5 netmask 0xffffff00 alias 
route add 172.16.3.0/24 172.16.1.12 
rivet: 
ifconfig vr0 inet 172.16.2.6 netmask 0xffffff00 alias 
route add 172.16.3.0/24 172.16.2.5 

Then from flame: 
traceroute to 172.16.2.6 (172.16.2.6), 30 hops max, 40 byte packets 
1  172.16.3.1  2.350 ms  1.368 ms  1.284 ms 
2  172.16.1.5  3.623 ms  3.327 ms  3.334 ms 
3  172.16.2.6  3.598 ms  3.571 ms  3.678 ms 

and from rivet: 
traceroute to 172.16.3.13 (172.16.3.13), 64 hops max, 40 byte packets 
1  172.16.2.5  0.353 ms  6.124 ms  0.232 ms 
2  172.16.1.12  2.785 ms  2.534 ms  2.570 ms 
3  172.16.3.13  3.153 ms  2.760 ms  2.814 ms 

No missing hops, so the TTLs look fine... 

In gw:/etc/ppp/ppp.conf: 
pppoe: 
set device PPPoE:fxp0:pppoe-in 
set authname gw 
set authkey blah 
set mru 1492 
set mtu 1492 
set speed sync 
enable lqr 
set cd 5 
set dial 
set redial 0 0 

In dev:/etc/rc.conf: 
pppoed_enable=YES 
pppoed_provider=pppoe-in 
pppoed_interface=dc0 

In dev:/etc/ppp/ppp.conf: 
pppoe-in: 
allow mode direct 
set mru 1492    
set mtu 1492 
set speed sync 
enable lqr    
set cd 5 
set ifaddr 172.16.1.5 172.16.1.12/24 
set timeout 0 

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