Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Aug 2008 11:09:32 -0700
From:      Julian Elischer <julian@elischer.org>
To:        Todor Genov <todor.genov@za.verizonbusiness.com>
Cc:        freebsd-net@freebsd.org
Subject:   Re: Possible bug - GRE tunnel routing
Message-ID:  <48AB0C5C.8090404@elischer.org>
In-Reply-To: <48AA88B4.6040606@za.verizonbusiness.com>
References:  <48AA1A9D.2040607@za.verizonbusiness.com> <48AA26FD.20305@elischer.org> <48AA88B4.6040606@za.verizonbusiness.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Todor Genov wrote:
> Hi Julian,
> 
> Julian Elischer wrote:
>> Todor Genov wrote:
>>> Hi everyone,
>>>
>>>  I may have found a routing bug relating to GRE tunnels. Could somebody
>>> try and replicate this?
>>>
>>>  As per the setup below GRE-encapsulated traffic to 194.31.254.148
>>> should be going out via tun1, but a tcpdump shows the traffic leaving
>>> via tun0. Any other traffic (icmp, tcp etc) destined to 194.31.154.148
>>> goes out via tun1 as expected.
>>>
>>> Configuration:
>>> FreeBSD 7.0-STABLE #4: Mon Aug 18 13:50:38 SAST 2008
>>> tun0 - PPPoE connection to ISP
>>> tun1 - vpn connection to office PIX (via vpnc)
>>> gre0 - GRE tunnel to machine sitting behind the PIX
>>>
>>> tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1492
>>>         inet 41.142.82.37 --> 41.142.82.1 netmask 0xffffff00
>>>         Opened by PID 509
>>> tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
>>>         inet 194.31.137.70 --> 194.31.137.64 netmask 0xffffff40
>>>         Opened by PID 984
>> Point to point interfaces really don't have netmasks.
>> Otherwise it wouldn't be "Point to Point", it would be
>> "multicast" like ethernet.
>>
>> There is really only one address at this end or the other end.
>> If you want to say that there is a network at the other end
>> then you really need to set a route for it.
>> but it applies equally to all three of these p2p links.
>>
>> so, add a route:
>>
>> route add 92.168.254.0/24 92.168.254.1
> 
>  The netmask for tun0 is automatically assigned by the ISP, and for tun1
> by the VPN server. The one for gre0 is a /30 in the connect scripts - I
> must have changed it to /24 somewhere along the troubleshooting process
> - it makes no difference to the end result.

let me rephrase that..
p2p links do not support netmasks. That's all p2p links.. ppp, slip, 
tun, ng, gre, etc.

If you what a virtual ethernet interface you may try tap(4) but you 
will need to have an appropriatly capable piece of software on the
other end of the link.


A p2p link doesn't take any notice of what you have written as netmask
and it doesn't matter what your ISP has given you, or if you
type /24 or /22 or /32.

The point to point interface only knows about the ONE SINGLE ADDRESS
on the other end of the link.
If there is a network there, which that address is a part of, then
it is up to YOU to add the route that allows packets to get there.


> 
>  The routing table does include routes to the /26 on tun1 and the /24 on
> gre0. I have left them out as they are not relevant to the problem. The
> troublesome route is the one to 194.31.154.148/32
> 
>  Just noticed that the PtP address for tun1 looks incorrect - with that
> netmask into account .64 is the network address. I'll look into that as
> a possible cause.

the netmask should not be taken into account because it is ignored.

>>
>

>
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48AB0C5C.8090404>