Re: Iptables problem

Re: Iptables problem

[Antony Stone]

On Friday 21 June 2002 3:40 pm, Paulo Andre wrote:

> I have the following setup.
>
>   <fw1>		<fw2>
> 	\		/
> 	 \	     /
> 	<gateway_fw>
>
>
> 	    <LAN>
>
> All the machines above run linux. The gw uses fw1 as default gw. fw2 has to
> be not set up(second isp).
> I have fw1 and gw working fine. We will be accessed from fw1 and fw2. I
> dont NAT coming in, so when a request comes in from fw2 then reply takes
> fw1 route back out.
> How can I fix this...any suggestions...????

Er, sorry - what is the problem ?   What's not working ?

 

Antony.

Re: Iptables problem

[Antony Stone]

On Monday 24 June 2002 3:12 pm, Paulo Andre wrote:

> My problem is this...
> A http request comes in on fw2 ip 196.25.31.195 DNAT's to server on lan
> 172.1.1.1
> I can pick up the packet all the way to server and back until it comes to
> fw1 ip 196.41.197.34, src=172.17.1.1 dst="pc requesting".
> But the people on the outside can not see the web page.
> Will the requesting pc have a problem if it requests a page from one ip and
> gets a reply from another...????

Yes, it definitely will.

I think your problem is that you have two firewalls, and you are DNATting 
packets on one of them, and then sending the replies back out through the 
other one, which of course does not do the corresponding "reverse" SNAT on 
the reply.

You need to make sure that your route to the Internet (from the web server) 
points to the machine which accepts the incoming requests (ie the one with 
the public address on it).

 

Antony.

Re: Iptables problem

[Antony Stone]

On Monday 24 June 2002 3:45 pm, Paulo Andre wrote:

> Will I have to set up iproute2 for that, my gateway uses fw1 as default gw,
> how else would I be able to allow specific ports to use fw2 as gateway to
> world...???

iproute2 might be able to do this for you - I'm not an expert.

Why not just set up the default route on the server to point to the firewall 
whcih has the public address on it ?

Then your requests come in through a firewall, get NATted to the server, the 
server sends the replies back through the same firewall, and the reverse NAT 
gets done.

The fact that you have another firewall on your network, bringing in other 
connections to your LAN (or allowing them out), is neither here nor there.


 

Antony.

Iptables problem

[Paulo Andre]

I have the following setup.

<fw1>		<fw2>
   \		/
    \	     /
  <gateway_fw>
	  |
	  |
	<LAN>


My problem is this...
A request comes in on fw2 DNAT's to server on LAN. The gw_fw uses fw1 as a
gateway.
What would be the best way to fix this. Should I get a routing protocol with
iproute2...???
Should I add an extra network card to fw1 and then do away with fw2...???
Any suggestions / help..???


Paulo Andre

Re: Iptables problem

[Ramin Alidousti]

On Tue, Jun 25, 2002 at 12:47:04PM +0200, Paulo Andre wrote:

> I have the following setup.
> 
> <fw1>		<fw2>
>    \		/
>     \	     /
>   <gateway_fw>
> 	  |
> 	  |
> 	<LAN>
> 
> 
> My problem is this...
> A request comes in on fw2 DNAT's to server on LAN. The gw_fw uses fw1 as a
> gateway.
> What would be the best way to fix this. Should I get a routing protocol with
> iproute2...???
> Should I add an extra network card to fw1 and then do away with fw2...???
> Any suggestions / help..???

My suggestion would be to replace fw1, fw2 and gateway_fw with one fw with
three nics.

Ramin

> 
> 
> Paulo Andre
> 
> 
> 

RE: Iptables problem

[Paulo Andre]

Sorry, I didn't mention it, but there is a three 'dmz' between gw_fw and
fw1/2
Thanks

Paulo Andre



-----Original Message-----
From: Ramin Alidousti [mailto:ramin@cannon.eng.us.uu.net]
Sent: 25 June 2002 13:52
To: Paulo Andre
Cc: Netfilter (E-mail)
Subject: Re: Iptables problem


On Tue, Jun 25, 2002 at 12:47:04PM +0200, Paulo Andre wrote:

> I have the following setup.
> 
> <fw1>		<fw2>
>    \		/
>     \	     /
>   <gateway_fw>
> 	  |
> 	  |
> 	<LAN>
> 
> 
> My problem is this...
> A request comes in on fw2 DNAT's to server on LAN. The gw_fw uses fw1 as a
> gateway.
> What would be the best way to fix this. Should I get a routing protocol
with
> iproute2...???
> Should I add an extra network card to fw1 and then do away with fw2...???
> Any suggestions / help..???

My suggestion would be to replace fw1, fw2 and gateway_fw with one fw with
three nics.

Ramin

> 
> 
> Paulo Andre
> 
> 
> 

Re: Iptables problem

[Ramin Alidousti]

On Tue, Jun 25, 2002 at 01:55:10PM +0200, Paulo Andre wrote:

> Sorry, I didn't mention it, but there is a three 'dmz' between gw_fw and
> fw1/2

OK. In that case you'll need one fw with four nics.

Ramin

> Thanks
> 
> Paulo Andre

IPTables Problem

[Niel Harper]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

I have IPTables version 1.2.6a running on my VPN (FreeS/Wan 1.98b) gateway.  
I have configured (or so I thought) it to accept incoming and outgoing 
IPSEC, ESP, and AH traffic.  When I try to connect from my remote client, I 
keep getting a "not permitted" error.  Could someone please check my 
iptables chains and tell me exactly what I'm doing wrong.  The IPTables list 
is attached to this document as a text file.

Niel Harper, CISA
Information Security Engineer
Institute of Electrical and Electronic Engineers
IEEE Information Assurance Task Force
Tel: (246) 424-3809
Fax: (246) 425-6076
Email: niel.harper@ieee.org




_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

