Date: Fri, 25 Jul 2008 16:27:36 -0700 From: Chris Pratt <eagletree@hughes.net> To: FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: IP alias/routing question Message-ID: <9DCE03A2-8CBB-4E0D-8BAF-C3DB3E43C66E@hughes.net> In-Reply-To: <2daa8b4e0807251605j525d7480n5a5531188f718660@mail.gmail.com> References: <9339104B-252B-49DC-9648-B59343E17E16@hughes.net> <488A0997.3090300@infracaninophile.co.uk> <2daa8b4e0807251605j525d7480n5a5531188f718660@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 25, 2008, at 4:05 PM, David Allen wrote: > On Fri, Jul 25, 2008 at 10:12 AM, Matthew Seaman > <m.seaman@infracaninophile.co.uk> wrote: >> Chris Pratt wrote: >> >>> I'm now setting up a bind server in which the third alias >>> is the address for incoming DNS queries. It appears >>> it's responding but even though the queries come in >>> on the third alias, they "go out" through the "primary" >>> address or more specifically, the packet count is >>> incremented in the Opkts total for the IP address first >>> attached to the interface via ifconfig (without an alias). >>> My problem appears to be that the packets really are >>> coming from the first IP as the source and are getting >>> blocked by my firewall as they should (the first address >>> is not supposed to be answering DNS queries). >> >> Carefully not answering the 'why do these packets come from the >> wrong address' question, but just pointing out that BIND is >> actually rather more configurable in this respect than most >> software. > > Deliberately addressing the question of 'why do these packets come > from the wrong address' question which Mr. Seaman avoided (hello > again, Mathew!), I'll add my two cents. > > Run netstat -rnfinet and examine what's in the 'Netif' column. If > there was some inter-host traffic, you'll see a host entry for each of > your aliases with a value of 'lo0'. Correlate all the entries in the > routing table and you'll be able to determine what exits where. > > I'm not sure why this question doesn't come up more frequently as it > can be problematic, especially in regards to jails (which are > implemented using IP aliasing). I started a discussion some weeks ago > on the subject that you may find interesting. To recap briefly, if a > jail host sends traffic to a jail, the traffic will transit the lo0 > interface, exit the jail's interface using the jail's IP address, and > connect to the jail on its IP address. The end result? Traffic with > identical source and destination IP addresses! > > Using your numbers, if named was running in a jail (192.168.0.18) and > a query was made on the host (192.168.0.12), instead of seeing > > 192.168.0.12.3450 -> 192.168.0.18.53 > 192.168.0.18.53 -> 192.168.0.12.3450 > > you'd see the following on lo0: > > 192.168.0.18.3450 -> 192.168.0.18.53 > 192.168.0.18.53 -> 192.168.0.18.3450 > > You're not using jails, but what I'm describing isn't a jail issue, or > a general IP aliasing issue, but a routing issue. Modifying the > routing table is, of course, possible. But the results, I've found, > are less than satisfactory. If you force traffic out an actual > interface, the return traffic will probably still have to occur over > loopback and you're back to where you started, but with some new > problems. Note also that the above seems to apply irrespective of > the number of network cards or networks. > > Tthe moral of the story? Configure named appropriately, and don't ask > any more questions. ;-) On the other hand, if you insist on thinking > immoral thoughts as I do, and find a more thorough explanation of any > of the above, please do let me know. Thanks for the very detailed explanation. I'm hot on the named configuration so that should quiet the questions. But ;-), how about the multiple route table implementation recently introduced in HEAD. Perhaps there is a solution there in the future! I stay with the current RELEASE so I haven't even researched, just watched the talk. Thanks again to both you and Matthew, Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9DCE03A2-8CBB-4E0D-8BAF-C3DB3E43C66E>