On Fri, Dec 30, 2011 at 05:08:28PM +0100, Henning Brauer wrote: > * PP;Q Q P(P8P?P8QP8P= <chipits...@gmail.com> [2011-12-30 05:21]: > > why does OpenBSD choose vlan379 ? how can I make it use vlan200 for > > all outgoing traffic except bgp communication ? > > for wildcard binds (INADDR_ANY aka 0.0.0.0, connect without bind has the > same effect) the address is chosen based on the route to the destination.
Many applications allow to bind(2) before doing the connect(2) so you can define the outgoing address being used. I know that especialy the DNS resolvers bind and unbound have that option. This is your best option to go NAT free in your situation without calling names at your ISP for insane filtering restrictions on the uplink. Seems like they're stuck in the past where a bgp router was only a bgp router and an easy target to other attacks (like telnet). > i. e. for www.google.com from my location: > > <br...@cr10.ham> $ route -n get 173.194.69.105 > route to: 173.194.69.105 > destination: 173.194.69.0 > mask: 255.255.255.0 > gateway: 80.81.203.34 > interface: carp0 > if address: 80.81.203.19 > priority: 48 (bgp) > flags: <UP,GATEWAY,DONE> > use mtu expire > 1431189 0 0 > > the "if address" is used. > > how's the if address figured out? easy. if the route lookup gives a > gateway route (as in the above example, gateway 80.81.203.34), a lookup > for the route to that gateway is done (basically, i simplify a bit). > if needed this is repeated until we get a connected route - which we > have straight after looking up the route to the gateway from the > previous route in this case. To be true the ifa (as in if address) is stored on each route individually and can be forced by route(8). But yes, on route insertion the kernel will do the mentioned dance by looking up the gateway unless userland provided an ifa in advance. Now that does not help for BGP learened routes but can be used for other tricks. > so all you need to do is getting your routes right. from your > description (which leads to the impression that your ISP makes you use > a pretty strange setup) you'll need to set the nexthop to your ISP's > address on that other vlan in your bgpd.conf - look for "set nexthop" > in bgpd.conf.5 set nexthop will not work it is used for outgoing updates not for the FIB. The only option I see to workaround the problem is to use multiple routing tables (one with the BGP feed and one with just a default route) but it still requires some pf(4) trickery to make packets switch between the tables at the right moment. -- :wq Claudio