[-- Attachment #2: iptables.txt --]
[-- Type: text/plain, Size: 9611 bytes --]

Chain INPUT (policy DROP)
target     prot opt source               destination
loopback_in  all  --  anywhere             anywhere
interface0_in  all  --  anywhere             anywhere
ACCEPT     udp  --  anywhere             anywhere           udp spt:isakmp 
dpt:isakmp
ACCEPT     ipv6-crypt--  anywhere             anywhere
ACCEPT     ipv6-auth--  anywhere             anywhere
LOG        all  --  anywhere             anywhere           LOG level 
warning prefix `giptables-end-of-firewall: '

Chain FORWARD (policy DROP)
target     prot opt source               destination
LOG        all  --  anywhere             anywhere           LOG level 
warning prefix `giptables-end-of-firewall: '

Chain OUTPUT (policy DROP)
target     prot opt source               destination
loopback_out  all  --  anywhere             anywhere
interface0_out  all  --  anywhere             anywhere
ACCEPT     udp  --  anywhere             anywhere           udp spt:isakmp 
dpt:isakmp
ACCEPT     ipv6-crypt--  anywhere             anywhere
ACCEPT     ipv6-auth--  anywhere             anywhere
ACCEPT     all  --  192.168.10.1         localhost.localdomain
LOG        all  --  anywhere             anywhere           LOG level 
warning prefix `giptables-end-of-firewall: '

Chain interface0_in (1 references)
target     prot opt source               destination
syn_flood_interface0_in  tcp  --  anywhere             anywhere           
tcp flags:SYN,RST,ACK/SYN
LOG        tcp  --  anywhere             anywhere           tcp 
flags:!SYN,RST,ACK/SYN state NEW limit: avg 5/min burst 7 LOG level warning 
prefix `giptables-new-no-syn: '
DROP       tcp  --  anywhere             anywhere           tcp 
flags:!SYN,RST,ACK/SYN state NEW
LOG        all  -f  anywhere             anywhere           limit: avg 5/min 
burst 7 LOG level warning prefix `giptables-fragments: '
DROP       all  -f  anywhere             anywhere
LOG        tcp  --  anywhere             anywhere           tcp 
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG limit: avg 5/min burst 
7 LOG level warning prefix `giptables-malformed-xmas: '
DROP       tcp  --  anywhere             anywhere           tcp 
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG
LOG        tcp  --  anywhere             anywhere           tcp 
flags:FIN,SYN,RST,PSH,ACK,URG/NONE limit: avg 5/min burst 7 LOG level 
warning prefix `giptables-malformed-null: '
DROP       tcp  --  anywhere             anywhere           tcp 
flags:FIN,SYN,RST,PSH,ACK,URG/NONE
LOG        all  --  192.168.10.2         anywhere           limit: avg 5/min 
burst 7 LOG level warning prefix `giptables-drop-src-spoof: '
DROP       all  --  192.168.10.2         anywhere
LOG        all  --  0.0.0.0/8            anywhere           limit: avg 5/min 
burst 7 LOG level warning prefix `giptables-drop-src-spoof: '
DROP       all  --  0.0.0.0/8            anywhere
LOG        all  --  127.0.0.0/8          anywhere           limit: avg 5/min 
burst 7 LOG level warning prefix `giptables-drop-src-spoof: '
DROP       all  --  127.0.0.0/8          anywhere
LOG        all  --  10.0.0.0/8           anywhere           limit: avg 5/min 
burst 7 LOG level warning prefix `giptables-drop-src-spoof: '
DROP       all  --  10.0.0.0/8           anywhere
LOG        all  --  172.16.0.0/12        anywhere           limit: avg 5/min 
burst 7 LOG level warning prefix `giptables-drop-src-spoof: '
DROP       all  --  172.16.0.0/12        anywhere
LOG        all  --  192.168.0.0/16       anywhere           limit: avg 5/min 
burst 7 LOG level warning prefix `giptables-drop-src-spoof: '
DROP       all  --  192.168.0.0/16       anywhere
LOG        all  --  224.0.0.0/3          anywhere           limit: avg 5/min 
burst 7 LOG level warning prefix `giptables-drop-src-spoof: '
DROP       all  --  224.0.0.0/3          anywhere
ACCEPT     udp  --  205.214.192.201      192.168.10.2       udp spt:domain 
dpts:1024:65535 state ESTABLISHED
ACCEPT     tcp  --  205.214.192.201      192.168.10.2       tcp spt:domain 
dpts:1024:65535 state ESTABLISHED
ACCEPT     udp  --  205.214.192.202      192.168.10.2       udp spt:domain 
dpts:1024:65535 state ESTABLISHED
ACCEPT     tcp  --  205.214.192.202      192.168.10.2       tcp spt:domain 
dpts:1024:65535 state ESTABLISHED
ACCEPT     tcp  --  anywhere             192.168.10.2       tcp spt:ftp 
dpts:1024:65535 state ESTABLISHED
ACCEPT     tcp  --  anywhere             192.168.10.2       tcp 
spts:1024:65535 dpts:1024:65535 state ESTABLISHED
ACCEPT     tcp  --  anywhere             192.168.10.2       tcp 
spts:1024:65535 dpt:ftp state NEW,ESTABLISHED
ACCEPT     tcp  --  anywhere             192.168.10.2       tcp 
spts:1024:65535 dpts:1024:65535 state RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             192.168.10.2       tcp 
spts:1024:65535 dpt:ftp-data state ESTABLISHED
ACCEPT     tcp  --  anywhere             192.168.10.2       tcp spt:ssh 
dpts:login:65535 state ESTABLISHED
ACCEPT     tcp  --  anywhere             192.168.10.2       tcp 
spts:login:65535 dpt:ssh state NEW,ESTABLISHED
ACCEPT     tcp  --  anywhere             192.168.10.2       tcp spt:telnet 
dpts:1024:65535 state ESTABLISHED
ACCEPT     tcp  --  anywhere             192.168.10.2       tcp spt:smtp 
dpts:1024:65535 state ESTABLISHED
ACCEPT     tcp  --  anywhere             192.168.10.2       tcp 
spts:1024:65535 dpt:smtp state NEW,ESTABLISHED
ACCEPT     tcp  --  anywhere             192.168.10.2       tcp spt:pop3 
dpts:1024:65535 state ESTABLISHED
ACCEPT     tcp  --  anywhere             192.168.10.2       tcp spt:imap 
dpts:1024:65535 state ESTABLISHED
ACCEPT     tcp  --  anywhere             192.168.10.2       tcp spt:http 
dpts:1024:65535 state ESTABLISHED
ACCEPT     tcp  --  anywhere             192.168.10.2       tcp spt:https 
dpts:1024:65535 state ESTABLISHED
ACCEPT     tcp  --  anywhere             192.168.10.2       tcp spt:webcache 
dpts:1024:65535 state ESTABLISHED
ACCEPT     tcp  --  anywhere             192.168.10.2       tcp spt:nntp 
dpts:1024:65535 state ESTABLISHED
ACCEPT     udp  --  anywhere             192.168.10.2       udp spt:ldap 
dpts:1024:65535 state ESTABLISHED
ACCEPT     icmp --  anywhere             192.168.10.2       state 
RELATED,ESTABLISHED
LOG        all  --  anywhere             anywhere           limit: avg 5/min 
burst 7 LOG level warning prefix `giptables-drop-src-norule: '
DROP       all  --  anywhere             anywhere

Chain interface0_out (1 references)
target     prot opt source               destination
ACCEPT     udp  --  192.168.10.2         205.214.192.201    udp 
spts:1024:65535 dpt:domain state NEW,ESTABLISHED
ACCEPT     tcp  --  192.168.10.2         205.214.192.201    tcp 
spts:1024:65535 dpt:domain state NEW,ESTABLISHED
ACCEPT     udp  --  192.168.10.2         205.214.192.202    udp 
spts:1024:65535 dpt:domain state NEW,ESTABLISHED
ACCEPT     tcp  --  192.168.10.2         205.214.192.202    tcp 
spts:1024:65535 dpt:domain state NEW,ESTABLISHED
ACCEPT     tcp  --  192.168.10.2         anywhere           tcp 
spts:1024:65535 dpt:ftp state NEW,ESTABLISHED
ACCEPT     tcp  --  192.168.10.2         anywhere           tcp 
spts:1024:65535 dpts:1024:65535 state RELATED,ESTABLISHED
ACCEPT     tcp  --  192.168.10.2         anywhere           tcp spt:ftp 
dpts:1024:65535 state ESTABLISHED
ACCEPT     tcp  --  192.168.10.2         anywhere           tcp 
spts:1024:65535 dpts:1024:65535 state ESTABLISHED
ACCEPT     tcp  --  192.168.10.2         anywhere           tcp spt:ftp-data 
dpts:1024:65535 state RELATED,ESTABLISHED
ACCEPT     tcp  --  192.168.10.2         anywhere           tcp 
spts:login:65535 dpt:ssh state NEW,ESTABLISHED
ACCEPT     tcp  --  192.168.10.2         anywhere           tcp spt:ssh 
dpts:login:65535 state ESTABLISHED
ACCEPT     tcp  --  192.168.10.2         anywhere           tcp 
spts:1024:65535 dpt:telnet state NEW,ESTABLISHED
ACCEPT     tcp  --  192.168.10.2         anywhere           tcp 
spts:1024:65535 dpt:smtp state NEW,ESTABLISHED
ACCEPT     tcp  --  192.168.10.2         anywhere           tcp spt:smtp 
dpts:1024:65535 state ESTABLISHED
ACCEPT     tcp  --  192.168.10.2         anywhere           tcp 
spts:1024:65535 dpt:pop3 state NEW,ESTABLISHED
ACCEPT     tcp  --  192.168.10.2         anywhere           tcp 
spts:1024:65535 dpt:imap state NEW,ESTABLISHED
ACCEPT     tcp  --  192.168.10.2         anywhere           tcp 
spts:1024:65535 dpt:http state NEW,ESTABLISHED
ACCEPT     tcp  --  192.168.10.2         anywhere           tcp 
spts:1024:65535 dpt:https state NEW,ESTABLISHED
ACCEPT     tcp  --  192.168.10.2         anywhere           tcp 
spts:1024:65535 dpt:webcache state NEW,ESTABLISHED
ACCEPT     tcp  --  192.168.10.2         anywhere           tcp 
spts:1024:65535 dpt:nntp state NEW,ESTABLISHED
ACCEPT     udp  --  192.168.10.2         anywhere           udp 
spts:1024:65535 dpt:ldap state NEW,ESTABLISHED
ACCEPT     udp  --  192.168.10.2         anywhere           udp 
spts:1024:65535 dpts:traceroute:33523 state NEW
ACCEPT     icmp --  192.168.10.2         anywhere           state 
NEW,RELATED,ESTABLISHED

Chain loopback_in (1 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere

Chain loopback_out (1 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere

Chain syn_flood_interface0_in (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere           limit: avg 1/sec 
burst 3
DROP       all  --  anywhere             anywhere

iptables problem

[김도균]

[-- Attachment #1: Type: text/plain, Size: 304 bytes --]

hi.
I am unskilled english. just understand my mail.

my box : kernel 2.4.18, iptables 1.2.5

i am serching ip_masq_h323 for kernel 2.4.18 but it is too hard to find.

because, in my NAT, I want to use VoIP(Voice over IP).

How to get h323 module or source for iptables 1.2.5 or later?





[-- Attachment #2: Type: text/html, Size: 1130 bytes --]

IPtables Problem

[Amit Kumar Gupta]

[-- Attachment #1.1: Type: text/plain, Size: 141 bytes --]

Hi List,
 
Can somebody tell me what are all possible ways using IPTables to detect
malicious activities?
 
Thanks & Regards,
Amit
 

[-- Attachment #1.2: Type: text/html, Size: 3649 bytes --]

[-- Attachment #2: Wipro_Disclaimer.txt --]
[-- Type: text/plain, Size: 514 bytes --]

**************************Disclaimer************************************************

Information contained in this E-MAIL being proprietary to Wipro Limited is 
'privileged' and 'confidential' and intended for use only by the individual
 or entity to which it is addressed. You are notified that any use, copying 
or dissemination of the information contained in the E-MAIL in any manner 
whatsoever is strictly prohibited.

***************************************************************************************

Re: iptables problem

[Raymond Leach]

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]

On Wed, 2002-11-27 at 05:26, 김도균 wrote:
> hi.
> I am unskilled english. just understand my mail.
>  
> my box : kernel 2.4.18, iptables 1.2.5
>  
> i am serching ip_masq_h323 for kernel 2.4.18 but it is too hard to
> find.
>  
> because, in my NAT, I want to use VoIP(Voice over IP).
>  
> How to get h323 module or source for iptables 1.2.5 or later?
For iptables try http://www.netfilter.org
>  
>  
>  
>  
>  
-- 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(  Raymond Leach                       )
 ) Knowledge Factory                  (
(                                      )
 ) Tel: +27 11 445 8100               (
(  Fax: +27 11 445 8101                )
 )                                    (
(  http://www.knowledgefactory.co.za/  )
 ) http://www.saptg.co.za/            (
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   o                                o
    o                              o
        .--.                  .--.
       | o_o|                |o_o |
       | \_:|                |:_/ |
      / /   \\              //   \ \
     ( |     |)            (|     | )
     /`\_   _/'\          /'\_   _/`\
     \___)=(___/          \___)=(___/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: iptables problem

[Diego Sarasua]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

http://roeder.goe.net/~koepi/newnat.html
:D
i hope it was wath U need
  ----- Original Message ----- 
  From: 김도균 
  To: netfilter@lists.netfilter.org 
  Sent: Wednesday, November 27, 2002 12:26 AM
  Subject: iptables problem 


  hi.
  I am unskilled english. just understand my mail.

  my box : kernel 2.4.18, iptables 1.2.5

  i am serching ip_masq_h323 for kernel 2.4.18 but it is too hard to find.

  because, in my NAT, I want to use VoIP(Voice over IP).

  How to get h323 module or source for iptables 1.2.5 or later?






[-- Attachment #2: Type: text/html, Size: 2198 bytes --]

Iptables problem

[De Jager Laubscher]

[-- Attachment #1: Type: text/plain, Size: 132 bytes --]

Can anyonne please tell me how to open port 1500 to 1511 on my NAT box using iptable on slackeware ??

please help very urgent !

[-- Attachment #2: Type: text/html, Size: 542 bytes --]

Re: Iptables problem

[Maciej Soltysiak]

> Can anyonne please tell me how to open port 1500 to 1511 on my NAT box
> using iptable on slackeware ??
You have not written what do you want precisely, so i will give a few
examples. But PLEASE READ THE HOWTO, it is very informative. It is vital
to know how it all works.
I will assume TCP.
If you want to open these ports _to_ the NAT box use:
# iptables -A INPUT -p tcp --dport 1500:1511 -j ACCEPT

If you want to NAT these ports do:
# iptables -t nat -A PREROUTING -i $EXT -p tcp --dport 1500 -j DNAT \
	--to x.y.z.a

Remember that if doing 1:1 NAT requiers a similar rule for SNAT on
POSTROUTING.

If you want to NAT and change the ports do:
# iptables -t nat -A PREROUTING -i $EXT -p tcp --dport 1500 -j DNAT \
	--to x.y.z.a:other_port

of course read also:
# iptables -j DNAT --help
# iptables -j SNAT --help
# iptables -p tcp --help

Regards,
Maciej Soltysiak

iptables problem

[hare ram]

Hi

i have installed iptables 1.2.8a in RH 9.0
and installed POM tooo
when i do

[root@ root]# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j
REDIRECT --to-port 3128
iptables: Invalid argument

what is wrong
i dont see any problem, but iam getting this error
what could be the problem

hare

Re: iptables problem

[Guilherme Viebig]

Change REDIRECT to DNAT
----- Original Message ----- 
From: "hare ram" <hareram@sol.net.in>
To: <netfilter@lists.samba.org>
Sent: Tuesday, May 13, 2003 12:13 PM
Subject: iptables problem


> Hi
> 
> i have installed iptables 1.2.8a in RH 9.0
> and installed POM tooo
> when i do
> 
> [root@ root]# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j
> REDIRECT --to-port 3128
> iptables: Invalid argument
> 
> what is wrong
> i dont see any problem, but iam getting this error
> what could be the problem
> 
> hare
> 
> 
> 

Re: iptables problem

[hare ram]

still same problem

hare
----- Original Message -----
From: "Guilherme Viebig" <guilherme@plannercorretora.com.br>
To: <netfilter@lists.samba.org>
Sent: Tuesday, May 13, 2003 10:32 PM
Subject: Re: iptables problem


> Change REDIRECT to DNAT
> ----- Original Message -----
> From: "hare ram" <hareram@sol.net.in>
> To: <netfilter@lists.samba.org>
> Sent: Tuesday, May 13, 2003 12:13 PM
> Subject: iptables problem
>
>
> > Hi
> >
> > i have installed iptables 1.2.8a in RH 9.0
> > and installed POM tooo
> > when i do
> >
> > [root@ root]# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j
> > REDIRECT --to-port 3128
> > iptables: Invalid argument
> >
> > what is wrong
> > i dont see any problem, but iam getting this error
> > what could be the problem
> >
> > hare
> >
> >
> >
>
>
>

Re: iptables problem

[Bikrant Neupane]

If you are trying to redirect web traffic  to squid proxy then you can try
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 
a.b.c.d:3128

Replace PREROUTING with OUTPUT if you are trying to redirect traffice 
originating from the same machine where you want the redirect to take 
place.

regards,
Bikrant

hare ram wrote:

>still same problem
>
>hare
>----- Original Message -----
>From: "Guilherme Viebig" <guilherme@plannercorretora.com.br>
>To: <netfilter@lists.samba.org>
>Sent: Tuesday, May 13, 2003 10:32 PM
>Subject: Re: iptables problem
>
>
>  
>
>>Change REDIRECT to DNAT
>>----- Original Message -----
>>From: "hare ram" <hareram@sol.net.in>
>>To: <netfilter@lists.samba.org>
>>Sent: Tuesday, May 13, 2003 12:13 PM
>>Subject: iptables problem
>>
>>
>>    
>>
>>>Hi
>>>
>>>i have installed iptables 1.2.8a in RH 9.0
>>>and installed POM tooo
>>>when i do
>>>
>>>[root@ root]# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j
>>>REDIRECT --to-port 3128
>>>iptables: Invalid argument
>>>
>>>what is wrong
>>>i dont see any problem, but iam getting this error
>>>what could be the problem
>>>
>>>hare
>>>
>>>
>>>
>>>      
>>>
>>
>>    
>>
>
>
>
>
>  
>

IPTables problem

[Tech]

Hopefully someone can help..please.

I have been using a rc.firewall script for quite sometime but now I have
upgraded my system to one way satellite. The problem I am having is that
most scripts are written with one internet interface. What I require is a
script that is capable of two.
The satellite brings in all data and all requests go out via the modem. I
also have an internal network that needs to be able to surf and collect
mail.

Has anyone had experience with this type of setup.
Any advice would be appreciated.

Michael

-- 
Did you know that if you play a Windows 2000 cd backwards, you will hear
the voice of Satan?

Iptables problem

[Glenn Hancock]

[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]

I have the following setup in my /etc/sysconfig/iptables file.  I start
the iptables service and do a --list and see all my rules.  I can attach
to the computer from outside so I know that the incoming rules work,
however, I can not perform any outgoing tasks.  No pings, no ssh no
nothing.

Can someone please explain why this is not working?

*filter
-A INPUT -p tcp --dport 110 --syn -j ACCEPT
-A INPUT -p tcp --dport 42 --syn -j ACCEPT
-A INPUT -p tcp --dport 7777 --syn -j ACCEPT
-A INPUT -p tcp --dport 7775 --syn -j ACCEPT
-A INPUT -p tcp --dport 22 --syn -j ACCEPT
-A INPUT -p tcp --dport 80 --syn -j ACCEPT
-A INPUT -p udp --dport 53 -j ACCEPT
-A INPUT -p udp --dport 42 -j ACCEPT
-A INPUT -p tcp --syn -j REJECT
-A INPUT -p udp -j REJECT
COMMIT


Thanks,

-- 
Glenn Hancock
SofTek Software International, Inc.
813 Pavilion Court
T: 678-583-5720
I: ghancock@softeksoftware.com
www.softeksoftware.com
www.Spambite.com
NOTE: My email address is currently protected by Spambite. If
you send me an email, you will be asked to validate your email
address on the Spambite network AND re-send you original email
to me. Or, you can pro-actively register your email address on
the Spambite network by visiting the website:
www.spambite.com
When visiting the website, please feel free to look around to
learn about this exciting new technology.

[-- Attachment #2: Type: text/html, Size: 1763 bytes --]

RE: Iptables problem

[Rob Sterenborg]

> all my rules.  I can attach to the computer from outside so I 
> know that the incoming rules work, however, I can not perform 
> any outgoing tasks.  No pings, no ssh no nothing.
> 
> Can someone please explain why this is not working?
> 
> *filter
> -A INPUT -p tcp --dport 110 --syn -j ACCEPT
> -A INPUT -p tcp --dport 42 --syn -j ACCEPT
> -A INPUT -p tcp --dport 7777 --syn -j ACCEPT
> -A INPUT -p tcp --dport 7775 --syn -j ACCEPT
> -A INPUT -p tcp --dport 22 --syn -j ACCEPT
> -A INPUT -p tcp --dport 80 --syn -j ACCEPT
> -A INPUT -p udp --dport 53 -j ACCEPT
> -A INPUT -p udp --dport 42 -j ACCEPT
> -A INPUT -p tcp --syn -j REJECT
> -A INPUT -p udp -j REJECT
> COMMIT

Is this rule-set complete ?

If it is, I see no rule like :
# iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
Which might help to accept incoming packets that are a reply of an
outgoing packet.

If it isn't, it could be that you have set policy to DROP for the OUTPUT
chain and have to ACCEPT rules for the OUTPUT chain : netfilter will not
let any (locally generated) packets out.
To check : if you start the service, type :
# iptables -P OUTPUT ACCEPT
and then try to ping or something.


Gr,
Rob

Iptables problem

[Marcelo Sinhorini]

I use slackware 9.0. I have made the upgrade to the lastest iptables, and now i want to compile the 2.4.27 kernel and enable nat of pptp. I applied the path-o-matic and actvated the option for it. After compile the kernel, almost everything is funcional, but the targets MASQUERADE and SNAT had a problem.. Show an error: Invalid argument. They are Modules and are loaded at the kernel. A frind had the same problem doing the same thing I wanted to do!

Anyone knows what can i do ?


Marcelo

RE: Iptables problem

[Jason Opperisano]

> I use slackware 9.0. I have made the upgrade to the lastest iptables, and nowi want to compile the 2.4.27 kernel and enable nat of pptp. I applied the path-o-matic and actvated the option for it. After compile the kernel, almost everything is funcional, but the targets MASQUERADE and SNAT had a problem.. Show an error: Invalid argument. They are Modules and are loaded at the kernel. A frind had the same problem doing the same thing I wanted to do!
>
> Anyone knows what can i do ?
>
>
> Marcelo

i can tell you "what" you need to do, but i learned this morning that i can't necessarily tell you "how" to do it.

what:  you need to rebuild your userspace "iptables" utility.  the error you're seeing is what happens when you apply patches to the kernel that change the internal structures of netfilter.  in order to interact with the new kernel, you need to compile a new iptables command against that patched kernel source.

this is normally as simple as:

cd /usr/local/src/iptables-x.x.x
make KERNEL_DIR=<<where-you-built-your-kernel>>
make install KERNEL_DIR=<<where-you-built-your-kernel>>

i can only assume that your friend is Paulo Andre, and this is apparently more complicated than i realize.

-j

Re: Iptables problem

[Jose Maria Lopez]

El mié, 25 de 08 de 2004 a las 21:52, Marcelo Sinhorini escribió:
> I use slackware 9.0. I have made the upgrade to the lastest iptables, and now i want to compile the 2.4.27 kernel and enable nat of pptp. I applied the path-o-matic and actvated the option for it. After compile the kernel, almost everything is funcional, but the targets MASQUERADE and SNAT had a problem.. Show an error: Invalid argument. They are Modules and are loaded at the kernel. A frind had the same problem doing the same thing I wanted to do!
> 
> Anyone knows what can i do ?
> 
> 
> Marcelo

Have you applied the p-o-m to the iptables sources and recompiled
it? You must do it if you want to have the new modules working,
maybe that it's the problem.
 
-- 
Jose Maria Lopez Hernandez
Director Tecnico de bgSEC
jkerouac@bgsec.com
bgSEC Seguridad y Consultoria de Sistemas Informaticos
http://www.bgsec.com
ESPAÑA

The only people for me are the mad ones -- the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn, burn
like fabulous yellow Roman candles.
                -- Jack Kerouac, "On the Road"

iptables problem

[Ashley M. Kirchner]

    I have three machines on our private network that need unrestricted 
access to and from FTP.  These are little photo kiosks that periodically 
connect to the master service machine elsewhere through ftp to send 
files and then receives information back.

    The machine running iptables has eth0 with our public ip and eth2 
with the internal (192.168.x.x) ip (where the three machines are on.) 

    Help anyone?

Re: iptables problem

[Buddy wu]

what's your problem or what do you mean?

2005/11/2, Ashley M. Kirchner <ashley@pcraft.com>:
>
>     I have three machines on our private network that need unrestricted
> access to and from FTP.  These are little photo kiosks that periodically
> connect to the master service machine elsewhere through ftp to send
> files and then receives information back.
>
>     The machine running iptables has eth0 with our public ip and eth2
> with the internal (192.168.x.x) ip (where the three machines are on.)
>
>     Help anyone?
>
>
>

Re: Re: iptables problem

[Ashley M. Kirchner]

Buddy wu wrote:

>what's your problem or what do you mean?
>  
>
    Problem is that while they can connect OUT, nothing from the outside 
can connect to them.

-- 
H | I haven't lost my mind; it's backed up on tape somewhere.
  +--------------------------------------------------------------------
  Ashley M. Kirchner <mailto:ashley@pcraft.com>   .   303.442.6410 x130
  IT Director / SysAdmin / WebSmith             .     800.441.3873 x130
  Photo Craft Imaging                       .     3550 Arapahoe Ave. #6
  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A. 

Re: Re: iptables problem

[Buddy wu]

>     Problem is that while they can connect OUT, nothing from the outside
> can connect to them.

I think you should load the ip_nat_ftp and ip_conntrack_ftp moudles.
do you load them?

RE: Re: iptables problem

[Rob Sterenborg]

>> what's your problem or what do you mean?
>> 
>> 
>     Problem is that while they can connect OUT, nothing from
> the outside can connect to them.

If you don't let us know what you have already done, we don't know
what's wrong.


Gr,
Rob

Re: Re: iptables problem

[Nikolai Georgiev]

Ashley M. Kirchner wrote:

> Buddy wu wrote:
>
>> what's your problem or what do you mean?
>>  
>>
>    Problem is that while they can connect OUT, nothing from the
> outside can connect to them.
>
Hello there, i think this should do
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT --dst $YOUR_IP -m state --state ESTABLISHED,RELATED -j
ACCEPT
iptables -A OUTPUT --src $YOUR_IP -m state --state
NEW,ESTABLISHED,RELATED -j ACCEPT

Re: Re: iptables problem

[Rob Sterenborg]

On Wed, November 2, 2005 08:20, Nikolai Georgiev wrote:
>>    Problem is that while they can connect OUT, nothing from the
>> outside can connect to them.
>>
> Hello there, i think this should do
> iptables -P INPUT DROP
> iptables -P OUTPUT DROP
> iptables -A INPUT --dst $YOUR_IP -m state --state ESTABLISHED,RELATED
> -j ACCEPT
> iptables -A OUTPUT --src $YOUR_IP -m state --state
> NEW,ESTABLISHED,RELATED -j ACCEPT

The INPUT and OUTPUT chains are for local traffic.
These kiosk hosts are probably *behind* iptables, so traffic will
travel through the FORWARD chain.

If you need external connections forwarded to hosts behind the
firewall, you need DNAT rules to make it happen.

In this case, the OP has 3 hosts to wich he wants to connect ("nothing
from the outside can connect to them", outgoing connections are
already working).
FTP only uses port 21/tcp (and 20). It's to my knowledge not possible
to forward 1 port to 3 hosts simultaneously (if that would do any
good), so he'll need to assign different ports for the second and
third host.
Something like :
21/tcp -> host 1
41/tcp -> host 2
61/tcp -> host 3
(if these ports are free).


Gr,
Rob

Re: Re: iptables problem

[Ashley M. Kirchner]

Rob Sterenborg wrote:

>The INPUT and OUTPUT chains are for local traffic.
>These kiosk hosts are probably *behind* iptables, so traffic will
>travel through the FORWARD chain.
>
>If you need external connections forwarded to hosts behind the
>firewall, you need DNAT rules to make it happen.
>  
>
    Yes, the kiosks are behind the firewall (iptables) and need 
unrestricted access to and from the internet, but only for FTP.

>In this case, the OP has 3 hosts to wich he wants to connect ("nothing
>from the outside can connect to them", outgoing connections are
>already working).
>FTP only uses port 21/tcp (and 20). It's to my knowledge not possible
>to forward 1 port to 3 hosts simultaneously (if that would do any
>good), so he'll need to assign different ports for the second and
>third host.
>Something like :
>21/tcp -> host 1
>41/tcp -> host 2
>61/tcp -> host 3
>(if these ports are free).
>  
>
    All right, so this is what I currently have in my iptables rules:

-A PREROUTING -i eth0 -p tcp -m tcp --dport 21 -j DNAT --to-destination 
192.168.1.xxx
-A PREROUTING -i eth0 -p tcp -m tcp --dport 20 -j DNAT --to-destination 
192.168.1.xxx

    ...and further down:

-A FORWARD -i eth0 -o eth2 -p tcp -m state --state NEW -m tcp --dport 21 
--tcp-flags SYN,RST,ACK SYN -j ACCEPT
-A FORWARD -i eth0 -o eth2 -p tcp -m state --state NEW -m tcp --dport 20 
--tcp-flags SYN,RST,ACK SYN -j ACCEPT


    In my logs, I see this:

kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx 
DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1587 DF 
PROTO=TCP SPT=1186 DPT=21 WINDOW=65338 RES=0x00 ACK PSH URGP=0

kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx 
DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1588 DF 
PROTO=TCP SPT=1181 DPT=21 WINDOW=65196 RES=0x00 ACK PSH URGP=0 

kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx 
DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1589 DF 
PROTO=TCP SPT=1184 DPT=21 WINDOW=65338 RES=0x00 ACK PSH URGP=0 


    The other problem is that, while I can change the FTP port on the 
kiosks, I can't change it on the other end (the receiving and sending) 
so I'm not sure how to handle that part.  They will always attempt to 
connect on the standard FTP port, which two of these machines won't be 
listening to since I would've changed them so they don't conflict with 
one another.  Or is that not so?


-- 
W | It's not a bug - it's an undocumented feature.
  +--------------------------------------------------------------------
  Ashley M. Kirchner <mailto:ashley@pcraft.com>   .   303.442.6410 x130
  IT Director / SysAdmin / Websmith             .     800.441.3873 x130
  Photo Craft Laboratories, Inc.            .     3550 Arapahoe Ave. #6
  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A.

RE: Re: iptables problem

[Rob Sterenborg]

>     Yes, the kiosks are behind the firewall (iptables) and need
> unrestricted access to and from the internet, but only for FTP.

...

>     All right, so this is what I currently have in my iptables rules:
> 
> -A PREROUTING -i eth0 -p tcp -m tcp --dport 21 -j DNAT
> --to-destination 192.168.1.xxx
> -A PREROUTING -i eth0 -p tcp -m tcp --dport 20 -j DNAT
> --to-destination 192.168.1.xxx
> 
>     ...and further down:
> 
> -A FORWARD -i eth0 -o eth2 -p tcp -m state --state NEW -m tcp
> --dport 21 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
> -A FORWARD -i eth0 -o eth2 -p tcp -m state --state NEW -m tcp
> --dport 20 --tcp-flags SYN,RST,ACK SYN -j ACCEPT

I assume your FORWARD policy is DROP ?

If you use RELATED,ESTABLISHED, you only need to allow port 21. Port 20
is then RELATED to the connection. So, do you also have (something like)
:
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

You *do* load the ftp conntack helpers, do you ?

>     In my logs, I see this:
> 
> kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx
> DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1587 DF
> PROTO=TCP SPT=1186 DPT=21 WINDOW=65338 RES=0x00 ACK PSH URGP=0
> 
> kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx
> DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1588 DF
> PROTO=TCP SPT=1181 DPT=21 WINDOW=65196 RES=0x00 ACK PSH URGP=0
> 
> kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx
> DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1589 DF
> PROTO=TCP SPT=1184 DPT=21 WINDOW=65338 RES=0x00 ACK PSH URGP=0

This looks like an ACK to me. Not sure why such packet would be in the
NEW state on port 21, where a ftp-client would connect to at first so I
would think it would be in the ESTABLISHED state. (Also not sure what
the logging rule looks like.)
Maybe someone else who has better knowledge of this can help here.

You could skip the tcp-flags at first and see if that works.

>     The other problem is that, while I can change the FTP port on the
> kiosks, I can't change it on the other end (the receiving and sending)
> so I'm not sure how to handle that part.  They will always attempt to
> connect on the standard FTP port, which two of these machines
> won't be listening to since I would've changed them so they don't
> conflict with one another.  Or is that not so?

You don't have to run the ftp service of the kiosk hosts on different
ports : just forward the external ports, let's say (40/)41 and (60/)61,
to ports (20/)21 on the kiosk hosts. But that is no solution to your
problem I suppose, because of the serverside problem.

Maybe you can let the kiosk hosts connect to the server and perform GET
and PUT commands. The server then only has to put the needed updates in
a specific directory where the kiosk hosts can download them from. This
way the hosts themselves don't have to be reachable on the internet
which would be better from a security point of view.


Gr,
Rob

Re: Re: iptables problem

[Ashley M. Kirchner]

>Maybe you can let the kiosk hosts connect to the server and perform GET
>and PUT commands. The server then only has to put the needed updates in
>a specific directory where the kiosk hosts can download them from. This
>way the hosts themselves don't have to be reachable on the internet
>which would be better from a security point of view.
>  
>
    Thanks for the explanation Rob.

    I can't control what happens on the serverside.  That's a third 
party company.  I figured regardless of me being able to forward port 21 
to one of these machines without a problem, I can't do it for all 
three.  So I think I'm screwed either way.  Grrr...

-- 
H | I haven't lost my mind; it's backed up on tape somewhere.
  +--------------------------------------------------------------------
  Ashley M. Kirchner <mailto:ashley@pcraft.com>   .   303.442.6410 x130
  IT Director / SysAdmin / WebSmith             .     800.441.3873 x130
  Photo Craft Imaging                       .     3550 Arapahoe Ave. #6
  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A. 

Re: Re: iptables problem (nfcan: addressed to exclusive sender for this address)

[Jim Laurino]

On 2005.11.03 01:45, Ashley M. Kirchner - ashley@pcraft.com wrote:
> 
>> Maybe you can let the kiosk hosts connect to the server and perform GET
>> and PUT commands. The server then only has to put the needed updates in
>> a specific directory where the kiosk hosts can download them from. This
>> way the hosts themselves don't have to be reachable on the internet
>> which would be better from a security point of view.
>>
>    Thanks for the explanation Rob.
> 
>    I can't control what happens on the serverside.  That's a third party  
> company.  I figured regardless of me being able to forward port 21 to one of  
> these machines without a problem, I can't do it for all three.  So I think  
> I'm screwed either way.  Grrr...

OK, here is how I understand your situation:
Each kiosk must have a distinct identity to the outside service.
A kiosk must play the role of an ftp server.
A server has to listen on a well known port.
The outside system can only use the standard ftp port.
(This does seem a rather inflexible design, but ...)
The only other way to distinguish servers is the IP address.

So, maybe you can get more IP addresses.

Some ISP's allow you to have more than one public IP.
(Sometimes they want a few bucks extra rent :-)

You can arrange to have the firewall in question
respond to 3 IP addresses on the outside interface and
forward the now distinct traffic to the 3 kiosks.
If this is possible, it might be better than being screwed.

HTH

-- 
Jim Laurino
nfcan.x.jimlaur@dfgh.net
Please reply to the list.
Only mail from the listserver reaches this address.

Re: Re: iptables problem (nfcan: addressed to exclusive sender for this address)

[Ashley M. Kirchner]

Jim Laurino wrote:

> You can arrange to have the firewall in question
> respond to 3 IP addresses on the outside interface and
> forward the now distinct traffic to the 3 kiosks.
> If this is possible, it might be better than being screwed.

    That would be nice, but no can do.  Remember, the server end, or 
receiving end, is a third party company.  They have hundreds, if not 
thousands of these little kiosks scattered across the country.  We are 
but a tiny little company with three of those kiosks.  Each kiosk makes 
an outbound FTP connection to the server.  Then the server makes an 
inbound connection back to the kiosk.  This is where it fails because it 
doesn't know where it came from since the kiosks are behind the firewall.

    Putting the kiosks OUTSIDE the firewall (with different IPs) also 
won't work because they also need to communicate (via windows shares) to 
internal machines, again, same scenario...they contact a print station, 
and the print station contacts them.  So you see, being screwed is the 
only option I see here.  Unless I'm overlooking something.

    And I can't tell the other company to send data to separate IPs 
either because their system works based on the packet they first receive 
when the kiosk contacts them.  Which goes back to my point above (about 
putting the kiosks outside the firewall.)

-- 
H | I haven't lost my mind; it's backed up on tape somewhere.
  +--------------------------------------------------------------------
  Ashley M. Kirchner <mailto:ashley@pcraft.com>   .   303.442.6410 x130
  IT Director / SysAdmin / WebSmith             .     800.441.3873 x130
  Photo Craft Imaging                       .     3550 Arapahoe Ave. #6
  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A. 

Re: Re: iptables problem (nfcan: addressed to exclusive sender for this address)

[Sven Schuster]

[-- Attachment #1: Type: text/plain, Size: 1107 bytes --]


Hi Ashley,

On Thu, Nov 03, 2005 at 09:02:58AM -0700, Ashley M. Kirchner told us:
>    And I can't tell the other company to send data to separate IPs 
> either because their system works based on the packet they first receive 
> when the kiosk contacts them.  Which goes back to my point above (about 
> putting the kiosks outside the firewall.)

you say "their" system works based on the packet they first receive
when contacting them. So with multiple IPs, wouldn't it work to let
each kiosk contact the server via its own IP address via SNAT??
E.g. kiosk 1 which is internally 1.2.3.4 gets natted to the public
ip 5.6.7.8, so when it contacts the server it will establish a
connection back to 5.6.7.8 which will in turn be DNATted to 1.2.3.4.
kiosk 2 (1.2.3.5) --> 5.6.7.9
and so on...
I haven't read the whole thread, so it might be that I missed
something :-)

Wouldn't this work??


HTH

Sven

-- 
Linux zion.homelinux.com 2.6.14-rc5-mm1_14 #14 Wed Nov 2 11:36:18 CET 2005 i686 athlon i386 GNU/Linux
 17:19:16 up 1 day,  5:25,  2 users,  load average: 0.38, 0.18, 0.07

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Re: iptables problem (nfcan: addressed to exclusive (nfcan: addressed to exclusive sender for this address) sender for this address)

[Jim Laurino]

On 2005.11.03 11:02, Ashley M. Kirchner - ashley@pcraft.com wrote:
> Jim Laurino wrote:
> 
>> You can arrange to have the firewall in question
>> respond to 3 IP addresses on the outside interface and
>> forward the now distinct traffic to the 3 kiosks.
>> If this is possible, it might be better than being screwed.
> 
>    That would be nice, but no can do.  Remember, the server end, or  
> receiving end, is a third party company.  They have hundreds, if not  
> thousands of these little kiosks scattered across the country.  We are but a  
> tiny little company with three of those kiosks.  Each kiosk makes an  
> outbound FTP connection to the server.  Then the server makes an inbound  
> connection back to the kiosk.  This is where it fails because it doesn't  
> know where it came from since the kiosks are behind the firewall.

Perhaps I am confused,
I thought that the kiosks in question were acting as ftp servers.

If the kiosks are ftp clients, the situation is entirely different.
This should not be a problem.

> 
>    Putting the kiosks OUTSIDE the firewall (with different IPs) also won't  
> work because they also need to communicate (via windows shares) to internal  
> machines, again, same scenario...they contact a print station, and the print  
> station contacts them.

Exactly what do you mean when you say "contacts".
Do you mean that the kiosk also must act as an ftp server?
Or do you mean contact as in a passive ftp transfer?
Passive ftp you can support via ftp helpers and RELATED.

> So you see, being screwed is the only option I see
> here.  Unless I'm overlooking something.
> 
>    And I can't tell the other company to send data to separate IPs either  
> because their system works based on the packet they first receive when the  
> kiosk contacts them.  Which goes back to my point above (about putting the  
> kiosks outside the firewall.)
> 
>-- 
> H | I haven't lost my mind; it's backed up on tape somewhere.
>  +--------------------------------------------------------------------
>  Ashley M. Kirchner <mailto:ashley@pcraft.com>   .   303.442.6410 x130
>  IT Director / SysAdmin / WebSmith             .     800.441.3873 x130
>  Photo Craft Imaging                       .     3550 Arapahoe Ave. #6
>  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A.
> 
> 
> 
>
-- 
Jim Laurino
nfcan.x.jimlaur@dfgh.net
Please reply to the list.
Only mail from the listserver reaches this address.

RE: Re: iptables problem (nfcan: addressed to exclusivesender for this address)

[Rob Sterenborg]

> you say "their" system works based on the packet they first
> receive when contacting them. So with multiple IPs, wouldn't
> it work to let each kiosk contact the server via its own IP
> address via SNAT??
> E.g. kiosk 1 which is internally 1.2.3.4 gets natted to the
> public ip 5.6.7.8, so when it contacts the server it will
> establish a connection back to 5.6.7.8 which will in turn be
> DNATted to 1.2.3.4.
> kiosk 2 (1.2.3.5) --> 5.6.7.9
> and so on...

Yes this could work. Stupid I didn't think of it.

Ext_ip1 -(DNAT)-> Int_ip1
Ext_ip2 -(DNAT)-> Int_ip2
Ext_ip3 -(DNAT)-> Int_ip3

But then (reading OP's other post : "And I can't tell the other company
to send data to separate IPs either because their system works based on
the packet they first receive when the kiosk contacts them") you should
also SNAT to different externals IP's :

Int_ip1 -(SNAT)-> Ext_ip1
Int_ip2 -(SNAT)-> Ext_ip2
Int_ip3 -(SNAT)-> Ext_ip3

> I haven't read the whole thread, so it might be that I missed
> something :-) 

I think not ;^)


Gr,
Rob

Re: Re: iptables problem (nfcan: addressed to exclusive (nfcan: addressed to exclusive sender for this address) sender for this address)

[Ashley M. Kirchner]

Jim Laurino wrote:

> If the kiosks are ftp clients, the situation is entirely different.
> This should not be a problem.

    They are clients.  But...keep reading...  Something changed today.

> Exactly what do you mean when you say "contacts".
> Do you mean that the kiosk also must act as an ftp server?
> Or do you mean contact as in a passive ftp transfer?
> Passive ftp you can support via ftp helpers and RELATED.

    Neither.  It's through windows network shares.  The kiosk puts the 
order on it's local drive which is shared to the network, and the print 
station comes and fetches the info periodically.  Keep reading...


    I just got off the phone with the company and they made a small 
change in our config.  Now, all the kiosks have to do is connect via FTP 
to their server and drop a file.  That's it.  Nothing comes back, no 
inbound connections to the kiosks.  Just going out.

    So, just out of curiosity, I decided to try doing a manual FTP 
transfer from a completely different machine on the network.  One that 
CAN connect to external ftp sites just fine and transfer files.  And 
this is what I see:

    - Open DOS window
    - Connect to FTP server
    - enter 'PUT file.xml' command
    ...and that's where it hangs.

    Now, looking in the firewall logs, I see this:

Nov  3 13:47:19 serpico kernel: New not syn:IN=eth2 OUT=eth0 
SRC=192.168.1.253 DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 
ID=43803 DF PROTO=TCP SPT=4100 DPT=21 WINDOW=65420 RES=0x00 ACK PSH URGP=0

Nov  3 13:47:49 serpico kernel: New not syn:IN=eth2 OUT=eth0 
SRC=192.168.1.253 DST=206.112.90.196 LEN=40 TOS=0x00 PREC=0x00 TTL=127 
ID=43949 DF PROTO=TCP SPT=4100 DPT=21 WINDOW=0 RES=0x00 ACK RST URGP=0

Nov  3 13:47:55 serpico kernel: New not syn:IN=eth2 OUT=eth0 
SRC=192.168.1.253 DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 
ID=43987 DF PROTO=TCP SPT=4117 DPT=21 WINDOW=65338 RES=0x00 ACK PSH URGP=0

    In my DOS window, I see this (while those errors are popping up in 
syslog):

    ftp> put 2008701033.xml
            ... pause ... first error in syslog
            ... pause ... second line in syslog
    Connection closed by remote host.
            ... third line in syslog
    ftp>
   

    Please remember that this is a machine onto which I CAN open an ftp 
connection to anywhere in the world and be able to send and receive 
files just fine.  So then why is it not working when going to these people?

    ---- FIVE MINUTES LATER ----

    I just tried directly from the firewall machine and found out they 
don't allow PASSIVE mode ON... As soon as I turn passive mode off, the 
transfer, FROM THE FIREWALL MACHINE, works.  (firewall machine has an 
external IP)

    So now I wonder, is it because of the passive mode setting they 
have?  Could that be why ftp transfers from within the firewall fails?

-- 
W | It's not a bug - it's an undocumented feature.
  +--------------------------------------------------------------------
  Ashley M. Kirchner <mailto:ashley@pcraft.com>   .   303.442.6410 x130
  IT Director / SysAdmin / Websmith             .     800.441.3873 x130
  Photo Craft Laboratories, Inc.            .     3550 Arapahoe Ave. #6
  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A.

RE: Re: iptables problem

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1




Why not have one system that reaches out for the files, and brings them 
inside, then point the kiosks at that one system?  Far easier to maintain 
and troubleshoot and far less FW coding.


Thanks,

Ron DuFresne


On Thu, 3 Nov 2005, Rob Sterenborg wrote:

>>     Yes, the kiosks are behind the firewall (iptables) and need
>> unrestricted access to and from the internet, but only for FTP.
>
> ...
>
>>     All right, so this is what I currently have in my iptables rules:
>>
>> -A PREROUTING -i eth0 -p tcp -m tcp --dport 21 -j DNAT
>> --to-destination 192.168.1.xxx
>> -A PREROUTING -i eth0 -p tcp -m tcp --dport 20 -j DNAT
>> --to-destination 192.168.1.xxx
>>
>>     ...and further down:
>>
>> -A FORWARD -i eth0 -o eth2 -p tcp -m state --state NEW -m tcp
>> --dport 21 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
>> -A FORWARD -i eth0 -o eth2 -p tcp -m state --state NEW -m tcp
>> --dport 20 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
>
> I assume your FORWARD policy is DROP ?
>
> If you use RELATED,ESTABLISHED, you only need to allow port 21. Port 20
> is then RELATED to the connection. So, do you also have (something like)
> :
> -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
>
> You *do* load the ftp conntack helpers, do you ?
>
>>     In my logs, I see this:
>>
>> kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx
>> DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1587 DF
>> PROTO=TCP SPT=1186 DPT=21 WINDOW=65338 RES=0x00 ACK PSH URGP=0
>>
>> kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx
>> DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1588 DF
>> PROTO=TCP SPT=1181 DPT=21 WINDOW=65196 RES=0x00 ACK PSH URGP=0
>>
>> kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx
>> DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1589 DF
>> PROTO=TCP SPT=1184 DPT=21 WINDOW=65338 RES=0x00 ACK PSH URGP=0
>
> This looks like an ACK to me. Not sure why such packet would be in the
> NEW state on port 21, where a ftp-client would connect to at first so I
> would think it would be in the ESTABLISHED state. (Also not sure what
> the logging rule looks like.)
> Maybe someone else who has better knowledge of this can help here.
>
> You could skip the tcp-flags at first and see if that works.
>
>>     The other problem is that, while I can change the FTP port on the
>> kiosks, I can't change it on the other end (the receiving and sending)
>> so I'm not sure how to handle that part.  They will always attempt to
>> connect on the standard FTP port, which two of these machines
>> won't be listening to since I would've changed them so they don't
>> conflict with one another.  Or is that not so?
>
> You don't have to run the ftp service of the kiosk hosts on different
> ports : just forward the external ports, let's say (40/)41 and (60/)61,
> to ports (20/)21 on the kiosk hosts. But that is no solution to your
> problem I suppose, because of the serverside problem.
>
> Maybe you can let the kiosk hosts connect to the server and perform GET
> and PUT commands. The server then only has to put the needed updates in
> a specific directory where the kiosk hosts can download them from. This
> way the hosts themselves don't have to be reachable on the internet
> which would be better from a security point of view.
>
>
> Gr,
> Rob
>
>

- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFDaob8st+vzJSwZikRAqYCAKDUUlIYj/Kc10C/NxsnEpRxRb4jjQCfTBU3
RYixAO5DstCZTr9QMCqXygI=
=hj6F
-----END PGP SIGNATURE-----

Re: Re: iptables problem

[Ashley M. Kirchner]

R. DuFresne wrote:

> Why not have one system that reaches out for the files, and brings 
> them inside, then point the kiosks at that one system?  Far easier to 
> maintain and troubleshoot and far less FW coding.

    Because I didn't code these machines.  They are proprietary and 
third party to us.

-- 
H | I haven't lost my mind; it's backed up on tape somewhere.
  +--------------------------------------------------------------------
  Ashley M. Kirchner <mailto:ashley@pcraft.com>   .   303.442.6410 x130
  IT Director / SysAdmin / WebSmith             .     800.441.3873 x130
  Photo Craft Imaging                       .     3550 Arapahoe Ave. #6
  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A. 

Re: Re: iptables problem

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 3 Nov 2005, Ashley M. Kirchner wrote:

> R. DuFresne wrote:
>
>> Why not have one system that reaches out for the files, and brings them 
>> inside, then point the kiosks at that one system?  Far easier to maintain 
>> and troubleshoot and far less FW coding.
>
>   Because I didn't code these machines.  They are proprietary and third 
> party to us.
>
>

Interesting, and that means I suspect that you have no ability to tune or 
config them as well?  Could one put in a request the third parties config 
them to look at one trusted host you could setup to pull the files from?

Have they been "tested" for their security?  Seems a tad risky, depending 
upon placement, hopefully they are in a dmz and not the soft chewy 
center....

Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFDatL0st+vzJSwZikRArWLAKDA/urNj4sEruwm7KU8ezInKPLpJQCeJk+R
MFr5oi+c3stQZx0mqQJgqmE=
=Z32v
-----END PGP SIGNATURE-----

Re: Re: iptables problem

[Ashley M. Kirchner]

R. DuFresne wrote:

> Interesting, and that means I suspect that you have no ability to tune 
> or config them as well?  Could one put in a request the third parties 
> config them to look at one trusted host you could setup to pull the 
> files from?
>
> Have they been "tested" for their security?  Seems a tad risky, 
> depending upon placement, hopefully they are in a dmz and not the soft 
> chewy center....

    Tested for security?  Does the fact that they transmit order details 
(including plain text client information and an encrypted CC string 
within the same file) via plain old FTP tell you anything?  Do I, 
personally, trust this system?  Oh HELL NO.  Would I, personally, use 
them to place any orders?  Oh HELL NO.  Do I have a choice in not using 
them?  Nope.  I'm merely the one that has to make them work...the big 
guys paid the money.

-- 
H | I haven't lost my mind; it's backed up on tape somewhere.
  +--------------------------------------------------------------------
  Ashley M. Kirchner <mailto:ashley@pcraft.com>   .   303.442.6410 x130
  IT Director / SysAdmin / WebSmith             .     800.441.3873 x130
  Photo Craft Imaging                       .     3550 Arapahoe Ave. #6
  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A. 

Re: Re: iptables problem (nfcan: addressed to exclusive (nfcan: addressed to exclusive sender for this address) (nfcan: addressed to exclusive sender for this address) sender for this address)

[Jim Laurino]

On 2005.11.03 14:57, Ashley M. Kirchner - ashley@pcraft.com wrote:
> Jim Laurino wrote:
>
...
>    I just got off the phone with the company and they made a small change in  
> our config.  Now, all the kiosks have to do is connect via FTP to their  
> server and drop a file.  That's it.  Nothing comes back, no inbound  
> connections to the kiosks.  Just going out.
> 
>    So, just out of curiosity, I decided to try doing a manual FTP transfer  
> from a completely different machine on the network.  One that CAN connect to  
> external ftp sites just fine and transfer files.  And this is what I see:
> 
>    - Open DOS window
>    - Connect to FTP server
>    - enter 'PUT file.xml' command
>    ...and that's where it hangs.
>
....
> 
>    Please remember that this is a machine onto which I CAN open an ftp  
> connection to anywhere in the world and be able to send and receive files  
> just fine.  So then why is it not working when going to these people?
> 
>    ---- FIVE MINUTES LATER ----
> 
>    I just tried directly from the firewall machine and found out they don't  
> allow PASSIVE mode ON... As soon as I turn passive mode off, the transfer,  
> FROM THE FIREWALL MACHINE, works.  (firewall machine has an external IP)
> 
>    So now I wonder, is it because of the passive mode setting they have?   
> Could that be why ftp transfers from within the firewall fails?
>

non-passive (active) FTP requires that
the outside ftp server be able to open
a secondary connection to the client.
That is why passive mode is so popular
when the ftp client is behind a firewall -
both of the connections are originated from the client,
and no ports have to be opened on the firewall
for the incoming secondary connection.

I was confused about this earlier,
and may have contributed to the confusion.

A clear explanation is here http://slacksite.com/other/ftp.html

So, it is possible that your firewall is not configured to allow
active mode ftp connections. (But it can be done).

HTH

-- 
Jim Laurino
nfcan.x.jimlaur@dfgh.net
Please reply to the list.
Only mail from the listserver reaches this address.

Re: Re: iptables problem (nfcan: addressed to exclusive (nfcan: addressed to exclusive sender for this address) (nfcan: addressed to exclusive sender for this address) sender for this address)

[Ashley M. Kirchner]

Jim Laurino wrote:

> So, it is possible that your firewall is not configured to allow
> active mode ftp connections. (But it can be done).

    Okay, so what am I supposed to do to "fix" this?  Thanks for the 
link by the way.  Helped clear up some things...

-- 
H | I haven't lost my mind; it's backed up on tape somewhere.
  +--------------------------------------------------------------------
  Ashley M. Kirchner <mailto:ashley@pcraft.com>   .   303.442.6410 x130
  IT Director / SysAdmin / WebSmith             .     800.441.3873 x130
  Photo Craft Imaging                       .     3550 Arapahoe Ave. #6
  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A. 

RE: Re: iptables problem (nfcan: addressed to exclusive (nfcan: addressed to exclusive sender for this address) (nfcan: addressed to exclusive sender for this address) sender for this address)

[Rob Sterenborg]

>> So, it is possible that your firewall is not configured to allow
>> active mode ftp connections. (But it can be done).
> 
>     Okay, so what am I supposed to do to "fix" this?  Thanks for the

Check out section "Connection tracking and ftp" on this page :
http://kalamazoolinux.org/presentations/20010417/conntrack.html


Gr,
Rob

IPTABLES PROBLEM

[Micol lupen]

Hi guys, thanks for all.
I have this problem whith iptables:,   
Io gestisco una rete con 10 pc (indirizzo e'
I have a lan whit 10 pc (use win9X) and have ip
10.10.10.2 ecc..)
Tree days ago Telecom build in my farm the adsl (using
router adsl cisco )  
i wont to create a firewall and use natting for pc 
I build a pc whit Slackware 10.1 
and i do this script:
----Information LAN--------
eth0: 10.10.10.50 netmask 255.255.255.0 (ETHO IS
connected to switch ) 
eth1:178.133.80.74 netmask 255.255.255.248 (IP
STATIC,GIVE ME THIS IP FROM TELECOM )
gatway 78.133.80.73 netmask 255.255.255.248
(GATWAY IP, GIVE ME THIS FROM TELECOM )
 DNS 151.99.125.1 (DNS IP, GIVE ME FROM TELECOM )
------SCRIPT FOR ETHERNET
CONFIGURATION----------------


//ETHERNET INTERFACE file conf.ps
!/bin/bash
ifconfig eth0 10.10.10.50 netmask 255.255.255.0
ifconfig eth1 178.133.80.74 netmask 255.255.255.248
route add -net default gw 178.133.80.73 netmask
255.255.255.248 
# END SCRIPT CONF.PS

//--- I WRITE IN /etc/resolv.conf 
NAMESERVER=151.99.125.1

//--------FIREWALL SCRIPT firewall.ps

#!/bin/bash
IPTAB=iptables
NAMESERVER=151.99.125.1  
IPADD=178.133.80.74 


# IMPORTANT UTILITY 
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 1 > /proc/sys/net/ipv4/ip_forward 
echo 0 >
/proc/sys/net/ipv4/conf/all/accept_source_route 
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 >
/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
#CLEAR ALL
$IPTAB -F
$IPTAB -X
$IPTAB -Z
$IPTAB -t nat -F
$IPTAB -t nat -X
# DROP ALL
$IPTAB -P INPUT DROP
$IPTAB -P FORWARD DROP
$IPTAB -P OUTPUT  DROP

$IPTAB -A INPUT -i lo -j ACCEPT
$IPTAB -A OUTPUT -o lo -j ACCEPT 

# FROM LAN TO INTERNET  
$IPTAB -A INPUT -s 10.10.10.0/24 -i eth0 -j ACCEPT  
# FORWORDING
$IPTAB -A FORWARD -i eth0 -s 10.10.10.0/24 -j ACCEPT
$IPTAB -A FORWARD -i eth1 -d 10.10.10.0/24 -j ACCEPT
# QUERY DNS (SERVER-> CLIENT)
$IPTAB -A INPUT -i eth1 -p udp -s $NAMESERVER --sport
53 -m state --state ESTABLISHED -j ACCEPT
$IPTAB -A INPUT -i eth1 -p tcp -s $NAMESERVER --sport
53 -m state --state ESTABLISHED
#QUERY DNS (CLIENT-> SERVER)
$IPTAB -A OUTPUT -o eth1 -p udp -d $NAMESERVER --dport
53 -m state --state NEW,ESTABLISHED -j ACCEPT
$IPTAB -A OUTPUT -o eth1 -p tcp -d $NAMESERVER --dport
53 -m state --state NEW,ESTABLISHED -j ACCEPT    
#HTTP E HTTPS
$IPTAB -A INPUT -i eth1 -p tcp --sport 80 -m state
--state ESTABLISHED -j ACCEPT
$IPTAB -A OUTPUT -o eth1 -p tcp --dport 80 -m state
--state NEW,ESTABLISHED -j ACCEPT 
$IPTAB -A INPUT -i eth1 -p tcp --sport 443 -m state
--state ESTABLISHED -j  ACCEPT
$IPTAB -A OUTPUT -o eth1 -p tcp --dport 443 -m state
--state NEW,ESTABLISHED -j ACCEPT
#NAT
$IPTAB -t nat -A POSTROUTING -o eth1 -s 10.10.10.0/24
-j SNAT --to $IPADD
 #fine

WHEN I START TO FIREWALL THE CLIENT CAN'T TO GO TO
INTERNET, HELP ME !!!!
P.S. excuse me for my bad english 
REGADS 
MICOL  
 

Grazie mille


	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it

RE: IPTABLES PROBLEM

[Rob Sterenborg]

> I have a lan whit 10 pc (use win9X) and have ip 10.10.10.2 ecc..
> Tree days ago Telecom build in my farm the adsl (using router adsl
> cisco ) i wont to create a firewall and use natting for pc
> I build a pc whit Slackware 10.1
> and i do this script:
> 
> ----Information LAN--------
> 
> (ethO is connected to switch)
> eth0: 10.10.10.50 netmask 255.255.255.0
> 
> (IP STATIC,GIVE ME THIS IP FROM TELECOM)
> eth1: 178.133.80.74 netmask 255.255.255.248 
> 
> (GATWAY IP, GIVE ME THIS FROM TELECOM)
> gatway 78.133.80.73 netmask 255.255.255.248
        ^^^^
I guess this is a typo ?? I suppose it should be 178.133.80.73

> (DNS IP, GIVE ME FROM TELECOM)
> DNS 151.99.125.1
> 
> ------SCRIPT FOR ETHERNET
> CONFIGURATION----------------
> 
> 
> //ETHERNET INTERFACE file conf.ps
> !/bin/bash
> ifconfig eth0 10.10.10.50 netmask 255.255.255.0
> ifconfig eth1 178.133.80.74 netmask 255.255.255.248
> route add -net default gw 178.133.80.73 netmask
> 255.255.255.248
> # END SCRIPT CONF.PS
> 
> //--- I WRITE IN /etc/resolv.conf
> NAMESERVER=151.99.125.1
> 
> //--------FIREWALL SCRIPT firewall.ps
> 
> #!/bin/bash
> IPTAB=iptables
> NAMESERVER=151.99.125.1
> IPADD=178.133.80.74

...

> 
> WHEN I START TO FIREWALL THE CLIENT CAN'T TO GO TO
> INTERNET, HELP ME !!!!

Please don't shout at us..

What is "the client" ? Is it the firewall or do you mean the LAN
clients.

You seem not familiar with iptables and immediately want to build a
ruleset that is quite closed. Maybe you should start simpler and when
you are confident enough, expand the ruleset into what you want it to
do.
Check out :
http://iptables-tutorial.frozentux.net/iptables-tutorial.html

Try the following. Setting OUTPUT policy to DROP makes it more difficult
for you to get things working, so I set it to ACCEPT.

============
# First, do not allow forwarding yet.
#
echo 0 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# Empty all chains
#
$IPT -F
$IPT -t nat -F

# Set policy
#
$IPT -P INPUT DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT  ACCEPT

# Accept on lo
#
$IPT -A INPUT -i lo -j ACCEPT

# Accept packets from already matched connections
#
$IPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
$IPT -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

# LAN -> firewall
#
$IPT -A INPUT -m state --state NEW -i eth0 -s 10.10.10.0/24 \
  -j ACCEPT

# LAN -> Internet
#
$IPT -A FORWARD -m state --state NEW -i eth0 -o eth1 \
  -s 10.10.10.0/24 -j ACCEPT

# NAT
#
$IPT -t nat -A POSTROUTING -o eth1 -s 10.10.10.0/24 \
  -j SNAT --to 178.133.80.74

# Allow forwarding
#
echo 1 > /proc/sys/net/ipv4/ip_forward
============


Gr,
Rob

Re: IPTABLES PROBLEM

[/dev/rob0]

On Tuesday 2005-November-08 11:08, Micol lupen wrote:
> I have a lan whit 10 pc (use win9X) and have ip

Win9x? Ugly!

> //ETHERNET INTERFACE file conf.ps
> !/bin/bash

Missing the # at the beginning of that line. You don't really need a 
"shabang" line at all for just running a few simple commands.

> ifconfig eth0 10.10.10.50 netmask 255.255.255.0
> ifconfig eth1 178.133.80.74 netmask 255.255.255.248
> route add -net default gw 178.133.80.73 netmask
> 255.255.255.248
> # END SCRIPT CONF.PS

Slackware will do this for you. Run "netconfig" or just edit 
"/etc/rc.d/rc.inet1.conf".

> //--- I WRITE IN /etc/resolv.conf
> NAMESERVER=151.99.125.1

Nope. "nameserver 151.99.125.1".

> //--------FIREWALL SCRIPT firewall.ps

If at /etc/rc.d/rc.firewall, Slackware will run it for you.

> echo 1 > /proc/sys/net/ipv4/ip_forward

Normally this should come at the end. I put a "0" in at the beginning 
and then "1" after firewall protections are in place. (Similar to the 
script Rob posted just now.)

> $IPTAB -P INPUT DROP
> $IPTAB -P FORWARD DROP

Okay.

> $IPTAB -P OUTPUT  DROP

Unless you know exactly what you plan to do with OUTPUT filtering, I 
strongly suggest you give it up.

> # FROM LAN TO INTERNET
> $IPTAB -A INPUT -s 10.10.10.0/24 -i eth0 -j ACCEPT

No, that's from LAN to firewall machine. See "man iptables", near the 
beginning, where the tables and their built-in chains are described.

> # FORWORDING
> $IPTAB -A FORWARD -i eth0 -s 10.10.10.0/24 -j ACCEPT
> $IPTAB -A FORWARD -i eth1 -d 10.10.10.0/24 -j ACCEPT

Okay. I think that would work, anyway. I do it differently, see next.

> # QUERY DNS (SERVER-> CLIENT)
> $IPTAB -A INPUT -i eth1 -p udp -s $NAMESERVER --sport
> 53 -m state --state ESTABLISHED -j ACCEPT

A simple --state RELATED,ESTABLISHED -j ACCEPT rule along with OUTPUT 
policy of ACCEPT would do better. I put that rule in a "State" chain 
and jump to State from both INPUT and FORWARD.

But that (INPUT) has nothing to do with your problem below.

> #NAT
> $IPTAB -t nat -A POSTROUTING -o eth1 -s 10.10.10.0/24
> -j SNAT --to $IPADD

Okay.

> WHEN I START TO FIREWALL THE CLIENT CAN'T TO GO TO
> INTERNET, HELP ME !!!!

And how are you diagnosing this? What did you try? What happened?

> P.S. excuse me for my bad english

Your English is fine. Work on your troubleshooting skills. :)
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Iptables problem

[tarak]

hello experts,

              i have a problem in iptables, i want to customize the
firewall. through iptable i want run a shell script which will keep an
watch
on each and every ip addresses in my organization, that how much amount
of
data downloading and uploading from those ip addresses...... seperately..
is
this possible to do,,,, if so please tell me how to do...

thanks in advance

Regards,
Tarak Ranjan

Iptables problem

[Saurabh Mehrotra]

---------- Forwarded message ----------
From: Saurabh Mehrotra <saurabh1980@gmail.com>
Date: Mon, 22 Jan 2007 21:29:46 +0530
Subject: Iptables problem help required !!!!
To: netfilter@lists.netfilter.org

Hi ,

I am using Red Hat Enterprise Linux AS release 4 (Nahant Update 3) with
Kernel 2.6.9-34.ELsmp #1

I am using Iptables for firewall .

But without firewall I m able to nslookup my own DNS server but whenever I
enabled firewall I am not able to nslookup to my own system.

And log files shows the following entry .

RULE 0 -- ACCEPT IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00
SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=15607 DF
PROTO=TCP SPT=46994 DPT=25 WINDOW=32767 RES=0x00 SYN URGP=0
Jan 22 15:52:01 trench1ams crond(pam_unix)[13126]: session closed for user
root

EVEN This rule 0 is also accept rule for SSH not for deny...


I have added rule to accept my own system  traffic ...to allow any service
but still tje proble, is same ....


root@trench1 ~]# nslookup trench1
Server:         212.165.108.4
Address:        212.165.108.4#53

*** Can't find trench1ams: No answer


Please advice me how can I overcome with this problem .......


Thanks

Saurabh

Re: Iptables problem

[Ted Phelps]

"Saurabh Mehrotra" writes:
> I am using Red Hat Enterprise Linux AS release 4 (Nahant Update 3) with
> Kernel 2.6.9-34.ELsmp #1
> 
> I am using Iptables for firewall .
> 
> But without firewall I m able to nslookup my own DNS server but whenever I
> enabled firewall I am not able to nslookup to my own system.

It sounds like your firewall is blocking DNS traffic.

You'll have to show us your firewall rules if we're going to be able to
help you:

    iptables -v -L

Cheers,
-Ted

Re: Iptables problem

[Saurabh Mehrotra]

Hi Ted,

Many thanks for reply....

Please find output of

iptables -v -L

Chain INPUT (policy DROP 1 packets, 40 bytes)
 pkts bytes target     prot opt in     out     source
destination
35353 2552K ACCEPT     all  --  any    any     anywhere
anywhere            state RELATED,ESTABLISHED
10736  644K lo_In_RULE_0  all  --  lo     any     anywhere
anywhere
  242 22264 Cid459E8205.0  all  --  any    any     anywhere
 10.150.0.225        state NEW
   59  3174 Cid459E8205.0  all  --  any    any     anywhere
 trench1ams          state NEW
    0     0 Cid459E82B3.2  udp  --  any    any     anywhere
 anywhere            udp multiport dports snmptrap,syslog,tftp state
NEW
    8   570 Cid459E81DA.0  udp  --  any    any     anywhere
 anywhere            udp dpt:domain state NEW
    8   570 Cid459E81DA.1  udp  --  any    any     anywhere
 anywhere            udp dpt:domain state NEW
    0     0 Cid459E8281.2  udp  --  any    any     anywhere
 anywhere            udp dpt:domain state NEW
    0     0 Cid45A018F5.0  all  --  any    any     10.150.0.225
 anywhere
    0     0 Cid45A018F5.0  all  --  any    any     trench1ams
 anywhere
    0     0 Cid45A018F5.0  all  --  any    any     trench1ams
 anywhere
  262 23360 RULE_5     all  --  any    any     anywhere
anywhere

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source
destination
    0     0 ACCEPT     all  --  any    any     anywhere
anywhere            state RELATED,ESTABLISHED
    0     0 Cid459E8205.4  all  --  any    any     anywhere
 10.150.0.226        state NEW
    0     0 Cid459E8205.4  all  --  any    any     anywhere
 212.165.108.5       state NEW
    0     0 Cid459E8205.4  all  --  any    any     anywhere
 10.150.65.12        state NEW
    0     0 Cid459E8205.4  all  --  any    any     anywhere
 212.165.65.4        state NEW
    0     0 Cid459E8205.4  all  --  any    any     anywhere
 10.150.65.13        state NEW
    0     0 Cid459E8205.4  all  --  any    any     anywhere
 212.165.65.5        state NEW
    0     0 Cid459E82B3.4  udp  --  any    any     anywhere
 anywhere            udp multiport dports snmptrap,syslog,tftp state
NEW
    0     0 Cid459E81DA.3  udp  --  any    any     anywhere
 anywhere            udp dpt:domain state NEW
    0     0 Cid459E8281.3  udp  --  any    any     anywhere
 anywhere            udp dpt:domain state NEW
    0     0 RULE_5     all  --  any    any     anywhere
anywhere

Chain OUTPUT (policy DROP 2 packets, 256 bytes)
 pkts bytes target     prot opt in     out     source
destination
31640 2770K ACCEPT     all  --  any    any     anywhere
anywhere            state RELATED,ESTABLISHED
10736  644K lo_Out_RULE_0  all  --  any    lo      anywhere
 anywhere
    0     0 Cid459E8205.2  all  --  any    any     anywhere
 10.150.0.226        state NEW
    1    74 Cid459E8205.2  all  --  any    any     anywhere
 212.165.108.5       state NEW
    0     0 Cid459E8205.2  all  --  any    any     anywhere
 10.150.65.12        state NEW
    0     0 Cid459E8205.2  all  --  any    any     anywhere
 212.165.65.4        state NEW
    0     0 Cid459E8205.2  all  --  any    any     anywhere
 10.150.65.13        state NEW
    0     0 Cid459E8205.2  all  --  any    any     anywhere
 212.165.65.5        state NEW
    0     0 Cid459E82B3.0  all  --  any    any     10.150.0.225
 anywhere            state NEW
 1119 80580 Cid459E82B3.0  all  --  any    any     trench1ams
 anywhere            state NEW
 1104 78714 Cid459E81DA.2  udp  --  any    any     anywhere
 anywhere            udp dpt:domain state NEW
    0     0 Cid459E8281.0  udp  --  any    any     anywhere
 anywhere            udp dpt:domain state NEW
    0     0 Cid459E8281.1  udp  --  any    any     anywhere
 anywhere            udp dpt:domain state NEW
    0     0 Cid45A018F5.1  all  --  any    any     10.150.0.225
 anywhere
   14  1738 Cid45A018F5.1  all  --  any    any     trench1ams
 anywhere
    0     0 Cid45A018F5.1  all  --  any    any     trench1ams
 anywhere
   14  1738 RULE_5     all  --  any    any     anywhere
anywhere

Chain Cid459E81DA.0 (1 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 RULE_2     all  --  any    any     10.150.0.225
anywhere
    0     0 RULE_2     all  --  any    any     trench1ams
anywhere

Chain Cid459E81DA.1 (1 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 RULE_2     all  --  any    any     10.150.0.226
anywhere
    8   570 RULE_2     all  --  any    any     212.165.108.5
anywhere
    0     0 RULE_2     all  --  any    any     10.150.65.12
anywhere
    0     0 RULE_2     all  --  any    any     212.165.65.4
anywhere
    0     0 RULE_2     all  --  any    any     10.150.65.13
anywhere
    0     0 RULE_2     all  --  any    any     212.165.65.5
anywhere

Chain Cid459E81DA.2 (1 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 RULE_2     all  --  any    any     10.150.0.225
anywhere
 1104 78714 RULE_2     all  --  any    any     trench1ams
anywhere

Chain Cid459E81DA.3 (1 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 RULE_2     all  --  any    any     10.150.0.226
anywhere
    0     0 RULE_2     all  --  any    any     212.165.108.5
anywhere
    0     0 RULE_2     all  --  any    any     10.150.65.12
anywhere
    0     0 RULE_2     all  --  any    any     212.165.65.4
anywhere
    0     0 RULE_2     all  --  any    any     10.150.65.13
anywhere
    0     0 RULE_2     all  --  any    any     212.165.65.5
anywhere

Chain Cid459E8205.0 (2 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 Cid459E8205.1  icmp --  any    any     anywhere
 anywhere            icmp ttl-zero-during-reassembly
    0     0 Cid459E8205.1  icmp --  any    any     anywhere
 anywhere            icmp ttl-zero-during-transit
    0     0 Cid459E8205.1  icmp --  any    any     anywhere
 anywhere            icmp port-unreachable
  242 22264 Cid459E8205.1  icmp --  any    any     anywhere
 anywhere            icmp type 8 code 0
    0     0 Cid459E8205.1  icmp --  any    any     anywhere
 anywhere            icmp type 0 code 0
    0     0 Cid459E8205.1  icmp --  any    any     anywhere
 anywhere            icmp host-unreachable
   50  2536 Cid459E8205.1  tcp  --  any    any     anywhere
 anywhere            tcp dpt:ssh
    1    68 Cid459E8205.1  udp  --  any    any     anywhere
 anywhere            udp dpt:snmp

Chain Cid459E8205.1 (8 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 ACCEPT     all  --  any    any     212.165.120.6
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.38
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.7
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.39
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.9
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.4
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.36
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.208
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.5
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.37
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.209
anywhere
    0     0 ACCEPT     all  --  any    any     POPA
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.44
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.216
anywhere
    0     0 ACCEPT     all  --  any    any     POPB
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.45
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.217
anywhere
    0     0 ACCEPT     all  --  any    any
host-83-146-60-149.bulldogdsl.com  anywhere
    0     0 ACCEPT     all  --  any    any     fre-67677.easynet.co.uk
 anywhere
    1    48 ACCEPT     all  --  any    any
host-84-9-3-176.bulldogdsl.com/28  anywhere
    0     0 ACCEPT     all  --  any    any
host-83-146-45-128.bulldogdsl.com/28  anywhere
    0     0 ACCEPT     all  --  any    any     213.250.154.166
anywhere
    0     0 ACCEPT     all  --  any    any     prodba.plus.com
anywhere
    0     0 ACCEPT     all  --  any    any     83.71.198.237
anywhere
   29  1392 ACCEPT     all  --  any    any
121.247.160.154.Ahmedabad-static-bb.vsnl.net.in  anywhere
    1    68 ACCEPT     all  --  any    any     POPB.Staging
anywhere

Chain Cid459E8205.2 (6 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 Cid459E8205.3  icmp --  any    any     anywhere
 anywhere            icmp ttl-zero-during-reassembly
    0     0 Cid459E8205.3  icmp --  any    any     anywhere
 anywhere            icmp ttl-zero-during-transit
    0     0 Cid459E8205.3  icmp --  any    any     anywhere
 anywhere            icmp port-unreachable
    0     0 Cid459E8205.3  icmp --  any    any     anywhere
 anywhere            icmp type 8 code 0
    0     0 Cid459E8205.3  icmp --  any    any     anywhere
 anywhere            icmp type 0 code 0
    0     0 Cid459E8205.3  icmp --  any    any     anywhere
 anywhere            icmp host-unreachable
    0     0 Cid459E8205.3  tcp  --  any    any     anywhere
 anywhere            tcp dpt:ssh
    0     0 Cid459E8205.3  udp  --  any    any     anywhere
 anywhere            udp dpt:snmp

Chain Cid459E8205.3 (8 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 ACCEPT     all  --  any    any     212.165.120.6
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.38
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.7
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.39
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.9
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.4
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.36
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.208
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.5
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.37
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.209
anywhere
    0     0 ACCEPT     all  --  any    any     POPA
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.44
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.216
anywhere
    0     0 ACCEPT     all  --  any    any     POPB
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.45
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.217
anywhere
    0     0 ACCEPT     all  --  any    any
host-83-146-60-149.bulldogdsl.com  anywhere
    0     0 ACCEPT     all  --  any    any     fre-67677.easynet.co.uk
 anywhere
    0     0 ACCEPT     all  --  any    any
host-84-9-3-176.bulldogdsl.com/28  anywhere
    0     0 ACCEPT     all  --  any    any
host-83-146-45-128.bulldogdsl.com/28  anywhere
    0     0 ACCEPT     all  --  any    any     213.250.154.166
anywhere
    0     0 ACCEPT     all  --  any    any     prodba.plus.com
anywhere
    0     0 ACCEPT     all  --  any    any     83.71.198.237
anywhere
    0     0 ACCEPT     all  --  any    any
121.247.160.154.Ahmedabad-static-bb.vsnl.net.in  anywhere
    0     0 ACCEPT     all  --  any    any     POPB.Staging
anywhere

Chain Cid459E8205.4 (6 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 Cid459E8205.5  icmp --  any    any     anywhere
 anywhere            icmp ttl-zero-during-reassembly
    0     0 Cid459E8205.5  icmp --  any    any     anywhere
 anywhere            icmp ttl-zero-during-transit
    0     0 Cid459E8205.5  icmp --  any    any     anywhere
 anywhere            icmp port-unreachable
    0     0 Cid459E8205.5  icmp --  any    any     anywhere
 anywhere            icmp type 8 code 0
    0     0 Cid459E8205.5  icmp --  any    any     anywhere
 anywhere            icmp type 0 code 0
    0     0 Cid459E8205.5  icmp --  any    any     anywhere
 anywhere            icmp host-unreachable
    0     0 Cid459E8205.5  tcp  --  any    any     anywhere
 anywhere            tcp dpt:ssh
    0     0 Cid459E8205.5  udp  --  any    any     anywhere
 anywhere            udp dpt:snmp

Chain Cid459E8205.5 (8 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 ACCEPT     all  --  any    any     212.165.120.6
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.38
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.7
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.39
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.9
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.4
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.36
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.208
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.5
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.37
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.209
anywhere
    0     0 ACCEPT     all  --  any    any     POPA
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.44
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.216
anywhere
    0     0 ACCEPT     all  --  any    any     POPB
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.45
anywhere
    0     0 ACCEPT     all  --  any    any     212.165.120.217
anywhere
    0     0 ACCEPT     all  --  any    any
host-83-146-60-149.bulldogdsl.com  anywhere
    0     0 ACCEPT     all  --  any    any     fre-67677.easynet.co.uk
 anywhere
    0     0 ACCEPT     all  --  any    any
host-84-9-3-176.bulldogdsl.com/28  anywhere
    0     0 ACCEPT     all  --  any    any
host-83-146-45-128.bulldogdsl.com/28  anywhere
    0     0 ACCEPT     all  --  any    any     213.250.154.166
anywhere
    0     0 ACCEPT     all  --  any    any     prodba.plus.com
anywhere
    0     0 ACCEPT     all  --  any    any     83.71.198.237
anywhere
    0     0 ACCEPT     all  --  any    any
121.247.160.154.Ahmedabad-static-bb.vsnl.net.in  anywhere
    0     0 ACCEPT     all  --  any    any     POPB.Staging
anywhere

Chain Cid459E8281.0 (1 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 RULE_3     all  --  any    any     anywhere
10.150.0.225
    0     0 RULE_3     all  --  any    any     anywhere
trench1ams

Chain Cid459E8281.1 (1 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 RULE_3     all  --  any    any     anywhere
10.150.0.226
    0     0 RULE_3     all  --  any    any     anywhere
212.165.108.5
    0     0 RULE_3     all  --  any    any     anywhere
10.150.65.12
    0     0 RULE_3     all  --  any    any     anywhere
212.165.65.4
    0     0 RULE_3     all  --  any    any     anywhere
10.150.65.13
    0     0 RULE_3     all  --  any    any     anywhere
212.165.65.5

Chain Cid459E8281.2 (1 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 RULE_3     all  --  any    any     anywhere
10.150.0.225
    0     0 RULE_3     all  --  any    any     anywhere
trench1ams

Chain Cid459E8281.3 (1 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 RULE_3     all  --  any    any     anywhere
10.150.0.226
    0     0 RULE_3     all  --  any    any     anywhere
212.165.108.5
    0     0 RULE_3     all  --  any    any     anywhere
10.150.65.12
    0     0 RULE_3     all  --  any    any     anywhere
212.165.65.4
    0     0 RULE_3     all  --  any    any     anywhere
10.150.65.13
    0     0 RULE_3     all  --  any    any     anywhere
212.165.65.5

Chain Cid459E82B3.0 (2 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 Cid459E82B3.1  udp  --  any    any     anywhere
 anywhere            udp multiport dports snmptrap,syslog,tftp

Chain Cid459E82B3.1 (1 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.6
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.38
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.7
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.39
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.9
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.4
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.36
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.208
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.5
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.37
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.209
    0     0 ACCEPT     all  --  any    any     anywhere
POPA
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.44
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.216
    0     0 ACCEPT     all  --  any    any     anywhere
POPB
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.45
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.217
    0     0 ACCEPT     all  --  any    any     anywhere
host-83-146-60-149.bulldogdsl.com
    0     0 ACCEPT     all  --  any    any     anywhere
fre-67677.easynet.co.uk
    0     0 ACCEPT     all  --  any    any     anywhere
host-84-9-3-176.bulldogdsl.com/28
    0     0 ACCEPT     all  --  any    any     anywhere
host-83-146-45-128.bulldogdsl.com/28
    0     0 ACCEPT     all  --  any    any     anywhere
213.250.154.166
    0     0 ACCEPT     all  --  any    any     anywhere
prodba.plus.com
    0     0 ACCEPT     all  --  any    any     anywhere
83.71.198.237
    0     0 ACCEPT     all  --  any    any     anywhere
121.247.160.154.Ahmedabad-static-bb.vsnl.net.in
    0     0 ACCEPT     all  --  any    any     anywhere
POPB.Staging

Chain Cid459E82B3.2 (1 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 Cid459E82B3.3  all  --  any    any     10.150.0.226
 anywhere
    0     0 Cid459E82B3.3  all  --  any    any     212.165.108.5
 anywhere
    0     0 Cid459E82B3.3  all  --  any    any     10.150.65.12
 anywhere
    0     0 Cid459E82B3.3  all  --  any    any     212.165.65.4
 anywhere
    0     0 Cid459E82B3.3  all  --  any    any     10.150.65.13
 anywhere
    0     0 Cid459E82B3.3  all  --  any    any     212.165.65.5
 anywhere

Chain Cid459E82B3.3 (6 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.6
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.38
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.7
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.39
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.9
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.4
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.36
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.208
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.5
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.37
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.209
    0     0 ACCEPT     all  --  any    any     anywhere
POPA
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.44
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.216
    0     0 ACCEPT     all  --  any    any     anywhere
POPB
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.45
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.217
    0     0 ACCEPT     all  --  any    any     anywhere
host-83-146-60-149.bulldogdsl.com
    0     0 ACCEPT     all  --  any    any     anywhere
fre-67677.easynet.co.uk
    0     0 ACCEPT     all  --  any    any     anywhere
host-84-9-3-176.bulldogdsl.com/28
    0     0 ACCEPT     all  --  any    any     anywhere
host-83-146-45-128.bulldogdsl.com/28
    0     0 ACCEPT     all  --  any    any     anywhere
213.250.154.166
    0     0 ACCEPT     all  --  any    any     anywhere
prodba.plus.com
    0     0 ACCEPT     all  --  any    any     anywhere
83.71.198.237
    0     0 ACCEPT     all  --  any    any     anywhere
121.247.160.154.Ahmedabad-static-bb.vsnl.net.in
    0     0 ACCEPT     all  --  any    any     anywhere
POPB.Staging

Chain Cid459E82B3.4 (1 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 Cid459E82B3.5  all  --  any    any     10.150.0.226
 anywhere
    0     0 Cid459E82B3.5  all  --  any    any     212.165.108.5
 anywhere
    0     0 Cid459E82B3.5  all  --  any    any     10.150.65.12
 anywhere
    0     0 Cid459E82B3.5  all  --  any    any     212.165.65.4
 anywhere
    0     0 Cid459E82B3.5  all  --  any    any     10.150.65.13
 anywhere
    0     0 Cid459E82B3.5  all  --  any    any     212.165.65.5
 anywhere

Chain Cid459E82B3.5 (6 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.6
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.38
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.7
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.39
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.9
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.4
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.36
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.208
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.5
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.37
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.209
    0     0 ACCEPT     all  --  any    any     anywhere
POPA
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.44
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.216
    0     0 ACCEPT     all  --  any    any     anywhere
POPB
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.45
    0     0 ACCEPT     all  --  any    any     anywhere
212.165.120.217
    0     0 ACCEPT     all  --  any    any     anywhere
host-83-146-60-149.bulldogdsl.com
    0     0 ACCEPT     all  --  any    any     anywhere
fre-67677.easynet.co.uk
    0     0 ACCEPT     all  --  any    any     anywhere
host-84-9-3-176.bulldogdsl.com/28
    0     0 ACCEPT     all  --  any    any     anywhere
host-83-146-45-128.bulldogdsl.com/28
    0     0 ACCEPT     all  --  any    any     anywhere
213.250.154.166
    0     0 ACCEPT     all  --  any    any     anywhere
prodba.plus.com
    0     0 ACCEPT     all  --  any    any     anywhere
83.71.198.237
    0     0 ACCEPT     all  --  any    any     anywhere
121.247.160.154.Ahmedabad-static-bb.vsnl.net.in
    0     0 ACCEPT     all  --  any    any     anywhere
POPB.Staging

Chain Cid45A018F5.0 (3 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 RULE_4     all  --  any    any     anywhere
10.150.0.225
    0     0 RULE_4     all  --  any    any     anywhere
trench1ams
    0     0 RULE_4     all  --  any    any     anywhere
trench1ams

Chain Cid45A018F5.1 (3 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 RULE_4     all  --  any    any     anywhere
10.150.0.225
    0     0 RULE_4     all  --  any    any     anywhere
trench1ams
    0     0 RULE_4     all  --  any    any     anywhere
trench1ams

Chain RULE_2 (16 references)
 pkts bytes target     prot opt in     out     source
destination
 1112 79284 LOG        all  --  any    any     anywhere
anywhere            LOG level info prefix `RULE 2 -- ACCEPT '
 1112 79284 ACCEPT     all  --  any    any     anywhere
anywhere

Chain RULE_3 (16 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 LOG        all  --  any    any     anywhere
anywhere            LOG level info prefix `RULE 3 -- ACCEPT '
    0     0 ACCEPT     all  --  any    any     anywhere
anywhere

Chain RULE_4 (6 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 LOG        all  --  any    any     anywhere
anywhere            LOG level info prefix `RULE 4 -- ACCEPT '
    0     0 ACCEPT     all  --  any    any     anywhere
anywhere

Chain RULE_5 (3 references)
 pkts bytes target     prot opt in     out     source
destination
  276 25098 LOG        all  --  any    any     anywhere
anywhere            LOG level info prefix `RULE 5 -- DENY '
  276 25098 DROP       all  --  any    any     anywhere
anywhere

Chain lo_In_RULE_0 (1 references)
 pkts bytes target     prot opt in     out     source
destination
10736  644K LOG        all  --  any    any     anywhere
anywhere            LOG level info prefix `RULE 0 -- ACCEPT '
10736  644K ACCEPT     all  --  any    any     anywhere
anywhere

Chain lo_Out_RULE_0 (1 references)
 pkts bytes target     prot opt in     out     source
destination
10736  644K LOG        all  --  any    any     anywhere
anywhere            LOG level info prefix `RULE 0 -- ACCEPT '
10736  644K ACCEPT     all  --  any    any     anywhere
anywhere


thanks

Saurabh

On 1/26/07, Ted Phelps <phelps@gnusto.com> wrote:
> "Saurabh Mehrotra" writes:
> > I am using Red Hat Enterprise Linux AS release 4 (Nahant Update 3) with
> > Kernel 2.6.9-34.ELsmp #1
> >
> > I am using Iptables for firewall .
> >
> > But without firewall I m able to nslookup my own DNS server but whenever I
> > enabled firewall I am not able to nslookup to my own system.
>
> It sounds like your firewall is blocking DNS traffic.
>
> You'll have to show us your firewall rules if we're going to be able to
> help you:
>
>     iptables -v -L
>
> Cheers,
> -Ted
>

Re: Iptables problem

[Ted Phelps]

Hi Saurabh,

"Saurabh Mehrotra" writes:
> Please find output of
> 
> iptables -v -L

I'm afraid I'm not clever enough to comprehend what your rules are
trying to do.  Also, I don't know what the IP address of trench1 is nor
where the firewall is located in the network, so it's difficult to see
which rules would be involved.

The likely cause of your problem is that the DNS request or its reply is
being dropped by your firewall.  The easiest way to see which is
happening is to have tcpdump listen to port 53 on 212.165.108.4 to see
if the request is coming in and if a reply is going out.

The iptables output you sent has packet counts for each rule, which
should help you to determine which rule is dropping or failing to
forward the DNS packets.

Hope that helps,
-Ted

Re: Iptables problem

[Saurabh Mehrotra]

Thanks for reply .

Can you guide me how to set up TCP dump on RHEL 4 and test .

Can u explain this more so that I will calculate that..

"  packet counts for each rule, which
 should help you to determine which rule is dropping or failing to
 forward the DNS packets."

It will be helpful for me .

Thanks saurabh

On 1/26/07, Ted Phelps <phelps@gnusto.com> wrote:
>
> Hi Saurabh,
>
> "Saurabh Mehrotra" writes:
> > Please find output of
> >
> > iptables -v -L
>
> I'm afraid I'm not clever enough to comprehend what your rules are
> trying to do.  Also, I don't know what the IP address of trench1 is nor
> where the firewall is located in the network, so it's difficult to see
> which rules would be involved.
>
> The likely cause of your problem is that the DNS request or its reply is
> being dropped by your firewall.  The easiest way to see which is
> happening is to have tcpdump listen to port 53 on 212.165.108.4 to see
> if the request is coming in and if a reply is going out.
>
> The iptables output you sent has packet counts for each rule, which
> should help you to determine which rule is dropping or failing to
> forward the DNS packets.
>
> Hope that helps,
> -Ted
>

Re: Iptables problem

[Ted Phelps]

"Saurabh Mehrotra" writes:
> Can you guide me how to set up TCP dump on RHEL 4 and test.

I'm afraid I don't use Red Hat Linux or RPMs so I'm not going to be able
to help you instal tcpdump.  There's a good chance that it's installed
by default, though.  To run it and monitor DNS traffic, do this:

    tcpdump port 53
 
> Can u explain this more so that I will calculate that..
> 
> "  packet counts for each rule, which
>  should help you to determine which rule is dropping or failing to
>  forward the DNS packets."

(1) Run iptables -v -L
(2) Look at the rules you believe should match UDP traffic on port 53
    between trench1 and 212.165.108.4.  Note the number of packets which
    have matched these rules.
(3) Run nslookup
(4) Run iptables -v -L again
(5) Look at the rules you believe should match UDP traffic on port 53
    between trench1 and 212.165.108.4.  Note the number of packets which
    have matched these rules.
(6) Compare the numbers from steps (2) and (5) to see if they've
    changed.  If not then the rules aren't doing what you think they
    are.

You may find a command like the following helpful:

    watch iptables -v -L

Cheers,
-Ted

IPtables problem

[Per Jørgensen]

Hej List.

I have a problem wit my Firewall - That is build upon Soekris 4801 with 
Debian Stable and IPTABLES.

I have from my work - been giving a internet connection - with static IP 
- and a range with 2 IP more.

Now I would like to use the extra IP for more cases.
Eth0 = WAN
eth0:0 WAN - extra IP 1
eth0:1 WAN - extra IP 2
eth1 = Lan
eth2 = DMZ
eth3 = testzone ( Pluto system)

I have placed my script here - http://linux.pbj-design.dk/IPTABLES.TXT
so you'll be able to se itt.

The problem is that I cannot get the connection on the extra IP1 to 
forward all request on port 22 & 80 - to the machine that is placed in 
eth3. I only gets a - Cannot display the page. I know the server is 
working OK - caurse when I place my computer on eth3 subnet - and point 
directly - it works.  So don't quite know what I'm doing wrong here - so 
please guide me to the rigth direction.

Thanks a lot!

-- 

Med Venlig Hilsen

Greetings

Per Jørgensen
Linux-user 393221
linux@pbj-design.dk <mailto:linux@pbj-design.dk>
<mailto:linux@pbj-design.dk>http://linux.pbj-design.dk 
<http://linux.pbj-design.dk/>

Re: IPtables problem

[Pascal Hambourg]

Hello,

Per Jørgensen a écrit :
> 
> The problem is that I cannot get the connection on the extra IP1 to 
> forward all request on port 22 & 80 - to the machine that is placed in 
> eth3.

I think that the following rule is wrong :

> $IPTABLES -A FORWARD -i $WAN -d $WAN1_IP -o $PLUTO -j wantopluto

"-d $WAN1_IP" should be removed.

This script is a very early beta version, isn't it ?

iptables problem

[Cam Bazz]

Hello

I am running a glassfish server and I need the basic requirement of
forwarding port 80 to port 8080. Here is what I have done: (I put
1.1.1.1 instead of my real ip adress.)

#
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT;
iptables -A INPUT --destination 1.1.1.1/32 -p tcp --dport 8080 -m
conntrack --ctstate DNAT -j ACCEPT;
iptables -t nat -A PREROUTING -d 1.1.1.1/32 -p tcp --dport 80 -j
REDIRECT --to-port 8080;
iptables -A INPUT -j DROP;
iptables -I INPUT 1 -i lo -j ACCEPT;
#


it works fine. but here is the problem. I added another ip address
with ip aliasing and now I got eth0:1.

I want to run apache on port 80 on this ip.

but no matter what I tried, I could not modify the rules so packets
coming to eth0:1 port80 do not go to port 8080 on eth0. currently all
packets routed to eth0:1 port80 goes to eth0 port 8080.

any ideas/recomendations/help greatly appreciated.

Best regards,
-C.B.

Re: iptables problem

[Matt Zagrabelny]

[-- Attachment #1: Type: text/plain, Size: 1441 bytes --]

On Fri, 2008-09-05 at 14:12 +0300, Cam Bazz wrote:
> Hello
> 
> I am running a glassfish server and I need the basic requirement of
> forwarding port 80 to port 8080. Here is what I have done: (I put
> 1.1.1.1 instead of my real ip adress.)
> 
> #
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT;
> iptables -A INPUT --destination 1.1.1.1/32 -p tcp --dport 8080 -m
> conntrack --ctstate DNAT -j ACCEPT;
> iptables -t nat -A PREROUTING -d 1.1.1.1/32 -p tcp --dport 80 -j
> REDIRECT --to-port 8080;
> iptables -A INPUT -j DROP;
> iptables -I INPUT 1 -i lo -j ACCEPT;
> #
> 
> 
> it works fine. but here is the problem. I added another ip address
> with ip aliasing and now I got eth0:1.
> 
> I want to run apache on port 80 on this ip.
> 
> but no matter what I tried, I could not modify the rules so packets
> coming to eth0:1 port80 do not go to port 8080 on eth0. currently all
> packets routed to eth0:1 port80 goes to eth0 port 8080.
> 
> any ideas/recomendations/help greatly appreciated.

The DNAT target can accept ip addresses as well as port numbers.

-- 
Matt Zagrabelny - mzagrabe@d.umn.edu - (218) 726 8844
University of Minnesota Duluth
Information Technology Systems & Services
PGP key 1024D/84E22DA2 2005-11-07
Fingerprint: 78F9 18B3 EF58 56F5 FC85  C5CA 53E7 887F 84E2 2DA2

He is not a fool who gives up what he cannot keep to gain what he cannot
lose.
-Jim Elliot

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: iptables problem

[Grant Taylor]

On 09/05/08 06:12, Cam Bazz wrote:
> but no matter what I tried, I could not modify the rules so packets
> coming to eth0:1 port80 do not go to port 8080 on eth0. currently all
> packets routed to eth0:1 port80 goes to eth0 port 8080.
> 
> any ideas/recomendations/help greatly appreciated.

Add the following rule:

    iptables -A INPUT --destination 1.1.1.2/32 -p tcp --dport 80 -m 
conntrack --ctstate NEW -j ACCEPT

This should allow your traffic to come in to port 80 on the new address.



Grant. . . .