RELATED emulation without ip_conntrack

RELATED emulation without ip_conntrack

[Roy Sigurd Karlsbakk]

hi

I've got this video server streaming @ ~250Mbps, so I really don't want to 
waste cpu cycles on ip_conntrack.

how can I test for tcp flags to allow me to do a poor-man's-conntrack?

the server is only to be contacted on tcp/1234 (on that network) and will 
answer from :1234 -> high port

roy
-- 
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356

Computers are like air conditioners.
They stop working when you open Windows.

Re: RELATED emulation without ip_conntrack

[Antony Stone]

On Wednesday 23 October 2002 3:02 pm, Roy Sigurd Karlsbakk wrote:

> hi
>
> I've got this video server streaming @ ~250Mbps, so I really don't want to
> waste cpu cycles on ip_conntrack.
>
> how can I test for tcp flags to allow me to do a poor-man's-conntrack?

Treat packets with SYN set, and ACK, FIN and RST clear as NEW connections.

Treat packets with SYN and ACK set, FIN and RST clear as NEW replies.

Treat packets with ACK set, SYN, FIN and RST clear as ESTABLISHED connections.

Treat packets with FIN or RST set (probably ACK too) as terminating 
connections.

Antony.

-- 

Most people have more than the average number of legs.

Re: RELATED emulation without ip_conntrack

[Roy Sigurd Karlsbakk]

On Wednesday 23 October 2002 17:17, Antony Stone wrote:
> On Wednesday 23 October 2002 3:02 pm, Roy Sigurd Karlsbakk wrote:
> > hi
> >
> > I've got this video server streaming @ ~250Mbps, so I really don't want
> > to waste cpu cycles on ip_conntrack.
> >
> > how can I test for tcp flags to allow me to do a poor-man's-conntrack?
>
> Treat packets with SYN set, and ACK, FIN and RST clear as NEW connections.
> Treat packets with SYN and ACK set, FIN and RST clear as NEW replies.
> Treat packets with ACK set, SYN, FIN and RST clear as ESTABLISHED
> connections.
> Treat packets with FIN or RST set (probably ACK too) as terminating
> connections.

ok. My system has a private network and a public network. the private is open 
to everyone connected on it. The public is open only to the video service 
(tcp/1234) and icmp. Does the following look reasonable?

iptables -I INPUT -i eth0 -j ACCEPT
iptables -I INPUT -i eth1 -p icmp -j ACCEPT
iptables -I INPUT -i eth1 -p tcp --dport 1234 --tcp-flags SYN,ACK,FIN,RST \
	SYN -j ACCEPT
iptables -I INPUT -i eth1 -p tcp --dport 1234 --tcp-flags SYN,ACK,FIN,RST \
	SYN ACK -j ACCEPT
iptables -I INPUT -i eth1 -p tcp --dport 1234 --tcp-flags SYN,ACK,FIN,RST \
	FIN,RST -j ACCEPT
iptables -I INPUT -i eth1 -p tcp --dport 1234 --tcp-flags SYN,ACK,FIN,RST \
	ACK,FIN,RST -j ACCEPT
iptables -I INPUT -j LOG --log-prefix "Illegal packet" --limit 5/second \
	--limit-burst 10
iptables -I INPUT -j DROP

-- 
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356

Computers are like air conditioners.
They stop working when you open Windows.

Re: RELATED emulation without ip_conntrack

[Antony Stone]

On Thursday 24 October 2002 11:45 am, Roy Sigurd Karlsbakk wrote:

> On Wednesday 23 October 2002 17:17, Antony Stone wrote:
> > On Wednesday 23 October 2002 3:02 pm, Roy Sigurd Karlsbakk wrote:
> > > hi
> > >
> > > I've got this video server streaming @ ~250Mbps, so I really don't want
> > > to waste cpu cycles on ip_conntrack.
> > >
> > > how can I test for tcp flags to allow me to do a poor-man's-conntrack?
> >
> > Treat packets with SYN set, and ACK, FIN and RST clear as NEW
> > connections. Treat packets with SYN and ACK set, FIN and RST clear as NEW
> > replies. Treat packets with ACK set, SYN, FIN and RST clear as
> > ESTABLISHED connections.
> > Treat packets with FIN or RST set (probably ACK too) as terminating
> > connections.
>
> ok. My system has a private network and a public network. the private is
> open to everyone connected on it. The public is open only to the video
> service (tcp/1234) and icmp. Does the following look reasonable?
>
> iptables -I INPUT -i eth0 -j ACCEPT
> iptables -I INPUT -i eth1 -p icmp -j ACCEPT
> iptables -I INPUT -i eth1 -p tcp --dport 1234 --tcp-flags SYN,ACK,FIN,RST \
> 	SYN -j ACCEPT
> iptables -I INPUT -i eth1 -p tcp --dport 1234 --tcp-flags SYN,ACK,FIN,RST \
> 	SYN ACK -j ACCEPT
> iptables -I INPUT -i eth1 -p tcp --dport 1234 --tcp-flags SYN,ACK,FIN,RST \
> 	FIN,RST -j ACCEPT
> iptables -I INPUT -i eth1 -p tcp --dport 1234 --tcp-flags SYN,ACK,FIN,RST \
> 	ACK,FIN,RST -j ACCEPT
> iptables -I INPUT -j LOG --log-prefix "Illegal packet" --limit 5/second \
> 	--limit-burst 10
> iptables -I INPUT -j DROP

