NAT and ICMP

NAT and ICMP

[Don Cohen]

Here's some behavior that seems clearly wrong, though I'm not
sure what is right.  This is from a redhat 8 box, 2.4.18-14,
so it's possible that this could be either specific to redhat
or fixed (or at least altered) in later kernels.

This box is connected to a LAN, and doing NAT for that LAN:

inside 10.0.0.2 --- 10.0.0.1 redhat8 24... --- internet --- server

The inside machine connects to the server in the internet.
In my test case it's doing ssh, running a program that prints
the time every minute.
I now disconnect the inside machine.
The server sends the next time update (to 24..., the address of
the redhat NAT machine, to be forwarded to the inside machine).
The redhat machine can no longer reach the inside machine and
replies with ICMP host unreachable - returning the packet that
it could not deliver, which is addressed to 10.0.0.2 !
This is clearly wrong, since the server has no idea who 10.0.0.2
is.  On the other hand, it also makes no sense to claim that
24... is an unreachable host - that's the one that is actually
answering.  The best I can think of is that it ought to say that
the port is unreachable for the packet it received (pre-NAT, so
its own address and the port as seen at the server).

Re: NAT and ICMP

[Michael Gale]

Hello,

	This makes sense from a routing perspective, if your RH box was a 
router on the web or routing to public networks then it would be 
functioning normally.

How ever is a firewall setup this is a undesirable response ... I would 
suggest blocking ICMP traffic on the external interface. Some people 
like to allow some specific ICMP traffic like Destination Unreachable or 
PATH MTU ... some people simple block all ICMP traffic.

I do not think this is a netfilter problem just a simple configuration 
issue depending on your setup.

Michael.


Don Cohen wrote:
> Here's some behavior that seems clearly wrong, though I'm not
> sure what is right.  This is from a redhat 8 box, 2.4.18-14,
> so it's possible that this could be either specific to redhat
> or fixed (or at least altered) in later kernels.
> 
> This box is connected to a LAN, and doing NAT for that LAN:
> 
> inside 10.0.0.2 --- 10.0.0.1 redhat8 24... --- internet --- server
> 
> The inside machine connects to the server in the internet.
> In my test case it's doing ssh, running a program that prints
> the time every minute.
> I now disconnect the inside machine.
> The server sends the next time update (to 24..., the address of
> the redhat NAT machine, to be forwarded to the inside machine).
> The redhat machine can no longer reach the inside machine and
> replies with ICMP host unreachable - returning the packet that
> it could not deliver, which is addressed to 10.0.0.2 !
> This is clearly wrong, since the server has no idea who 10.0.0.2
> is.  On the other hand, it also makes no sense to claim that
> 24... is an unreachable host - that's the one that is actually
> answering.  The best I can think of is that it ought to say that
> the port is unreachable for the packet it received (pre-NAT, so
> its own address and the port as seen at the server).
> 
> 

-- 
Michael Gale
Lan Administrator
Utilitran Corp.

Hey, let me file that under important .... > /dev/null
...
"Hey did you read my e-mail"
"Let my check"
^From:.* > /dev/null
"Nope, I missed it, send it again"

Re: NAT and ICMP

[Michael Gale]

Sorry ... I was thinking of the system with out NATing ... obviously I 
need a day off.

Michael.

Michael Gale wrote:
> Hello,
> 
>     This makes sense from a routing perspective, if your RH box was a 
> router on the web or routing to public networks then it would be 
> functioning normally.
> 
> How ever is a firewall setup this is a undesirable response ... I would 
> suggest blocking ICMP traffic on the external interface. Some people 
> like to allow some specific ICMP traffic like Destination Unreachable or 
> PATH MTU ... some people simple block all ICMP traffic.
> 
> I do not think this is a netfilter problem just a simple configuration 
> issue depending on your setup.
> 
> Michael.
> 
> 
> Don Cohen wrote:
> 
>> Here's some behavior that seems clearly wrong, though I'm not
>> sure what is right.  This is from a redhat 8 box, 2.4.18-14,
>> so it's possible that this could be either specific to redhat
>> or fixed (or at least altered) in later kernels.
>>
>> This box is connected to a LAN, and doing NAT for that LAN:
>>
>> inside 10.0.0.2 --- 10.0.0.1 redhat8 24... --- internet --- server
>>
>> The inside machine connects to the server in the internet.
>> In my test case it's doing ssh, running a program that prints
>> the time every minute.
>> I now disconnect the inside machine.
>> The server sends the next time update (to 24..., the address of
>> the redhat NAT machine, to be forwarded to the inside machine).
>> The redhat machine can no longer reach the inside machine and
>> replies with ICMP host unreachable - returning the packet that
>> it could not deliver, which is addressed to 10.0.0.2 !
>> This is clearly wrong, since the server has no idea who 10.0.0.2
>> is.  On the other hand, it also makes no sense to claim that
>> 24... is an unreachable host - that's the one that is actually
>> answering.  The best I can think of is that it ought to say that
>> the port is unreachable for the packet it received (pre-NAT, so
>> its own address and the port as seen at the server).
>>
>>
> 

