Possible bug - GRE tunnel routing
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 22.214.171.124
>>> should be going out via tun1, but a tcpdump shows the traffic leaving
>>> via tun0. Any other traffic (icmp, tcp etc) destined to 126.96.36.199
>>> goes out via tun1 as expected.
>>> 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 188.8.131.52 --> 184.108.40.206 netmask 0xffffff00
>>> Opened by PID 509
>>> tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
>>> inet 220.127.116.11 --> 18.104.22.168 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 22.214.171.124/24 126.96.36.199
> 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 188.8.131.52/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.
More information about the freebsd-net