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 _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
