Ryan Novosielski wrote: > James Ray wrote: >>>>> The problem with my tcpdump is it looks only for traffic on 9101, >>>>> which would be incoming connections to the DIR. I was not looking >>>>> for outgoing connections from the DIR. >>>>> >>>>> >>>>> Yes, the DIR is initiating outgoing connections on an IP address not >>>>> specified in the Director resource of the bacula-dir.conf >>>>> configuration file. >>>>> >>>>> >>>> Which is normal behavior. The port and address(es) that the server >>>> listens on has nothing to do with the port and address a client socket >>>> is bound to when making a client connection to a server. Those are >>>> normally assigned by kernel routing. As James Harper mentioned >>>> previously, the routing table is where this sort of routing assignment >>>> should be made. His post shows clearly how to assign a preferred source >>>> address to a particular route. >>>> >>> I don't really see this as a 'routing' decision though. Lets take >>> proftpd as an example here. >>> >>> Now I connect to proftpd that is running on a system with virtual >>> interfaces, proftpd's listening port is bound to one interface which is >>> a virtual one... >>> >>> Now I have passive mode turned on and I do an 'ls' command, at which >>> point the FTP server opens a connection to my client _from the virtual >>> interfaces IP address_. >>> >>> This just wouldn't work at all if I go a connection coming from the >>> machines physical 'default' IP address. >>> >>> All I want is for when I connect to a client from the director that it >>> uses a defined IP address rather than me Source NATing or doing other >>> evil routing things. >>> >>> I don't want to always talk to these machines from the virtual interface >>> either so the routing tricks aren't really feasible. I want all my >>> normal communications (sshing outwards, blah blah blah) to come from the >>> 'default' IP address, but I want bacula to come from its service IP >>> address which isn't the default one. > > I find that this kind of stuff is much more easily handled if you keep > your service networks split out by subnet and/or set your netmask as > sufficiently restrictive. The OS will then choose the proper interface > to use based on where the traffic is headed (ie. a Bacula service > network, etc.). Kinda sticky when you get down to it, and if you aren't > using sufficiently small address ranges you can run out of addresses, > but a lot of this stuff can be done on private networks anyway and > eliminate the need for you to use addresses from your IANA block. >
Unfortunately that is not possible in my case. So as I understand the rest of this thread, yes my assumption is right, but no bacula can't (Kern, and won't?) support binding to a source IP address for out going connections? -- James Ray. <[EMAIL PROTECTED]> Computing Services Queen Mary, University of London ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
