Packet rewrite
-
Listing this under general forum as I’m not sure any of the other forums are more applicable
Using pfsense as an edge router; eBGP on my multiple WAN/upstream links and iBGP to other network routers.
On some of my WAN links they are tunnels, GRE or Wireguard. When doing traceroutes from external networks to downstream routers or other hosts on my network, I am getting “leakage” of the inner-tunnel IP addresses showing up as they pass through the pfsense box; example below.
The pfsense box isn’t doing NAT on these interfaces, just routing. That said… I need a way to rewrite the ICMP packets to replace or rewrite the inner-tunnel IP with another IP (be it a virtual IP, another interface’s IP, etc) so that traceroutes don't reflect the inner-tunnel IP in any way.
I have experience doing this in BIRD via the “krt_prefsrc” rewrite variable, but FRR/FreeBSD doesn’t use that so thinking I may be able to do something with NAT??
Alternatively, there is the system tunable “net.inet.icmp.reply_from_interface” - is it advisable to alter that?
Thoughts?
Running 22.01 on a SG-8860.
Thank you.
-
Solved using a combination of two tunables:
-
net.inet.icmp.reply_from_interface=0
-
net.inet.icmp.reply_src=<<iface that you want the IP to reflect in ICMP traffic, e.g. igb0 or em2>>
-
-
Interesting. What was the reason for not wanting the internal tunnel IPs to show in a traceroute?
Doing this makes route diagnosis more difficult if there is a ever a problem.
Steve
-
A couple thoughts:
-
don’t want the inner-tunnel IP showing party due to looking tacky, but also due to security concerns (third parties don’t need to know about the tunnel, IP schemes, etc). Some of my other sites have other routers in play further downstream with non-routeable addresses which even further paints a picture that doesn’t need filled in.
-
I would argue that having a routeable IP and in-addr PTR makes things more easier to troubleshoot, because you know which box/router the traffic is actually flowing through. The argument could be said in the screenshot from this thread that a network admin really has no idea what path the traffic took between hop 7 and 9. And at the end of the day, whenever you do a traceroute between any points on the public Internet, the vast majority of those hosts have multiple interfaces and the IPs you see could very well be an IP of another interface on that router and not the actual interface your traffic ingress/egressed on… so where as-is you have no info to go on in troubleshooting, and corrected you at least have something to go off of…. I’ll take the latter if it’s me.
-
-
Mmm, I could see that. If it works better for you then why not.
