All of lore.kernel.org
 help / color / mirror / Atom feed
* problem reach the internal.
@ 2002-11-29 19:32 james.Q.L
  2002-11-30  1:03 ` james.Q.L
  0 siblings, 1 reply; 8+ messages in thread
From: james.Q.L @ 2002-11-29 19:32 UTC (permalink / raw)
  To: netfilter

hi,

i have access to my firewall ip at port 8888 forward to port 80 at internal machine 192.168.0.3 .
but the connection always fail. can someone help me debug ? thanks.


[root@cozy166 public]#iptables -L --line-number -n
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         
1    REJECT     tcp  --  0.0.0.0/0            0.0.0.0/0          tcp dpt:6000 reject-with
tcp-reset 

Chain FORWARD (policy DROP)
num  target     prot opt source               destination         
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED 
2    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          
3    ACCEPT     tcp  --  0.0.0.0/0            192.168.0.3        tcp dpt:80 
4    LOG        all  --  0.0.0.0/0            0.0.0.0/0          LOG flags 0 level 4 

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination         

Chain drop-and-log-it (0 references)
num  target     prot opt source               destination         
1    DROP       all  --  0.0.0.0/0            0.0.0.0/0          

[root@cozy166 public]#iptables -L --line-number -n -t nat
Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination         
1    DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0          tcp dpt:8888 to:192.168.0.3:80 

Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination         
1    SNAT       tcp  --  192.168.0.0/24       192.168.0.3        tcp dpt:80 to:192.168.0.1 
2    MASQUERADE  all  --  0.0.0.0/0            0.0.0.0/0          

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination         

the rules i added to try to make it work are :

iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 8888 \
	-j DNAT --to-destination 192.168.0.3:80
iptables -A FORWARD -p tcp --dport 80 -d 192.168.0.3 -j ACCEPT
iptables -t nat -A POSTROUTING -p tcp -s 192.168.0.0/24 -d 192.168.0.3 --dport 80 -j SNAT \ 
        --to-source 192.168.0.1



=====
/James.Q.L

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: problem reach the internal.
  2002-11-29 19:32 problem reach the internal james.Q.L
@ 2002-11-30  1:03 ` james.Q.L
  2002-11-30  1:35   ` Anders Fugmann
  0 siblings, 1 reply; 8+ messages in thread
From: james.Q.L @ 2002-11-30  1:03 UTC (permalink / raw)
  To: netfilter

sorry, i forgot mention that the request from outside my local network to the INET_IP:8888 is
fine. only the internal request to it fails.

i do not see what is wrong in the rules, anyone ? 



 --- "james.Q.L" <shijialeeee@yahoo.ca> wrote: > hi,
> 
> i have access to my firewall ip at port 8888 forward to port 80 at internal machine 192.168.0.3
> .
> but the connection always fail. can someone help me debug ? thanks.
> 
> 
> [root@cozy166 public]#iptables -L --line-number -n
> Chain INPUT (policy ACCEPT)
> num  target     prot opt source               destination         
> 1    REJECT     tcp  --  0.0.0.0/0            0.0.0.0/0          tcp dpt:6000 reject-with
> tcp-reset 
> 
> Chain FORWARD (policy DROP)
> num  target     prot opt source               destination         
> 1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED 
> 2    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          
> 3    ACCEPT     tcp  --  0.0.0.0/0            192.168.0.3        tcp dpt:80 
> 4    LOG        all  --  0.0.0.0/0            0.0.0.0/0          LOG flags 0 level 4 
> 
> Chain OUTPUT (policy ACCEPT)
> num  target     prot opt source               destination         
> 
> Chain drop-and-log-it (0 references)
> num  target     prot opt source               destination         
> 1    DROP       all  --  0.0.0.0/0            0.0.0.0/0          
> 
> [root@cozy166 public]#iptables -L --line-number -n -t nat
> Chain PREROUTING (policy ACCEPT)
> num  target     prot opt source               destination         
> 1    DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0          tcp dpt:8888 to:192.168.0.3:80 
> 
> Chain POSTROUTING (policy ACCEPT)
> num  target     prot opt source               destination         
> 1    SNAT       tcp  --  192.168.0.0/24       192.168.0.3        tcp dpt:80 to:192.168.0.1 
> 2    MASQUERADE  all  --  0.0.0.0/0            0.0.0.0/0          
> 
> Chain OUTPUT (policy ACCEPT)
> num  target     prot opt source               destination         
> 
> the rules i added to try to make it work are :
> 
> iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 8888 \
> 	-j DNAT --to-destination 192.168.0.3:80
> iptables -A FORWARD -p tcp --dport 80 -d 192.168.0.3 -j ACCEPT
> iptables -t nat -A POSTROUTING -p tcp -s 192.168.0.0/24 -d 192.168.0.3 --dport 80 -j SNAT \ 
>         --to-source 192.168.0.1

=====
/James.Q.L

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: problem reach the internal.
  2002-11-30  1:03 ` james.Q.L
