Problems with gif tunnels

[Greg 'groggy' Lehey]

On Tuesday,  7 June 2005 at 11:48:48 +0200, Marc Olzheim wrote:
> On Tue, Jun 07, 2005 at 07:07:17PM +0930, Greg 'groggy' Lehey wrote:
>> I posted this message to the -questions list an hour or so ago.
>> Possibly it's of interest to people on this list.  Certainly the
>> problem is non-obvious, so even (as I suspect) if it's my fault, it
>> would be interesting to document the problem.
>
> The interface on the default route is rl0 instead of gif0...
> Could you try with -interface gif0 ?


On Tuesday,  7 June 2005 at 12:09:58 +0200, Jeremie Le Hen wrote:
> Hi Greg,
>
>>>   Destination        Gateway            Flags    Refs      Use  Netif Expire
>>>   default            150.101.14.9       UGS         0        7    rl0
>>>   150.101.14.8/30    link#2             UC          0        0    rl0
>>>   150.101.14.9       00:90:1a:40:09:98  UHLW        2        2    rl0    903
>>>   192.109.197        link#1             UC          0        0    xl0
>>>   192.109.197.135    00:10:4b:66:1e:e9  UHLW        0     6757    xl0   1056
>>>   192.109.197.137    00:50:da:cf:07:35  UHLW        0    99336    xl0   1188
>>>   192.109.197.255    ff:ff:ff:ff:ff:ff  UHLWb       0    34521    xl0
>>>   203.16.215.227     150.101.14.9       UGHS        1        4    rl0
>
> I guess you need a route to something like 192.83.231.0/24 through gif0.
> Try
>>>>
>     route add -host 192.83.231.16 -interface gif0
>>>>

Well, this is the default interface, but yes, for outgoing traffic
this is obviously correct.  It also appears to work.

>
>>> I then get somebody from the other end to ping me:
>>>
>>>   17:49:10.228597 IP 203.16.215.227 > 150.101.14.10: IP 192.83.231.16 > 192.109.197.145: icmp 64: echo request seq 6908
>>>   17:49:11.229188 IP 203.16.215.227 > 150.101.14.10: IP 192.83.231.16 > 192.109.197.145: icmp 64: echo request seq 6909
>>>
>>> But that's all.  Nothing goes out.  I've tried this on different
>>> systems, and I know somebody else who is using what looks like an
>>> identical configuration with this ISP, and it works fine.  I've tried
>>> different systems, one and two NICs, 4.x and 5.x, all with the same
>>> (non)result.  What am I missing?
>
> It would be worth knowing if the ICMP packet goes out from your
> ``internal'' interface (xl0).

No, of course not.  It goes out from the other end (at the ISP).  It
comes in on the rl0 interface.

> In this case, you should also see the ICMP echo-reply.

I don't see any reply.  But that's not surprising, since the echo
packet doesn't get delivered.  To summarize again:

- rl0 is the external interface (-> DSL), IP 150.101.14.10.
- xl0 is the internal interface, IP 192.109.197.143.
- encapsulated packet comes in from 203.16.215.227 with data from IP
  192.83.231.16 for 192.109.197.145.  It should go out xl0.
- It doesn't.  No further indication of why not.

Greg
--
The virus contained in this message was not detected.

Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20050608/c20558e3/attachment.bin