NAT problem

NAT problem

[Tyler Kemp]

Hey,
	I recently installed linux on a spare box I had, in order to share my DSL
connection throughout the house. I've run into a problem with iptables.

Linux distro: Debian Woody
Kernel: 2.4.17
iptables version: 1.2.6a

	Iptables modules are loaded completely, local LAN is setup correctly, and
the windows machine I've been testing the connection with is configured to
use the linux box as it's gateway (no firewall on the windows machine).

Rules I'm using:
#!/bin/sh
#
#   Firewall
#


echo "Setting up Netfilter Firewall"
#flush
iptables -F
iptables -t nat -F

#allow anything already established
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#allow anything new from LAN
iptables -A INPUT -m state --state NEW -i ! ppp0 -j ACCEPT

#drop mySQL
iptables -A INPUT -p tcp --dport 3306 -j REJECT --reject-with tcp-reset

#open ident
#iptables -A INPUT -p tcp --dport 113 -j ACCEPT

#open httpd
#iptables -A INPUT -p tcp --dport 80 -m limit --limit 2/s -j
LOG --log-prefix "Apache "
#iptables -A INPUT -p tcp --dport 80 -j ACCEPT

#open ssh
#iptables -A INPUT -p tcp --dport 22 -m limit --limit 2/s -j
LOG --log-prefix "SSH "
#iptables -A INPUT -p tcp --dport 22 -j ACCEPT

#allow identd
#iptables -A INPUT -p tcp --dport 53 -j ACCEPT

#log specific curious ports before accepting/denying them
iptables -A INPUT -i ppp0 -p tcp --dport 31337 -m limit --limit 2/s -j
LOG --log-prefix "Trojan "
iptables -A INPUT -i ppp0 -p tcp --dport 27374 -m limit --limit 2/s -j
LOG --log-prefix "Trojan "
iptables -A INPUT -i ppp0 -p tcp --dport 12345 -m limit --limit 2/s -j
LOG --log-prefix "Trojan "

#iptables -A INPUT -i ppp0 -p tcp --dport 6666:7000 -m limit --limit 2/s -j
LOG --log-prefix "IRC "
iptables -A INPUT -i ppp0 -p tcp --dport 6346 -m limit --limit 2/s -j
LOG --log-prefix "6346 DoS "

#allow anything out of service range for tcp/udp (ports over 1024)
iptables -A INPUT -p tcp --dport 1024: -j ACCEPT
iptables -A INPUT -p udp --dport 1024: -j ACCEPT

#Log everything else below 1024
iptables -A INPUT -i ppp0 -p tcp -m limit --limit 1/s -j LOG --log-prefix
"DROPPED "
iptables -A INPUT -i ppp0 -p udp -m limit --limit 1/s -j LOG --log-prefix
"DROPPED "
iptables -A INPUT -i ppp0 -p icmp -m limit --limit 1/s -j LOG --log-prefix
"DROPPED "

#drop the rest with devious tcp reset
iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
iptables -A INPUT -j DROP

#setup NAT
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE


#forward chain

#syn flood limiting
iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit
1/s -j ACCEPT


#enable ip forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

echo "Starting IP Forwarding"


The symptoms:
	The linux box connects properly to my DSL service, and can see the windows
box on the local LAN (windows box can see the linux box aswell). I can
access services on the linux box such as ssh and http, but something is
preventing the windows box from seeing anything on the outside world via the
DSL. Any ideas/solutions?

		Cheers,
			Tyler

Tyler Kemp
----------
tylerk4@sbcglobal.net
tyler@strtok.co.uk
tylerk4@softhome.net

Re: NAT problem

[Antony Stone]

On Thursday 09 May 2002 5:41 am, Tyler Kemp wrote:

> Hey,
> 	I recently installed linux on a spare box I had, in order to share my DSL
> connection throughout the house. I've run into a problem with iptables.
>
> The symptoms:
> 	The linux box connects properly to my DSL service, and can see the windows
> box on the local LAN (windows box can see the linux box aswell). I can
> access services on the linux box such as ssh and http, but something is
> preventing the windows box from seeing anything on the outside world via
> the DSL. Any ideas/solutions?

Yes.   All your rules are in the INPUT chain (except for the stuff labelled 
'syn flood limiting').

The INPUT chain is only for packets going to the firewall itself.

The FORWARD chain is for packets going across the firewall from a machine on 
one side to a machine on the other.

 

Antony.

Completely NAT an ISP: A practical possibility?

[Brian Capouch]

I tried to capture the whole message there in the subject :-)

I wonder if the sages on this list might share advice as to whether or 
not it might be practical to maintain a working ISP where ALL client 
machines use private IP addresses, which are then NAT-ted to public IP 
space as necessary by iptables.

I am getting ready to deploy a small ISP, and this is a very attractive 
idea, but when soliciting ideas from various in-the-know folks I have 
consulted opinions seem to vary very widely.

The biggest drawback that has been voiced so far is that many 
peer-to-peer apps would break, but I'm not so sure right now that is bad 
thing.

All advice gratefully considered.

Thanks.

B.

Re: Completely NAT an ISP: A practical possibility?

[Antony Stone]

On Saturday 15 June 2002 11:14 pm, Brian Capouch wrote:

> I wonder if the sages on this list might share advice as to whether or
> not it might be practical to maintain a working ISP where ALL client
> machines use private IP addresses, which are then NAT-ted to public IP
> space as necessary by iptables.
>
> The biggest drawback that has been voiced so far is that many
> peer-to-peer apps would break, but I'm not so sure right now that is bad
> thing.

Some current ISPs already do this, and I guess the popularity with their 
customers varies according to what the customers want to do :-)

I know of 'residential' accounts where the ISP gives you a private address 
and you're dynamically NATted out to the Internet (so there's no possibility 
at all of hosting incoming services), and 'business' accounts where you have 
two-way static SNAT/DNAT, where as you say above some protocols will work and 
some won't.

Technically there's certainly no reason at all why you can't do this; in 
practice it'll come down to the contract you have with your customers, and 
what they can reasonably expect to be able to do with the connection you 
provide.

Just out of interest, how are you proposing to handle bandwidth allocation - 
making sure each customer gets a reasonable bandwidth without hogging the 
whole link ?

 

Antony.

Re: Completely NAT an ISP: A practical possibility?

[Brian Capouch]

Antony Stone wrote:
> 
> Just out of interest, how are you proposing to handle bandwidth allocation - 
> making sure each customer gets a reasonable bandwidth without hogging the 
> whole link ?
> 

(Ducking) Still studying that matter, but the current 
candidates-of-record are tc, and cbq, but the Advanced Routing HOWTO is 
about to scare me off from CBQ, even though they admit there that it is 
the "most hyped."

I won't mind any advice in that arena, either :-)

Thx.

B.

Re: Completely NAT an ISP: A practical possibility?

[Nick Drage]

On Sat, Jun 15, 2002 at 11:33:23PM +0100, Antony Stone wrote:
> On Saturday 15 June 2002 11:14 pm, Brian Capouch wrote:

> > I wonder if the sages on this list might share advice as to whether or
> > not it might be practical to maintain a working ISP where ALL client
> > machines use private IP addresses, which are then NAT-ted to public IP
> > space as necessary by iptables.
> >
> > The biggest drawback that has been voiced so far is that many
> > peer-to-peer apps would break, but I'm not so sure right now that is bad
> > thing.
> 
> Some current ISPs already do this, and I guess the popularity with their 
> customers varies according to what the customers want to do :-)

Can you name any ISPs that do this?  I haven't seen it in my limited
experience.

<snip>

-- 
FunkyJesus System Administration Team

Re: Completely NAT an ISP: A practical possibility?

[Antony Stone]

On Sunday 16 June 2002 12:17 am, Nick Drage wrote:

> On Sat, Jun 15, 2002 at 11:33:23PM +0100, Antony Stone wrote:
> > On Saturday 15 June 2002 11:14 pm, Brian Capouch wrote:

> > > I wonder if the sages on this list might share advice as to whether or
> > > not it might be practical to maintain a working ISP where ALL client
> > > machines use private IP addresses, which are then NAT-ted to public IP
> > > space as necessary by iptables.

> > Some current ISPs already do this, and I guess the popularity with their
> > customers varies according to what the customers want to do :-)

> Can you name any ISPs that do this?  I haven't seen it in my limited
> experience.

There's a satellite ISP in the UK which does this - it's called either Hughes 
or StreamBeam, I'm not sure which is the end provider and which is the 
sub-carrier.   The equipment they provide is labelled Hughes.

As a standard account you get private (10.x.y.z) addresses on the end of the 
link, however you can ask for public-private NAT and they do SNAT/DNAT to 
your private addresses (one-to-one mapping).

I thought I'd heard that some ADSL services in UK provide private addresses 
too, but I've never had this, so I can't comment from personal experience.

 

Antony.

Re: Completely NAT an ISP: A practical possibility?

[Sathi]

Hi,
I am Sathi from India.
I have implemented this in my place by providing a connectionn to 100 to 150
customers.

I provide a Local ip address and all will be terminate in a linux box in my
office which is then nated to public ip.

Everything looks fine except MSN voice chat , NETMEETING voice and video and
some other tools used for phone2pc and pc2phone.

Regards,
Sathi

> On Sat, Jun 15, 2002 at 11:33:23PM +0100, Antony Stone wrote:
> > On Saturday 15 June 2002 11:14 pm, Brian Capouch wrote:
>
> > > I wonder if the sages on this list might share advice as to whether or
> > > not it might be practical to maintain a working ISP where ALL client
> > > machines use private IP addresses, which are then NAT-ted to public IP
> > > space as necessary by iptables.
> > >
> > > The biggest drawback that has been voiced so far is that many
> > > peer-to-peer apps would break, but I'm not so sure right now that is
bad
> > > thing.
> >
> > Some current ISPs already do this, and I guess the popularity with their
> > customers varies according to what the customers want to do :-)
>
> Can you name any ISPs that do this?  I haven't seen it in my limited
> experience.
>
> <snip>
>
> --
> FunkyJesus System Administration Team
>
>

nat problem.

[umar]

Hi, 
 
Trying out  a very simple configuration of a firewall here, but having some problems.
The firewall  has two NIC's and have enabled ip forwarding. 

I want the internal machines to connect to the internet,  So have enabled NAT : 
Runing squid - transparent proxy on port 3232. Clients have been onfigured to connect to internet directly. 
eth0 is my external interface.
 
Following are the nat rules conigured on the firewall
 
iptables -t nat -A PREROUTING -i eth0  -p tcp --dport 80 -j REDIRECT --to-port 3232
 
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source x.x.x.x ( public IP of the other netwrok card )

I can ping to the gateway ( private IP ) and the other network card havng the public IP , but nothing beyond that, Why ?? 
And my clients are also not able to connect to the internet ?? 
I have tried removing the first rule and disabling squid, so that clients could connect to the intenet directly. 
That also failed, and the result is the same. All the default poilicies of all rules are set to ACCEPT.

Runing rh 7.2 with 2.4.7-10 kernel.

Please help. 

Warm Regards, 
Kumar. 

(no subject)

[skmail]

Hi all-

I'm trying to patch a stock 2.4.18 kernel with a few extras from the
current patch-o-matic.  The only one that seems to have trouble so far
(kernel compile in progress) is the string match support.  Here is the
output of my kernel compile.  Can somebody help?  TIA

gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes 
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common 
-pipe -mpreferred-stack-boundary=2 -march=i486   
-DKBUILD_BASENAME=ipt_limit  -c -o ipt_limit.o ipt_limit.c
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes 
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common 
-pipe -mpreferred-stack-boundary=2 -march=i486   -DKBUILD_BASENAME=ipt_mac  
-c -o ipt_mac.o ipt_mac.c
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes 
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common 
-pipe -mpreferred-stack-boundary=2 -march=i486   
-DKBUILD_BASENAME=ipt_multiport  -c -o ipt_multiport.o ipt_multiport.c
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes 
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common 
-pipe -mpreferred-stack-boundary=2 -march=i486   
-DKBUILD_BASENAME=ipt_time  -c -o ipt_time.o ipt_time.c
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes 
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common 
-pipe -mpreferred-stack-boundary=2 -march=i486   
-DKBUILD_BASENAME=ipt_state  -c -o ipt_state.o ipt_state.c
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes 
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common 
-pipe -mpreferred-stack-boundary=2 -march=i486   
-DKBUILD_BASENAME=ipt_iplimit  -c -o ipt_iplimit.o ipt_iplimit.c
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes 
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common 
-pipe -mpreferred-stack-boundary=2 -march=i486   
-DKBUILD_BASENAME=ipt_unclean  -c -o ipt_unclean.o ipt_unclean.c
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes 
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common 
-pipe -mpreferred-stack-boundary=2 -march=i486   
-DKBUILD_BASENAME=ipt_string  -c -o ipt_string.o ipt_string.c
ipt_string.c:80:72: macro "max" passed 3 arguments, but takes just 2
ipt_string.c: In function `search_sublinear':
ipt_string.c:53: warning: subscript has type `char'
ipt_string.c:78: warning: subscript has type `char'
ipt_string.c:80: `max' undeclared (first use in this function)
ipt_string.c:80: (Each undeclared identifier is reported only once
ipt_string.c:80: for each function it appears in.)
make[3]: *** [ipt_string.o] Error 1
make[3]: Leaving directory `/usr/src/linux/net/ipv4/netfilter'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux/net/ipv4/netfilter'
make[1]: *** [_subdir_ipv4/netfilter] Error 2
make[1]: Leaving directory `/usr/src/linux/net'
make: *** [_dir_net] Error 2

Re: nat problem.

[Antony Stone]

On Monday 17 June 2002 11:58 am, umar wrote:

> Hi, 
>  
> Trying out  a very simple configuration of a firewall here, but having some
> problems.
 The firewall  has two NIC's and have enabled ip forwarding.
> 
> I want the internal machines to connect to the internet,  So have enabled
> NAT : 
 Runing squid - transparent proxy on port 3232. Clients have been
> onfigured to connect to internet directly. eth0 is my external interface.
>  
> Following are the nat rules conigured on the firewall
>  
> iptables -t nat -A PREROUTING -i eth0  -p tcp --dport 80 -j REDIRECT
> --to-port 3232
 
> iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source x.x.x.x ( public
> IP of the other netwrok card )
 

What do you mean "IP of the *other* network card" ?

The address here should be the address of eth0.   Tell us if you're using 
something else, and if so what you're using (we don'tneed to know the IP 
address, just where it lives on the network).

 

Antony.

Re: Completely NAT an ISP: A practical possibility?

[Rodrigo Senra]

|On Sun, 16 Jun 2002 00:17:45 +0100
|Nick Drage <nickd@funkyjesus.org> wrote
| about Re: Completely NAT an ISP: A practical possibility?:

>> On Sat, Jun 15, 2002 at 11:33:23PM +0100, Antony Stone wrote:
> > On Saturday 15 June 2002 11:14 pm, Brian Capouch wrote:
> 
> > Some current ISPs already do this, and I guess the popularity with their 
> > customers varies according to what the customers want to do :-)
> 
> Can you name any ISPs that do this?  I haven't seen it in my limited
> experience.
> 

 Here in Brazil this is often used, though I'm not at liberty to name actual
 ISPs. We have very little H.323 (read Netmeeting) demand, but it is growing.
 Most ISP clients still have 56Kbps dial-up access, with the number of ADSL
 clients increasing fast. 

 The NAT solution is often used to allow multiple ISP access though the 
 same media provider (probably ADSL). Since there is a law that a 
 "Content Provider" (like aol,etc) cannot be same as the media provider
 (like AT&T, etc), which fosters the adoption solution such as that. 

 In fact, it is not the ISP that is "Natted", but a subset of the client address
 space before they reach their target ISP, and while in transit in the media
 provider routers. Naturally, there is some cooking to achieve that. 

 I'm not sure if this is the kind of practical appication youe were expecting to hear
 from, but there is no harm to talk about it anyway....

 regards,
 Senra
   
-- 
Rodrigo Senra         
MSc Computer Engineer   (GPr Sistemas Ltda)     rodsenra@gpr.com.br 
http://www.ic.unicamp.br/~921234  (LinUxer 217.243) (ICQ 114477550)

Re: Completely NAT an ISP: A practical possibility?

[Ramin Alidousti]

On Tue, Jun 18, 2002 at 02:16:32PM -0300, Rodrigo Senra wrote:

> |On Sun, 16 Jun 2002 00:17:45 +0100
> |Nick Drage <nickd@funkyjesus.org> wrote
> | about Re: Completely NAT an ISP: A practical possibility?:
> 
> >> On Sat, Jun 15, 2002 at 11:33:23PM +0100, Antony Stone wrote:
> > > On Saturday 15 June 2002 11:14 pm, Brian Capouch wrote:
> > 
> > > Some current ISPs already do this, and I guess the popularity with their 
> > > customers varies according to what the customers want to do :-)
> > 
> > Can you name any ISPs that do this?  I haven't seen it in my limited
> > experience.
> > 
> 
>  Here in Brazil this is often used, though I'm not at liberty to name actual
>  ISPs. We have very little H.323 (read Netmeeting) demand, but it is growing.
>  Most ISP clients still have 56Kbps dial-up access, with the number of ADSL
>  clients increasing fast. 
> 
>  The NAT solution is often used to allow multiple ISP access though the 
>  same media provider (probably ADSL).

Doesn't bridged context DSLAM eliminate the need for the NAT?


>   Since there is a law that a 
>  "Content Provider" (like aol,etc) cannot be same as the media provider
>  (like AT&T, etc), which fosters the adoption solution such as that. 
> 
>  In fact, it is not the ISP that is "Natted", but a subset of the client address
>  space before they reach their target ISP, and while in transit in the media
>  provider routers. Naturally, there is some cooking to achieve that. 

This would break lots of protocols. How would the clients put up with
this broken functionality? Or maybe they tunnel on top of this IP network
which is still a huge overhead...and needs additional client-side config.

Ramin

> 
>  I'm not sure if this is the kind of practical appication youe were expecting to hear
>  from, but there is no harm to talk about it anyway....
> 
>  regards,
>  Senra
>    
> -- 
> Rodrigo Senra         
> MSc Computer Engineer   (GPr Sistemas Ltda)     rodsenra@gpr.com.br 
> http://www.ic.unicamp.br/~921234  (LinUxer 217.243) (ICQ 114477550)

Re: Completely NAT an ISP: A practical possibility?

[Rodrigo Senra]

|On Tue, 18 Jun 2002 14:50:05 -0400
|Ramin Alidousti <ramin@cannon.eng.us.uu.net> wrote
| about Re: Completely NAT an ISP: A practical possibility?:

> >  The NAT solution is often used to allow multiple ISP access though the 
> >  same media provider (probably ADSL).
> 
> Doesn't bridged context DSLAM eliminate the need for the NAT?

I humbly confess that I do not know what DSLAM is ;o)

> This would break lots of protocols. How would the clients put up with
> this broken functionality?

Good observation. Yes it breaks some (all not NAT-able), and when this is used
clients have to live up with the limitations. But as I said, for the time being 
this is used to accomodate a multiple-ISP cenario where clients need basically
HTTP, FTP, and less percentage of H.323.  

Take notice that NAT takes place before the packets reach their service providers.
So maybe, I couldn't call it properly  "NAT an ISP" as the title suggests.
 
> Or maybe they tunnel on top of this IP network