I think all these rules should be in the FORWARD chain, not the INPUT chain - 
I mean, these are for packets being routed through the netfilter box, right ? 
The netfilter machine is neither of the endpoints of your connection ?

Also there's no rule to allow packets in from eth1 which have ACK only set - 
the majority of packets in that direction !

Remember the way TCP sets up, maintains, and shuts down a connection:

SYN only - initial contact
SYN + ACK - reply
ACK - connection established
ACK - all further data packets
FIN + ACK - shut down
ACK - acknowledge shutdown
(last two generally happen in both directions)

Also, since your main requirement is for speed of processing packets, make 
sure you place them in the correct order, so the rule which will match the 
most packets comes first etc.

You might want to set up the rules and let some traffic flow, then use
iptables -L FORWARD -n -v -x
to see how many packets / bytes have matched each rule, and adjust the order 
so the most-used ones come before the least-used ones.

Antony.

-- 

In science, one tries to tell people
in such a way as to be understood by everyone
something that no-one ever knew before.

In poetry, it is the exact opposite.

 - Paul Dirac

Hi , problem with quota and Time

[hare ram]

Hi all

 i have installed redhat 7.3 with iptables 1.2.5

i have patched the  kernal for iplimit, time, and quota
but iam able to use only iplimit command,
but rest other  giving problem that /lib/iptables/*.so   not found when
excute the time and quota command

any one help will be appriciated

thanks
hare

poptop connection problem

[Sundaram Ramasamy]

Hi,

I am trying setup poptop VPN server on my firewall machine.

eth0 - internet IP
eth1 - LAN IP (192.168.1.1)

from inside my LAN I was able to make the connection, from outside I was not
able to make the connection.

tcpdump -i eth0 proto 47 or port 1723
the above command not showing any  information.

my iptables command:
iptables -A INPUT -i eth0 -p tcp --dport 1763 -j ACCEPT
iptables -A INPUT -i eth0 -p 47 -j ACCEPT

Any help
Thanks
SR

lsmod output:

# lsmod
Module                  Size  Used by    Tainted: P
ppp_async               8128   0
ppp_mppe               25120   0
ppp_generic            24076   0  [ppp_async ppp_mppe]
slhc                    6348   0  [ppp_generic]
iptable_filter          2624   1  (autoclean)
ipt_MASQUERADE          2816   1
ipt_state               1408   2
ipt_REJECT              3872   3
ipt_LOG                 4608   9
ip_nat_h323             4352   0  (unused)
ip_conntrack_h323       4352   1  [ip_nat_h323]
ip_nat_ftp              4640   0  (unused)

Re: poptop connection problem

[Antony Stone]

On Thursday 24 October 2002 7:17 pm, Sundaram Ramasamy wrote:

> Hi,
>
> I am trying setup poptop VPN server on my firewall machine.
>
> eth0 - internet IP
> eth1 - LAN IP (192.168.1.1)
>
> from inside my LAN I was able to make the connection, from outside I was
> not able to make the connection.
>
> tcpdump -i eth0 proto 47 or port 1723
> the above command not showing any  information.
>
> my iptables command:
> iptables -A INPUT -i eth0 -p tcp --dport 1763 -j ACCEPT
> iptables -A INPUT -i eth0 -p 47 -j ACCEPT

What packets are you allowing out ?

Try adding a rule at the end of your INPUT chain just before the default DROP 
to LOG any packets which aren't being accepted to see if you need any extra 
rules.

The fact that it worked from the inside but it doesn't work from the outside 
means that (a) it can be made to work, (b) the problem, if it's with 
netfilter, must be in a rule which specifies the interface or the source 
address, and (c) you can easily capture a working session from the inside to 
see what protocols / ports it does need, to make sure they are allowed from 
the outside.

Are you sure that your ISP doesn't block the ports or protocols needed to 
make this work externally ?

Antony.

-- 

What is this talk of software 'release' ?
Our software evolves and matures until it becomes capable of escape,
leaving a bloody trail of designers and quality assurance people in its wake.

Re: poptop connection problem

[Cedric Blancher]

Le jeu 24/10/2002 à 20:17, Sundaram Ramasamy a écrit :
> tcpdump -i eth0 proto 47 or port 1723
> the above command not showing any  information. 
> my iptables command:
> iptables -A INPUT -i eth0 -p tcp --dport 1763 -j ACCEPT
> iptables -A INPUT -i eth0 -p 47 -j ACCEPT

There's a typo here !

iptables -A INPUT -i eth0 -p tcp --dport 1723 -j ACCEPT
					 ^^^^

-- 
Cédric Blancher  <blancher@cartel-securite.fr>
Consultant en sécurité des systèmes et réseaux  - Cartel Sécurité
Tél: +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE