[quagga-users 5728] Re: Can this be done with quagga?

urgrue urgrue at bulbous.org
Wed Oct 26 06:50:27 IST 2005


option 1: dont listen to rip on the VPN host or your gateway (or if you  
need rip for other purposes, filter the one route out with  
distribute-list)
option 2: insert the "correct" routes manually into quagga ie as static  
routes ("ip route blah" in zebra.conf). or add them as normal routes  
("route add blahblah"). i might be wrong but i recall that quagga wont  
replace an existing kernel route with a learned one. although actually,  
in this case i think youd end up with two routes in your table, so  
forget about option 2, its a bad option  ;)
option 3: advertise them with a higher metric, or larger netmask, than  
the static routes in the router/vpn host. this way hosts with the  
static entry will route to that, routes without it will route to the  
vpn.
option 4: use policy routing. ie on the vpn host do something like:
ip rule add from <vpn host> to <remote vpn> table 200
ip route add <remove vpn> <router ip> table 200
this way any traffic from <vpn host> to <remove vpn> will use routing  
table 200 and be routed through <router ip>. ie basically ignoring  
normal routing and quagga altogether.
do the same thing on the router.

personally i would just use option 1.




> Neither the LAN gateway nor the local VPN terminus (both Linux boxes)
> can
> contain an entry in their routing tables directing packets to the
> remote VPN
> terminus through the local terminus.  The gateway must route the
> VPN's
> UDP-encapsulated ESP packets on through to the Internet so they can
> make it
> to the remote VPN terminus.  If the LAN gateway contains a routing
> entry
> sending such packets back to the local VPN terminus then we basically
> have a
> routing loop.
> 
> The problem is basically that I need some way to propagate the VPN
> route
> using RIPv1 on the LAN so that _neither_ the local VPN terminus nor
> the LAN
> gateway will instantiate the route, but other boxes will.  This is no
> problem with the LAN gateway since it's not configured to accept RIP
> routing
> info anyway.
> 
> Thus spake Brandon Penglase on Tue, Oct 25, 2005 at 02:15:43PM CDT
> > I believe this can be done, but depends on your lan gateway. If the
> > gateway can accept rip, ospf, or the like, then you can have it
> accept the
> > route from the VPN box. The VPN box won't have a route directly to
> that
> > IP, however, it could go through the LAN gateway, then back to each
> it.
> > But with the gateway having the route, then all the boxes will go
> through
> > the gateway, then the vpn box, then out.
> >
> >     Help this helps,
> >       Brandon Penglase
> >
> >
> > P.S. Someone might know a better way to do it...
> >
> > Lindsay Haisley wrote ..
> > > I'm familiar with IP routing, but not with RIP or quagga, and
> would like
> > > to
> > > do a simple job that requires advertising a point to point route
> on a
> > > private LAN.
> > >
> > > Here's my situation.  I have an in-house LAN consisting of several
> Linux
> > > boxes and several Windows boxes running a variety of versions of
> Windows.
> > > The LAN uses an RFC1918 address space (192.168.1.0/24).  I have a
> VPN tunnel
> > > set up from one of the boxes on the LAN using racoon.  For reasons
> I won't
> > > go into, this tunnel terminus is not the LAN gateway box, nor can
> it be.
> > >
> > > The tunnel terminus on the LAN has an IP address of 192.168.1.16,
> and the
> > > public IP address to which the VPN connects has and address of
> > > 216.110.12.105.  This works OK, but unlike earlier VPN
> configurations using
> > > FreeS/WAN, there is no interface or routing table entry for the
> VPN tunnel
> > > on 192.168.1.16, and if one tries to put one there, the tunnel
> breaks.
> > >
> > > So all boxes on the LAN _except the box hosting the VPN terminus_
> must
> > > have
> > > a route something like:
> > >
> > > Destination     Gateway         Genmask         Flags Metric Ref
>  Use
> > > Iface
> > > 216.110.12.105  192.168.1.16    255.255.255.255 UGH   0      0
>    0
> > > eth0
> > >
> > > I can set this route manually, or by using Windows "persistent
> routing",
> > > on
> > > each of the boxes on the LAN, but the boxes running newer versions
> of
> > > Windows (XP, maybe earlier) can supposedly be configured to read
> RIPv1
> > > traffic and configure their routing tables accordingly.
> > >
> > > How can I configure quagga (zebra.conf, ripd.conf) on 192.168.1.16
> so that
> > > this route is advertised on the LAN using RIPv1, but this route is
> _not_
> > > put
> > > in the routing table on 192.168.1.16?
> > >
> > > (or is this impossible?)
> > >
> > > --
> > > Lindsay Haisley       | "Fighting against human |     PGP public
> key
> > > FMP Computer Services |    creativity is like   |      available
> at
> > > 512-259-1190          |    trying to eradicate  |
> <http://pubkeys.fmp.com>
> > > http://www.fmp.com    |        dandelions"      |
> > >                       |      (Pamela Jones)     |
> > > _______________________________________________
> > > Quagga-users mailing list
> > > Quagga-users at lists.quagga.net
> > > http://lists.quagga.net/mailman/listinfo/quagga-users
> 
> > _______________________________________________
> > Quagga-users mailing list
> > Quagga-users at lists.quagga.net
> > http://lists.quagga.net/mailman/listinfo/quagga-users
> 
> 
> --
> Lindsay Haisley       | "Fighting against human |     PGP public key
> FMP Computer Services |    creativity is like   |      available at
> 512-259-1190          |    trying to eradicate  |
> <http://pubkeys.fmp.com>
> http://www.fmp.com    |        dandelions"      |
>                       |      (Pamela Jones)     |
> _______________________________________________
> Quagga-users mailing list
> Quagga-users at lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-users
> 




More information about the Quagga-users mailing list