Possible bug - GRE tunnel routing

Julian Elischer julian at elischer.org
Tue Aug 19 18:09:27 UTC 2008

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
>>> should be going out via tun1, but a tcpdump shows the traffic leaving
>>> via tun0. Any other traffic (icmp, tcp etc) destined to
>>> 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 --> netmask 0xffffff00
>>>         Opened by PID 509
>>> tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
>>>         inet --> 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
>  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
>  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.



More information about the freebsd-net mailing list