Not that I know of.
Thank you for your observations.

regards,
Senra
-- 
Rodrigo Senra         
MSc Computer Engineer   (GPr Sistemas Ltda)     rodsenra@gpr.com.br 
http://www.ic.unicamp.br/~921234  (LinUxer 217.243) (ICQ 114477550)

Re: Completely NAT an ISP: A practical possibility?

[Ramin Alidousti]

On Tue, Jun 18, 2002 at 05:22:03PM -0300, Rodrigo Senra wrote:

> > This would break lots of protocols. How would the clients put up with
> > this broken functionality?
> 
> Good observation. Yes it breaks some (all not NAT-able), and when this is used
> clients have to live up with the limitations. But as I said, for the time being 
> this is used to accomodate a multiple-ISP cenario where clients need basically
> HTTP, FTP, and less percentage of H.323.  

Just a small note. FTP is one of the protocols that would break...

Ramin

> 
> Take notice that NAT takes place before the packets reach their service providers.
> So maybe, I couldn't call it properly  "NAT an ISP" as the title suggests.
>  
> > Or maybe they tunnel on top of this IP network
> 
> Not that I know of.
> Thank you for your observations.
> 
> regards,
> Senra
> -- 
> Rodrigo Senra         
> MSc Computer Engineer   (GPr Sistemas Ltda)     rodsenra@gpr.com.br 
> http://www.ic.unicamp.br/~921234  (LinUxer 217.243) (ICQ 114477550)

Re: Completely NAT an ISP: A practical possibility?

[Rodrigo Senra]

|On Tue, 18 Jun 2002 18:50:58 -0400
|Ramin Alidousti <ramin@cannon.eng.us.uu.net> wrote
| about Re: Completely NAT an ISP: A practical possibility?:

 >> On Tue, Jun 18, 2002 at 05:22:03PM -0300, Rodrigo Senra wrote:
> 
> 
> Just a small note. FTP is one of the protocols that would break...

Hi,
  could you care to explain me how it would break ? Since it is working
  here ;o), I think we are discussing different scenarios because of my
  poor explanation on the matter.

 But I think I can gain a lot from your explanation.

 TIA,
 Senra 
-- 
Rodrigo Senra         
MSc Computer Engineer   (GPr Sistemas Ltda)     rodsenra@gpr.com.br 
http://www.ic.unicamp.br/~921234  (LinUxer 217.243) (ICQ 114477550)

Re: Completely NAT an ISP: A practical possibility?

[Ramin Alidousti]

On Wed, Jun 19, 2002 at 11:36:33AM -0300, Rodrigo Senra wrote:

> |On Tue, 18 Jun 2002 18:50:58 -0400
> |Ramin Alidousti <ramin@cannon.eng.us.uu.net> wrote
> | about Re: Completely NAT an ISP: A practical possibility?:
> 
>  >> On Tue, Jun 18, 2002 at 05:22:03PM -0300, Rodrigo Senra wrote:
> > 
> > 
> > Just a small note. FTP is one of the protocols that would break...
> 
> Hi,
>   could you care to explain me how it would break ? Since it is working
>   here ;o), I think we are discussing different scenarios

I defer this explanation to the documents available about the NAT
and FTP. You can start with the netfilter documents on the need
for ip_nat_ftp. Also the FTP protocol and more specifically the
PORT command would give you what you're looking for.

>   because of my poor explanation on the matter.

No, not at all.

Ramin

> 
>  But I think I can gain a lot from your explanation.
> 
>  TIA,
>  Senra 
> -- 
> Rodrigo Senra         
> MSc Computer Engineer   (GPr Sistemas Ltda)     rodsenra@gpr.com.br 
> http://www.ic.unicamp.br/~921234  (LinUxer 217.243) (ICQ 114477550)

Re: Completely NAT an ISP: A practical possibility?

[Antony Stone]

On Tuesday 18 June 2002 11:50 pm, Ramin Alidousti wrote:

> On Tue, Jun 18, 2002 at 05:22:03PM -0300, Rodrigo Senra wrote:
> > > This would break lots of protocols. How would the clients put up with
> > > this broken functionality?
> >
> > Good observation. Yes it breaks some (all not NAT-able), and when this is
> > used clients have to live up with the limitations. But as I said, for the
> > time being this is used to accomodate a multiple-ISP cenario where
> > clients need basically HTTP, FTP, and less percentage of H.323.
>
> Just a small note. FTP is one of the protocols that would break...

This is, of course, assuming that they only do "simple NAT", rather than 
implementing netfilter + associated helper modules inside the ISP....

 

Antony.

Re: Completely NAT an ISP: A practical possibility?

[Rodrigo Senra]

|On Thu, 20 Jun 2002 10:48:01 +0100
|Antony Stone <Antony@Soft-Solutions.co.uk> wrote
| about Re: Completely NAT an ISP: A practical possibility?:

 >> On Tuesday 18 June 2002 11:50 pm, Ramin Alidousti wrote:
> 
> > On Tue, Jun 18, 2002 at 05:22:03PM -0300, Rodrigo Senra wrote:
> > > > This would break lots of protocols. How would the clients put up with
> > > > this broken functionality?
> > >
> > > Good observation. Yes it breaks some (all not NAT-able), and when this is
> > > used clients have to live up with the limitations. But as I said, for the
> > > time being this is used to accomodate a multiple-ISP cenario where
> > > clients need basically HTTP, FTP, and less percentage of H.323.
> >
> > Just a small note. FTP is one of the protocols that would break...
> 
> This is, of course, assuming that they only do "simple NAT", rather than 
> implementing netfilter + associated helper modules inside the ISP....
> 

Thank you Antony.

Indeed we were discussing different things! I believe now that Ramin
made reference that protocols would break due to a lack of "connection
conntracking" withou which packets couldn't suffer NAT properly. We have
implemented a rudimentar NAT+conntrack kernel 2.2 patch, because by the time
we netfilter/iptables was not available in all its glory ;o).
What we did was to use a priority queue and hashtables to implement full
NAT to FTP and H.323 only (our immediate needs by then).

We've upgraded the solution to use netfilter/iptables last year.

regards,
Senra 

-- 
Rodrigo Senra         
MSc Computer Engineer   (GPr Sistemas Ltda)     rodsenra@gpr.com.br 
http://www.ic.unicamp.br/~921234  (LinUxer 217.243) (ICQ 114477550)

Re: Completely NAT an ISP: A practical possibility?

[Ramin Alidousti]

On Thu, Jun 20, 2002 at 04:37:10PM -0300, Rodrigo Senra wrote:

> > > > time being this is used to accomodate a multiple-ISP cenario where
> > > > clients need basically HTTP, FTP, and less percentage of H.323.
> > >
> > > Just a small note. FTP is one of the protocols that would break...
> > 
> > This is, of course, assuming that they only do "simple NAT", rather than 
> > implementing netfilter + associated helper modules inside the ISP....
> > 
> 
> Thank you Antony.
> 
> Indeed we were discussing different things! I believe now that Ramin
> made reference that protocols would break due to a lack of "connection
> conntracking" withou which packets couldn't suffer NAT properly. We have
> implemented a rudimentar NAT+conntrack kernel 2.2 patch, because by the time
> we netfilter/iptables was not available in all its glory ;o).

Oh, I see, I wasn't thinking in terms of netfilter when I read your
original email about NATting FTP. Yes, FTP is supported and (although
I didn't do it myself) H.323 is also supported (except for certain
functionalities, I hear). So, you can easily say that your routed
context DSL solution works by means of a linux nat box.

Do you guys do DNAT too? I mean do you let the costomers run services?
Who assigns IP's to them? The content providers? How do you sync up
with them for the DNAT? The whole NAT solution between the medium provider
and the content provider is still a bit vague to me, especially when you
sell static IP's to the customers...

> What we did was to use a priority queue and hashtables to implement full
> NAT to FTP and H.323 only (our immediate needs by then).

Feel free to elaborate on this priority queue/hashtables implementation
to solve FTP/H.323 problem. Sounds like an extendable thing for other
unfriendly protocols.

> We've upgraded the solution to use netfilter/iptables last year.

Good for you.

Ramin

> regards,
> Senra 
> 
> -- 
> Rodrigo Senra         
> MSc Computer Engineer   (GPr Sistemas Ltda)     rodsenra@gpr.com.br 
> http://www.ic.unicamp.br/~921234  (LinUxer 217.243) (ICQ 114477550)

Nat PROBLEM

[lcef]

Hello netfilter,

  Hello:
  I have a problem with IP translation.
  I have 2 machines, with DSL conection.
  First machine have eth0 (213.23.xxx.xxx) and second machine with a
  second ethernet named eth1(192.168.2.1).
  I have a webcam in the second machine(192.168.1.21 eth1)and i want
  who any people go to first machine (213.23.xxx.xxx)can look the
  webcam who are installed in de second machine 192.168.2.1:8080.
  In others words when you type http://213.23.xxx.xxx:8080  go to
  192.168.2.1:8080.
  What rules need i to put with IPFILTER?
  Can you help me please.
  Thanks for your time

-- 
Best regards,
 lcef                          mailto:lcef@eb3cef.net

Re: Nat PROBLEM

[Antony Stone]

On Monday 24 June 2002 12:11 pm, lcef wrote:

> Hello netfilter,
>
>   I have 2 machines, with DSL conection.
>   First machine have eth0 (213.23.xxx.xxx) and second machine with a
>   second ethernet named eth1(192.168.2.1).
>   I have a webcam in the second machine(192.168.1.21 eth1)and i want
>   who any people go to first machine (213.23.xxx.xxx)can look the
>   webcam who are installed in de second machine 192.168.2.1:8080.
>   In others words when you type http://213.23.xxx.xxx:8080  go to
>   192.168.2.1:8080.
>   What rules need i to put with IPFILTER?

