Support Center > Search Results > SecureKnowledge Details
ICMP Error packets are not translated according to NAT rulebase
Symptoms
  • ICMP Error packets (redirect, fragmentation needed, etc) are not translated according to the NAT rule base.

  • ICMP Error packets are partially translated (only the Destination address is changed correctly) when going through the FireWall.

  • While running traceroute from the Security Gateway itself, traceroute output shows hops as expected.

    While running traceroute from the network behind Security Gateway, traceroute hops are replaced with the Security Gateway's IP address.

    Example:

    C:\> tracert 8.8.8.8
    Tracing route to google-public-dns-a.google.com [8.8.8.8]
    over a maximum of 30 hops:
    1 <1 ms <1 ms 1 ms 172.16.200.242
    2 1 ms 1 ms <1 ms 192.168.200.242
    3 1 ms 1 ms 1 ms 192.168.200.242
    4 2 ms 2 ms 15 ms 192.168.200.242
    5 2 ms 3 ms 2 ms 192.168.200.242
    6 3 ms 2 ms 2 ms 192.168.200.242
    7 3 ms 2 ms 2 ms 192.168.200.242
    8 2 ms 2 ms 2 ms 192.168.200.242
    9 3 ms 3 ms 3 ms 192.168.200.242
    10 3 ms 2 ms 3 ms 192.168.200.242
Cause

When it comes to the handling of ICMP error packets, in version R65 and below, the NAT rule base was inherited from the internal packet.

This means that the same NAT decisions would have been taken for the internal packet and the ICMP IP header, and there was no way to configure explicit rules for the ICMP Error IP header itself.

Starting in version R70, by default, it is possible to configure explicit NAT rules for ICMP Error packets. However, for routing decisions, an ICMP Error packet will go over the NAT rule base in the Outbound Chain and only after the Destination address has been translated according to the internal packet NAT rule base.


Solution
Note: To view this solution you need to Sign In .