Fwd: Re: Strange FreeBSD behavior when trying to forward beetween ipsec crypted gif's. May be a problem with ICMP unreach packets at all

[Tom Judge]

On 09/17/2010 03:18 AM, Vladimir Grigorov wrote:
> greets all
>
>
>   
>> If you take a look at icmp_error() in sys/netinet/ip_icmp.c you will see
>> that icmp errors are not sent for packets that have been previously been
>> decrypted by IPSec.  
>>     
> May  be  some misunderstandings happens. I have gif and ipsec. IPSEC  mode is transport, that means, traffic encrypted only between gif's 
> outer  addresses.  As  result,  traffic in gif encrypted by encrypting ipip container. But I can view traffic on gif by tcpdump as on 
> regular interfaces. E.g. gif's inner traffic not processed by ipsec at all
>
>   
Consider you have a packet that looks something like this:

|IP[1]|ESP|IP[2]|IP[3]|<TCP,UDP,Other Payload>|

1) The packet enters ip_input() is validated against a policy and that
its IP[1] header lists the router as the destination.

2) ip_input() passes the frame (mbuf) into ip_ipsec_input() which will
return 0 and allow the frame to continue to be processed.

3) ip_input() then (eventually) calls esp_input() which in turn calls
esp_input_cb()

4) esp_input_cb() does the decryption work and tags the mbuf containing
the frame with M_DECRYPTED at this stage the frame in the mbuf will look
like this:

|IP[2]|IP[3]|<TCP,UDP,Other Payload>|

5) esp_input_cp() passes the processed mbuf to ipsec_common_input_cb()
which will redispatch the mbuf (frame) to in_gif_input() via the netisr
queue.

6) in_gif_input() calls gif_input() to process the frame which will look
like this:

|IP[3]|<TCP,UDP,Other Payload>|

*Note:  the mbuf this frame is stored in is the same mbuf as the
original packet was received in by the NIC so still carries the flag
M_DECRYPTED.

7) gif_input() re dispatches the mbuf via the netisr queue again.

8) Packet causes a call to icmp_error() in either ip_input() or
ip_foarward() and ecmp_error() does not send the message as M_DECRYPTED
is set.


I have missed/glossed over a few steps here I feel, but in general I
think from my 15 minutes reading the code this is how it works (or at
least the important parts of it).


Hope this helps.

Tom

-- 
TJU13-ARIN