Possible bug - GRE tunnel routing

[Todor Genov]

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.

 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.
> 
> 
> 
>> 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..
> 

 I am using -S just to make sure that the source IP is the gre0
interface - more of a habit than any particular reason.

>>
>> [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..

 It is also expected that the /32 route over tun1 to the GRE endpoint
(196.31.154.148) should suffice. What puzzles me is the fact that GRE
traffic to 196.31.154.138 leaves via tun0 and icmp traffic leaves via tun1.

> 
>>
>>
>>
> 
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"