Date: Tue, 19 Aug 2008 10:47:48 +0200 From: Todor Genov <todor.genov@za.verizonbusiness.com> To: Julian Elischer <julian@elischer.org> Cc: freebsd-net@freebsd.org Subject: Re: Possible bug - GRE tunnel routing Message-ID: <48AA88B4.6040606@za.verizonbusiness.com> In-Reply-To: <48AA26FD.20305@elischer.org> References: <48AA1A9D.2040607@za.verizonbusiness.com> <48AA26FD.20305@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48AA88B4.6040606>