Skip to Content.
Sympa Menu

perfsonar-user - [perfsonar-user] Perfsonar ports - tracepath blocked

Subject: perfSONAR User Q&A and Other Discussion

List archive

[perfsonar-user] Perfsonar ports - tracepath blocked


Chronological Thread 
  • From: Brian Candler <>
  • To: "" <>
  • Subject: [perfsonar-user] Perfsonar ports - tracepath blocked
  • Date: Mon, 15 Feb 2016 17:19:13 +0000
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=pobox.com; h=to:from:subject :message-id:date:mime-version:content-type :content-transfer-encoding; q=dns; s=sasl; b=hB6NMNETGt8gGRmtWyl fub1aHPBSNxuxXIUIVXu5VsTm0Z+4ZmXe0gv/ktsBjXTgvoqd0hz8ZocCGqdSR+/ SLo7kXrsn+tjlUNz06lwDZ1IK997QE4W8sJ5IipODpgE1ArljO3Sa+E6z7S0ij2S mkquhHj67u30YXsdV6o5MRIM=

The perfsonar ports are documented at:
http://www.perfsonar.net/deploy/security-considerations/

Now, I have a perfsonar node behind a firewall (it's used for internal IPSEC testing), and configured ACLs according to this list. Firewall logs show that periodically there are a range of attempted connections to UDP ports 44445-44457 from other perfsonar nodes, and these are currently being blocked.

The same source port is the same for the duration of a burst of packets to that range. Looking at netstat at the source end, I see that the high port chosen is bound to a "tracepath" process

udp 0 0 0.0.0.0:36334 0.0.0.0:* 6344/tracepath

And looking on a target perfsonar box, that range of ports is not enabled in iptables either.

Now, as far as I can tell from googling, tracepath is a utility for checking the path MTU - although it doesn't turn up a list of what ports it uses. So my questions are:

1. should I enable ports 44444 upwards for tracepath:
- in the firewall in front of the perfsonar box?
- in iptables in the perfsonar box itself?
2. and if so, should this be added to the document linked above?

Or does it really not matter - e.g. tracepath only cares about the intermediate hops and not the final destination?

Thanks,

Brian.




Archive powered by MHonArc 2.6.16.

Top of Page