iptables -A PREROUTING -d 213.23.xxx.xxx -p tcp --dport 8080 -j DNAT --to 
192.168.1.21
iptables -A FORWARD -d 192.168.1.21 -p tcp --dport 8080 -j ACCEPT

 

Antony.

Re: Completely NAT an ISP: A practical possibility?

[Rodrigo Senra]

|On Thu, 20 Jun 2002 20:19:43 -0400
|Ramin Alidousti <ramin@cannon.eng.us.uu.net> wrote
| about Re: Completely NAT an ISP: A practical possibility?:

> Do you guys do DNAT too? I mean do you let the costomers run services?

Nope. Only SNAT is used to route the client pool (with the same media provider)
to the appropriate ISP.

> Who assigns IP's to them?

They used DHCP with ADSL ( I said there were some dial-ups but I was mistaken, all use ADSL now)

> The content providers? How do you sync up with them for the DNAT?

They sync up for SNAT. They have to authenticate via Web (before the firewall/router to ISP),
after that a some rules are added automagically to the firewall by a third interface.
Since all use ADSL accounting can be done by crossing (ADSL modem ID,Dynamic IP, time, logs).

              /------- Web Auth-v
client pool -                   | 
              \ ----- Firewall/Router----------(ISP pool)
                                   \------------  "
                                   \------------- "

> The whole NAT solution between the medium provider
> and the content provider is still a bit vague to me, especially when you
> sell static IP's to the customers...

In fact there are no more static addresses, I mixed up some scenarios in my
previous e-mails ;o) 

 
> > What we did was to use a priority queue and hashtables to implement full
> > NAT to FTP and H.323 only (our immediate needs by then).
> 
> Feel free to elaborate on this priority queue/hashtables implementation
> to solve FTP/H.323 problem. Sounds like an extendable thing for other
> unfriendly protocols.

We dropped that solution because it was focused in kernel 2.2 and iproute2.
Basically we had a priority queue acting as a self-made conntrack module.
We have chosen in favour of a priority queue "statistically"
betting in better performance, supposing client traffic would be in bursts
during short periods of time. That proved to be  more efficient than using a hashtable 
as the top level indexing structure.

I do not know in what data structures the current conntrack/filtering is based, 
did not have the time (and the need!) to check it out. For the time being I trust
is is fast/smart enough. If it becomes a bottleneck, then we'll see !

best regards
Senra     

-- 
Rodrigo Senra         
MSc Computer Engineer   (GPr Sistemas Ltda)     rodsenra@gpr.com.br 
http://www.ic.unicamp.br/~921234  (LinUxer 217.243) (ICQ 114477550)

NAT Problem

[Morgan]

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

Hello.
 
I have a question about NAT.
 
I have a client and three servers.
 
One server which I do a remote connect to, and two application servers.
 
Client IP =                            1.2.3.4
Remote con server IP =          1.2.3.5
App Server 1 IP =                  1.2.3.6
App Server 2 IP =                  1.2.3.7
 
I have the following problem.
When I have connected to the Remote con Server I need to be able to
access App Server 1 port 5555 by entering the name of App Server 2 port
5555. (Why is long story)
 
So if I access Remote Con Server and give the command: AppName
AppServer2 -p 5555 I should really access AppServer1 -p 5555
 
 
I figure this can be done with some NATing.
 
Anyone who have any suggestions?
 
 
 
Thanks
Morgan
 

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

NAT problem

[saravanan sakthi]

  Here is my sinario...
        |             
     ___v__________________
    | eth0: 192.168.1.3/24 |
    |                      |
    |     Linux Box        |
    |                      |
    | eth1: 10.1.1.1/16    |
    `---|------------------'
        |
    ____v________________________________________
   /                                             \
  |   10.1.0.0 network                            \
  |                                                \
  |       ____________         __________           |
  |      /            \       /           \         |
  |     | 10.1.11.0/16 |     | 10.1.9.0/16 |        |
  |     |   network    |     |   network   |        |
  |      \____________/       \___________/         |
  |                                                 |
  |       _____________________________             |
  |      /                             \            |
  |     | 10.1.12.0 (My Network)        \           |
  |     |         |                      \          |
  |     |         |                       \         |
  |     |      ___v________________        |        |
  |     |     | eth0: 10.1.12.1/16 |       |       /
  |     |     |                    |       |      /
  |     |     |    Linux Box       |       |     /
  |     |     |                    |      /     /
  |     |     | eth1: 10.0.0.1/8   |     /     /
  |     |     `---|----------------'    /     /
  |     |         |                    /     /
  |     |        _v________           /     /
  |     |       /          \         /     /
  |     |      | 10.0.0.0/8 |       /     /
  |     |      | network    |      /     /
  |      \      \__________/      /     /
   \      \                      /     /
    \      \____________________/     /
     \                               /
      \_____________________________/

Here

  * The Linux box at the beginning acts as a gateway
and DNS forwarder
    for the entire network (installed with
rc.firewall-2.4).

  * My network is 10.1.12.0, I have implemented my
Linux box as a
    router for my network (installed with
rc.firewall-2.4).also acts
    as DNS forwarder (forwards requests to 10.1.1.1).

  * I have a subnet inside (10.0.0.0).my Linux box
acts as a gateway
    for these computers.

What I want is.....

   Connect a computer from 10.0.0.0 network to connect
computers at
   10.1.0.0 network.

Please tell me what are the rules should be added to
rc.firewall-2.4
file to accomplish this.

Thanks for time

Regards,

Saravanan.V

__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/

Re: NAT problem

[Antony Stone]

On Monday 21 October 2002 2:04 pm, saravanan sakthi wrote:

>   Here is my sinario...

 [ Large Ascii-art diagram snipped for brevity ]

This network setup simply will not work sensibly.

You have the following networks connected to each other:

10.1.1.0/16
10.1.11.0/16
10.1.9.0/16
10.1.12.0/16
10.0.0.0/8

There is no sane way you can get the network addresses, all with a /16 
netmask, to communicate.   Every one of the /16 networks has 10.1.0.0 as its 
network address, and 10.1.255.255 as its broadcast address.   Yoou routers 
simply will not know what to do.

Also, the final network you listed, 10.0.0.0/8, covers all the other networks 
combined - I don't know whether to say this is just as bad as the first four, 
or even worse:-)

To summarise - before you start playing around with netfilter and trying to 
control what *isn't* allowed through your routers (after all, that's what 
netfilter is - a packet filter which doesn't allow some packets through which 
otherwise would get routed), please create a network setup where you have 
differen subnets on each segment, and it is possible to create some routing 
tables which will work.

As a first suggestion, changing all your netmasks to /24 would appear to do 
the trick.

Antony.

-- 

Never write it in Perl if you can do it in Awk.
Never do it in Awk if sed can handle it.
Never use sed when tr can do the job.
Never invoke tr when cat is sufficient.
Avoid using cat whenever possible.

nat problem...

[Rahul Jadhav]

I have a setup without a dmz, ie, the servers (http, mail, ssh) share the same subnet as my intranet clients (dhcp). The iptables script I am struggling with allows clients to browse the net but refuses them connections to the servers. Somehow the firewall refuses tcp/udp connections meant for the servers. The firewall machine runs no public services (forwards traffic only).
the forward and nat rules that i use are 

public_ip=external web ip
intra_dev=internal iface
extra_dev=external iface
intra_ip=internal ip
extra_ip=external ip
http=http server ip
mail=mail server ip

# forward
$iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# do I need these 2 lines
$iptables -A FORWARD -p tcp -i $intra_dev -o $extra_dev -j ACCEPT
$iptables -A FORWARD -p udp -i $intra_dev -o $extra_dev -j ACCEPT

$iptables -A FORWARD -p tcp -i $extra_dev -m state --state NEW,ESTABLISHED,RELATED --dport 80 -j ACCEPT
$iptables -A FORWARD -p tcp -i $extra_dev -m state --state NEW,ESTABLISHED,RELATED --dport 81 -j ACCEPT

$iptables -A FORWARD -p tcp -i $extra_dev -o $intra_dev --dport 80 -d $http -j ACCEPT
$iptables -A FORWARD -p tcp -i $extra_dev -o $intra_dev --dport 81 -d $mail -j ACCEPT

# prerouting
$iptables -A PREROUTING -t nat -p tcp -i $extra_dev -d $public_ip --dport 80 -j DNAT --to $http
$iptables -A PREROUTING -t nat -p tcp -i $extra_dev -d $public_ip --dport 81 -j DNAT --to $mail

# postrouting
# either these 2 rules or the masquerade rule works

$iptables -A POSTROUTING -t nat -p tcp -o $extra_dev -s $intra_lan -d $universe -j SNAT --to $extra_ip
$iptables -A POSTROUTING -t nat -p tcp -o $extra_dev -s $intra_lan -d $universe -j SNAT --to $extra_ip

$iptables -A POSTROUTING -t nat -o $extra_dev -j MASQUERADE

does someone see a problem that I can't. Also, could someone enlighten me about the output chain and whether or not I need it here.
Thanks

Rahul

RE: nat problem...

[Yogini Parkhi]

Hi Rahul,
Couple of tips that might help you...
1: 
Use "iptables -L -v -n"
Look at the packet and byte counters in there and see which ones of your accept rules actually are accepting packets.

2:
Also a log rule at the end of your FORWARD chain might help identify what kinds of packets are getting dropped.  The log rule will look something like
$iptables -A FORWARD -m limit -j LOG -log-prefix "RAHULS_LOG"
This will log packets to your syslog "/var/log/messages" usually. You can observ those and debug further.

I suspect your syn packets are getting dropped. 
Add the following rule right before: "$iptables -A FORWARD -p tcp -i $extra_dev -m state --state NEW,ESTABLISHED,RELATED --dport 80 -j ACCEPT" This rule you have.

