[Linux-HA] Setting Source IP for outgoing traffic?

Dejan Muhamedagic dejanmm at fastmail.fm
Thu Oct 25 04:45:37 MDT 2007


On Wed, Oct 24, 2007 at 10:55:10PM -0400, Timothy Meader wrote:
> Hello, I'm having an issue that I'm hoping someone could provide me 
> some help on. To give a brief synopsis of the situation:
> We originally had a single server setup running OSSEC. Last week, we 
> decided to combine this server with another two that were running as 
> a simple log server (in high availability fail-over mode using 
> heartbeat) to make better use of the existing systems. The log server 
> portion is running on the virtual IP xxx.xxx.xxx.7 on eth0:0, the 
> OSSEC server is setup to run on a secondary virtual IP, 
> xxx.xxx.xxx.29, on eth0:1. When running on a single server, OSSEC 
> worked fine. But now, the clients refuse to communicate properly with 
> the server.
> Using tcpdump, I tracked this communications problem down to the fact 
> that the server response from OSSEC in the high availability setup is 
> going back to the client with the ACTUAL address of eth0 
> (xxx.xxx.xxx.17 or 18 depending on which of the two high-avail nodes 

I think that I've seen this happen before. It actually violates
RFC recommendations (a SHOULD) for multihomed hosts. Normally,
the host should use a source address from the packet which was
used as the destination address. Is this Linux? Perhaps you
should complain on the networking list.

> it's currently running on). What I need is for the server response to 
> come back to the client with the xxx.xxx.xxx.29 address as the 
> source. I've investigated the "IPsrcaddr" script that comes with 
> heartbeat, but unfortunately there are two issues that preclude me 
> from using it, so I'm looking to iptables for a means to handle this.

Why is it that you cannot use it? Could it be modified to fit?

> Basically, I need the responses to any traffic coming in on UDP port 
> 1514 (or, alternatively, to the destination IP x.29) to go back out 
> with a src address of x.29 instead of x.17 or x.18. Is there a method 
> using iptables that can handle this problem? Or barring that, can 
> anyone think of any other means to accomplish this task if iptables 
> can't handle this on its own? Below, I've included the current 
> iptables data rules that the two cluster nodes are presently sharing.

It's definitely possible to mangle packets and replace the IP
address on all traffic matching udp and that port. There should
be some good howto docs or just try the man page. Sorry, not
exactly an expert on iptables, always have to read the



> Thank you in advance for any and all replies up-front.
> *filter
> :RH-Firewall-1-INPUT - [0:0]
> -A INPUT -j RH-Firewall-1-INPUT
> -A FORWARD -j RH-Firewall-1-INPUT
> -A RH-Firewall-1-INPUT -i lo -j ACCEPT
> -A RH-Firewall-1-INPUT -i eth1 -j ACCEPT
> -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
> -A RH-Firewall-1-INPUT -p 50 -j ACCEPT
> -A RH-Firewall-1-INPUT -p 51 -j ACCEPT
> -A RH-Firewall-1-INPUT -p udp --dport 5353 -d -j ACCEPT
> -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 514 -j 
> -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 514 -j 
> -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 720 -j 
> -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 
> 1514 -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 
> 5514 -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 
> 5140 -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 
> 8000:8001 -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 
> 8089 -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j 
> -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j 
> -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
> ---
> Tim Meader
> L-3 Communications, NASA EOS Security Operations
> Timothy.Meader at gsfc.nasa.gov
> (301) 614-6371  
> _______________________________________________
> Linux-HA mailing list
> Linux-HA at lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems

More information about the Linux-HA mailing list