@ 2002-11-30  1:35   ` Anders Fugmann
  2002-11-30  2:20     ` Joel Newkirk
  0 siblings, 1 reply; 8+ messages in thread
From: Anders Fugmann @ 2002-11-30  1:35 UTC (permalink / raw)
  To: james.Q.L; +Cc: netfilter

james.Q.L wrote:
> sorry, i forgot mention that the request from outside my local network to the INET_IP:8888 is
> fine. only the internal request to it fails.
> 
> i do not see what is wrong in the rules, anyone ? 

It cannot be done, as the webserver will try to give an answer to the 
query directly, and not back through your router, and thus the client 
will not accept the reply.

For a more complete explanation, search the email archives. This 
question has been asked and answered numerous times.

Regards
Anders Fugmann



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: problem reach the internal.
  2002-11-30  1:35   ` Anders Fugmann
@ 2002-11-30  2:20     ` Joel Newkirk
  2002-11-30  8:34       ` james.Q.L
  2002-11-30 11:44       ` Anders Fugmann
  0 siblings, 2 replies; 8+ messages in thread
From: Joel Newkirk @ 2002-11-30  2:20 UTC (permalink / raw)
  To: Anders Fugmann, james.Q.L; +Cc: netfilter

On Friday 29 November 2002 08:35 pm, Anders Fugmann wrote:
> james.Q.L wrote:
> > sorry, i forgot mention that the request from outside my local network to
> > the INET_IP:8888 is fine. only the internal request to it fails.
> >
> > i do not see what is wrong in the rules, anyone ?
>
> It cannot be done, as the webserver will try to give an answer to the
> query directly, and not back through your router, and thus the client
> will not accept the reply.
>
> For a more complete explanation, search the email archives. This
> question has been asked and answered numerous times.

That's what his SNAT rule should handle: (snippet from original message)

> the rules i added to try to make it work are :
> 
> iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 8888 \
>       -j DNAT --to-destination 192.168.0.3:80
> iptables -A FORWARD -p tcp --dport 80 -d 192.168.0.3 -j ACCEPT
> iptables -t nat -A POSTROUTING -p tcp -s 192.168.0.0/24 -d 192.168.0.3 \
>     --dport 80 -j SNAT --to-source 192.168.0.1

