Possible bug - GRE tunnel routing

[Julian Elischer]

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



> gre0: flags=9051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> metric 0 mtu 1476
>         tunnel inet 194.31.137.70 --> 194.31.154.148
>         inet 192.168.254.2 --> 92.168.254.1 netmask 0xffffff00
> 
> Routing table:
> Destination        Gateway            Flags    Refs      Use  Netif Expire
> default            41.142.82.1        UGS         1     1365   tun0
> 41.142.82.1        41.142.82.37       UGH         1        0   tun0
> 192.168.254.1      192.168.254.2      UH          0        3   gre0
> 194.31.137.64      194.31.137.70      UH          1        0   tun1
> 194.31.154.148     194.31.137.64      UGS         0        0   tun1
> 
> GRE traffic (generated by ping -S 192.168.254.2 192.168.254.1) is routed
> via tun0

Why do you think you need -S? routing takes into account only the 
destination..

> 
> [root at fw ~]# tcpdump -ni tun0 proto gre
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes
> 23:14:58.700415 IP 194.31.137.70 > 194.31.154.148: GREv0, length 88: IP
> 192.168.254.2 > 192.168.254.1: ICMP echo request, id 61956, seq 777,
> length 64
> 
> 
> ICMP traffic (generated by ping -S 194.31.137.70 194.31.154.148) is
> routed via tun1
> 
> [root at fw ~]# tcpdump -ni tun1 icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on tun1, link-type NULL (BSD loopback), capture size 96 bytes
> 23:15:50.328470 IP 194.31.137.70 > 196.31.154.148: ICMP echo request, id
> 10757, seq 14, length 64
> 23:15:50.340888 IP 196.31.154.148 > 194.31.137.70: ICMP echo reply, id
> 10757, seq 14, length 64
> 
> 
> However, if I add a /24 route for the GRE endpoint subnet, instead of a
> /32 to the host:
> 
> 194.31.154.0/24    194.31.137.64      UGS         0        0   tun1
> 
> and then bring up the GRE tunnel, everything works as expected and GRE
> traffic exits via tun1.

yes.. that is as expected..

> 
> 
>