Linux Advanced Routing and Traffic Control list
 help / color / mirror / Atom feed
From: Greg Scott <GregScott@InfraSupportEtc.com>
To: lartc@vger.kernel.org
Subject: RE: [LARTC] routing with 2.4 kernel
Date: Sat, 27 Oct 2001 01:54:32 +0000	[thread overview]
Message-ID: <marc-lartc-100414767220368@msgid-missing> (raw)
In-Reply-To: <marc-lartc-100411065110257@msgid-missing>

My situation is a little different than yours.  I want to masquerade
everything in my internal LAN that goes back to the Internet.  Same idea,
just a different implementation.  Here is the relevant masquerading rule I
put in that works:

	echo "	MASQUERADing everything else"
# $IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j LOG
$IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j MASQUERADE

(Note the line commented out - it's in there in case I need to debug
anything.)

In your case, I don't think you want to masquerade packets from source
10.2.0.0/16.  I think you want to masquerade packets on the way to
destination 10.2.0.0/16.  So try this as a rule instead:

iptables -t nat -A POSTROUTING  -d 10.2.0.0/16  -j MASQUERADE
(Not sure if this will work after thinking about it.)

This is better:
iptables -t nat -A POSTROUTING  -o eth1  -j MASQUERADE
This says to masquerade anything outbound on interface eth1, no matter where
it goes and no matter what protocol.

or maybe something like this:
iptables -t nat -A POSTROUTING  -o eth1 -p tcp --sport 20 -j MASQUERADE
to get really specific.

Everyone from 10.2.0.0/16 thinks your iptables box is the ftp server, but
the real ftp server lives on the other side.  So when your users ftp, they
go to 10.2.0.1.  So the firewall sees this stuff and needs to get it to the
real ftp server.  To make this work, you will also need some PREROUTING
rules, like this: (The variables PUBLIC_WEB1_IP, and PRIVATE_WEB1_IP have
the IP addresses.)

echo "	Setting up Destination NAT (DNAT) rules for  . . ."
echo "	FTP command channel (TCP port 21)"
$IPTABLES -t nat -A PREROUTING -i $INET_IFACE -d $PUBLIC_WEB1_IP \
		-p tcp --dport 21 -j DNAT --to $PRIVATE_WEB1_IP

In your situation, try something like this:
$IPTABLES -t nat -A PREROUTING -i eth1 -d 10.2.0.1 \
		-p tcp --dport 21 -j DNAT --to 200.47.43.240

This says anything that comes in on interface eth1 with protocol tcp and
port 21, fudge in the ip address of the real ftp server.  Since this is in
the PREROUTING chain, do this before doing any other processing.

Also, be sure to put in a route from your ftp server thru the firewall to
get to network 10.2.0.0/16.  Something like this:

route add -net 10.2.0.0 netmask 255.255.0.0 gw 200.47.43.241

And don't forget to do this in your firewall to turn on IP forwarding:

echo "Turning on IP forwarding"
echo "1" > /proc/sys/net/ipv4/ip_forward

Also, you might not need your forwarding rule.  Your ftp users all think
your firewall is the ftp server, right?  So they won't be sending packets
directly to the real ftp server.  I could be wrong on this - try some
experiments.  

Finally, here are some really valuable commands that can help debugging:

iptables -L -v -n
iptables -L -v -n -t nat
Gives a verbose listing of all your rules, in order, and a count of the
number of packets that met each rule.

iptables -Z
iptables -Z -t nat
Zeroes the counters.

Oh - and for debugging, put in a rule like this at the end of each chain:

$IPTABLES -A OUTPUT -j LOG
# Debug - Log anything and everything that gets this far

$IPTABLES -A OUTPUT -j DROP

This will log everything that comes "drops off the end".  You can then get
counts for what packets you drop and you can find more detail like this:

more /var/log/messages    or
tail /var/log/messages

And take a look at installing tcpdump.  This will give you a real-time
stream of packets coming through and you can watch what's happening as it
happens.  This is a super-valuable tool for debugging.

- Greg Scott



-----Original Message-----
From: Fabian Gervan [mailto:fabian1@inter-k.com.ar]
Sent: Friday, October 26, 2001 6:45 AM
To: lartc@mailman.ds9a.nl
Subject: [LARTC] routing with 2.4 kernel


Hello

I am new with 2.4 kernel an have trouble to setup routing as I had in
2.2 kernel:

My setup:

server1  eth0:200.47.43.240   (FTP SERVER)

server2  eth0: 200.47.43.241  (MASQ BOX)
         eth1:  10.2.0.1

client1:       10.2.0.2
client2:       10.2.0.3
clientN:       10.2.0.nnn

I want to clients 10.2.0.0/16 connect to my FTP server with 10.2 IP (no
internet IP).
200.47.43.240 is a linux 2.2 kernel, it already have a right setup for
routing to 10.2.0.0/16 clients, I have trouble with 200.47.43.241
(linux 2.4).

My actual setup: (in 200.47.43.241)
iptables -A FORWARD -s 10.2.0.0/16  -d 200.47.43.240 -j ACCEPT //it
doesn't work)
iptables -t nat -A POSTROUTING  -s 10.2.0.0/16  -j MASQUERADE

-- 
Saludos,
 Fabian Gervan


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO:
http://ds9a.nl/2.4Routing/

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/

      reply	other threads:[~2001-10-27  1:54 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-26 11:45 [LARTC] routing with 2.4 kernel Fabian Gervan
2001-10-27  1:54 ` Greg Scott [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-lartc-100414767220368@msgid-missing \
    --to=gregscott@infrasupportetc.com \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox