Hi, We have some FreeBSD machines that have several IP''s on them and running snmpd. The udp packets always return on the default IP even though they come in on different ones during an snmpget. What is the most efficient way to handle this shorewall on the client box? Thanks, -- Pete Greenwell System Administrator Missouri Research and Education Network [MOREnet] http://www.more.net ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
pete wrote:> Hi, We have some FreeBSD machines that have several IP''s on them and > running snmpd. > > The udp packets always return on the default IP even though they come in > on different ones during an snmpget. > > What is the most efficient way to handle this shorewall on the client > box?Given what little you''ve told us, I can''t even describe the problem let alone any possible solution. See http://www.shorewall.net/support.htm#Guidelines. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Tue, Oct 02, 2007 at 06:30:55AM -0700, Tom Eastep wrote:> pete wrote: > > Hi, We have some FreeBSD machines that have several IP''s on them and > > running snmpd. > > > > The udp packets always return on the default IP even though they come in > > on different ones during an snmpget. > > > > What is the most efficient way to handle this shorewall on the client > > box? > > Given what little you''ve told us, I can''t even describe the problem let > alone any possible solution. See > http://www.shorewall.net/support.htm#Guidelines.Thanks, sorry I''ve attached what you requested. My issue is pretty simple, but the solution isn''t for me. I have a box that runs shorewall with no rules. I just need it to be able to connect via an snmp client, like snmpget to a remote machine. Normal snmp connections are not a problem as shorewall/iptables keeps track of the connections, but I need to be able to connect to a machine that is receiving the connection on one IP and returning it on another. The server receiving the connection is not the issue, but it''s my client machines rules that are breaking it. If I turn off shorewall, the problem goes away. MYCLIENT(with shorewall) ---->161/udp----> PROBLEM_SERVER(receives on IP A) But when PROBLEM_SERVER receives it on IP A, it returns the udp packet on port 161 back over IP B which is the default interfaces IP. PROBLEM_SERVER(sends on IP B) ---->161/udp----> [BLOCKED]// MYCLIENT(with shorewall) So MYCLIENT''s shorewall doesn''t allow the packet in, because it can''t relate the connection to anything. I''ve tried many, many different configurations, and the docks seem to describe issues close to this, but I couldn''t find anything that seems to address this type of situation. Any help would be appreciated. Thanks, -- Pete Greenwell System Administrator Missouri Research and Education Network [MOREnet] http://www.more.net ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
pete wrote:> On Tue, Oct 02, 2007 at 06:30:55AM -0700, Tom Eastep wrote: >> pete wrote: >>> Hi, We have some FreeBSD machines that have several IP''s on them and >>> running snmpd. >>> >>> The udp packets always return on the default IP even though they come in >>> on different ones during an snmpget. >>> >>> What is the most efficient way to handle this shorewall on the client >>> box? >> Given what little you''ve told us, I can''t even describe the problem let >> alone any possible solution. See >> http://www.shorewall.net/support.htm#Guidelines. > > Thanks, sorry I''ve attached what you requested. > > My issue is pretty simple, but the solution isn''t for me. > > > I have a box that runs shorewall with no rules. I just need it to be > able to connect via an snmp client, like snmpget to a remote machine. > > Normal snmp connections are not a problem as shorewall/iptables keeps > track of the connections, but I need to be able to connect to a machine > that is receiving the connection on one IP and returning it on another. > > The server receiving the connection is not the issue, but it''s my client > machines rules that are breaking it. If I turn off shorewall, the > problem goes away. > > MYCLIENT(with shorewall) ---->161/udp----> PROBLEM_SERVER(receives on > IP A) > > But when PROBLEM_SERVER receives it on IP A, it returns the udp packet > on port 161 back over IP B which is the default interfaces IP. > > PROBLEM_SERVER(sends on IP B) ---->161/udp----> [BLOCKED]// MYCLIENT(with shorewall) > > So MYCLIENT''s shorewall doesn''t allow the packet in, because it can''t > relate the connection to anything. > > I''ve tried many, many different configurations, and the docks seem to > describe issues close to this, but I couldn''t find anything that seems > to address this type of situation. > > Any help would be appreciated.I see no solution but this: ACCEPT net:<IP B> fw udp - 161 -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Tue, Oct 02, 2007 at 08:49:02AM -0700, Tom Eastep wrote:> I see no solution but this: > > ACCEPT net:<IP B> fw udp - 161Just for the sake of completeness, it should be possible to construct a poor man''s variation of conntrack using a recent match, to block replies that don''t match queries. I doubt that it''s worthwhile in this case, though. SNMP isn''t even remotely secure in the first place. There should also be an SNAT solution (remapping the offending source address back to what it should be), but I don''t think netfilter is currently capable of it. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Tue, Oct 02, 2007 at 08:49:02AM -0700, Tom Eastep wrote:> pete wrote: > > On Tue, Oct 02, 2007 at 06:30:55AM -0700, Tom Eastep wrote: > >> pete wrote: > >>> Hi, We have some FreeBSD machines that have several IP''s on them and > >>> running snmpd. > >>> > >>> The udp packets always return on the default IP even though they come in > >>> on different ones during an snmpget. > >>> > >>> What is the most efficient way to handle this shorewall on the client > >>> box? > >> Given what little you''ve told us, I can''t even describe the problem let > >> alone any possible solution. See > >> http://www.shorewall.net/support.htm#Guidelines. > > > > Thanks, sorry I''ve attached what you requested. > > > > My issue is pretty simple, but the solution isn''t for me. > > > > > > I have a box that runs shorewall with no rules. I just need it to be > > able to connect via an snmp client, like snmpget to a remote machine. > > > > Normal snmp connections are not a problem as shorewall/iptables keeps > > track of the connections, but I need to be able to connect to a machine > > that is receiving the connection on one IP and returning it on another. > > > > The server receiving the connection is not the issue, but it''s my client > > machines rules that are breaking it. If I turn off shorewall, the > > problem goes away. > > > > MYCLIENT(with shorewall) ---->161/udp----> PROBLEM_SERVER(receives on > > IP A) > > > > But when PROBLEM_SERVER receives it on IP A, it returns the udp packet > > on port 161 back over IP B which is the default interfaces IP. > > > > PROBLEM_SERVER(sends on IP B) ---->161/udp----> [BLOCKED]// MYCLIENT(with shorewall) > > > > So MYCLIENT''s shorewall doesn''t allow the packet in, because it can''t > > relate the connection to anything. > > > > I''ve tried many, many different configurations, and the docks seem to > > describe issues close to this, but I couldn''t find anything that seems > > to address this type of situation. > > > > Any help would be appreciated. > > I see no solution but this: > > ACCEPT net:<IP B> fw udp - 161Thanks, that works. We were doing that type of thing with ipfilter on FreeBSD, but I was hoping that there was nifty way of doing that with the connection tracking in netfilter/shorewall. However, if that''s the only solution, at least that''s something. I appreciate your patience and your help! Have good one, -- Pete Greenwell System Administrator Missouri Research and Education Network [MOREnet] http://www.more.net ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
pete wrote:> >> I see no solution but this: >> >> ACCEPT net:<IP B> fw udp - 161 > > Thanks, that works. We were doing that type of thing with ipfilter on FreeBSD, but I was hoping that there was nifty way of doing that with the connection tracking in netfilter/shorewall. > > However, if that''s the only solution, at least that''s something. > > I appreciate your patience and your help!As Andrew says, you might be able to put together an action implemented with an extension script using recent match. See the article "Port Knocking and Other uses of ''Recent Match''" at http://www.shorewall.net/PortKnocking.html -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Andrew Suffield wrote:> > There should also be an SNAT solution (remapping the offending source > address back to what it should be), but I don''t think netfilter is > currently capable of it.It isn''t. Netfilter cannot change the source IP address prior to routing just as it cannot change the destination IP address after routing. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/