Group, Any advise on this?
-Rahul N. On Saturday, August 11, 2012, Rahul Nair <rahul.n...@finicity.com> wrote: > By default net.ipv4.conf.eth0.rp_filter is 1 which means IP spoofing protection is enabled (source route verification is turned on) > As far as I understand, TPROXY spoofs outgoing connections using the client's IP address. > But since all the IPs are configured on same physical adapter, not sure if setting net.ipv4.conf.eth0.rp_filter to 0 will make any difference. > Also the issue is intermittent and not Boolean in nature. > -Rahul N. > On Sat, Aug 11, 2012 at 12:01 AM, Rahul Nair <rahul.n...@finicity.com> wrote: > > Willy, > Following are the information I could gather: > As per this link we need to add following sysctl parameters. > #Reverse Path Filtering: Basically, if the reply to a packet wouldn't go out the interface this packet came in, then this is a bogus packet and should be ignored. > net.ipv4.conf.default.rp_filter = 2 > net.ipv4.conf.all.rp_filter = 2 > #Disable Reverse Path Filtering > net.ipv4.conf.eth0.rp_filter = 0 > I am currently using a single physical ethernet interface for both the networks (realservers network and VIPs network) > Are there any chances that this could create any issues? > Regarding kernel bugs: > > 2.6.28 to 2.6.32 have different rp_filter configuration. The rp_filter settings (0 or 1) for these kernels will silently block TPROXY if used on newer kernels. > 2.6.28 to 2.6.36 are known to have ICMP and TIME_WAIT issues. > 2.6.32 to 2.6.34 have bridging issues on some systems > > I am now using kernel version: 2.6.38-15-server > Thanks > Rahul N. > > On Fri, Aug 10, 2012 at 1:30 PM, Rahul Nair <rahul.n...@finicity.com> wrote: > > Just FYI... > Following are the config parameters that I use: > global > log 127.0.0.1 local0 info > ulimit-n 80038 > chroot /var/lib/haproxy > daemon > defaults > log global > mode http > option dontlognull > retries 3 > option redispatch > maxconn 2000 > timeout connect 5000 > timeout client 300000 > timeout server 300000 > > listen httpsite 10.1.16.15:80 > mode http > balance leastconn > cookie PHPSESSID prefix > option httpclose > server web01 10.1.1.20 cookie web01 check > server web02 10.1.1.30 cookie web02 check > listen httpssite 10.1.16.15:443 > mode tcp > source 0.0.0.0 usesrc clientip > balance source > option ssl-hello-chk > server web01 10.1.1.20 check > server web02 10.1.1.30 check > Thanks > Rahul N. > On Fri, Aug 10, 2012 at 11:20 AM, Rahul Nair <rahul.n...@finicity.com> wrote: > > Willy, > > The issue still persists. > Not sure what am I missing. > > -Rahul N. > > On Friday, August 10, 2012, Rahul Nair <rahul.n...@finicity.com> wrote: >> Willy, >> I have upgraded the Linux kernel to and haproxy to 1.4.18 and kernel to 2.6.38-15-server >> Will monitor it for few days and will let you know the updates. >> -Rahul N. >> >> On Fri, Aug 10, 2012 at 2:04 AM, Willy Tarreau <w...@1wt.eu> wrote: >>> >>> On Thu, Aug 09, 2012 at 11:54:08PM +0530, Rahul Nair wrote: >>> > Willy, >>> > >>> > >From your description, it could be an issue with some connection >>> > tracking somewhere caused by excess of source addr:ports. >>> > >>> > Ohh ok.. >>> > Also I just found that as per the documentation in this link , it says that >>> > "it can cause problems when IP connection tracking is enabled on the >>> > machine, because a same connection may be seen twice with different states". >>> > Does this mean that I need to disable the nf_conntrack module by adding >>> > "net.netfilter.nf_conntrack_acct = 0" t -- -Rahul N. IT Department In2M Technologies Pvt Ltd. (Finicity) Website: www.finicity.com/india
