PfSense not showing in traceroute
-
Hi,
Having a problem when performing a traceroute to a Virtual IP address with a nat 1:1. The local machine that's assigned to the 1:1 shows up twice at the end of the traceroute but the hop for the pfSense box isn't shown e.g.:
13 30ms 32ms 31ms my-server.co.uk
14 30ms 32ms 31ms my-server.co.ukPerforming a traceroute from that local machine to my IP address correctly shows the first hop as the pfSense box, performing a traceroute to the public IP of the pfSense box also works as expected.
Any ideas?
-
NAT happens very early on when an incoming packet arrives (i.e. before ordinary firewall rules - which need to use the NATed destination when trying to match…). So by the time the incoming traceroute packet has been allowed into the firewall (pfSense) the destination address has already been changed by the NAT rule from the public-facing IP to the internal IP. Then (on hop 13 in your example) the TTL goes to zero and I guess pfSense responds with the TTL-expired packet, but as if it was from the NATed destination.
Then for TTL=14 the packet gets all the way to the real destination, which also replies with its (same as hop 13) address.
Thus the hop points look the same on 13 and 14. -
That's how things should work in that scenario. It does show, it's the second to last hop. The last hop is the system behind the 1:1 NAT, which gets translated back to the public IP again, which is why it shows twice. First is pfSense itself, second is the system behind the 1:1.
-
cmb is correct, my explanation is a bit round the wrong way - even though each hop is NATed in to the private side of pfSense, on the way back out the replies are "unNATed" back to the public-facing IP. So replies from both hops 13 and 14 are seen as coming from the public-facing IP, which reverse-resolves to the public name.
-
But pfSense is setup to use a WAN IP different to the external IP it's replying with in the traceroute, surely it should be using that IP on hop 13?
-
But pfSense is setup to use a WAN IP different to the external IP it's replying with in the traceroute, surely it should be using that IP on hop 13?
Not where that VIP is assigned as CARP or IP alias, in that case it's a local IP to it and will reply with that. If it were being routed through and no local binding, that's how it would behave.
-
Sorry for pulling up this old thread again.
Just recognized that with 2.3.1_1 it looks like something regarding this behaviour has been changed.
Previously when using 1:1 NAT with additional IPs, the WAN IP was included within the traceroute like this:
…
12. last-hop.our-isp.com 1.2.3.4
13. our-wan-gw.corp.com 2.2.2.2
14. our-web-server.corp.com 2.2.2.3Now with 2.3.1_1 all of a sudden the traces look like this:
...
12. last-hop.our-isp.com 1.2.3.4
13. our-web-server.corp.com 2.2.2.3I reviewed all the tickets assigned to 2.3.1_1 but i could not find any relevant code changes.
Any hints why this behaviour may have changed? Just for interest.
Thanks
-
push.