Newbie - problem with PREROUTING on nat - I'm missing something obvious?

Newbie - problem with PREROUTING on nat - I'm missing something obvious?

[al clethero]

Folks

I'm having some issues with the nat table and redirection. I'm trying to
redirect traffic destined for port 80 to port
8080, so that there is no need to specify a proxy server in the browser
settings. I'm fairly new to netfilter, so it may be I'm missing
something obvious. If so, I apologise beforehand!

I set up a contrived scenario on my isolated test system as follows (so
the browser, squid etc are all running on the same box):

1/ I have nothing listening on port 80
2/ Squid is running, listening on port 8080
3/ Proxy options are turned off in the browser
4/ iptables has the following statement in the nat table (and this is
the only statement in my iptables while I test this out):

   iptables -t nat -A PREROUTING  -p tcp --dport 80 -j REDIRECT
--to-ports 8080

My understanding of this rule is that any tcp packets destined for port
80 on any interface will be redirected to port 8080.

5/ I try to connect to www.google.com from the browser and the following
should happen:

the request goes out to port 80
the rule in the nat table picks up the packet and forwards it to port
8080, where squid connects to google, retrieves the page and supplies it
to the browser.

However, this doesn't seem to happen, connections go straight through to
google from port 80 without being redirected. I have tested this by
shutting down squid and having no proxy servers configured in the
browser, yet I can still connect, whereas I would expect an error.

If I check the iptables status before and after doing this I get

Before

iptables -t nat -v -L
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source              
destination
         
    0     0 REDIRECT   tcp  --  any    any     anywhere            
anywhere
       tcp dpt:http redir ports 8080
 
Chain POSTROUTING (policy ACCEPT 10 packets, 600 bytes)
 pkts bytes target     prot opt in     out     source              
destination
         
 
Chain OUTPUT (policy ACCEPT 10 packets, 600 bytes)
 pkts bytes target     prot opt in     out     source              
destination
         
After

Chain PREROUTING (policy ACCEPT 43 packets, 3496 bytes)
 pkts bytes target     prot opt in     out     source              
destination
         
    0     0 REDIRECT   tcp  --  any    any     anywhere            
anywhere
       tcp dpt:http redir ports 8080
 
Chain POSTROUTING (policy ACCEPT 209 packets, 13148 bytes)
 pkts bytes target     prot opt in     out     source              
destination
         
 
Chain OUTPUT (policy ACCEPT 209 packets, 13148 bytes)
 pkts bytes target     prot opt in     out     source              
destination
         

Since the above seems to indicate packets going through the nat
prerouting chain but not being acted upon I suspect I am missing
something fairly obvious!

My version of Linux is Redhat 9.0 with a kernel of:
Linux r1 2.4.20-8 #1 Thu Mar 13 17:18:24 EST 2003 i686 athlon i386
GNU/Linux

A modprobe returns

