use of the limiting options

use of the limiting options

[Tib]

I'd like to use the --limit and --limit-burst options to protect my sshd
from dictionary password attacks. Considering the userbase and activity
level I'd say that something like this would suit me just fine.

--limit 6/hour
--limit-burst 2

This would limit it to two connect/login attempts at first, and then one
more every 10 minutes.. correct?

Would this be the proper command to use? I'm trying to just limit
connections from the outside world, not from the local network, hence the
address as a destination:

iptables -A INPUT --d 66.80.174.210 --dport 22   \
   --limit 6/hour --limit-burst 2


<EOL>
Tib

Re: use of the limiting options

[Tib]

Ok.. looked at my other rules and came up with this instead.. but it still
complains:

iptables -A INPUT -i eth0 -p tcp --destination-port 22 \
--limit 6/hour --limit-burst 2

iptables v1.2.6a: Unknown arg `--limit'
Try `iptables -h' or 'iptables --help' for more information.

Help would be much appreciated :]

<EOL>
Tib


On Tue, 25 Jan 2005, Tib wrote:

>
> I'd like to use the --limit and --limit-burst options to protect my sshd
> from dictionary password attacks. Considering the userbase and activity
> level I'd say that something like this would suit me just fine.
>
> --limit 6/hour
> --limit-burst 2
>
> This would limit it to two connect/login attempts at first, and then one
> more every 10 minutes.. correct?
>
> Would this be the proper command to use? I'm trying to just limit
> connections from the outside world, not from the local network, hence the
> address as a destination:
>
> iptables -A INPUT --d 66.80.174.210 --dport 22   \
>    --limit 6/hour --limit-burst 2
>
>
> <EOL>
> Tib
>

Re: use of the limiting options

[Tib]

Kept digging and I found a syntax that at least does not get rejected..
Here's hoping it works:

iptables -A INPUT -i eth0 -p tcp --destination-port 22 \
      -m limit --limit 6/hour --limit-burst 2

<EOL>
Tib

On Tue, 25 Jan 2005, Tib wrote:

>
> Ok.. looked at my other rules and came up with this instead.. but it still
> complains:
>
> iptables -A INPUT -i eth0 -p tcp --destination-port 22 \
> --limit 6/hour --limit-burst 2
>
> iptables v1.2.6a: Unknown arg `--limit'
> Try `iptables -h' or 'iptables --help' for more information.
>
> Help would be much appreciated :]
>
> <EOL>
> Tib
>
>
> On Tue, 25 Jan 2005, Tib wrote:
>
> >
> > I'd like to use the --limit and --limit-burst options to protect my sshd
> > from dictionary password attacks. Considering the userbase and activity
> > level I'd say that something like this would suit me just fine.
> >
> > --limit 6/hour
> > --limit-burst 2
> >
> > This would limit it to two connect/login attempts at first, and then one
> > more every 10 minutes.. correct?
> >
> > Would this be the proper command to use? I'm trying to just limit
> > connections from the outside world, not from the local network, hence the
> > address as a destination:
> >
> > iptables -A INPUT --d 66.80.174.210 --dport 22   \
> >    --limit 6/hour --limit-burst 2
> >
> >
> > <EOL>
> > Tib
> >
>

Re: use of the limiting options

[Mark Moseley]

Heh, forgot to CC the list on my original reply, sorry.

Makes sense on the --limit-burst. :)

As far as adding the DROP/REJECT after that, once the connection limit
in the --limit rule has been reached, it will simply just fall through
the next rule (i.e. it doesn't do any implicit DROP'ing on its own).
So the rule with the --limit just matches up to the rate in --limit
and then doesn't match. Without a rule later on (or a policy to
DROP/REJECT), any overflow will just get accepted.



> Yup - once I saw an example of someone USING the limit options it made
> sense :]
> 
> The only thing --limit-burst does is say 'you have x many free tries
> before you fall under the rate limit of Y/time restrictions'.
> 
> So on mine, you can effectively connect twice in short succession before
> you are cut back to once every 10 minutes (6 per hour).
> 
> > Be sure to add a DROP or REJECT on the same match (unless the default
> > policy is already that).
> 
> I don't follow why to do this - explain?
> 
> <EOL>
> Tib
>

