FreeBSD 6.3 gre and traceroute

[Stephen Clark]

Stephen Clark wrote:
> Robert Noland wrote:
>> On Thu, 2008-11-13 at 07:48 -0500, Stephen Clark wrote:
>>> Julian Elischer wrote:
>>>> Stephen Clark wrote:
>>>>> Julian Elischer wrote:
>>>>>> you will need to define the setup and question better.
>>>> thanks.. cleaning it up a bit more...
>>>>
>>>> 10.0.129.1 FreeBSD workstation
>>>>  ^
>>>>  |
>>>>  | ethernet
>>>>  |
>>>>  v
>>>> 10.0.128.1 Freebsd FW "A"
>>>>  ^
>>>>  |
>>>>  | gre / ipsec
>>>>  |
>>>>  v
>>>> 192.168.3.1 FreeBSD FW "B"
>>>>  ^
>>>>  |
>>>>  | ethernet
>>>>  |
>>>>  v
>>>> 192.168.3.86 linux workstation
>>>>
>>>>> $ sudo traceroute 192.168.3.86
>>>>> traceroute to 192.168.3.86 (192.168.3.86), 64 hops max, 40 byte 
>>>>> packets
>>>>>  1  HQFirewallRS.com (10.0.128.1)  0.575 ms  0.423 ms  0.173 ms
>>>>>  2  * * *
>>>>>  3  192.168.3.86 (192.168.3.86)  47.972 ms  45.174 ms  49.968 ms
>>>>>
>>>>> No response from the FreeBSD "B" box.
>>>>>
>>>>> When I do a tcpdump on "B" of the gre interface I see UDP packets
>>>>> with a TTL of 1 but no ICMP response packets being sent back.
>>>>> If I do the traceroute from the linux workstation 192.168.3.86 I get
>>>>> similar results - I don't see a response from the FreeBSD "A" box.
>>>> could you try using just GRE encasulation?
>>>> (i.e. turn off IPSEC for now)
>>>>
>>>> I think that is much more likely to be where the problem is..
>>>>
>>>>
>>> I'll have to set this up to test it.
>>
>> The ttl exceeded is triggered from one of two places.  Either
>> netinet/ip_fastfwd.c if fast_forwarding is enabled or in
>> netinet/ip_input.c.  Look for the code relating to IPTTLDEC.  This isn't
>> your problem though...  If ttl were not being decremented, the packet
>> would just be forwarded on to the next hop (IP_STEALTH), which would
>> just make the firewalls invisible.  The fact that you are seeing * * *
>> indicates that you are not receiving the ttl exceeded message for the
>> packet sent with that particular ttl.  I still think that the issue you
>> are seeing is that one way or another the generated ICMP response isn't
>> making it back onto the tunnel.  Either via security policy, firewall or
>> routing.
> Your right, when I do a tcpdump on the gre interface I see the udp 
> packet come
> in with a ttl=1 but I don't see a response icmp packet. I have tested 
> this with
> all the firewalls disabled to make sure the icmp packet was not being 
> blocked.
> I just ran another test and did tcpdump on all the other interfaces to 
> make sure
> the icmp's were not being misrouted, it seems they are not being 
> generated for some reason. Also just using gre's without the underlying 
> ipsec tunnels seems to
> work properly.
>>
>> robert.
>>
>>> What code in the FreeBSD kernel is responsible for generating the 
>>> response ICMP dest unreachable message?
>>>
> 
> 
Another data point I had been using option FILTER_GIF I tried a kernel
without that option and it behaved the same.

Steve

-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)