/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/arp_tables.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/arptable_filter.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ip_conntrack.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ip_conntrack_ftp.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ip_conntrack_irc.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ip_nat_ftp.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ip_nat_irc.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ip_nat_snmp_basic.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ip_queue.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipchains.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipfwadm.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_DSCP.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_ECN.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_LOG.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_MARK.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_MASQUERADE.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_MIRROR.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_REDIRECT.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_REJECT.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_TCPMSS.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_TOS.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_ULOG.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_ah.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_conntrack.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_dscp.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_ecn.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_esp.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_helper.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_length.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_limit.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_mac.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_mark.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_multiport.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_owner.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_pkttype.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_state.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_tcpmss.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_tos.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_ttl.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/ipt_unclean.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/iptable_filter.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/iptable_mangle.o
/lib/modules/2.4.20-8/kernel/net/ipv4/netfilter/iptable_nat.o
/lib/modules/2.4.20-8/kernel/net/ipv6/netfilter/ip6_tables.o
/lib/modules/2.4.20-8/kernel/net/ipv6/netfilter/ip6t_LOG.o
/lib/modules/2.4.20-8/kernel/net/ipv6/netfilter/ip6t_MARK.o
/lib/modules/2.4.20-8/kernel/net/ipv6/netfilter/ip6t_eui64.o
/lib/modules/2.4.20-8/kernel/net/ipv6/netfilter/ip6t_length.o
/lib/modules/2.4.20-8/kernel/net/ipv6/netfilter/ip6t_limit.o
/lib/modules/2.4.20-8/kernel/net/ipv6/netfilter/ip6t_mac.o
/lib/modules/2.4.20-8/kernel/net/ipv6/netfilter/ip6t_mark.o
/lib/modules/2.4.20-8/kernel/net/ipv6/netfilter/ip6t_multiport.o
/lib/modules/2.4.20-8/kernel/net/ipv6/netfilter/ip6t_owner.o
/lib/modules/2.4.20-8/kernel/net/ipv6/netfilter/ip6table_filter.o
/lib/modules/2.4.20-8/kernel/net/ipv6/netfilter/ip6table_mangle.o


any thoughts would be appreciated,

regards

al

Re: Newbie - problem with PREROUTING on nat - I'm missing something obvious?

[John A. Sullivan III]

On Wed, 2004-03-17 at 08:49, al clethero wrote:
> Folks
> 
> I'm having some issues with the nat table and redirection. I'm trying to
> redirect traffic destined for port 80 to port
> 8080, so that there is no need to specify a proxy server in the browser
> settings. I'm fairly new to netfilter, so it may be I'm missing
> something obvious. If so, I apologise beforehand!
> 
> I set up a contrived scenario on my isolated test system as follows (so
> the browser, squid etc are all running on the same box):
> 
> 1/ I have nothing listening on port 80
> 2/ Squid is running, listening on port 8080
> 3/ Proxy options are turned off in the browser
> 4/ iptables has the following statement in the nat table (and this is
> the only statement in my iptables while I test this out):
> 
>    iptables -t nat -A PREROUTING  -p tcp --dport 80 -j REDIRECT
> --to-ports 8080
> 
> My understanding of this rule is that any tcp packets destined for port
> 80 on any interface will be redirected to port 8080.
> 
> 5/ I try to connect to www.google.com from the browser and the following
> should happen:
> 
> the request goes out to port 80
> the rule in the nat table picks up the packet and forwards it to port
> 8080, where squid connects to google, retrieves the page and supplies it
> to the browser.
> 
> However, this doesn't seem to happen, connections go straight through to
> google from port 80 without being redirected. I have tested this by
> shutting down squid and having no proxy servers configured in the
> browser, yet I can still connect, whereas I would expect an error.
> 
> If I check the iptables status before and after doing this I get
> 
> Before
> 
> iptables -t nat -v -L
> Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target     prot opt in     out     source              
> destination
>          
>     0     0 REDIRECT   tcp  --  any    any     anywhere            
> anywhere
>        tcp dpt:http redir ports 8080
>  
> Chain POSTROUTING (policy ACCEPT 10 packets, 600 bytes)
>  pkts bytes target     prot opt in     out     source              
> destination
>          
>  
> Chain OUTPUT (policy ACCEPT 10 packets, 600 bytes)
>  pkts bytes target     prot opt in     out     source              
> destination
>          
> After
> 
> Chain PREROUTING (policy ACCEPT 43 packets, 3496 bytes)
>  pkts bytes target     prot opt in     out     source              
> destination
>          
>     0     0 REDIRECT   tcp  --  any    any     anywhere            
> anywhere
>        tcp dpt:http redir ports 8080
>  
> Chain POSTROUTING (policy ACCEPT 209 packets, 13148 bytes)
>  pkts bytes target     prot opt in     out     source              
> destination
>          
>  
> Chain OUTPUT (policy ACCEPT 209 packets, 13148 bytes)
>  pkts bytes target     prot opt in     out     source              
> destination
>          
> 
> Since the above seems to indicate packets going through the nat
> prerouting chain but not being acted upon I suspect I am missing
> something fairly obvious!
<snip>
I must confess to not fully digesting your message as I am up against a
deadline.  However, three things come to mind.