Re: use of the limiting options

[Tib]

You're kidding o_O

I guess it makes sense.. the connections will trip that rule until it is
satisfied and then move onto the next. That's.. bizarre.

<EOL>
Tib

On Tue, 25 Jan 2005, Mark Moseley wrote:

> Heh, forgot to CC the list on my original reply, sorry.
>
> Makes sense on the --limit-burst. :)
>
> As far as adding the DROP/REJECT after that, once the connection limit
> in the --limit rule has been reached, it will simply just fall through
> the next rule (i.e. it doesn't do any implicit DROP'ing on its own).
> So the rule with the --limit just matches up to the rate in --limit
> and then doesn't match. Without a rule later on (or a policy to
> DROP/REJECT), any overflow will just get accepted.
>
>
>
> > Yup - once I saw an example of someone USING the limit options it made
> > sense :]
> >
> > The only thing --limit-burst does is say 'you have x many free tries
> > before you fall under the rate limit of Y/time restrictions'.
> >
> > So on mine, you can effectively connect twice in short succession before
> > you are cut back to once every 10 minutes (6 per hour).
> >
> > > Be sure to add a DROP or REJECT on the same match (unless the default
> > > policy is already that).
> >
> > I don't follow why to do this - explain?
> >
> > <EOL>
> > Tib
> >
>

Re: use of the limiting options

[Mark Moseley]

It's used very often for logging, so that the logging doesn't swamp
the firewall's disk. Imagine you're dropping 100 packet/s and want to
log what's going on. You'd want to have the logging rule limited to
something like 1/s or whatever.



On Tue, 25 Jan 2005 13:56:25 -0600 (CST), Tib <tib@tigerknight.org> wrote:
> 
> You're kidding o_O
> 
> I guess it makes sense.. the connections will trip that rule until it is
> satisfied and then move onto the next. That's.. bizarre.
> 
> <EOL>
> Tib
> 
> On Tue, 25 Jan 2005, Mark Moseley wrote:
> 
> > Heh, forgot to CC the list on my original reply, sorry.
> >
> > Makes sense on the --limit-burst. :)
> >
> > As far as adding the DROP/REJECT after that, once the connection limit
> > in the --limit rule has been reached, it will simply just fall through
> > the next rule (i.e. it doesn't do any implicit DROP'ing on its own).
> > So the rule with the --limit just matches up to the rate in --limit
> > and then doesn't match. Without a rule later on (or a policy to
> > DROP/REJECT), any overflow will just get accepted.
> >
> >
> >
> > > Yup - once I saw an example of someone USING the limit options it made
> > > sense :]
> > >
> > > The only thing --limit-burst does is say 'you have x many free tries
> > > before you fall under the rate limit of Y/time restrictions'.
> > >
> > > So on mine, you can effectively connect twice in short succession before
> > > you are cut back to once every 10 minutes (6 per hour).
> > >
> > > > Be sure to add a DROP or REJECT on the same match (unless the default
> > > > policy is already that).
> > >
> > > I don't follow why to do this - explain?
> > >
> > > <EOL>
> > > Tib
> > >
> >
>

Re: use of the limiting options

[Tib]

OOOOOOH - I see I think.. the ones that get caught by the limit rule don't
go to the drop rule, which means they're allowed to connect. The ones that
don't get caught by the limit rule slip on through to the drop rule.

See - my understanding of what the limit module was doing was completely
off base! Now I understand what's going on.

<EOL>
Tib

On Tue, 25 Jan 2005, Mark Moseley wrote:

> It's used very often for logging, so that the logging doesn't swamp
> the firewall's disk. Imagine you're dropping 100 packet/s and want to
> log what's going on. You'd want to have the logging rule limited to
> something like 1/s or whatever.
>
>
>
> On Tue, 25 Jan 2005 13:56:25 -0600 (CST), Tib <tib@tigerknight.org> wrote:
> >
> > You're kidding o_O
> >
> > I guess it makes sense.. the connections will trip that rule until it is
> > satisfied and then move onto the next. That's.. bizarre.
> >
> > <EOL>
> > Tib
> >
> > On Tue, 25 Jan 2005, Mark Moseley wrote:
> >
> > > Heh, forgot to CC the list on my original reply, sorry.
> > >
> > > Makes sense on the --limit-burst. :)
> > >
> > > As far as adding the DROP/REJECT after that, once the connection limit
> > > in the --limit rule has been reached, it will simply just fall through
> > > the next rule (i.e. it doesn't do any implicit DROP'ing on its own).
> > > So the rule with the --limit just matches up to the rate in --limit
> > > and then doesn't match. Without a rule later on (or a policy to
> > > DROP/REJECT), any overflow will just get accepted.
> > >
> > >
> > >
> > > > Yup - once I saw an example of someone USING the limit options it made
> > > > sense :]
> > > >
> > > > The only thing --limit-burst does is say 'you have x many free tries
> > > > before you fall under the rate limit of Y/time restrictions'.
> > > >
> > > > So on mine, you can effectively connect twice in short succession before
> > > > you are cut back to once every 10 minutes (6 per hour).
> > > >
> > > > > Be sure to add a DROP or REJECT on the same match (unless the default
> > > > > policy is already that).
> > > >
> > > > I don't follow why to do this - explain?
> > > >
> > > > <EOL>
> > > > Tib
> > > >
> > >
> >
>

Re: use of the limiting options

[Tib]

Hmm.. Some problems I think. I went with what you said and put a drop line
right after the rate limit.. and it's having problems. It doesn't seem to
be allowing anything through. Here's the two lines - they are the first
two to be executed - that go into my iptables configuration. What's going
on?

iptables -A INPUT -i eth0 -p tcp --destination-port 22 \
     -m limit --limit 6/hour --limit-burst 2

iptables -A INPUT -i eth0 -p tcp --destination-port 22 -j DROP


I tested this by trying to ssh in from a friend's server. First attempt to
connect and nothing happened.. what's going on?

<EOL>
Tib


On Tue, 25 Jan 2005, Tib wrote:

>
> OOOOOOH - I see I think.. the ones that get caught by the limit rule don't
> go to the drop rule, which means they're allowed to connect. The ones that
> don't get caught by the limit rule slip on through to the drop rule.
>
> See - my understanding of what the limit module was doing was completely
> off base! Now I understand what's going on.
>
> <EOL>
> Tib
>
> On Tue, 25 Jan 2005, Mark Moseley wrote:
>
> > It's used very often for logging, so that the logging doesn't swamp
> > the firewall's disk. Imagine you're dropping 100 packet/s and want to
> > log what's going on. You'd want to have the logging rule limited to
> > something like 1/s or whatever.
> >
> >
> >
> > On Tue, 25 Jan 2005 13:56:25 -0600 (CST), Tib <tib@tigerknight.org> wrote:
> > >
> > > You're kidding o_O
> > >
> > > I guess it makes sense.. the connections will trip that rule until it is
> > > satisfied and then move onto the next. That's.. bizarre.
> > >
> > > <EOL>
> > > Tib
> > >
> > > On Tue, 25 Jan 2005, Mark Moseley wrote:
> > >
> > > > Heh, forgot to CC the list on my original reply, sorry.
> > > >
> > > > Makes sense on the --limit-burst. :)
> > > >
> > > > As far as adding the DROP/REJECT after that, once the connection limit
> > > > in the --limit rule has been reached, it will simply just fall through
> > > > the next rule (i.e. it doesn't do any implicit DROP'ing on its own).
> > > > So the rule with the --limit just matches up to the rate in --limit
> > > > and then doesn't match. Without a rule later on (or a policy to
> > > > DROP/REJECT), any overflow will just get accepted.
> > > >
> > > >
> > > >
> > > > > Yup - once I saw an example of someone USING the limit options it made
> > > > > sense :]
> > > > >
> > > > > The only thing --limit-burst does is say 'you have x many free tries
> > > > > before you fall under the rate limit of Y/time restrictions'.
> > > > >
> > > > > So on mine, you can effectively connect twice in short succession before
> > > > > you are cut back to once every 10 minutes (6 per hour).
> > > > >
> > > > > > Be sure to add a DROP or REJECT on the same match (unless the default
> > > > > > policy is already that).
> > > > >
> > > > > I don't follow why to do this - explain?
> > > > >
> > > > > <EOL>
> > > > > Tib
> > > > >
> > > >
> > >
> >
>