port 80 requests heading out to the server (192.168.0.3) from anywhere on the 
lan (already DNATted in prerouting) are SNATted to appear to come from the 
firewall/router (192.168.0.1) so that they return through it properly.  Yes, 
this has been answered before, and is covered in the DNAT section of Oscar's 
tutorial, but the rules he has here appear to be correct. (well, along with 
the FORWARD EST/REL rule I didn't include in this snippet)

James - I'd recommend that you try:
iptables -z
to clear counters, then try accessing the server from the LAN, then
iptables -L -v -n
to list your ruleset along with the packet/byte counts which matched.  This 
will often show where unexpected things are happening.  IE, if the counts in 
the FORWARD rules accepting ESTABLISHED/RELATED and packets destined for the 
server are both zero, then the problem is at PREROUTING.  If the FORWARD 
count for server-bound shows your request, but your POSTROUTING SNAT is zero, 
or if those both show counts but nothing coming back from the server 
(EST/REL) those can narrow things down.  (of course if the DNAT rule in 
PREROUTING counts 0 that pretty much nails the problem down... :^) Extreme 
Logging can help as well, where you insert a LOG rule as the first rule in 
each chain, try to connect, then check the logs.  This can generate a LOT of 
logging if there is other activity through the firewall, though.  If you do 
this, you should log nat PRE and POST, FORWARD, and INPUT.  The first three 
are where it should be, the fourth is where it shouldn't but might, if the 
DNAT isn't matching.

I'd also suggest you reconsider FORWARD rule #2, which accepts EVERYTHING, and 
limit your MASQUERADE to traffic outbound to the internet, simply with 
-o $eth0 or whatever interface connects to the world.

j



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: problem reach the internal.
  2002-11-30  2:20     ` Joel Newkirk
@ 2002-11-30  8:34       ` james.Q.L
  2002-11-30 15:27         ` Joel Newkirk
  2002-11-30 11:44       ` Anders Fugmann
  1 sibling, 1 reply; 8+ messages in thread
From: james.Q.L @ 2002-11-30  8:34 UTC (permalink / raw)
  To: netfilter, Anders Fugmann; +Cc: netfilter

the iptables counter is very neat to debug problem. i never thought of that.

found a problem that in the following ruleset i shouldn't have '-i eth1'. it blocks the internal
DNAT.

> > iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 8888 \
> > 	-j DNAT --to-destination 192.168.0.3:80

i also change the order of the rule in FORWARD chain in Filter table.

the rule for filter table is:
[root@cozy166 Qiang]#iptables -L -n --line-numbers

Chain FORWARD (policy DROP)
num  target     prot opt source               destination         
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED 
2    ACCEPT     tcp  --  0.0.0.0/0            192.168.0.3        tcp dpt:80 
3    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          
4    LOG        all  --  0.0.0.0/0            0.0.0.0/0          LOG flags 0 level 4 
        
the line num 3 and num 2 are swapped.

i tried reset the counter of ruleset and make connection test to it. i found something that i
don't understand. when i am testing from an internal machine to INET_IP:8888 the ruleset for
filter table is (counter has reset to zero)

[root@cozy166 Qiang]#iptables -L -v -n --line-numbers

Chain FORWARD (policy DROP 5 packets, 224 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1    11806   15M ACCEPT     all  --  eth1   eth0    0.0.0.0/0            0.0.0.0/0          state
RELATED,ESTABLISHED 
2        3   144 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.0.3        tcp
dpt:80 
3     8000  341K ACCEPT     all  --  eth0   eth1    0.0.0.0/0            0.0.0.0/0          
4        5   224 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0          LOG
flags 0 level 4 

Chain OUTPUT (policy ACCEPT 13143 packets, 996K bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain drop-and-log-it (0 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0   

####
noticed that the Forward chain has (policy DROP 5 packets, 224 bytes) and the line num 2 has 3
counter and 144bytes hits. it's gotta be a problem here. 
one thing i am unsure is if the counter and packet get hit means the packet get passed or
attempted to pass?  taking a look at the line num 2 ruleset, it shouldn't block proper packet tho.
2    ACCEPT     tcp  --  0.0.0.0/0            192.168.0.3        tcp dpt:80 

another thing i'm unsure is the POSTROUTING and PREROUTING both have two hits and packet records.
so this seems to say the packet got back from the webserver. but if the FORWARD chain drops the
packet there, the POSTROUTING shouldn't have anything..

[root@cozy166 Qiang]#iptables -L -v -n -t nat --line-numbers
Chain PREROUTING (policy ACCEPT 146 packets, 10341 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        4   192 DNAT       tcp  --  *      *       0.0.0.0/0            65.48.28.33        tcp
dpt:8888 to:192.168.0.3:80 

Chain POSTROUTING (policy ACCEPT 1 packets, 249 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        4   192 SNAT       tcp  --  *      *       192.168.0.0/24       192.168.0.3        tcp
dpt:80 to:192.168.0.1 
2       51  2866 MASQUERADE  all  --  *      eth1    0.0.0.0/0            0.0.0.0/0          

Chain OUTPUT (policy ACCEPT 79573 packets, 5705K bytes)
num   pkts bytes target     prot opt in     out     source               destination

James.Q.L

=====
/James.Q.L

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: problem reach the internal.
  2002-11-30  2:20     ` Joel Newkirk
  2002-11-30  8:34       ` james.Q.L
@ 2002-11-30 11:44       ` Anders Fugmann
  1 sibling, 0 replies; 8+ messages in thread
From: Anders Fugmann @ 2002-11-30 11:44 UTC (permalink / raw)
  To: netfilter; +Cc: james.Q.L, netfilter

Joel Newkirk wrote:
> On Friday 29 November 2002 08:35 pm, Anders Fugmann wrote:
>>It cannot be done, as the webserver will try to give an answer to the
>>query directly, and not back through your router, and thus the client
>>will not accept the reply.
>>
>>For a more complete explanation, search the email archives. This
>>question has been asked and answered numerous times.
> 
> 
> That's what his SNAT rule should handle: (snippet from original message)
Thanks for the correction. I see that it can be done, allthough I guess 
that some serious network degradation will result, especially on a half 
duplex network.

Regards
Anders Fugmann



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: problem reach the internal.
  2002-11-30  8:34       ` james.Q.L
@ 2002-11-30 15:27         ` Joel Newkirk
  2002-12-01 22:35           ` james.Q.L
  0 siblings, 1 reply; 8+ messages in thread
From: Joel Newkirk @ 2002-11-30 15:27 UTC (permalink / raw)
  To: james.Q.L; +Cc: netfilter

On Saturday 30 November 2002 03:34 am, james.Q.L wrote:
> the iptables counter is very neat to debug problem. i never thought of
> that.
>
> found a problem that in the following ruleset i shouldn't have '-i eth1'.
> it blocks the internal DNAT.
>
> > > iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 8888 \
> > > 	-j DNAT --to-destination 192.168.0.3:80
>
> i also change the order of the rule in FORWARD chain in Filter table.
>
> the rule for filter table is:
> [root@cozy166 Qiang]#iptables -L -n --line-numbers
>
> Chain FORWARD (policy DROP)
> num  target     prot opt source               destination
> 1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          state
> RELATED,ESTABLISHED 2    ACCEPT     tcp  --  0.0.0.0/0           
> 192.168.0.3        tcp dpt:80 3    ACCEPT     all  --  0.0.0.0/0           
> 0.0.0.0/0
> 4    LOG        all  --  0.0.0.0/0            0.0.0.0/0          LOG flags
> 0 level 4
>
> the line num 3 and num 2 are swapped.
>
> i tried reset the counter of ruleset and make connection test to it. i
> found something that i don't understand. when i am testing from an internal
> machine to INET_IP:8888 the ruleset for filter table is (counter has reset
> to zero)
>
> [root@cozy166 Qiang]#iptables -L -v -n --line-numbers
>
> Chain FORWARD (policy DROP 5 packets, 224 bytes)
> num   pkts bytes target     prot opt in     out     source       destination 
> 1    11806   15M ACCEPT     all  --  eth1   eth0    0.0.0.0/0  
>          0.0.0.0/0          state RELATED,ESTABLISHED
> 2        3   144 ACCEPT     tcp  --  *      *       0.0.0.0/0           
> 	192.168.0.3        tcp dpt:80
> 3     8000  341K ACCEPT     all  --  eth0   eth1    0.0.0.0/0           
> 	0.0.0.0/0 
> 4        5   224 LOG        all  --  *      *       0.0.0.0/0    
>        0.0.0.0/0          LOG flags 0 level 4
>
> Chain OUTPUT (policy ACCEPT 13143 packets, 996K bytes)
> num   pkts bytes target     prot opt in     out     source              
> destination
>
> Chain drop-and-log-it (0 references)
> num   pkts bytes target     prot opt in     out     source              
> destination 
> 1        0     0 DROP       all  --  *      *       0.0.0.0/0  
>          0.0.0.0/0
>
> ####
> noticed that the Forward chain has (policy DROP 5 packets, 224 bytes) and
> the line num 2 has 3 counter and 144bytes hits. it's gotta be a problem
> here.

Well, what were those 5 packets?  They were logged by line 4.  You can add
--log-prefix "IPT:forward drop:" to the rule, and then use:
tail -n 100 /var/log/messages | grep IPT:for 
later to list them.  (or any other useful prefix for the log lines)

> one thing i am unsure is if the counter and packet get hit means the packet
> get passed or attempted to pass?  taking a look at the line num 2 ruleset,
> it shouldn't block proper packet tho. 
> 2    ACCEPT     tcp  --  0.0.0.0/0   192.168.0.3        tcp dpt:80

The counter in the first listing indicates that three packets matched this 
rule, and were accepted.

> another thing i'm unsure is the POSTROUTING and PREROUTING both have two
> hits and packet records. so this seems to say the packet got back from the
> webserver. but if the FORWARD chain drops the packet there, the POSTROUTING
> shouldn't have anything..
>
> [root@cozy166 Qiang]#iptables -L -v -n -t nat --line-numbers
> Chain PREROUTING (policy ACCEPT 146 packets, 10341 bytes)
> num   pkts bytes target     prot opt in     out     source              
> destination 
> 1        4   192 DNAT       tcp  --  *      *       0.0.0.0/0  
>          65.48.28.33        tcp dpt:8888 to:192.168.0.3:80
>
> Chain POSTROUTING (policy ACCEPT 1 packets, 249 bytes)
> num   pkts bytes target     prot opt in     out     source              
> destination 
> 1        4   192 SNAT       tcp  --  *      *    192.168.0.0/24       
> 	192.168.0.3        tcp dpt:80 to:192.168.0.1

This tells us that 4 packets, total 192 bytes, matched this rule in 
POSTROUTING.  4 packets from somewhere on the LAN, going to the server.  The 
rule above this shows 4 packets, total 192 bytes, matching the rule in 
PREROUTING that performs the DNAT.

Unfortunately this doesn't tell us anything about return packets.  The only 
places those would be matched (at least with the listed rules) are in the PRE 
and POST policies, and in the ESTABLISHED rule in FORWARD.  However, 
PREROUTING policy accepted 146 packets, POSTROUTING policy only 1, and the 
listed rules match 4 and 4, so the remaining 145 packets are unaccounted for 
in the data here.

> 2       51  2866 MASQUERADE  all  --  *      eth1    0.0.0.0/0           
> 0.0.0.0/0
>
> Chain OUTPUT (policy ACCEPT 79573 packets, 5705K bytes)
> num   pkts bytes target     prot opt in     out     source              
> destination

j



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: problem reach the internal.
  2002-11-30 15:27         ` Joel Newkirk
@ 2002-12-01 22:35           ` james.Q.L
  0 siblings, 0 replies; 8+ messages in thread
From: james.Q.L @ 2002-12-01 22:35 UTC (permalink / raw)
  To: netfilter; +Cc: netfilter


> > [root@cozy166 Qiang]#iptables -L -n --line-numbers
> >
> > Chain FORWARD (policy DROP)
> > num  target     prot opt source               destination
> > 1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          state
> > RELATED,ESTABLISHED 2    ACCEPT     tcp  --  0.0.0.0/0           
> > 192.168.0.3        tcp dpt:80 3    ACCEPT     all  --  0.0.0.0/0           
> > 0.0.0.0/0
> > 4    LOG        all  --  0.0.0.0/0            0.0.0.0/0          LOG flags
> > 0 level 4
> >
> > the line num 3 and num 2 are swapped.
> >
> > i tried reset the counter of ruleset and make connection test to it. i
> > found something that i don't understand. when i am testing from an internal
> > machine to INET_IP:8888 the ruleset for filter table is (counter has reset
> > to zero)
> >
> > [root@cozy166 Qiang]#iptables -L -v -n --line-numbers
> >
> > Chain FORWARD (policy DROP 5 packets, 224 bytes)
> > num   pkts bytes target     prot opt in     out     source       destination 
> > 1    11806   15M ACCEPT     all  --  eth1   eth0    0.0.0.0/0  
> >          0.0.0.0/0          state RELATED,ESTABLISHED
> > 2        3   144 ACCEPT     tcp  --  *      *       0.0.0.0/0           
> > 	192.168.0.3        tcp dpt:80
> > 3     8000  341K ACCEPT     all  --  eth0   eth1    0.0.0.0/0           
> > 	0.0.0.0/0 
> > 4        5   224 LOG        all  --  *      *       0.0.0.0/0    
> >        0.0.0.0/0          LOG flags 0 level 4
> >
> > Chain OUTPUT (policy ACCEPT 13143 packets, 996K bytes)
> > num   pkts bytes target     prot opt in     out     source              
> > destination
> >
> > Chain drop-and-log-it (0 references)
> > num   pkts bytes target     prot opt in     out     source              
> > destination 
> > 1        0     0 DROP       all  --  *      *       0.0.0.0/0  
> >          0.0.0.0/0
> >
> > ####
> > noticed that the Forward chain has (policy DROP 5 packets, 224 bytes) and
> > the line num 2 has 3 counter and 144bytes hits. it's gotta be a problem
> > here.

haven't nailed the problem yet.. can i ask further help please ? 

#eth0 is internal IF, eth1 external IF.

#dmesg | tail

FWD drop IN=eth0 OUT=eth0 SRC=192.168.0.3 DST=192.168.0.12 LEN=64 TOS=0x00 PREC=0x00 TTL=127
ID=22869 DF PROTO=TCP SPT=80 DPT=1026 WINDOW=17520 RES=0x00 ACK SYN URGP=0 

so it's the FWD chain problem?

# request INET_IP:8888 from internal machine 192.168.0.12. only one type of msg greped out.
#grep 192.168.0.12 /proc/net/ip_conntrack

tcp      6 59 SYN_RECV src=192.168.0.12 dst=65.48.28.33 sport=1109 dport=8888 src=192.168.0.3
dst=192.168.0.1 sport=80 dport=1109 use=1 

this seeems to be SYN/ACK in return. but no established further on..

here is more verbose iptables dump.. 
from iptables -L -v -n

Chain FORWARD (policy DROP 130 packets, 7822 bytes)
 pkts bytes target     prot opt in     out     source               destination         
1292K 1462M ACCEPT     all  --  eth1   eth0    0.0.0.0/0            0.0.0.0/0          state
RELATED,ESTABLISHED 
   55  3204 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.0.3        tcp dpt:80 
18402 1286K ACCEPT     all  --  eth0   eth1    0.0.0.0/0            0.0.0.0/0          
   53  3296 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0          LOG flags 0
level 4 prefix `FWD DROP ' 

from iptables -L -v -n -t nat

Chain PREROUTING (policy ACCEPT 51091 packets, 3818K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    7   396 DNAT       tcp  --  *      *       0.0.0.0/0            65.48.28.33        tcp
dpt:8888 to:192.168.0.3:80 

Chain POSTROUTING (policy ACCEPT 276 packets, 46588 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   10   576 SNAT       tcp  --  *      *       192.168.0.0/24       192.168.0.3        tcp dpt:80
to:192.168.0.1 
 5715  315K MASQUERADE  all  --  *      eth1    0.0.0.0/0            0.0.0.0/0      


many thanks,

=====
/James.Q.L

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2002-12-01 22:35 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-11-29 19:32 problem reach the internal james.Q.L
2002-11-30  1:03 ` james.Q.L
2002-11-30  1:35   ` Anders Fugmann
2002-11-30  2:20     ` Joel Newkirk
2002-11-30  8:34       ` james.Q.L
2002-11-30 15:27         ` Joel Newkirk
2002-12-01 22:35           ` james.Q.L
2002-11-30 11:44       ` Anders Fugmann

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.