-- 
Michael Gale
Lan Administrator
Utilitran Corp.

Hey, let me file that under important .... > /dev/null
...
"Hey did you read my e-mail"
"Let my check"
^From:.* > /dev/null
"Nope, I missed it, send it again"

Re: NAT and ICMP

[Patrick McHardy]

Don Cohen wrote:

>Here's some behavior that seems clearly wrong, though I'm not
>sure what is right.  This is from a redhat 8 box, 2.4.18-14,
>so it's possible that this could be either specific to redhat
>or fixed (or at least altered) in later kernels.
>
It has been fixed in 2.4.29.

Regards
Patrick

NAT and ICMP

[Chris Hall]

I have a firewall/router using nft.  It connects to the outside world 
with a single globally routeable IP address ('Real-IP').

I want to use the Real-IP both for NAT and for the firewall/router itself.

My understanding is that for tcp and udp:

   * for private source IPs, I can configure SNAT to use one port
     range, say 16384:65535.

   * and I can, elsewhere, configure the firewall/router to use a
     different range, say 0.16383, with no NAT required (inbound
     or outbound).

But for ICMP queries, I cannot find equivalent settings to manage the 
"Query Identifier".

It has occurred to me that the trick might be to SNAT all outbound ICMP 
queries, something like:

   .... ip protocol ICMP ip saddr 203.0.113.1 snat to 203.0.113.1
   .... ip protocol ICMP ip saddr 10.0.0.0/8  snat to 203.0.113.1

where 203.0.113.1 is the Real-IP. I'm guessing NATing the source address 
to itself is OK... yes ?

------------------------------------------------------------

Separately: where should I look to find the degree of conformance to the 
various "NAT Behavioural Requirements": RFCs 4787, 5382, 5508 and 7857 ?

------------------------------------------------------------

Thanks,

Chris

Re: NAT and ICMP

[Sunny73Cr]

Hi,

> ...configure the firewall/router to use a different range

You do not need to allocate a different range, per se; the port selection algorithm of the kernel will only use a port if it is not already in use.

For LAN to WAN forwarded connections; you should SNAT the local port of most requests to the range 49152-65535, and the address to an available or appropriate 'public IP' (appears to be 203.0.113.1). Requirements may be different as defined by the network administrator for your LAN or a MAN/Intranet.

Refer to IANA Service Name and Transport Protocol Port Number Registry for a description of ephemeral/private/dynamic ports; and why you may wish to avoid the 'System' and 'User' port range for local ports. There are exceptions: NTP is static 123<->123; do not blindly NAT everything.

> ICMP "Query Identifier"

May you explain this one in more detail? I'm unfamiliar with an ICMP Query Identifier.

> SNAT all outbound ICMP queries, something like:
>
>  .... ip protocol ICMP ip saddr 203.0.113.1 snat to 203.0.113.1

This SNAT is not neccessary and will only load the router for not much gain. It may be neccesary if you were attempting to alter the port: though, if you wish for the router to use a different port range across the board; you can simply change the "net.ipv4.ip_local_port_range" via `# sysctl -w net.ipv4.ip_local_port_range="low high"` where low and high are the lower and upper bounds of the port range.

To adhere to IANA recommendations:

`sudo sysctl -w net.ipv4.ip_local_port_range="49152 65535"`
or
`su -l root && sysctl -w net.ipv4.ip_local_port_range="49152 65535"`
or
something that adheres to your SELinux policy.

I am unsure of how to make these edits persistent (they revert after a reboot with no further interaction); you may need to recompile the kernel to do so. Looks like `man sysctl` mentions `/etc/sysctl.d/*.conf` files: these may be of use also.

As for:

> where should I look to find the degree of conformance to the various "NAT Behavioural Requirements"...

I am unsure. I am hoping for "Address and Port-Dependent Mapping". I believe the best way to check is to make some connections in a test environment and observe tshark / wireshark logs. If you were looking for a 'NAT Connection State' table; I am unsure. You could browse the likes of VyOS source code (I think it is available!). If you can't use tshark / wireshark, try the TCP and UDP tables in `/net/tcp` and `/net/udp`.

sunny

Re: NAT and ICMP

[Sunny73Cr]

> You could browse the likes of VyOS source code...

I was mistaken regarding VyOS; it looks like it pulls your Debian configuration across to the new system: therefore it isn't of much help in deciding on how to NAT.

If you're interested; you could purchase a subscription, or try their 'contributors get it free' program. The OS they provide might contain some better hints.

sunny