Re: use of the limiting options

[Mark Moseley]

I'm guessing maybe you don't have a rule above that accepts
established connections? e.g.
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state
ESTABLISHED -j ACCEPT

If you don't have that, your established connection will soon deplete
the 6/hr packets as well.

Though, as Jason mentioned, you probably want to poke a hole or two
through for select known-good IPs.

Re: use of the limiting options

[Tib]

Ahh, I was wondering about this. I had put the limit rule in place and the 
drop after it, and found that it apparently shut everything out. So do I 
need to do all three then?

Establish rule
Limit rule
Drop rule

In that order?

<EOL>
Tib



On Wed, 26 Jan 2005, Mark Moseley wrote:

> I'm guessing maybe you don't have a rule above that accepts
> established connections? e.g.
> iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state
> ESTABLISHED -j ACCEPT
>
> If you don't have that, your established connection will soon deplete
> the 6/hr packets as well.
>
> Though, as Jason mentioned, you probably want to poke a hole or two
> through for select known-good IPs.
>
>

Re: use of the limiting options

[Bob Tellefson]

On Friday 28 January 2005 21:32, Tib wrote:
> Ahh, I was wondering about this. I had put the limit rule in place and the
> drop after it, and found that it apparently shut everything out. So do I
> need to do all three then?
>
> Establish rule
> Limit rule
> Drop rule
>

Here's a setup that works and shows the logic.

As noted by others, this is not a replacement for properly tightening your 
sshd configuration.  It is useful when you have ssh access from inside your 
network and limited usage from outside.  If you set the limit too low, you 
will find your outside users complaining about erratic service.

#!/bin/sh
IPTABLES="iptables"
PER_MIN_LOG_LIMIT=30
NEW_SSH_PER_MIN_LIMIT=3
ISP_IFACE=eth0

#
###### routine ##### SSH LIMIT EXCEEDED - DO LOG/DROP
#
$IPTABLES -N do_drop_limited
$IPTABLES -A do_drop_limited -m limit --limit $PER_MIN_LOG_LIMIT/minute -j LOG 
--log-prefix "__DROP LIMITED: "
$IPTABLES -A do_drop_limited -j DROP

#
###### routine ##### SSH LIMIT NOT EXCEEDED - LOG FOR INFO
#
$IPTABLES -N log_limited_service
$IPTABLES -A log_limited_service -m limit --limit $PER_MIN_LOG_LIMIT/minute -j 
LOG --log-prefix "__LIMITED REQUEST: "

#
###### routine ##### SSH LIMIT
# limits number of incomming ssh connections per minute.
# NOTE: disable this one when your only access is from the outside
# to avoid being the victom of a mini DoS locking you out.
#
$IPTABLES -N ssh_limit
$IPTABLES -A ssh_limit -j log_limited_service
$IPTABLES -A ssh_limit -m limit --limit NEW_SSH_PER_MIN_LIMIT/minute  
--limit-burst NEW_SSH_PER_MIN_LIMIT -j RETURN
$IPTABLES -A ssh_limit -j do_drop_limited

#
##### FORWARD RULES
#
# if we reject with reset, maybe we can prevent some hanging connections
$IPTABLES -A FORWARD -p tcp ! --syn -m state --state NEW -j REJECT 
--reject-with tcp-reset
# assumes NEW without syn has already been taken care of
$IPTABLES -A FORWARD -p TCP -i $ISP_IFACE -m state --state NEW --dport 22 -j 
ssh_limit


