On Mon, Oct 29, 2012 at 12:44 AM, Eliezer Croitoru <eliezer@xxxxxxxxxxxx> wrote: > You are not suppose to be EXPERT but just to understand the basics. > In most cases it will continue to frustrate you after you will understand > the real problem so give yourself some slack. hehe, and that's a comfort? :-) > I like the output of "iptables-save" which can make more sense to me. # Generated by iptables-save v1.4.12 on Tue Oct 30 20:45:29 2012 *filter :INPUT DROP [13737:1067977] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [1866822:2015017078] -A INPUT -i lo -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource -j LOG --log-prefix "iptables denied SSH: " --log-level 7 -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH --rsource -j DROP -A INPUT -s 83.133.227.121/32 -i eth0 -j DROP -A INPUT -s 82.96.90.170/32 -i eth0 -j DROP -A INPUT -s 93.159.16.170/32 -i eth0 -j DROP -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m state --state NEW -m multiport --dports 20,21,22 -j ACCEPT -A INPUT -i eth0 -p tcp -m multiport --dports 22,80,4000,8080 -j ACCEPT -A INPUT -s 192.168.0.0/24 -i eth1 -j ACCEPT -A INPUT -s 212.97.132.102/32 -p tcp -m tcp --dport 3306 -j ACCEPT -A INPUT -i eth1 -p udp -m udp --sport 68 --dport 67 -j ACCEPT -A INPUT -i eth0 -p udp -m udp --sport 67 --dport 68 -j ACCEPT -A INPUT -i eth1 -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -i eth1 -p tcp -m tcp --dport 8080 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 443 -j ACCEPT -A INPUT -i eth0 -p udp -m udp --dport 443 -j ACCEPT -A INPUT -i eth1 -p tcp -m tcp --dport 443 -j ACCEPT -A INPUT -i eth1 -p udp -m udp --dport 443 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 6891:6901 -j ACCEPT -A INPUT -i eth0 -p udp -m udp --dport 6891:6901 -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -s 192.168.0.0/24 -d 192.168.0.0/24 -i eth1 -p tcp -m tcp --sport 1024:65535 --dport 139 -j ACCEPT -A INPUT -s 192.168.0.0/24 -d 192.168.0.0/24 -i eth1 -p tcp -m tcp --sport 1024:65535 --dport 445 -j ACCEPT -A INPUT -s 192.168.0.0/24 -d 192.168.0.0/24 -i eth1 -p udp -m udp --sport 1024:65535 --dport 137:138 -j ACCEPT -A INPUT -s 192.168.0.0/24 -d 192.168.0.0/24 -i eth1 -p udp -m udp --sport 137:138 --dport 137:138 -j ACCEPT -A INPUT -s 192.168.0.0/24 -d 192.168.0.0/24 -i eth1 -p tcp -m tcp --sport 139 --dport 139 -j ACCEPT -A INPUT -s 192.168.0.0/24 -d 192.168.0.0/24 -i eth1 -p tcp -m tcp --sport 445 --dport 445 -j ACCEPT -A FORWARD -i eth1 -j ACCEPT -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 192.168.0.0/24 -j ACCEPT -A FORWARD -j REJECT --reject-with icmp-port-unreachable -A OUTPUT -o lo -j ACCEPT -A OUTPUT -s 212.97.132.102/32 -p tcp -m tcp --dport 3306 -j ACCEPT -A OUTPUT -o eth0 -p tcp -m tcp --dport 443 -j ACCEPT -A OUTPUT -o eth0 -p udp -m udp --dport 443 -j ACCEPT -A OUTPUT -o eth1 -p tcp -m tcp --dport 443 -j ACCEPT -A OUTPUT -o eth1 -p udp -m udp --dport 443 -j ACCEPT -A OUTPUT -s 192.168.0.0/24 -d 192.168.0.0/24 -p tcp -m tcp --sport 139 --dport 1024:65535 -j ACCEPT -A OUTPUT -s 192.168.0.0/24 -d 192.168.0.0/24 -p tcp -m tcp --sport 445 --dport 1024:65535 -j ACCEPT -A OUTPUT -s 192.168.0.0/24 -d 192.168.0.0/24 -p udp -m udp --sport 137:138 --dport 1024:65535 -j ACCEPT -A OUTPUT -s 192.168.0.0/24 -d 192.168.0.0/24 -p udp -m udp --sport 137:138 --dport 137:138 -j ACCEPT -A OUTPUT -s 192.168.0.0/24 -d 192.168.0.0/24 -p tcp -m tcp --sport 139 --dport 139 -j ACCEPT -A OUTPUT -s 192.168.0.0/24 -d 192.168.0.0/24 -p tcp -m tcp --sport 445 --dport 445 -j ACCEPT COMMIT > if it worked before and the only problem was it is dosnt work well > that(iptables) is probably not the problem. I'm a bit unsure if the problem happend when i switched to a new server (2 years ago). I didn't realize there was a problem until i started using VPN (one year ago) > I mean by drivers faulty switch\cable\router\line etc. > (maybe it's related to reverse path filtering) > > the odds that the fault is at iptables is so limited it's unlikely the > cause.(but not 100% guarantied). if i plug the company PC directly to the plug, IE, bypass the server and one switch, it works flawless, so yeah, cables, one switch, Iptables or some other setting on the ubuntu server must be the reason. > what evidence you do have that proves the packets loss? 10 pings gave 10, 30 and 40% packetloss. > if it get's into one interface but dosnt come-out from the other it's > something with kernel settings. > there aren't many options about it. How do i debug on that? tcpdump? (used it once ages ago) some logging in iptables? > I would suggest you to post in Ubuntu-servers with hardware specification of > the machine and topology. I'm not sure that's the way to go? I might call it a server, it's s plain PC used as firewall, router, webserver, databaseserver etc. with a desktop install. > you can Cc me and I will try to help you on my free time. Thank you so far for the inputs. -- Take care Kim Emax http://emax.dk -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