1) are you really sure that Squid has stopped? It frequently runs from a
daemon which continually restarts it even after doing a squid -k
shutdown

2) do you really want to redirect all traffic destined for port 80 or
just the traffic coming from the Internal network?

3) I believe you must ensure that traffic can flow to interface lo on
the INPUT chain as well as doing the redirect . . . but it has been a
long time since I configured Squid so I may be wrong
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com
---
If you are interested in helping to develop a GPL enterprise class
VPN/Firewall/Security device management console, please visit
http://iscs.sourceforge.net 

Re: Newbie - problem with PREROUTING on nat - I'm missing something obvious?

[al clethero]

Folks

Well I guess I haven't made this too clear :) but I've battled on and
tried some experimentation and I've found that I can redirect a packet
to a different port in  the nat table with a PREROUTING rule if the
packet comes through on eth0 from another machine, but NOT if the source
of the packet is 127.0.0.1 port 80 and the destination is 127.0.0.1 port
8080 ( i.e. a browser on my gateway machine connected to the internet
sends to port 80 and needs to be redirected to port 8080 ). 

The reason I'm trying this is so that the browser on the gateway machine
is forced to use port 8080 whether a proxy server is defined or not in
the browser.

Is there a reason for 127.0.0.1 not using prerouting? Can anyone confirm
this for me?

John, I didn't fully understand your final point :

I believe you must ensure that traffic can flow to interface lo on
the INPUT chain as well as doing the redirect . . . but it has been a
long time since I configured Squid so I may be wrong

can you elaborate?

regards

al

On Wed, 2004-03-17 at 16:13, John A. Sullivan III wrote:
> On Wed, 2004-03-17 at 08:49, al clethero wrote:
> > Folks
> > 
> > I'm having some issues with the nat table and redirection. I'm trying to
> > redirect traffic destined for port 80 to port
> > 8080, so that there is no need to specify a proxy server in the browser
> > settings. I'm fairly new to netfilter, so it may be I'm missing
> > something obvious. If so, I apologise beforehand!
> > 
> > I set up a contrived scenario on my isolated test system as follows (so
> > the browser, squid etc are all running on the same box):
> > 
> > 1/ I have nothing listening on port 80
> > 2/ Squid is running, listening on port 8080
> > 3/ Proxy options are turned off in the browser
> > 4/ iptables has the following statement in the nat table (and this is
> > the only statement in my iptables while I test this out):
> > 
> >    iptables -t nat -A PREROUTING  -p tcp --dport 80 -j REDIRECT
> > --to-ports 8080
> > 
> > My understanding of this rule is that any tcp packets destined for port
> > 80 on any interface will be redirected to port 8080.
> > 
> > 5/ I try to connect to www.google.com from the browser and the following
> > should happen:
> > 
> > the request goes out to port 80
> > the rule in the nat table picks up the packet and forwards it to port
> > 8080, where squid connects to google, retrieves the page and supplies it
> > to the browser.
> > 
> > However, this doesn't seem to happen, connections go straight through to
> > google from port 80 without being redirected. I have tested this by
> > shutting down squid and having no proxy servers configured in the
> > browser, yet I can still connect, whereas I would expect an error.
> > 
> > If I check the iptables status before and after doing this I get
> > 
> > Before
> > 
> > iptables -t nat -v -L
> > Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
> >  pkts bytes target     prot opt in     out     source              
> > destination
> >          
> >     0     0 REDIRECT   tcp  --  any    any     anywhere            
> > anywhere
> >        tcp dpt:http redir ports 8080
> >  
> > Chain POSTROUTING (policy ACCEPT 10 packets, 600 bytes)
> >  pkts bytes target     prot opt in     out     source              
> > destination
> >          
> >  
> > Chain OUTPUT (policy ACCEPT 10 packets, 600 bytes)
> >  pkts bytes target     prot opt in     out     source              
> > destination
> >          
> > After
> > 
> > Chain PREROUTING (policy ACCEPT 43 packets, 3496 bytes)
> >  pkts bytes target     prot opt in     out     source              
> > destination
> >          
> >     0     0 REDIRECT   tcp  --  any    any     anywhere            
> > anywhere
> >        tcp dpt:http redir ports 8080
> >  
> > Chain POSTROUTING (policy ACCEPT 209 packets, 13148 bytes)
> >  pkts bytes target     prot opt in     out     source              
> > destination
> >          
> >  
> > Chain OUTPUT (policy ACCEPT 209 packets, 13148 bytes)
> >  pkts bytes target     prot opt in     out     source              
> > destination
> >          
> > 
> > Since the above seems to indicate packets going through the nat
> > prerouting chain but not being acted upon I suspect I am missing
> > something fairly obvious!
> <snip>
> I must confess to not fully digesting your message as I am up against a
> deadline.  However, three things come to mind.
> 
> 1) are you really sure that Squid has stopped? It frequently runs from a
> daemon which continually restarts it even after doing a squid -k
> shutdown
> 
> 2) do you really want to redirect all traffic destined for port 80 or
> just the traffic coming from the Internal network?
> 
> 3) I believe you must ensure that traffic can flow to interface lo on
> the INPUT chain as well as doing the redirect . . . but it has been a
> long time since I configured Squid so I may be wrong