-- 

Bob Tellefson
Java network application development & hosting

Re: use of the limiting options

[Jason Opperisano]

On Tue, Jan 25, 2005 at 12:54:54PM -0600, Tib wrote:
> 
> I'd like to use the --limit and --limit-burst options to protect my sshd
> from dictionary password attacks. Considering the userbase and activity
> level I'd say that something like this would suit me just fine.
> 
> --limit 6/hour
> --limit-burst 2
> 
> This would limit it to two connect/login attempts at first, and then one
> more every 10 minutes.. correct?
> 
> Would this be the proper command to use? I'm trying to just limit
> connections from the outside world, not from the local network, hence the
> address as a destination:
> 
> iptables -A INPUT --d 66.80.174.210 --dport 22   \
>    --limit 6/hour --limit-burst 2

that's a fantastic way to DoS yourself.  so after 8 idiots try to
connect to your SSH server--you're locked out from connecting yourself
for an hour...*brilliant*.

try some real security measures instead of snake oil:

- disable password auth on your SSHD and only allow public key auth

- filter access to your SSHD by source IP, if possible

- use some sort of VPN access (IPSec/OpenVPN/etc) to get to your SSHD,
  and only allow access that way.

-j

--
"Please do not offer my god a peanut"
        --The Simpsons

Re: use of the limiting options

[Tib]

> that's a fantastic way to DoS yourself.  so after 8 idiots try to
> connect to your SSH server--you're locked out from connecting yourself
> for an hour...*brilliant*.

Does the limit module not track such things according to source IP then? 
From the sound (snide and condescending as it is) of it, it just counts 
these limit tokens against the destination itself without regard to 
source.

And actually - it would only be 10 minutes, based on the regeneration 
rate.

> - disable password auth on your SSHD and only allow public key auth

This assums a level of competency that the majority of my userbase does 
not have. If you'd like to do desktop support for them to generate keys, 
upload them to the server, and authenticate against them; be my guest.

> - filter access to your SSHD by source IP, if possible

'If possible' - it's not. The majority of my userbase works off dynamic 
ip's. Whether dialup accounts, cable modem, or home-user dsl packages. The 
solution isn't that easy.

> - use some sort of VPN access (IPSec/OpenVPN/etc) to get to your SSHD,
>  and only allow access that way.

See comment to public key auth.


If it were just me using it, this would not be an issue. But there's such 
a thing as 'user friendly' security (honest, I swear), and your offered 
solutions are not it.

How about working with me rather than trying to tell me how stupid I am 
for doing it a particular way?

<EOL>
Tib

Re: use of the limiting options

[Josh Nerius]

Hello, 

A few thoughts/comments on your situation.  

1. You are correct, limit does not keep track of source. You may find
the 'recent' module useful if you wish to do this.

2. You may want to simplify things by easing up on the limit. Doing
something like 1/minute with a burst of 3 would still prevent
bruteforcing (or your password ir *really* insecure ;-) ) but at the
same time, give you a little more protection from DoS.

3. In the setup you mention, the limit would *not* reset itself every
10 minutes. limit basically says, "ok, he said 6 in an hour, so if I
see 6 in the first 5 seconds,  that's it for the rest of this hour..."
(and the burst is just the number of packets it has to see in the
given time increment before it'll start counting off hits)

4. As Mark mentioned, you definitely want to add a rule to accept
packets that are related to an already established ssh connection.
Otherwise, as he mentioned, once your connection is established, it'd
use up all the packets alloted in limit and then your ssh session
would die. A rule like `iptables -I INPUT -i eth0 -p tcp --dport 22 -m
state --state ESTABLISHED -j ACCEPT` would do this quite nicely.
Notice the -I INPUT...this can be changed to -A but the -I will put it
at the top of your chain. This rule needs to be above the limit rule
in order to function properly.

5. Don't let Jason get to you :-P

Hope this information proves to be helpful :-)