$iptables -A FORWARD -p tcp -i $extra_dev --syn --dport 80 -j ACCEPT

Hopefully this rule will solve your immediate issue. Then the packet and byte counters will point out the unnecessary rules to you and you can remove those.

Hope this helps,
-Yogini




-----Original Message-----
From: Rahul Jadhav [mailto:rahul@iatp.org]
Sent: Friday, November 15, 2002 12:45 PM
To: netfilter@lists.netfilter.org
Subject: nat problem...

I have a setup without a dmz, ie, the servers (http, mail, ssh) share the same subnet as my intranet clients (dhcp). The iptables script I am struggling with allows clients to browse the net but refuses them connections to the servers. Somehow the firewall refuses tcp/udp connections meant for the servers. The firewall machine runs no public services (forwards traffic only).
the forward and nat rules that i use are

public_ip=external web ip
intra_dev=internal iface
extra_dev=external iface
intra_ip=internal ip
extra_ip=external ip
http=http server ip
mail=mail server ip

# forward
$iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# do I need these 2 lines
$iptables -A FORWARD -p tcp -i $intra_dev -o $extra_dev -j ACCEPT
$iptables -A FORWARD -p udp -i $intra_dev -o $extra_dev -j ACCEPT

$iptables -A FORWARD -p tcp -i $extra_dev -m state --state NEW,ESTABLISHED,RELATED --dport 80 -j ACCEPT
$iptables -A FORWARD -p tcp -i $extra_dev -m state --state NEW,ESTABLISHED,RELATED --dport 81 -j ACCEPT

$iptables -A FORWARD -p tcp -i $extra_dev -o $intra_dev --dport 80 -d $http -j ACCEPT
$iptables -A FORWARD -p tcp -i $extra_dev -o $intra_dev --dport 81 -d $mail -j ACCEPT

# prerouting
$iptables -A PREROUTING -t nat -p tcp -i $extra_dev -d $public_ip --dport 80 -j DNAT --to $http
$iptables -A PREROUTING -t nat -p tcp -i $extra_dev -d $public_ip --dport 81 -j DNAT --to $mail

# postrouting
# either these 2 rules or the masquerade rule works

$iptables -A POSTROUTING -t nat -p tcp -o $extra_dev -s $intra_lan -d $universe -j SNAT --to $extra_ip
$iptables -A POSTROUTING -t nat -p tcp -o $extra_dev -s $intra_lan -d $universe -j SNAT --to $extra_ip

$iptables -A POSTROUTING -t nat -o $extra_dev -j MASQUERADE

does someone see a problem that I can't. Also, could someone enlighten me about the output chain and whether or not I need it here.
Thanks

Rahul

NAT problem

[Jose Pascual]

Hi all,
I am new using iptables and surelly  this wil be an easy and stupid question
but perhaps you can help me. I want to understand NAT so I am trying to do
the following:

I have three computers in my LAN (192.168.1.1; 192.168.1.2 and 192.168.1.3).
192.168.1.1 has a web server and I would like to access it through
192.168.1.2 with NAT. For example openning my browser in 192.168.1.3 and
connecting to 192.168.1.2   I  should see the same as if I connected to
192.168.1.1 web server directly, so I have done the following in
192.168.1.2:

 iptables -t nat -A PREROUTING -p tcp --dport 80 -j
DNAT --to-destination 192.168.1.1


 iptables -t nat -A POSTROUTING -p tcp --sport 80 -j SNAT
--to-source 192.168.1.2

However it doesn't work. Anyone can help me?

Thanks

Regards
Jose Pascual

Re: NAT problem

[Venkatesh. K]

What you are trying to do is not possible with a straight forward
configuration.

You have to get the concept of DNAT right. DNAT only works when the DNAT ip
address is on seperate subnet.

For example,

192.168.0.1 <-> 192.168.0.254 <-> 192.168.1.1

you can DNAT requests coming from 192.168.0.1 to 192.168.0.254 to
192.168.1.1 by doing

/sbin/iptables -t nat -I PREROUTING -s 192.168.0.1 -p tcp --dport www -j
DNAT --to-destination 192.168.1.1

Venkatesh K

----- Original Message ----- 
From: "Jose Pascual" <jose.pascual@optivamedia.com>
To: <netfilter@lists.netfilter.org>
Sent: Monday, October 06, 2003 6:00 PM
Subject: NAT problem


> Hi all,
> I am new using iptables and surelly  this wil be an easy and stupid
question
> but perhaps you can help me. I want to understand NAT so I am trying to do
> the following:
>
> I have three computers in my LAN (192.168.1.1; 192.168.1.2 and
192.168.1.3).
> 192.168.1.1 has a web server and I would like to access it through
> 192.168.1.2 with NAT. For example openning my browser in 192.168.1.3 and
> connecting to 192.168.1.2   I  should see the same as if I connected to
> 192.168.1.1 web server directly, so I have done the following in
> 192.168.1.2:
>
>  iptables -t nat -A PREROUTING -p tcp --dport 80 -j
> DNAT --to-destination 192.168.1.1
>
>
>  iptables -t nat -A POSTROUTING -p tcp --sport 80 -j SNAT
> --to-source 192.168.1.2
>
> However it doesn't work. Anyone can help me?
>
> Thanks
>
> Regards
> Jose Pascual
>
>
>
>
>

Re: NAT problem

[Cedric Blancher]

Le lun 06/10/2003 à 15:19, Venkatesh. K a écrit :
> You have to get the concept of DNAT right. DNAT only works when the DNAT ip
> address is on seperate subnet.

You can DNAT to the same subnet providing you SNAT the forwarded flow
with redirector IP.

192.168.1.3 ----> 192.168.1.2 ----> 192.168.1.1

On 192.168.1.2 :

	iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT \
		--to 192.168.1.1
	iptables -t nat -A POSTROUTING -p tcp -d 182.168.1.1 \
		--dport 80 -j SNAT --to 192.168.1.2

This prevent 192.168.1.3 to reply 192.168.1.2 directly, ans thus
confusing 192.168.1.1. It's a common issue for people thrying to reach
an inside host belonging to the same subnet via its public DNAT IP.

From OP :
>> iptables -t nat -A POSTROUTING -p tcp --sport 80 -j SNAT
>> --to-source 192.168.1.2

This is not needed as returning packets for natted connections are
automaticly handled through conntrack engine.

By the way, I would have set this up using a simple TCP port redirector
like redir.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: NAT problem

[Joel Newkirk]

Your SNAT rule should be matching dport, not sport.

Do you have a rule in FORWARD table on 192.168.1.2 that ACCEPTs this
traffic?  And is 192.168.1.2 configured to even allow forwarding?

j

On Mon, 2003-10-06 at 08:30, Jose Pascual wrote:
> Hi all,
> I am new using iptables and surelly  this wil be an easy and stupid question
> but perhaps you can help me. I want to understand NAT so I am trying to do
> the following:
> 
> I have three computers in my LAN (192.168.1.1; 192.168.1.2 and 192.168.1.3).
> 192.168.1.1 has a web server and I would like to access it through
> 192.168.1.2 with NAT. For example openning my browser in 192.168.1.3 and
> connecting to 192.168.1.2   I  should see the same as if I connected to
> 192.168.1.1 web server directly, so I have done the following in
> 192.168.1.2:
> 
>  iptables -t nat -A PREROUTING -p tcp --dport 80 -j
> DNAT --to-destination 192.168.1.1
> 
> 
>  iptables -t nat -A POSTROUTING -p tcp --sport 80 -j SNAT
> --to-source 192.168.1.2
> 
> However it doesn't work. Anyone can help me?
> 
> Thanks
> 
> Regards
> Jose Pascual
> 

nat problem

[Frans Luteijn]

Dear Sirs,

I have a little problem, which might be a bug. I have an 3COM
ISDN-router. It broadcasts every 10 seconds its connectionstatus to the
internal net. Now I want to forward those broadcasts to another network.
This is the situation:


+------+    +--------+    +--------+
|ISDN- |    |        |    |Internal|
|router|----|firewall|----|network |
+------+    |        |    +--------+
            +--------+
                |
                |
                |
            +------+
            |ADSL- |
            |router|
            +------+


The ISDN-router has 192.168.1.1/24, the ADSL-router has 172.19.3.1/16,
the firewall has at eth0 192.168.1.4, at eth1 172.19.3.2 and at eth2
192.168.2.1. The internal network is 192.168.2.0/24.

The firewall is a Debian-Linux with a 2.4.26 kernel with Nat enabled.

After reading of all the nesesary HOWTO's, I decided that that
forwarding should be done with prerouting. To know what I have to
forward, I have to know what the packets are. I turned logging on for
that interface, and if I can log the packets, I can also manipulate
them.
So I typed:

iptables -t nat -A PREROUTING -i eth0 -j LOG

and waited for the packets to come by. But nothing happened. Althought I
could see some other packets coming in. From my log:

Jul  2 16:38:16 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:50:04:0e:d9:00:08:00 SRC=192.168.1.3
DST=192.168.1.255 LEN=240 TOS=0x00 PREC=0x00 TTL=32 ID=19499 PROTO=UDP
SPT=138 DPT=138 LEN=220
Jul  2 16:43:40 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:50:04:0e:d9:00:08:00 SRC=192.168.1.3
DST=192.168.1.255 LEN=240 TOS=0x00 PREC=0x00 TTL=32 ID=19755 PROTO=UDP
SPT=138 DPT=138 LEN=220

Those are from a machine that will be moved to my internal network

Then I typed:

iptables -A INPUT -i eth0 -j LOG

and there were the packets:

Jul  2 16:47:43 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:08:00:4e:a6:f5:74:08:00 SRC=192.168.1.1
DST=192.168.1.255 LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=48404 PROTO=UDP
SPT=1025 DPT=2071 LEN=96
Jul  2 16:47:53 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:08:00:4e:a6:f5:74:08:00 SRC=192.168.1.1
DST=192.168.1.255 LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=48405 PROTO=UDP
SPT=1025 DPT=2071 LEN=96
Jul  2 16:48:03 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:08:00:4e:a6:f5:74:08:00 SRC=192.168.1.1
DST=192.168.1.255 LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=48406 PROTO=UDP
SPT=1025 DPT=2071 LEN=96

In /proc/net/ip_conntrack I can see:

udp      17 27 src=192.168.1.3 dst=192.168.1.255 sport=138 dport=138
[UNREPLIED] src=192.168.1.255 dst=192.168.1.3 sport=138 dport=138 use=1
udp      17 20 src=192.168.1.1 dst=192.168.1.255 sport=1025 dport=2071
[UNREPLIED] src=192.168.1.255 dst=192.168.1.1 sport=2071 dport=1025
use=1
.......


Now are my questions:
am I doing something wrong, e.g. shouldn't it be prerouting;
can't it be done, because of the sourceport and the destport are
different;
is it a bug in the nat-software or is it intended to work that way?

If you need some extra information, I am happily to provide it.

Yours Sincerely,
--
Frans Luteijn
PGP PblKey fprnt=C4 87 CE AF BC B6 98 C1  EF 42 A1 9A E2 C0 42 5B

Re: nat problem

[Antony Stone]

On Monday 05 July 2004 5:33 pm, Frans Luteijn wrote:

> Dear Sirs,
>
> I have a little problem, which might be a bug. I have an 3COM
> ISDN-router. It broadcasts every 10 seconds its connectionstatus to the
> internal net.

What do yuo mean by "broadcasts"?   What protocol is being used?   What 
address are the packets sent to?

> Now I want to forward those broadcasts to another network.

