search for: smgtec

I saw this snippet from Daniel Chemko dchemko@smgtec.com Mon, 31 May 2004 09:30:43 -0700 # Egress marking (mostly for QOS operations) iptables -t mangle -A POSTROUTING -j CONNMARK --restore-mark iptables -t mangle -A POSTROUTING -m mark ! --mark 0 -j ACCEPT iptables -t mangle -A POSTROUTING -o ${if_inet} --dport 21 -j MARK --set-mark 0x111 iptabl...

...******************** lrmdn> --__--__-- lrmdn> Message: 2 lrmdn> Date: Thu, 2 Oct 2003 08:36:55 +0100 (BST) lrmdn> Subject: RE: [LARTC] Packet mangling latency lrmdn> From: "Jamie Harris" <jamie@jharris.homeip.net> lrmdn> To: "Daniel Chemko" <dchemko@smgtec.com> lrmdn> Cc: lartc@mailman.ds9a.nl >> The server should be fine. What network bandwidths are you looking into? lrmdn> Nothing wild, ~10Mb tops >> The more the bandwidth, the higher the requirements. Also, ram is useful >> if you have a lot of smaller connections pas...

Hi, Partly because I never like straightforward solutions, I am looking to implement a non-standard failover system that owes its origins to mixing RAID 5 with some beer. The idea is to have machines A, B and C, configured as follows: 1) Any given process is running on TWO machines at the same time. If a process or machine fails, then a new backup is started on the third machine. There is thus

Please refer to www.netfilter.org There is a definite gap in your knowledge of iptables that can be fulfilled there, or on the Netfilter ML: netfilter@lists.netfilter.org _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Unless the bridge keeps stateful inspection data and can reply back to the session''s origin, not it route then its fine. The only way I can see this working is either putting the FTP/.. DMZ behind the firewall giving true firewall protection for all services involved, or if you just want to kludge the current solution, you can perform a DNAT/SNAT interface bounce like the following: #

Objective: All web traffic originating from my proxy server should be forwarded through interface eth2 instead of the default eth0. The reply should take the same path back to the proxy server. Problem: On the return bout, the kernel doesn''t pass the packet to the higher layers. The reply seems to be getting tossed away between PREROUTING and INPUT Netfilter chains.