Josh Nerius



-- 
Math problems? Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x]


On Tue, 25 Jan 2005 12:54:54 -0600 (CST), Tib <tib@tigerknight.org> wrote:
> 
> I'd like to use the --limit and --limit-burst options to protect my sshd
> from dictionary password attacks. Considering the userbase and activity
> level I'd say that something like this would suit me just fine.
> 
> --limit 6/hour
> --limit-burst 2
> 
> This would limit it to two connect/login attempts at first, and then one
> more every 10 minutes.. correct?
> 
> Would this be the proper command to use? I'm trying to just limit
> connections from the outside world, not from the local network, hence the
> address as a destination:
> 
> iptables -A INPUT --d 66.80.174.210 --dport 22   \
>    --limit 6/hour --limit-burst 2
> 
> <EOL>
> Tib
> 
>

Re: use of the limiting options

[R. DuFresne]

On Sun, 30 Jan 2005, Josh Nerius wrote:

> Hello, 
> 
> A few thoughts/comments on your situation.  
> 
> 1. You are correct, limit does not keep track of source. You may find
> the 'recent' module useful if you wish to do this.
> 
> 2. You may want to simplify things by easing up on the limit. Doing
> something like 1/minute with a burst of 3 would still prevent
> bruteforcing (or your password ir *really* insecure ;-) ) but at the
> same time, give you a little more protection from DoS.

I'd set this in the shhd_conf file, allowiong only one wrong passwd to
close the connection attempt, this makes bruteforcing via sshd much more
costly and time consuming without relying upon another tool.


Course, I as well like to limit where ssh is allowed to connect directly
internally from.  If this is hard to accomplish with many roadwarrirors,
then I'd make ssh into the internalside a two factor login at least.  Once
to a box on the DMZ, with sshd tightened down considerably, and then once
a connection was made to that system, force the users to then ssh from
there to an internal sshd chokepoint that only accepts connections from
the tightened DMZ server.  I'd see this all as not really a
FW/netfilter issue, but a security issue with a different perspective
completely.


Thanks,

Ron DuFresne

> 
> 3. In the setup you mention, the limit would *not* reset itself every
> 10 minutes. limit basically says, "ok, he said 6 in an hour, so if I
> see 6 in the first 5 seconds,  that's it for the rest of this hour..."
> (and the burst is just the number of packets it has to see in the
> given time increment before it'll start counting off hits)
> 
> 4. As Mark mentioned, you definitely want to add a rule to accept
> packets that are related to an already established ssh connection.
> Otherwise, as he mentioned, once your connection is established, it'd
> use up all the packets alloted in limit and then your ssh session
> would die. A rule like `iptables -I INPUT -i eth0 -p tcp --dport 22 -m
> state --state ESTABLISHED -j ACCEPT` would do this quite nicely.
> Notice the -I INPUT...this can be changed to -A but the -I will put it
> at the top of your chain. This rule needs to be above the limit rule
> in order to function properly.
> 
> 5. Don't let Jason get to you :-P
> 
> Hope this information proves to be helpful :-)
> 
> Josh Nerius
> 
> 
> 
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        admin & senior security consultant:  sysinfo.com
                        http://sysinfo.com

...Love is the ultimate outlaw.  It just won't adhere to rules.
The most any of us can do is sign on as it's accomplice.  Instead
of vowing to honor and obey, maybe we should swear to aid and abet.
That would mean that security is out of the question.  The words
"make" and "stay" become inappropriate.  My love for you has no
strings attached.  I love you for free...
                        -Tom Robins <Still Life With Woodpecker>

forwarding internet connection

[elg3ne]

Hi guys...Im new to iptables please help me with my problem...

How do I forward incoming traffic to a diffent machine? example is that I
have 2 ISP 1 is primary & the other 1 is backup only... Now I want to
utilize the backup ISP because it is not being used...

I dont want to make changes per PC to PC just to change their gateway or
proxy to use the backup ISP...

