When running traceroute a trace is show.
Because current network configuration may send port X to a different destination as port Y, there is an issue using traceroute.
(besides the obvious blocking of UDP traceroute packets ...)
Problem with tcptraceroute is:
# tcptraceroute 1.1.1.1
Selected device wlp45s0, address 192.168.7.72, port 45737 for outgoing packets
Tracing the path to 1.1.1.1 on TCP port 80 (http), 30 hops max
1 * * * (OpnSense)
2 * * * (ISP)
3 * * *
Where i expected some ip addresses. Regular traceroute shows a nice trace until the end.
With IPv6 it is a little better..., at least the OpnSense & One upstream are shown.
Nothing after that.
The way it works is the same as with UDP traceroute a packet is sent with increasing TTL times.
Except there is never a SYN/ACK... just a SYN.
Obviously resulting in some ICMP that the packet died..., OR accepted on end of the chain with SYN/ACK.
How should a rule to allow for this be setup.
I've never used tcptraceroute that I recall. From the man page, default destination port is 80, and good old Cloudflare has a page on 1.1.1.1 with a nice ad. Per-hop behavior should be largely identical to UDP traceroute, only with destination port 80 (unless otherwise specified) - I'd expect the protocol fixups in pf to handle the responses. As far as an appropriate rule, a pass rule that encompasses "TCP, source port any, destination port 80, source address (client subnet), destination address 1.1.1.1" should do for your example invocation of tcptraceroute. (It can be more permissive, of course, up to "pass any".) So I'd watch the "Firewall: Log Files: Live View" to see what's happening. Oh - filters on your client device (if any) could be an issue as well.
Outgoing port 80 is open to anywhere so that is not the blocking factor.
The client in question has no filters when on the home network. (Linux client).
A curl request instantly returns an answer. It more or less looks like either ICMP is not matched or Only matured (SYN - SYN/ACK - ACK is considered).
# tcptraceroute 1.1.1.1
Selected device wlp45s0, address 192.168.7.72, port 33297 for outgoing packets
Tracing the path to 1.1.1.1 on TCP port 80 (http), 30 hops max
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 one.one.one.one (1.1.1.1) [open] 4.402 ms 4.013 ms 4.058 ms
# curl http://1.1.1.1/
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>cloudflare</center>
</body>
</html>
I'll check what the firewall log tells me.
BTW tcptraceroute is not limited to port 80 any port can be specified....
It has helped me in the past where someone had routing for IMAP/IMAPS differing, causing IMAPS to fail.
(IMAP was forwarded to a dovecot server, the IMAPS ended up on their webserver).
Quote from: Noci on September 17, 2025, 05:54:00 PM[...]
It more or less looks like either ICMP is not matched or Only matured (SYN - SYN/ACK - ACK is considered).[...]
Actually, the TTL expiry may not be handled by default. I always have pass rules for "echo request" and "unreachable"s (after general block rules), as I want to see those. You might need a pass rule for unreachables (in the direction opposite of your request).
I think i found part of the issue......
outside:
51 108.436969 X 1.1.1.1 TCP 44 52439 → 80 [SYN] Seq=0 Win=0 Len=0
52 108.437547 185.93.175.230 X ICMP 60 Time-to-live exceeded (Time to live exceeded in transit)
13 91.725489 192.168.7.72 1.1.1.1 TCP 56 41611 → 80 [SYN] Seq=0 Win=0 Len=0
14 91.725573 192.168.7.1 192.168.7.72 ICMP 82 Time-to-live exceeded (Time to live exceeded in transit)
The ICMP Does enter the system...., it gets NATted or the source is morfed.
The changed source address probably is the issue....
Question what is the cause.