> Now with some -j LOG i can see the packet going > into OUTPUT with eth1 as dst interface > > Now it gets into my anti-spoof rule : > Aug 11 13:20:17 natasha kernel: firewall::OUT_IP_CHECK IN= OUT=eth1 > SRC=sql.se.rv.er DST=192.168.0.149 LEN=40 TOS=0x00 > PREC=0x00 TTL=255 ID=0 DF PROTO=TCP SPT=445 DPT=3394 WINDOW=0 RES=0x00 ACK > RST URGP=0 > > If i open this rule, i can see the packet adressed to 192.168.0.149 > sent on eth1 (WAN) with tcpdump. > > Any other ideas ? yeah--in order for your netfilter machine to be able to reset the connection--it has to spoof/pretend to be the original destination of the packet (sql.se.rv.er). i.e. it generates a packet locally with a source IP of the SQL server and a destination of the client that is subject to the OUTPUT chain filters. your OUT_IP_CHECK chain only allows the source IP to be the actual IP's of the netfilter machine (this is actually a good thing). my guess is adding this: -I OUTPUT -p tcp --tcp-flags SYN,RST,FIN RST -j ACCEPT would fix the situation. if it does--i'll leave it to you to decide how you want to incorporate it into your custom chains. -j