How do I forward the incoming request to my primary ISP to 2nd ISP?

For example client has 192.168.1.11 IP and I want the IP to use the 2nd ISP
instead the 1st ISP..

Btw Im using squid to access the internet for my client.

Sorry if my explanation is not good...but I hope someone could help me...

RE: forwarding internet connection

[Essien Ita Essien]

> For example client has 192.168.1.11 IP and I want the IP to use the 2nd
>ISP instead the 1st ISP..

Are you trying to send all outbound traffic via your backup ISP now? Or you
want folks accessing you from the internet to pass via you backup ISP link?
More explanation please.

> Sorry if my explanation is not good...but I hope someone could help me...

Uhh... I'm not too sure I understand. Maybe a little diagram mite help
better?

For example..

[internal-network]--[router]--[router-interface1]
				|
				------[router-interface2]

It can help sometimes in difficult explanations :)

I dunno, maybe you can flesh this out a bit and explain, or explain in more
detail.


__________________________
Essien  Ita Essien
http://www.datavibe.net/~essiene
http://essiene.blogspot.com
 

Re: forwarding internet connection

[Jörg Harmuth]

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

as far as I unstand your posting, you want to forward traffic based on
the source IP of the client. So, some clients should use ISP1 and some
ISP2. You could write per client:

## Rewriting destination address
iptables -t nat -A PREROUTING -s $IP_OF_CLIENT -j DNAT --to $IP_ISP2

## Allow forwarding of connections
iptables -A FORWARD -s $IP_OF_CLIENT -d $IP_ISP2 -m state \
- --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -d $IP_OF_CLIENT -s $IP_ISP2 -m state \
- --state ESTABLISHED,RELATED -j ACCEPT

## Maybe you need SNATing. If so:
iptables -t nat -A POSTROUTING -s $IP_OF_CLIENT -d $IP_ISP2 -j SNAT
- --to-source $IP_ISP1

May be, you can additionally add interface or protocol specifications
or the like. I don't know, because your exact network layout is unknown.

A very good tutorial on iptables is here:

http://iptables-tutorial.frozentux.net/chunkyhtml/index.html

Have a nice time,

Jörg

elg3ne schrieb:

| Hi guys...Im new to iptables please help me with my problem...
|
| How do I forward incoming traffic to a diffent machine? example is
| that I have 2 ISP 1 is primary & the other 1 is backup only... Now
| I want to utilize the backup ISP because it is not being used...
|
| I dont want to make changes per PC to PC just to change their
| gateway or proxy to use the backup ISP...
|
| How do I forward the incoming request to my primary ISP to 2nd ISP?
|
|
| For example client has 192.168.1.11 IP and I want the IP to use the
| 2nd ISP instead the 1st ISP..
|
| Btw Im using squid to access the internet for my client.
|
| Sorry if my explanation is not good...but I hope someone could help
| me...
|


- --
- -----------------------------------------------------------------------
mnemon
Jörg Harmuth
Marie-Curie.Str. 1
53359 Rheinbach

Tel.: (+49) 22 26  87 18 12
Fax:  (+49) 22 26 87 18 19
mail: harmuth@mnemon.de
Web:  http://www.mnemon.de
PGP-Key: http://www.mnemon.de/keys/harmuth_mnemon.asc
PGP-Fingerprint: 692E 4476 0838 60F8 99E2  7F5D B7D7 E48E 267B 204F
- -----------------------------------------------------------------------
Diese Mail wurde vor dem Versenden auf Viren und andere schädliche
Software untersucht. Es wurde keine maliziöse Software gefunden.

This Mail was checked for virusses and other malicious software before
sending. No malicious software was detected.
- -----------------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
 
iD8DBQFCJbLyt9fkjiZ7IE8RAlYQAKCXvDV8MfHDaIH6GJa1jay56A+t2ACdFZ7w
MlbrDGj7qFY14xeWA+ULBB4=
=+e3D
-----END PGP SIGNATURE-----