PfSense not replying to UDP traceroute on WAN
-
Hi there
I'm trying to configure my pfSense firewall to reply to traceroute requests on the WAN interface and I'm having a little trouble.
When I traceroute to the LAN interface IP, it works great. A packet capture shows the UDP traffic come in on port 3343X and then a TTL expired in transit ICMP message goes out to the IP attempting the traceroute just like it's supposed to.
On the WAN interface, I created a firewall rule allowing UDP ports 33434 to 33534 with the source of any, destination set to WAN address. I also enabled logging on this rule.
I don't have any outbound floating rules that would prevent the ICMP message generated by the firewall from going out.
When I do a traceroute from a random Internet location to my firewall's WAN IP, I see the UDP packets hitting the firewall in a packet capture within the port range I allowed. I know they're hitting the allow rule because I'm seeing the packets logged in the firewall logs. However, the TTL expired in transit message never goes out, like it does on LAN according to my packet capture, and the traceroute times out for the pfSense hop.
I tried this on two different pfSense firewalls. One running 2.3, and another running 2.4. I didn't see any setting like "Don't generate ICMP control messages on the WAN interface" and my forum/kb search has been fruitless.
If I force traceroute to use ICMP, it works great. What am I missing?
-
Probably the "destination set to WAN address" part. The destination is probably not your firewall but something behind it. You could set it to destination of your LAN network.
-
In my traceroute, I'm using the WAN IP address, and the packet capture confirms that the destination IP is the same one assigned to my WAN interface.
-
Try rejecting, not passing. This works for me:
![Screen Shot 2018-03-02 at 4.20.26 PM.png](/public/imported_attachments/1/Screen Shot 2018-03-02 at 4.20.26 PM.png)
![Screen Shot 2018-03-02 at 4.20.26 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2018-03-02 at 4.20.26 PM.png_thumb) -
Yup same rule here..
-
that's a lot of NTP traffic…. :)
-
Yeah have a stratum 1 in the pool..
-
That did the trick! Thanks!
-
One weird thing I'm seeing is with Windows tracert which uses ICMP, pfSense sends a TTL expired reply when the request TTL is < 6, so I get a weird result where my pfSense firewall shows up 5 times. I don't want to reject ICMP packets, and I don't see a way to configure the TTL threshold. Anyone know of a remedy?
-
I would need to see a packet capture of that.
-
Here you go. I've anonymized the pcap so 1.1.1.1 is the host running the traceroute, and 2.2.2.2 is my pfSense firewall. Looks like I was wrong and it stops sending a TTL expired, and starts replying, when the TTL is greater than 4.
Edit: Oops, there's a 1:1 NAT and the replies are probably the routers in between and the host the packets are being NATted to.
Edit: Packet capture on the LAN interface confirms this theory.
-
OK you're kind of all over the place. You state that pfSense responds in the negative with a TTL > 4. What, exactly am I looking for?
What interface was that pcap taken on?
Anonymizing MAC addresses? Really? I can't help you.
-
"One weird thing I'm seeing is with Windows tracert which uses ICMP, pfSense sends a TTL expired reply when the request TTL is < 6"
From where to where?
I trace through pfsense to internet all the time, never seen such a thing..
-
What was the resolution? I am having the same problem as in topic. Tracing PFSense from outside PFSense seems that it is not recognizing traces at all. Ping works fine. It can't be true that PFSense does not work with Traceroute in UDP mode... can it?
Ax.
-
Ah screenshot is missing - prob got lost when they updated the forum... You juts need to set a reject rule on your wan for the udp ports. When get back from lunch can post up a screenshot.
-
Got it... I think. I created Rejected rule for UDP between ports 33434 and 33634. It actually resolves the issue.
-
yup... that is all you need to do.
edit: for the next guy that finds this thread... I will post up screenshot of the rule