Date: Tue, 19 Aug 2008 11:09:32 -0700 From: Julian Elischer <julian@elischer.org> To: Todor Genov <todor.genov@za.verizonbusiness.com> Cc: freebsd-net@freebsd.org Subject: Re: Possible bug - GRE tunnel routing Message-ID: <48AB0C5C.8090404@elischer.org> In-Reply-To: <48AA88B4.6040606@za.verizonbusiness.com> References: <48AA1A9D.2040607@za.verizonbusiness.com> <48AA26FD.20305@elischer.org> <48AA88B4.6040606@za.verizonbusiness.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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. 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 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. the netmask should not be taken into account because it is ignored. >> > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48AB0C5C.8090404>