[c-nsp] Tunnel keepalive in NAT environment problem

[Oliver Boehmer (oboehmer)]

Brett Frankenberger <mailto:rbf+cisco-nsp at panix.com> wrote on Tuesday,
November 18, 2008 19:49:

> On Tue, Nov 18, 2008 at 02:03:08PM +0100, Oliver Boehmer (oboehmer)
> wrote: 
>> 
>> Well, it looks like the linux NAT/firewall is not NAT'ing the
>> keepalive GRE packets correctly, otherwise they would not arrive with
>> the 172.16.1.1 src address on router2. Not sure what's happening
>> there, but I would focus my attention on the NAT/firewall box.. I
>> guess NAT for the "other" GRE packets work just fine? Maybe related
>> to the different protocol type (0x0) or the lack of payload in the
>> GRE keepalive packet? 
>> 
>> 	oli
> 
> The issue is that a GRE keepalive packet has the originating tunnel
> endpoint IP address as the destination address of the encapsulated
> packet.  That is, consider the following:
>     interface tunnel1
>      tunnel source 10.0.0.1
>      tunnel destination 20.0.0.2
>      tunnel keepalive
>  (Not sure I've got the syntax right, but you get the idea.)
> 
> A keepalive packet generated by the router will look like the
>    following: IP header:  Source=10.0.0.1 Destination=20.0.0.2
>     Protocol=GRE GRE Header:  Protocol=IP
>      Encapsulated Packet:
>       IP Header:  Source=? (Not Inportant)  Dest=10.0.0.1  Proto=GRE
>        GRE Header: 0x0000
> 
> The idea is that the router at the far end will received the packet,
> remove the outer header, and transmit the encapsulated packet.  (The
> router at the far end will, then, not do any special processing all
> for 
> a keepalive packet originating from the near end.)  THe issue with
> keepalive is that the 10.0.0.1 appears in the encapsulated packet, so
> if that's being NAT'd somewhere, for keepalive to work, the NAT needs
> to translate the address on the encapsulated packet also.
> 
> AFAIK, essentially no NATs will do that.

agreed, I stand corrected.. was not aware of the encapsulated payload..
tx!

	oli