If, by broadcasts, you mean packets addressed to the "broadcast address" of 
your subnet, it can't be done - you cannot route broadcast packets across a 
router (that's why people use bridges).   The only way it could be done is to 
have a machine which understands the protocol, and is connected to both 
networks, picking up the broadcast packets on one subnet, and then creating 
new broadcast packets to send to the other network (and, of course, dealign 
sensibly with the replies).

This, for example, is how you get Windows NetBios share browsing to work 
across network boundaries - it's not pretty, but if broadcast packets are 
what you're starting from then it's the only way.

Regards,

Antony.

-- 
I love deadlines.   I love the whooshing noise they make as they go by.

 - Douglas Noel Adams

                                                     Please reply to the list;
                                                           please don't CC me.

nat problem

[Frans Luteijn]

Dear sirs, madams,

I have a little problem, which might be a bug. I have an 3COM
ISDN-router. It broadcasts every 10 seconds its connectionstatus to the
internal net. Now I want to forward those broadcasts to another network.

This is the situation:


+------+    +--------+    +--------+
|ISDN- |    |        |    |Internal|
|router|----|firewall|----|network |
+------+    |        |    +--------+
            +--------+
                |
                |
                |
            +------+
            |ADSL- |
            |router|
            +------+


The ISDN-router has 192.168.1.1/24, the ADSL-router has 172.19.3.1/16,
the firewall has at eth0 192.168.1.4, at eth1 172.19.3.2 and at eth2
192.168.2.1. The internal network is 192.168.2.0/24.

The firewall is a Debian-Linux with a 2.4.26 kernel with Nat enabled.

After reading of all the nesesary HOWTO's, I decided that that
forwarding should be done with prerouting. To know what I have to
forward, I have to know what the packets are. I turned logging on for
that interface, and if I can log the packets, I can also manipulate
them.
So I typed:

iptables -t nat -A PREROUTING -i eth0 -j LOG

and waited for the packets to come by. But nothing happened. Althought I

could see some other packets coming in. From my log:

Jul  2 16:38:16 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:50:04:0e:d9:00:08:00 SRC=192.168.1.3
DST=192.168.1.255 LEN=240 TOS=0x00 PREC=0x00 TTL=32 ID=19499 PROTO=UDP
SPT=138 DPT=138 LEN=220
Jul  2 16:43:40 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:50:04:0e:d9:00:08:00 SRC=192.168.1.3
DST=192.168.1.255 LEN=240 TOS=0x00 PREC=0x00 TTL=32 ID=19755 PROTO=UDP
SPT=138 DPT=138 LEN=220

Those are from a machine that will be moved to my internal network

Then I typed:

iptables -A INPUT -i eth0 -j LOG

and there were the packets:

Jul  2 16:47:43 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:08:00:4e:a6:f5:74:08:00 SRC=192.168.1.1
DST=192.168.1.255 LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=48404 PROTO=UDP
SPT=1025 DPT=2071 LEN=96
Jul  2 16:47:53 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:08:00:4e:a6:f5:74:08:00 SRC=192.168.1.1
DST=192.168.1.255 LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=48405 PROTO=UDP
SPT=1025 DPT=2071 LEN=96
Jul  2 16:48:03 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:08:00:4e:a6:f5:74:08:00 SRC=192.168.1.1
DST=192.168.1.255 LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=48406 PROTO=UDP
SPT=1025 DPT=2071 LEN=96

In /proc/net/ip_conntrack I can see:

udp      17 27 src=192.168.1.3 dst=192.168.1.255 sport=138 dport=138
[UNREPLIED] src=192.168.1.255 dst=192.168.1.3 sport=138 dport=138 use=1
udp      17 20 src=192.168.1.1 dst=192.168.1.255 sport=1025 dport=2071
[UNREPLIED] src=192.168.1.255 dst=192.168.1.1 sport=2071 dport=1025
use=1
.......


Now are my questions:
am I doing something wrong, e.g. shouldn't it be prerouting;
can't it be done, because of the sourceport and the destport are
different;
is it a bug in the nat-software or is it intended to work that way?

If you need some extra information, I am happily to provide it.

Yours Sincerely,
--
Frans Luteijn
PGP PblKey fprnt=C4 87 CE AF BC B6 98 C1  EF 42 A1 9A E2 C0 42 5B

Re: nat problem

[Antony Stone]

On Tuesday 13 July 2004 9:40 pm, Frans Luteijn wrote:

> I have a little problem, which might be a bug. I have an 3COM
> ISDN-router. It broadcasts every 10 seconds its connectionstatus to the
> internal net. Now I want to forward those broadcasts to another network.

On Wednesday 07 July 2004 2:07 pm, Antony Stone wrote:

> On Monday 05 July 2004 5:33 pm, Frans Luteijn wrote:
> >
> > I have a little problem, which might be a bug. I have an 3COM
> > ISDN-router. It broadcasts every 10 seconds its connectionstatus to the
> > internal net.
>
> What do yuo mean by "broadcasts"?   What protocol is being used?   What
> address are the packets sent to?
>
> > Now I want to forward those broadcasts to another network.
>
> If, by broadcasts, you mean packets addressed to the "broadcast address" of
> your subnet, it can't be done - you cannot route broadcast packets across a
> router (that's why people use bridges).   The only way it could be done is
> to have a machine which understands the protocol, and is connected to both
> networks, picking up the broadcast packets on one subnet, and then creating
> new broadcast packets to send to the other network (and, of course, dealign
> sensibly with the replies).
>
> This, for example, is how you get Windows NetBios share browsing to work
> across network boundaries - it's not pretty, but if broadcast packets are
> what you're starting from then it's the only way.
>
> Regards,
>
> Antony.

-- 
"Linux is going to be part of the future. It's going to be like Unix was."

 - Peter Moore, Asia-Pacific general manager, Microsoft

                                                     Please reply to the list;
                                                           please don't CC me.

Re: nat problem

[Frans Luteijn]

Antony Stone schreef:

> On Tuesday 13 July 2004 9:40 pm, Frans Luteijn wrote:
>
> > I have a little problem, which might be a bug. I have an 3COM
> > ISDN-router. It broadcasts every 10 seconds its connectionstatus to the
> > internal net. Now I want to forward those broadcasts to another network.
>
> On Wednesday 07 July 2004 2:07 pm, Antony Stone wrote:
>
> > On Monday 05 July 2004 5:33 pm, Frans Luteijn wrote:
> > >
> > > I have a little problem, which might be a bug. I have an 3COM
> > > ISDN-router. It broadcasts every 10 seconds its connectionstatus to the
> > > internal net.
> >
> > What do yuo mean by "broadcasts"?   What protocol is being used?   What
> > address are the packets sent to?

These are real broadcasts to 192.168.1.255. The protocol is UDP, the source port
is 1025 and the destination port is 2071.Isn't it weird, that at the nat-table,
when I add a rule for logging, I can't see the above meant packets, but at the
filter- and the mangle-table those packets are logged?

At a company I worked for, DHCP broadcasts were sent from one network to another,
so it should be possible.

> >
> > > Now I want to forward those broadcasts to another network.
> >
> > If, by broadcasts, you mean packets addressed to the "broadcast address" of
> > your subnet, it can't be done - you cannot route broadcast packets across a
> > router (that's why people use bridges).   The only way it could be done is
> > to have a machine which understands the protocol, and is connected to both
> > networks, picking up the broadcast packets on one subnet, and then creating
> > new broadcast packets to send to the other network (and, of course, dealign
> > sensibly with the replies).

This is exactly what I mean. I want to forward the broadcastpackets from
192.168.1.255 to 192.168.2.255. I don't want to use a bridge here. I want those
networks separated, so I can share the connection to others without concerning
they can see my private network.

> >
> > This, for example, is how you get Windows NetBios share browsing to work
> > across network boundaries - it's not pretty, but if broadcast packets are
> > what you're starting from then it's the only way.
> >
> > Regards,
> >
> > Antony.
>
> --
> "Linux is going to be part of the future. It's going to be like Unix was."
>
>  - Peter Moore, Asia-Pacific general manager, Microsoft
>
>                                                      Please reply to the list;
>                                                            please don't CC me.



--
Frans Luteijn
PGP PblKey fprnt=C4 87 CE AF BC B6 98 C1  EF 42 A1 9A E2 C0 42 5B

Re: nat problem

[Antony Stone]

On Tuesday 13 July 2004 11:21 pm, Frans Luteijn wrote:

> Antony Stone schreef:
> > On Tuesday 13 July 2004 9:40 pm, Frans Luteijn wrote:
> > > I have a little problem, which might be a bug. I have an 3COM
> > > ISDN-router. It broadcasts every 10 seconds its connectionstatus to the
> > > internal net. Now I want to forward those broadcasts to another
> > > network.
> >
> > > What do you mean by "broadcasts"?   What protocol is being used?   What
> > > address are the packets sent to?
>
> These are real broadcasts to 192.168.1.255. The protocol is UDP, the source
> port is 1025 and the destination port is 2071.Isn't it weird, that at the
> nat-table, when I add a rule for logging, I can't see the above meant
> packets, but at the filter- and the mangle-table those packets are logged?

No, I don't think so.   Broadcast packets are not supposed to cross routers 
(they will enter the router as a machine on the local subnet, but they will 
not be routed anywhere else, because they already come from the subnet they 
are addressed to)

> At a company I worked for, DHCP broadcasts were sent from one network to
> another, so it should be possible.

I would suggest that the network you refer to had a DHCP relay server on it.

> > > > Now I want to forward those broadcasts to another network.
> > >
> > > If, by broadcasts, you mean packets addressed to the "broadcast
> > > address" of your subnet, it can't be done - you cannot route broadcast
> > > packets across a router (that's why people use bridges).   The only way
> > > it could be done is to have a machine which understands the protocol,
> > > and is connected to both networks, picking up the broadcast packets on
> > > one subnet, and then creating new broadcast packets to send to the
> > > other network (and, of course, dealign sensibly with the replies).
>
> This is exactly what I mean. I want to forward the broadcastpackets from
> 192.168.1.255 to 192.168.2.255. I don't want to use a bridge here. I want
> those networks separated, so I can share the connection to others without
> concerning they can see my private network.

In that case put a DHCP relay server on the subnet on which the broadcasts are 
being generated, and configure it to forward the packets to the DHCP server 
on the other subnet.

You cannot use netfilter to do this, simply because broadcast packets don't 
cross routers.   That is why DHCP relays exist.


Regards,

Antony.

-- 
How I want a drink, alcoholic of course, after the heavy chapters involving 
quantum mechanics.

 - 3.14159265358979

                                                     Please reply to the list;
                                                           please don't CC me.

Re: nat problem

[Nick Taylor]

> > > > I have a little problem, which might be a bug. I have an 3COM
> > > > ISDN-router. It broadcasts every 10 seconds its connectionstatus to the
> > > > internal net. Now I want to forward those broadcasts to another
> > > > network.
> > >
> > > > What do you mean by "broadcasts"?   What protocol is being used?   What
> > > > address are the packets sent to?
> >
> > These are real broadcasts to 192.168.1.255. The protocol is UDP, the source
> > port is 1025 and the destination port is 2071.Isn't it weird, that at the
> > nat-table, when I add a rule for logging, I can't see the above meant
> > packets, but at the filter- and the mangle-table those packets are logged?
>
> No, I don't think so.   Broadcast packets are not supposed to cross routers
> (they will enter the router as a machine on the local subnet, but they will
> not be routed anywhere else, because they already come from the subnet they
> are addressed to)
>
Not to be contrary, and *NOT* to suggest that this is correct behaviour,
but...  The company I used to work for uses a lot of LinkSys gear for CPE,
including their NAT routers and their VPN routers, and we've had bizarre
problems with these products.  The VPN router, in particular *will*
forward a packet with the destination address set to the IP broadcast
address!  Then, they run NAT rules beyond the VPN server at the other
side, so you get:
192.168.1.43 -> 192.168.1.255, which getts natted to:
real_ip -> 192.168.1.255, but of course, that's behind the VPN tunnel, so,
the box routes it back through the VPN, where it gets spit out on the
customer's lan, (thankfully NOT forwarded back again) but this confuses
Windoze something aweful, and causes it to refuse to use windows
networking, because it thinks there's another machine on the network with
it's name registered. DOH!  Anyway, the point is that while it may or may
not be correct, many products do it, and there must be some (twisted)
reason that the hardware vendors chose to enhance (read break) their
products in this way, ie, some application may depend on this (braindead)
behaviour.

Re: nat problem

[Frans Luteijn]

Antony Stone schreef:

> On Tuesday 13 July 2004 11:21 pm, Frans Luteijn wrote:
>
> > Antony Stone schreef:
> > > On Tuesday 13 July 2004 9:40 pm, Frans Luteijn wrote:
> > > > I have a little problem, which might be a bug. I have an 3COM
> > > > ISDN-router. It broadcasts every 10 seconds its connectionstatus to the
> > > > internal net. Now I want to forward those broadcasts to another
> > > > network.
> > >
> > > > What do you mean by "broadcasts"?   What protocol is being used?   What
> > > > address are the packets sent to?
> >
> > These are real broadcasts to 192.168.1.255. The protocol is UDP, the source
> > port is 1025 and the destination port is 2071.Isn't it weird, that at the
> > nat-table, when I add a rule for logging, I can't see the above meant
> > packets, but at the filter- and the mangle-table those packets are logged?
>
> No, I don't think so.   Broadcast packets are not supposed to cross routers
> (they will enter the router as a machine on the local subnet, but they will
> not be routed anywhere else, because they already come from the subnet they
> are addressed to)
>

I have been doing some testing:I have a machine, which broadcasts to 192.168.1.255
prot.: udp sport/dport: 138/138
I typed in:

iptables -t nat -A PREROUTING -i eth0 -d 192.168.1.255 -p udp --sport 138 -j LOG
iptables -t nat -A PREROUTING -i eth0 -d 192.168.1.255 -p udp --sport 138 -j DNAT
192.168.2.255

Then I saw in my log:
Jul 14 02:34:16 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:50:04:0e:d9:00:08:00 SRC=192.168.1.3 DST=192.168.1.255
LEN=240 TOS=0x00 PREC=0x00 TTL=32 ID=60162 PROTO=UDP SPT=138 DPT=138 LEN=220

and I saw trafic on my other network.
When I type:

cat /proc/net/ip_conntrack

I see:
udp      17 17 src=192.168.1.3 dst=192.168.1.255 sport=138 dport=138 [UNREPLIED]
src=192.168.2.255 dst=192.168.1.3 sport=138 dport=138 use=1

This means to me, that those packets are forwarded. So why can't I forward the
other packets (192.168.1.255, prot.: udp, sport/dport: 1025/2071)?

> > At a company I worked for, DHCP broadcasts were sent from one network to
> > another, so it should be possible.
>
> I would suggest that the network you refer to had a DHCP relay server on it.
>
> > > > > Now I want to forward those broadcasts to another network.
> > > >
> > > > If, by broadcasts, you mean packets addressed to the "broadcast
> > > > address" of your subnet, it can't be done - you cannot route broadcast
> > > > packets across a router (that's why people use bridges).   The only way
> > > > it could be done is to have a machine which understands the protocol,
> > > > and is connected to both networks, picking up the broadcast packets on
> > > > one subnet, and then creating new broadcast packets to send to the
> > > > other network (and, of course, dealign sensibly with the replies).
> >
> > This is exactly what I mean. I want to forward the broadcastpackets from
> > 192.168.1.255 to 192.168.2.255. I don't want to use a bridge here. I want
> > those networks separated, so I can share the connection to others without
> > concerning they can see my private network.
>
> In that case put a DHCP relay server on the subnet on which the broadcasts are
> being generated, and configure it to forward the packets to the DHCP server
> on the other subnet.
>
> You cannot use netfilter to do this, simply because broadcast packets don't
> cross routers.   That is why DHCP relays exist.
>
> Regards,
>
> Antony.
>
> --
> How I want a drink, alcoholic of course, after the heavy chapters involving
> quantum mechanics.
>
>  - 3.14159265358979
>
>                                                      Please reply to the list;
>                                                            please don't CC me.



--
Frans Luteijn
PGP PblKey fprnt=C4 87 CE AF BC B6 98 C1  EF 42 A1 9A E2 C0 42 5B

Re: nat problem

[Antony Stone]

On Wednesday 14 July 2004 2:02 am, Frans Luteijn wrote:

> Antony Stone schreef:
> >
> > No, I don't think so.   Broadcast packets are not supposed to cross
> > routers (they will enter the router as a machine on the local subnet, but
> > they will not be routed anywhere else, because they already come from the
> > subnet they are addressed to)
>
> I have been doing some testing:I have a machine, which broadcasts to
> 192.168.1.255 prot.: udp sport/dport: 138/138
> I typed in:
>
> iptables -t nat -A PREROUTING -i eth0 -d 192.168.1.255 -p udp --sport 138
> -j LOG iptables -t nat -A PREROUTING -i eth0 -d 192.168.1.255 -p udp
> --sport 138 -j DNAT 192.168.2.255
>
> Then I saw in my log:
> Jul 14 02:34:16 firewall kernel: IN=eth0 OUT=
> MAC=ff:ff:ff:ff:ff:ff:00:50:04:0e:d9:00:08:00 SRC=192.168.1.3
> DST=192.168.1.255 LEN=240 TOS=0x00 PREC=0x00 TTL=32 ID=60162 PROTO=UDP
> SPT=138 DPT=138 LEN=220
>
> and I saw trafic on my other network.
> When I type:
>
> cat /proc/net/ip_conntrack
>
> I see:
> udp      17 17 src=192.168.1.3 dst=192.168.1.255 sport=138 dport=138
> [UNREPLIED] src=192.168.2.255 dst=192.168.1.3 sport=138 dport=138 use=1
>
> This means to me, that those packets are forwarded. So why can't I forward
> the other packets (192.168.1.255, prot.: udp, sport/dport: 1025/2071)?

What happens if you try the same test as above, but with the port numbers you 
are interested in?   Do the connection tracking table and the log file 
suggest that packets are being forwarded?   If you can get it to "work" on 
port 138, I don't see why it shouldn't "work" on port 2071.

BTW: I put "work" in quotes there because although you see the packets going 
through the firewall, does the actual NetBios service allow you to browse 
Windows shares on machines on the other subnet?   My expectation is not, 
because there have been many questions on this list previously about share 
browsing across routers (Windows does network browsing using broadcast 
packets), the solution to which has always been a PDC on the source network, 
with knowledge of the second subnet.

Regards,

Antony.

-- 
I think, therefore I am.
I'm pink, therefore I'm Spam.
I drink, therefore I think I am.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: nat problem

[Frans Luteijn]

Antony Stone schreef:

> On Wednesday 14 July 2004 2:02 am, Frans Luteijn wrote:
>
> > Antony Stone schreef:
> > >
> > > No, I don't think so.   Broadcast packets are not supposed to cross
> > > routers (they will enter the router as a machine on the local subnet, but
> > > they will not be routed anywhere else, because they already come from the
> > > subnet they are addressed to)
> >
> > I have been doing some testing:I have a machine, which broadcasts to
> > 192.168.1.255 prot.: udp sport/dport: 138/138
> > I typed in:
> >
> > iptables -t nat -A PREROUTING -i eth0 -d 192.168.1.255 -p udp --sport 138
> > -j LOG iptables -t nat -A PREROUTING -i eth0 -d 192.168.1.255 -p udp
> > --sport 138 -j DNAT 192.168.2.255
> >
> > Then I saw in my log:
> > Jul 14 02:34:16 firewall kernel: IN=eth0 OUT=
> > MAC=ff:ff:ff:ff:ff:ff:00:50:04:0e:d9:00:08:00 SRC=192.168.1.3
> > DST=192.168.1.255 LEN=240 TOS=0x00 PREC=0x00 TTL=32 ID=60162 PROTO=UDP
> > SPT=138 DPT=138 LEN=220
> >
> > and I saw trafic on my other network.
> > When I type:
> >
> > cat /proc/net/ip_conntrack
> >
> > I see:
> > udp      17 17 src=192.168.1.3 dst=192.168.1.255 sport=138 dport=138
> > [UNREPLIED] src=192.168.2.255 dst=192.168.1.3 sport=138 dport=138 use=1
> >
> > This means to me, that those packets are forwarded. So why can't I forward
> > the other packets (192.168.1.255, prot.: udp, sport/dport: 1025/2071)?
>
> What happens if you try the same test as above, but with the port numbers you
> are interested in?   Do the connection tracking table and the log file
> suggest that packets are being forwarded?   If you can get it to "work" on
> port 138, I don't see why it shouldn't "work" on port 2071.
>

Nothing happens, no logging or anything else:iptables -t nat -A PREROUTING -i eth0
-d 192.168.1.255 -p udp --sport 1025 -j LOG
iptables -t nat -A PREROUTING -i eth0 -d 192.168.1.255 -p udp --sport 1025 -j DNAT
--to 192.168.2.255

When I type:
cat /proc/net/ip_conntrack
I see:
udp      17 25 src=192.168.1.1 dst=192.168.1.255 sport=1025 dport=2071 [UNREPLIED]
src=192.168.1.255 dst=192.168.1.1 sport=2071 dport=1025 use=1

After typing:
iptables -t nat -I PREROUTING 2 -i eth0 -d 192.168.1.255 -p udp --sport 2071 -j
LOG
iptables -t nat -I PREROUTING 3 -i eth0 -d 192.168.1.255 -p udp --dport 1025 -j
LOG
iptables -t nat -I PREROUTING 4 -i eth0 -d 192.168.1.255 -p udp --dport 2071 -j
LOG
nothing happens either.

But after typing:
iptables -t filter -A INPUT -i eth0 -d 192.168.1.255 -p udp --sport 1025 -j LOG
I see the packets coming in:
Jul 15 00:59:11 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:08:00:4e:a6:f5:74:08:00 SRC=192.168.1.1 DST=192.168.1.255
LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=31435 PROTO=UDP SPT=1025 DPT=2071 LEN=96
Jul 15 00:59:21 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:08:00:4e:a6:f5:74:08:00 SRC=192.168.1.1 DST=192.168.1.255
LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=31436 PROTO=UDP SPT=1025 DPT=2071 LEN=96
Jul 15 00:59:31 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:08:00:4e:a6:f5:74:08:00 SRC=192.168.1.1 DST=192.168.1.255
LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=31437 PROTO=UDP SPT=1025 DPT=2071 LEN=96

So what is wrong here? I think, it is a bug, because it doesn't work as expected.

> BTW: I put "work" in quotes there because although you see the packets going
> through the firewall, does the actual NetBios service allow you to browse
> Windows shares on machines on the other subnet?   My expectation is not,
> because there have been many questions on this list previously about share
> browsing across routers (Windows does network browsing using broadcast
> packets), the solution to which has always been a PDC on the source network,
> with knowledge of the second subnet.
>

That was not my intention. This was only an example to show you, it is possible to
forward broadcastpackets to another network.

> Regards,
>
> Antony.
>
> --
> I think, therefore I am.
> I'm pink, therefore I'm Spam.
> I drink, therefore I think I am.
>
>                                                      Please reply to the list;
>                                                            please don't CC me.

--
Frans Luteijn
PGP PblKey fprnt=C4 87 CE AF BC B6 98 C1  EF 42 A1 9A E2 C0 42 5B
GPG PblKey fprnt=ED20 0F25 C233 DC59 3FFA  170E D0BF 15F5 0BA6 1355

Re: nat problem

[Antony Stone]

On Thursday 15 July 2004 12:30 am, Frans Luteijn wrote:

> Antony Stone schreef:
> >
> > What happens if you try the same test as above, but with the port numbers
> > you are interested in?   Do the connection tracking table and the log
> > file suggest that packets are being forwarded?   If you can get it to
> > "work" on port 138, I don't see why it shouldn't "work" on port 2071.
>
> Nothing happens, no logging or anything else
>
> So what is wrong here? I think, it is a bug, because it doesn't work as
> expected.

Well, I don't think it can be called a bug in netfilter (I may be wrong), 
because there's nothing about netfilter which should make NAT for one port 
any different from NAT for another port.

I'm surprised you got the port 138 packets to be forwarded; I don't know why 
the two are behaving differently.

> > BTW: I put "work" in quotes there because although you see the packets
> > going through the firewall, does the actual NetBios service allow you to
> > browse Windows shares on machines on the other subnet?   My expectation
> > is not, because there have been many questions on this list previously
> > about share browsing across routers (Windows does network browsing using
> > broadcast packets), the solution to which has always been a PDC on the
> > source network, with knowledge of the second subnet.
>
> That was not my intention. This was only an example to show you, it is
> possible to forward broadcast packets to another network.

Oh, sure - I knew you didn't actually *want* to use port 138, but I was still 
interested to know whether, having got the packets to cross the router, they 
would work and provide your witha  working service.   If not, then it's a bit 
moot as to whether you can forward the broadcasts or not.

I hope someone else here can suggest whether (and if so, how) it's possible to 
do what you want - I didn't think it was, but you've obviously got more to 
work than I had expected possible.

Regards,

Antony.

-- 
"It is easy to be blinded to the essential uselessness of them by the sense of 
achievement you get from getting them to work at all. In other words - and 
this is the rock solid principle on which the whole of the Corporation's 
Galaxy-wide success is founded - their fundamental design flaws are 
completely hidden by their superficial design flaws."

 - Douglas Noel Adams

                                                     Please reply to the list;
                                                           please don't CC me.

Re: nat problem

[Frans Luteijn]

Antony Stone schreef:

> On Thursday 15 July 2004 12:30 am, Frans Luteijn wrote:
>
> > Antony Stone schreef:
> > >
> > > What happens if you try the same test as above, but with the port numbers
> > > you are interested in?   Do the connection tracking table and the log
> > > file suggest that packets are being forwarded?   If you can get it to
> > > "work" on port 138, I don't see why it shouldn't "work" on port 2071.
> >
> > Nothing happens, no logging or anything else
> >
> > So what is wrong here? I think, it is a bug, because it doesn't work as
> > expected.
>
> Well, I don't think it can be called a bug in netfilter (I may be wrong),
> because there's nothing about netfilter which should make NAT for one port
> any different from NAT for another port.
>
> I'm surprised you got the port 138 packets to be forwarded; I don't know why
> the two are behaving differently.

Maybe because in the 138-case the sport and the dport are the same and
in the
other case they are different? Or the sport and dport are above 1024? I
don't know
either. Who should I ask, any suggestion?

>

(snip)

>
>
>
> I hope someone else here can suggest whether (and if so, how) it's possible to
> do what you want - I didn't think it was, but you've obviously got more to
> work than I had expected possible.

What is a broadcastpacket different from any other packet, except that
every
computer on the network can respond to it? So it can be treated as any
other
packet.

>
>
> Regards,
>
> Antony.
>

P.S.
Sorry for the late response, for some strange reason I didn't receive
any mail from this list any more for two days. I had to look up the
answer in the archieves.

Regards,
--
Frans Luteijn
PGP PblKey fprnt=C4 87 CE AF BC B6 98 C1  EF 42 A1 9A E2 C0 42 5B
GPG PblKey fprnt=ED20 0F25 C233 DC59 3FFA  170E D0BF 15F5 0BA6 1355