FreeBSD 6.3 gre and traceroute

[Robert Noland]

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.

robert.

> What code in the FreeBSD kernel is responsible for generating the response ICMP 
> dest unreachable message?
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081113/b6b36261/attachment.pgp