Re: Newbie - problem with PREROUTING on nat - I'm missing something obvious?

[John A. Sullivan III]

On Thu, 2004-03-18 at 18:27, al clethero wrote:
> Folks
> 
> Well I guess I haven't made this too clear :) but I've battled on and
> tried some experimentation and I've found that I can redirect a packet
> to a different port in  the nat table with a PREROUTING rule if the
> packet comes through on eth0 from another machine, but NOT if the source
> of the packet is 127.0.0.1 port 80 and the destination is 127.0.0.1 port
> 8080 ( i.e. a browser on my gateway machine connected to the internet
> sends to port 80 and needs to be redirected to port 8080 ). 
> 
> The reason I'm trying this is so that the browser on the gateway machine
> is forced to use port 8080 whether a proxy server is defined or not in
> the browser.
> 
> Is there a reason for 127.0.0.1 not using prerouting? Can anyone confirm
> this for me?
> 
> John, I didn't fully understand your final point :
> 
> I believe you must ensure that traffic can flow to interface lo on
> the INPUT chain as well as doing the redirect . . . but it has been a
> long time since I configured Squid so I may be wrong
> 
> can you elaborate?
> 
<snip>
I'm stretching back in my rusty memory here but I believe that when you
redirect the packet to Squid, there is an internal socket connection to
Squid, in other words, the system talks to itself as if it was talking
to another network connection except that then network connection is on
127.0.0.1.  If your INPUT chain does not allow traffic to pass on the lo
interface, these internal socket connections will be dropped. Thus, one
must allow these internal socket connections by ACCEPTing traffic from
lo on the INPUT chain.
These were guesses that I made to make it work and I have never looked
at the netfilter code so please believe someone else if they tell you
differently.

I also believe that locally generated packets do not pass through -t nat
PREROUTING but rather through -t nat OUTPUT.  Again, this is not a
configuration I usually use so I am not 100% sure.  That may explain why
locally generated http connections are not routed through squid. Hope
this helps and is accurate.

My apologies for all the cautious phrasing but I am always very
suspicious that I am being given advice on a mail list from someone who
is well meaning but not authoritative.  Thus, I try to make it clear
that I am not authoritative :-)
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com