* really need your help about iptables
@ 2009-08-25 11:33 J. Bakshi
2009-08-25 12:27 ` Problem with statistic module nth mode John Lister
2009-08-25 14:09 ` really need your help about iptables Oskar Berggren
0 siblings, 2 replies; 20+ messages in thread
From: J. Bakshi @ 2009-08-25 11:33 UTC (permalink / raw)
To: netfilter
Dear list,
I really really need your help to configure iptables to cope with
"connection time out problem" Here what actually the situation is.
I have configured iptables to drop nmap and other port scanning
techniques ( collected from internet, like XMAS scan, FIN scan etc...).
If I run nmap against the server ( like nmap -P0 <myserver> or nmap -P0
-sT <myserver> ) then the firewall successfully dropping the scan
packets and make the nmap scan to wait for *looooong* . Good. But on
the other hand the http and mail server running on the server
providing "time out error" hence it is not possible to connect the mail
/apache and other services running on that server during port scanning
against it. Could any one kindly suggest how to cope with this situiation ?
Thanks for your time.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Problem with statistic module nth mode
2009-08-25 11:33 really need your help about iptables J. Bakshi
@ 2009-08-25 12:27 ` John Lister
2009-08-25 12:48 ` Patrick McHardy
2009-08-25 14:09 ` really need your help about iptables Oskar Berggren
1 sibling, 1 reply; 20+ messages in thread
From: John Lister @ 2009-08-25 12:27 UTC (permalink / raw)
To: netfilter
Hi, I have a set of rules as follows
iptables -t nat -N SNAT1
iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 0 -j
SNAT --to-source 87.194.x.1
iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 1 -j
SNAT --to-source 87.194.x.2
iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 2 -j
SNAT --to-source 87.194.x.3
iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 3 -j
SNAT --to-source 87.194.x.4
iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 4 -j
SNAT --to-source 87.194.x.5
iptables -t nat -A POSTROUTING -o eth1 -j SNAT1
...
iptables -t nat -A POSTROUTING -o eth1 -j LOG --log-prefix "Failed to nat"
The last rule is occasionally triggered, is this a bug? I could put a catch
all there, but the 5 "nth" rules should cover all possible cases or have I
missed something obvious??
I'm running ubuntu hardy, kernel 2.6.24-24 and iptables 3.8
Thanks
John
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Problem with statistic module nth mode
2009-08-25 12:27 ` Problem with statistic module nth mode John Lister
@ 2009-08-25 12:48 ` Patrick McHardy
2009-08-25 12:55 ` John Lister
2009-09-02 9:23 ` Checking line status John Lister
0 siblings, 2 replies; 20+ messages in thread
From: Patrick McHardy @ 2009-08-25 12:48 UTC (permalink / raw)
To: John Lister; +Cc: netfilter
John Lister wrote:
> Hi, I have a set of rules as follows
>
> iptables -t nat -N SNAT1
> iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 0 -j
> SNAT --to-source 87.194.x.1
> iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 1 -j
> SNAT --to-source 87.194.x.2
> iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 2 -j
> SNAT --to-source 87.194.x.3
> iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 3 -j
> SNAT --to-source 87.194.x.4
> iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 4 -j
> SNAT --to-source 87.194.x.5
>
> iptables -t nat -A POSTROUTING -o eth1 -j SNAT1
> ...
> iptables -t nat -A POSTROUTING -o eth1 -j LOG --log-prefix "Failed to nat"
>
>
> The last rule is occasionally triggered, is this a bug? I could put a
> catch all there, but the 5 "nth" rules should cover all possible cases
> or have I missed something obvious??
This is a common misunderstanding - the counters are not shared and
since the rules are all terminal, the second rule will only see the
packets not caught by the first rule etc. So the proportions need to
be adjusted for the "missing" packets:
... --mode nth --every 5 ...
... --mode nth --every 4 ...
... --mode nth --every 3 ...
... --mode nth --every 2 ...
... <unconditional> ...
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Problem with statistic module nth mode
2009-08-25 12:48 ` Patrick McHardy
@ 2009-08-25 12:55 ` John Lister
2009-09-02 9:23 ` Checking line status John Lister
1 sibling, 0 replies; 20+ messages in thread
From: John Lister @ 2009-08-25 12:55 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter
----- Original Message -----
From: "Patrick McHardy" <kaber@trash.net>
To: "John Lister" <john.lister@kickstone.com>
Cc: <netfilter@vger.kernel.org>
Sent: Tuesday, August 25, 2009 1:48 PM
Subject: Re: Problem with statistic module nth mode
> John Lister wrote:
>> Hi, I have a set of rules as follows
>>
>> iptables -t nat -N SNAT1
>> iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 0 -j
>> SNAT --to-source 87.194.x.1
>> iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 1 -j
>> SNAT --to-source 87.194.x.2
>> iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 2 -j
>> SNAT --to-source 87.194.x.3
>> iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 3 -j
>> SNAT --to-source 87.194.x.4
>> iptables -t nat -A SNAT1 -m statistic --mode nth --every 5 --packet 4 -j
>> SNAT --to-source 87.194.x.5
>>
>> iptables -t nat -A POSTROUTING -o eth1 -j SNAT1
>> ...
>> iptables -t nat -A POSTROUTING -o eth1 -j LOG --log-prefix "Failed to
>> nat"
>>
>>
>> The last rule is occasionally triggered, is this a bug? I could put a
>> catch all there, but the 5 "nth" rules should cover all possible cases
>> or have I missed something obvious??
>
> This is a common misunderstanding - the counters are not shared and
> since the rules are all terminal, the second rule will only see the
> packets not caught by the first rule etc. So the proportions need to
> be adjusted for the "missing" packets:
>
> ... --mode nth --every 5 ...
> ... --mode nth --every 4 ...
> ... --mode nth --every 3 ...
> ... --mode nth --every 2 ...
> ... <unconditional> ...
> --
Thanks for that, I was slightly confused - I had originally done it using
"random" with decreasing percentages but wanted to use nth.
I'll let you know how I get on...
JOHN
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: really need your help about iptables
2009-08-25 11:33 really need your help about iptables J. Bakshi
2009-08-25 12:27 ` Problem with statistic module nth mode John Lister
@ 2009-08-25 14:09 ` Oskar Berggren
2009-08-26 12:14 ` J. Bakshi
1 sibling, 1 reply; 20+ messages in thread
From: Oskar Berggren @ 2009-08-25 14:09 UTC (permalink / raw)
To: J. Bakshi; +Cc: netfilter
Use a higher limit for SYN packets to those services. IIRC your
ruleset from before.
/Oskar
2009/8/25 J. Bakshi <joydeep@infoservices.in>:
> Dear list,
>
> I really really need your help to configure iptables to cope with
> "connection time out problem" Here what actually the situation is.
>
> I have configured iptables to drop nmap and other port scanning
> techniques ( collected from internet, like XMAS scan, FIN scan etc...).
> If I run nmap against the server ( like nmap -P0 <myserver> or nmap -P0
> -sT <myserver> ) then the firewall successfully dropping the scan
> packets and make the nmap scan to wait for *looooong* . Good. But on
> the other hand the http and mail server running on the server
> providing "time out error" hence it is not possible to connect the mail
> /apache and other services running on that server during port scanning
> against it. Could any one kindly suggest how to cope with this situiation ?
>
> Thanks for your time.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: really need your help about iptables
2009-08-25 14:09 ` really need your help about iptables Oskar Berggren
@ 2009-08-26 12:14 ` J. Bakshi
2009-08-26 12:36 ` Re:[possible solution] " J. Bakshi
0 siblings, 1 reply; 20+ messages in thread
From: J. Bakshi @ 2009-08-26 12:14 UTC (permalink / raw)
To: Oskar Berggren; +Cc: netfilter
Oskar Berggren wrote:
> Use a higher limit for SYN packets to those services. IIRC your
> ruleset from before.
>
> /Oskar
>
Hello,
Thanks for your hint. I have googled based on your hint and found a lot
of solution for rate limit incoming connection. one ruleset valid for
me are
````````````````````````
iptables -I INPUT -p tcp --dport 995 -i eth0 -m state --state NEW -m
recent \
--set
iptables -I INPUT -p tcp --dport 995 -i eth0 -m state --state NEW -m
recent \
--update --seconds 60 --hitcount 4 -j DROP
iptables -I INPUT -p tcp --dport 995 -i eth0 -j ACCEPT
`````````````````````````````````
But the problem with my iptables is default policy--> drop. I have also
tested with
````````````
iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 995 -m
limit --limit 1/minute --limit-burst 2 -j ACCEPT
``````````
This works fine and limiting the connection 1/min but a brute force
attack ( like nmap scan) make the port not useable any more.
What can be the solution for such an iptables ?
Thanks
>
> 2009/8/25 J. Bakshi <joydeep@infoservices.in>:
>
>> Dear list,
>>
>> I really really need your help to configure iptables to cope with
>> "connection time out problem" Here what actually the situation is.
>>
>> I have configured iptables to drop nmap and other port scanning
>> techniques ( collected from internet, like XMAS scan, FIN scan etc...).
>> If I run nmap against the server ( like nmap -P0 <myserver> or nmap -P0
>> -sT <myserver> ) then the firewall successfully dropping the scan
>> packets and make the nmap scan to wait for *looooong* . Good. But on
>> the other hand the http and mail server running on the server
>> providing "time out error" hence it is not possible to connect the mail
>> /apache and other services running on that server during port scanning
>> against it. Could any one kindly suggest how to cope with this situiation ?
>>
>> Thanks for your time.
>> --
>> To unsubscribe from this list: send the line "unsubscribe netfilter" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re:[possible solution] really need your help about iptables
2009-08-26 12:14 ` J. Bakshi
@ 2009-08-26 12:36 ` J. Bakshi
0 siblings, 0 replies; 20+ messages in thread
From: J. Bakshi @ 2009-08-26 12:36 UTC (permalink / raw)
To: Oskar Berggren; +Cc: netfilter
J. Bakshi wrote:
> Oskar Berggren wrote:
>
>> Use a higher limit for SYN packets to those services. IIRC your
>> ruleset from before.
>>
>> /Oskar
>>
>>
>
> Hello,
>
> Thanks for your hint. I have googled based on your hint and found a lot
> of solution for rate limit incoming connection. one ruleset valid for
> me are
>
> ````````````````````````
> iptables -I INPUT -p tcp --dport 995 -i eth0 -m state --state NEW -m
> recent \
> --set
>
> iptables -I INPUT -p tcp --dport 995 -i eth0 -m state --state NEW -m
> recent \
> --update --seconds 60 --hitcount 4 -j DROP
>
> iptables -I INPUT -p tcp --dport 995 -i eth0 -j ACCEPT
> `````````````````````````````````
>
> But the problem with my iptables is default policy--> drop. I have also
> tested with
>
> ````````````
> iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 995 -m
> limit --limit 1/minute --limit-burst 2 -j ACCEPT
> ``````````
> This works fine and limiting the connection 1/min but a brute force
> attack ( like nmap scan) make the port not useable any more.
>
> What can be the solution for such an iptables ?
>
> Thanks
>
>
One possible solution might be for a default *dropped* firewall; placing
the incoming rate limit rules before syn flood protection and port
scanner protection rules. Like
````````````````````
rules set to make default polict drop
## limiting incoming pop3s connection
iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 995 -m
limit --limit 10/minute --limit-burst 2 -j ACCEPT
limiting other incoming connection
ruleset for syn-flood prevention
ruleset to delayed nmap scan etc...
````````````````````````
Please suggest if my approach is right.
Thanks
>
>> 2009/8/25 J. Bakshi <joydeep@infoservices.in>:
>>
>>
>>> Dear list,
>>>
>>> I really really need your help to configure iptables to cope with
>>> "connection time out problem" Here what actually the situation is.
>>>
>>> I have configured iptables to drop nmap and other port scanning
>>> techniques ( collected from internet, like XMAS scan, FIN scan etc...).
>>> If I run nmap against the server ( like nmap -P0 <myserver> or nmap -P0
>>> -sT <myserver> ) then the firewall successfully dropping the scan
>>> packets and make the nmap scan to wait for *looooong* . Good. But on
>>> the other hand the http and mail server running on the server
>>> providing "time out error" hence it is not possible to connect the mail
>>> /apache and other services running on that server during port scanning
>>> against it. Could any one kindly suggest how to cope with this situiation ?
>>>
>>> Thanks for your time.
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netfilter" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>>
>>
>>
>
>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Checking line status
2009-08-25 12:48 ` Patrick McHardy
2009-08-25 12:55 ` John Lister
@ 2009-09-02 9:23 ` John Lister
2009-09-02 10:23 ` Gáspár Lajos
` (2 more replies)
1 sibling, 3 replies; 20+ messages in thread
From: John Lister @ 2009-09-02 9:23 UTC (permalink / raw)
To: netfilter
Hi, I have a multihomed machine to which i'd like to check the status of
each line periodically. I want to do this so that I can modify the iptables
rules and send new connections out over the active lines and restore service
when the line comes back up.
I thought I could use ping with the -I option, but that doesn't seem to
work, it always uses the default route. However if I get rid of the default
route and modify the rules to match the packets I get a "network
unreachable" message without it ever hitting iptables. For example adding
something like this never gets matched for the ping.
iptables -t mangle -I OUTPUT -j LOG --log-prefix "output: "
Normally ping results in ICMP messages being traversed, but not this time.
Could someone explain what is going on and I'd be grateful if there were any
suggestions on other ways to detect if a line is down - simply looking in
/proc/net/dev or similar wouldn't help as the local connection is likely to
be up, but the physical line to the ISP may be down.
Thanks
John
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Checking line status
2009-09-02 9:23 ` Checking line status John Lister
@ 2009-09-02 10:23 ` Gáspár Lajos
2009-09-02 11:21 ` John Lister
2009-09-02 12:47 ` Thomas Jacob
2009-09-02 14:13 ` Tormod Nygård
2 siblings, 1 reply; 20+ messages in thread
From: Gáspár Lajos @ 2009-09-02 10:23 UTC (permalink / raw)
To: John Lister; +Cc: netfilter
Hi!
I have written a target for this: www.glsys.eu/iface
Swifty
John Lister írta:
> Hi, I have a multihomed machine to which i'd like to check the status
> of each line periodically. I want to do this so that I can modify the
> iptables rules and send new connections out over the active lines and
> restore service when the line comes back up.
>
> I thought I could use ping with the -I option, but that doesn't seem
> to work, it always uses the default route. However if I get rid of the
> default route and modify the rules to match the packets I get a
> "network unreachable" message without it ever hitting iptables. For
> example adding something like this never gets matched for the ping.
>
> iptables -t mangle -I OUTPUT -j LOG --log-prefix "output: "
>
> Normally ping results in ICMP messages being traversed, but not this
> time.
>
> Could someone explain what is going on and I'd be grateful if there
> were any suggestions on other ways to detect if a line is down -
> simply looking in /proc/net/dev or similar wouldn't help as the local
> connection is likely to be up, but the physical line to the ISP may be
> down.
>
>
> Thanks
>
> John
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Checking line status
2009-09-02 10:23 ` Gáspár Lajos
@ 2009-09-02 11:21 ` John Lister
0 siblings, 0 replies; 20+ messages in thread
From: John Lister @ 2009-09-02 11:21 UTC (permalink / raw)
To: Gáspár Lajos; +Cc: netfilter
> I have written a target for this: www.glsys.eu/iface
Thanks for your reply, I'm not sure this would help me in my situation for 2
reasons:
Firstly doesn't it just report on the state of the interface, I need to know
if any intermediary router/line is down after the interface, this is why i
was using ping to check known remote sites.
Secondly my rules are fairly complex and trying to design in dynamic checks
in the ruleset is probably too complicated. For example i have 4 lines at
the minute which are load balanced, i would need to repeat the rules 15
times to cover all combinations of lines up/down. It seems simpler to
generate a new ruleset based on the active lines when a change is detected.
any other ideas gratefully received
> Swifty
>
> John Lister írta:
>> Hi, I have a multihomed machine to which i'd like to check the status of
>> each line periodically. I want to do this so that I can modify the
>> iptables rules and send new connections out over the active lines and
>> restore service when the line comes back up.
>>
>> I thought I could use ping with the -I option, but that doesn't seem to
>> work, it always uses the default route. However if I get rid of the
>> default route and modify the rules to match the packets I get a "network
>> unreachable" message without it ever hitting iptables. For example adding
>> something like this never gets matched for the ping.
>>
>> iptables -t mangle -I OUTPUT -j LOG --log-prefix "output: "
>>
>> Normally ping results in ICMP messages being traversed, but not this
>> time.
>>
>> Could someone explain what is going on and I'd be grateful if there were
>> any suggestions on other ways to detect if a line is down - simply
>> looking in /proc/net/dev or similar wouldn't help as the local connection
>> is likely to be up, but the physical line to the ISP may be down.
Thanks
John
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Checking line status
2009-09-02 9:23 ` Checking line status John Lister
2009-09-02 10:23 ` Gáspár Lajos
@ 2009-09-02 12:47 ` Thomas Jacob
2009-09-02 13:54 ` John Lister
2009-09-02 14:02 ` John Lister
2009-09-02 14:13 ` Tormod Nygård
2 siblings, 2 replies; 20+ messages in thread
From: Thomas Jacob @ 2009-09-02 12:47 UTC (permalink / raw)
To: John Lister; +Cc: netfilter
[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]
On Wed, 2009-09-02 at 10:23 +0100, John Lister wrote:
> Hi, I have a multihomed machine to which i'd like to check the status of
> each line periodically. I want to do this so that I can modify the iptables
> rules and send new connections out over the active lines and restore service
> when the line comes back up.
>
> I thought I could use ping with the -I option, but that doesn't seem to
> work, it always uses the default route. However if I get rid of the default
> route and modify the rules to match the packets I get a "network
> unreachable" message without it ever hitting iptables. For example adding
> something like this never gets matched for the ping.
You need to ensure that your ping packets come from the right IP and get
routed to the right interface. Useless comment maybe, but without
you posting your details here it is difficult to say more specific
things ;)
Binding to the right IP is accomplished with ping -I <IP>, just as you
do. But then you need some sort of route to send this packet to the
right interface (-I has nothing to do with that). One way to achieve
this could be using things like scapy where basically roll your own ping
tool and just force the packet out on the right interface.
Or you could use policy routing like this:
/sbin/ip rule add from <Secondary Interface IP> pref 10000 table 100
/sbin/ip route add default via <Secondary Next HOP IP> table 100
Thomas
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5414 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Checking line status
2009-09-02 12:47 ` Thomas Jacob
@ 2009-09-02 13:54 ` John Lister
2009-09-02 14:02 ` John Lister
1 sibling, 0 replies; 20+ messages in thread
From: John Lister @ 2009-09-02 13:54 UTC (permalink / raw)
To: Thomas Jacob; +Cc: netfilter
>On Wed, 2009-09-02 at 10:23 +0100, John Lister wrote:
>> Hi, I have a multihomed machine to which i'd like to check the status of
>> each line periodically. I want to do this so that I can modify the
>> iptables
>> rules and send new connections out over the active lines and restore
>> service
>> when the line comes back up.
>>
>> I thought I could use ping with the -I option, but that doesn't seem to
>> work, it always uses the default route. However if I get rid of the
>> default
>> route and modify the rules to match the packets I get a "network
>> unreachable" message without it ever hitting iptables. For example adding
>> something like this never gets matched for the ping.
>You need to ensure that your ping packets come from the right IP and get
>routed to the right interface. Useless comment maybe, but without
>you posting your details here it is difficult to say more specific
>things ;)
>Binding to the right IP is accomplished with ping -I <IP>, just as you
>do. But then you need some sort of route to send this packet to the
>right interface (-I has nothing to do with that). One way to achieve
>this could be using things like scapy where basically roll your own ping
>tool and just force the packet out on the right interface.
>Or you could use policy routing like this:
>/sbin/ip rule add from <Secondary Interface IP> pref 10000 table 100
>/sbin/ip route add default via <Secondary Next HOP IP> table 100
Cheers, that did the trick, didn't realise that was possible.. Just got to
make sure all my other rules (both firewall and routing) are still working -
John
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Checking line status
2009-09-02 12:47 ` Thomas Jacob
2009-09-02 13:54 ` John Lister
@ 2009-09-02 14:02 ` John Lister
2009-09-02 14:29 ` Pascal Hambourg
2009-09-02 14:30 ` Thomas Jacob
1 sibling, 2 replies; 20+ messages in thread
From: John Lister @ 2009-09-02 14:02 UTC (permalink / raw)
To: Thomas Jacob; +Cc: netfilter
>You need to ensure that your ping packets come from the right IP and get
>routed to the right interface. Useless comment maybe, but without
>you posting your details here it is difficult to say more specific
>things ;)
One more thing, I had this (simplified) configuration, but none of the rules
seem to be triggered, I thought local packets went through this chain
mangle(OUTPUT) -> nat (OUTPUT) -> OUTPUT -> routing decision -> mangle
(POSTROUTING) -> nat (POSTROUTING)
ip route add 87.194.A.B/22 dev eth1 table 111
ip route add 192.168.2.0/24 dev eth0 table 111
ip route add default via 87.194.a.b dev eth1 table 111
ip route add 94.30.X.Y/29 dev eth4 table 222
ip route add 192.168.2.0/24 dev eth0 table 222
ip route add default via 94.30.x.y dev eth4 table 222
ip rule add fwmark 111 table 111
ip rule add fwmark 222 table 222
iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark
iptables -t mangle -A OUTPUT -m mark --mark 0 -m state --state NEW -m
statistic --mode nth --every 2 --packet 0 -j MARK --set-mark 111
iptables -t mangle -A OUTPUT -m mark --mark 0 -m state --state
-j MARK --set-mark 111
iptables -t mangle -A OUTPUT -j CONNMARK --save-mark
iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 87.194.a.b
iptables -t nat -A POSTROUTING -o eth4 -j SNAT --to-source 94.30.x.y
I would hope that the first set of iptables rules mark the packets before
the routing rules forward them on their way (via a bit of SNATting), however
it looks like the mangle OUTPUT table is skipped and no marks are added...
Thanks
John
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Checking line status
2009-09-02 9:23 ` Checking line status John Lister
2009-09-02 10:23 ` Gáspár Lajos
2009-09-02 12:47 ` Thomas Jacob
@ 2009-09-02 14:13 ` Tormod Nygård
2 siblings, 0 replies; 20+ messages in thread
From: Tormod Nygård @ 2009-09-02 14:13 UTC (permalink / raw)
To: netfilter; +Cc: john.lister
Hi
I do what you try at a couple of networks.
I have one IP-address outside my networks that I use to ping to check if
a link is good. I do some counting of packet loss before switching
routes. The IP-address I use to check routes is always routed out of the
preferred route and not the default route. I switch route based on
packet loss.
The script I use is meant to choose between two bad links where I prefer
one of them, you should change and tune it to fit your needs. This is
not a script to check if an interface is down. The script never stops,
you have to use <ctrl-c>. It could probably be done more elegant, but it
fit my needs.
#!/bin/sh
# An IP-address outside our net, used to check the link.
target=xxx.xxx.xxx.xxx
# Preferred route
route1=xxx.xxx.xxx.xxx
# Backup route
route2=xxx.xxx.xxx.xxx
interval=1
pingfail=5
switchback=100
# Internal variables
switch=0
successcounter=0
# Delete any existing route to $target and add one trought $route1
if ( ip route | grep $target ) ; then
ip route del $target
fi
ip route add $target via $route1
if ( ip route | grep "default via $route1" > /dev/null 2>&1 ) ; then
echo $(date) - Starting on $route1
else
echo $(date) - Starting on $route2
fi
while [ 1 ] ; do
if ( ! ping -c $pingfail $target > /dev/null 2>&1 ) ; then
if ( ip route | grep "default via $route1" > /dev/null 2>&1 ) ;
then
# We are using the prefered route, switch to route2
switch=1
fi
successcounter=0
else
successcounter=$( echo $successcounter+1 | bc )
if ( ip route | grep "default via $route2" > /dev/null 2>&1 ) ;
then
# We are not using the prefered route
if [ $switchback == $successcounter ] ; then
# We have enough success pings to switch back
switch=1
fi
fi
fi
if [ $switch == 1 ] ; then
# Switch route
if ( ip route | grep "default via $route2" > /dev/null 2>&1 ) ;
then
echo $(date) - Switching to $route1
ip route del default via $route2
ip route add default via $route1
else
echo $(date) - Switching to $route2
ip route del default via $route1
ip route add default via $route2
fi
# Flush routing cache
ip route flush cache
# HUP openvpn to reset connection
ps ax | grep [o]penvpn | awk '{ print $1 }' | xargs kill -HUP
> /dev/null 2>&1
switch=0
fi
# Sleep for $interval seconds
sleep $interval
done
exit 0
Tormod Nygård
On Wed, 2009-09-02 at 10:23 +0100, John Lister wrote:
> Hi, I have a multihomed machine to which i'd like to check the status of
> each line periodically. I want to do this so that I can modify the iptables
> rules and send new connections out over the active lines and restore service
> when the line comes back up.
>
> I thought I could use ping with the -I option, but that doesn't seem to
> work, it always uses the default route. However if I get rid of the default
> route and modify the rules to match the packets I get a "network
> unreachable" message without it ever hitting iptables. For example adding
> something like this never gets matched for the ping.
>
> iptables -t mangle -I OUTPUT -j LOG --log-prefix "output: "
>
> Normally ping results in ICMP messages being traversed, but not this time.
>
> Could someone explain what is going on and I'd be grateful if there were any
> suggestions on other ways to detect if a line is down - simply looking in
> /proc/net/dev or similar wouldn't help as the local connection is likely to
> be up, but the physical line to the ISP may be down.
>
>
> Thanks
>
> John
>
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Checking line status
2009-09-02 14:02 ` John Lister
@ 2009-09-02 14:29 ` Pascal Hambourg
2009-09-02 14:42 ` John Lister
2009-09-02 14:30 ` Thomas Jacob
1 sibling, 1 reply; 20+ messages in thread
From: Pascal Hambourg @ 2009-09-02 14:29 UTC (permalink / raw)
To: John Lister; +Cc: netfilter
Hello,
John Lister a écrit :
> I thought local packets went through this chain
>
> mangle(OUTPUT) -> nat (OUTPUT) -> OUTPUT -> routing decision -> mangle
> (POSTROUTING) -> nat (POSTROUTING)
Actually there is an initial decision routing when the packet is created
before the OUTPUT chains, in order to select the output interface and
source address. Also after "nat (OUTPUT)" it should be "filter (OUTPUT)".
[...]
> ip rule add fwmark 111 table 111
> ip rule add fwmark 222 table 222
>
> iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark
> iptables -t mangle -A OUTPUT -m mark --mark 0 -m state --state NEW -m
> statistic --mode nth --every 2 --packet 0 -j MARK --set-mark 111
> iptables -t mangle -A OUTPUT -m mark --mark 0 -m state --state
> -j MARK --set-mark 111
Isn't something missing in that rule ?
Also, I can see no iptables rule setting mark 222.
> I would hope that the first set of iptables rules mark the packets before
> the routing rules forward them on their way
This is normally what happens.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Checking line status
2009-09-02 14:02 ` John Lister
2009-09-02 14:29 ` Pascal Hambourg
@ 2009-09-02 14:30 ` Thomas Jacob
2009-09-02 15:02 ` John Lister
1 sibling, 1 reply; 20+ messages in thread
From: Thomas Jacob @ 2009-09-02 14:30 UTC (permalink / raw)
To: John Lister; +Cc: netfilter
[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]
On Wed, 2009-09-02 at 15:02 +0100, John Lister wrote:
> >You need to ensure that your ping packets come from the right IP and get
> >routed to the right interface. Useless comment maybe, but without
> >you posting your details here it is difficult to say more specific
> >things ;)
>
> One more thing, I had this (simplified) configuration, but none of the rules
> seem to be triggered, I thought local packets went through this chain
>
> mangle(OUTPUT) -> nat (OUTPUT) -> OUTPUT -> routing decision -> mangle (POSTROUTING) -> nat (POSTROUTING)
Nope: The (initial) routing decision is taken first and then the chains
are traversed as follows.
http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html#section3
But apparently when you set fwmarks the kernel then reconsiders
its routing decision later on, don't ask me how that works, maybe
some of the developers can answer that.
> ip route add 87.194.A.B/22 dev eth1 table 111
> ip route add 192.168.2.0/24 dev eth0 table 111
> ip route add default via 87.194.a.b dev eth1 table 111
>
> ip route add 94.30.X.Y/29 dev eth4 table 222
> ip route add 192.168.2.0/24 dev eth0 table 222
> ip route add default via 94.30.x.y dev eth4 table 222
>
> ip rule add fwmark 111 table 111
> ip rule add fwmark 222 table 222
>
> iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark
> iptables -t mangle -A OUTPUT -m mark --mark 0 -m state --state NEW -m
> statistic --mode nth --every 2 --packet 0 -j MARK --set-mark 111
> iptables -t mangle -A OUTPUT -m mark --mark 0 -m state --state
> -j MARK --set-mark 111
> iptables -t mangle -A OUTPUT -j CONNMARK --save-mark
Google dragged up this:
http://rumytaulu.wordpress.com/2009/05/23/linux-loadbalancing-with-two-adsl-modems/
> iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 87.194.a.b
> iptables -t nat -A POSTROUTING -o eth4 -j SNAT --to-source 94.30.x.y
>
>
> I would hope that the first set of iptables rules mark the packets before
> the routing rules forward them on their way (via a bit of SNATting), however
> it looks like the mangle OUTPUT table is skipped and no marks are added...
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5414 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Checking line status
2009-09-02 14:29 ` Pascal Hambourg
@ 2009-09-02 14:42 ` John Lister
2009-09-02 15:16 ` Pascal Hambourg
0 siblings, 1 reply; 20+ messages in thread
From: John Lister @ 2009-09-02 14:42 UTC (permalink / raw)
To: Pascal Hambourg; +Cc: netfilter
>John Lister a écrit :
>> I thought local packets went through this chain
>>
>> mangle(OUTPUT) -> nat (OUTPUT) -> OUTPUT -> routing decision -> mangle
>> (POSTROUTING) -> nat (POSTROUTING)
>Actually there is an initial decision routing when the packet is created
>before the OUTPUT chains, in order to select the output interface and
>source address. Also after "nat (OUTPUT)" it should be "filter (OUTPUT)".
Ah, that sort of makes sense... I'd assumed the source address wasn't set
until the routing decision later in the list...
I'd shortened it without the filter part as you don't need to specify the
table :)
>[...]
>> iptables -t mangle -A OUTPUT -m mark --mark 0 -m state --state
>> -j MARK --set-mark 111
>Isn't something missing in that rule ?
I'm guessing you mean the statistic bit? It isn't needed as the first will
have set the mark to be non zero, but i guess it should be there for
consistency..
>Also, I can see no iptables rule setting mark 222.
cut and paste error, last line should be 222
Thanks
John
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Checking line status
2009-09-02 14:30 ` Thomas Jacob
@ 2009-09-02 15:02 ` John Lister
0 siblings, 0 replies; 20+ messages in thread
From: John Lister @ 2009-09-02 15:02 UTC (permalink / raw)
To: Thomas Jacob; +Cc: netfilter
>Nope: The (initial) routing decision is taken first and then the chains
>are traversed as follows.
>http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html#section3
Odd, the diagram I was using differed in where the routing decision was
made. But that seems to fit more with what is happening...
>But apparently when you set fwmarks the kernel then reconsiders
>its routing decision later on, don't ask me how that works, maybe
>some of the developers can answer that.
>Google dragged up this:
>http://rumytaulu.wordpress.com/2009/05/23/linux-loadbalancing-with-two-adsl-modems/
Cheers for the link, I think i'd read that before and others. My rules are
similar (if expanded for more interfaces), that works fine for forwarded
packets (as does mine) but not locally generated ones - unless you have a
default route in. I've had trouble load balancing locally sourced packets -
although I will only be using them to test the lines and modify the rules if
a line goes down..
I'll post the script once i've tested things.
Thanks
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Checking line status
2009-09-02 14:42 ` John Lister
@ 2009-09-02 15:16 ` Pascal Hambourg
2009-09-02 16:48 ` John Lister
0 siblings, 1 reply; 20+ messages in thread
From: Pascal Hambourg @ 2009-09-02 15:16 UTC (permalink / raw)
To: John Lister; +Cc: netfilter
John Lister a écrit :
>
> I'd shortened it without the filter part as you don't need to specify the
> table :)
Only in the userland tools. In the kernel there is no default table.
>>> iptables -t mangle -A OUTPUT -m mark --mark 0 -m state --state
>>> -j MARK --set-mark 111
>
>> Isn't something missing in that rule ?
> I'm guessing you mean the statistic bit?
And the state after --state too.
Do your MARK rules match some packets (counters increase) ?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Checking line status
2009-09-02 15:16 ` Pascal Hambourg
@ 2009-09-02 16:48 ` John Lister
0 siblings, 0 replies; 20+ messages in thread
From: John Lister @ 2009-09-02 16:48 UTC (permalink / raw)
To: Pascal Hambourg; +Cc: netfilter
> And the state after --state too.
>
copy and pasting without looking...
> Do your MARK rules match some packets (counters increase) ?
>
I haven't checked this, but i did have similar rules which wrote to the
log file and these were never triggered...
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2009-09-02 16:48 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-25 11:33 really need your help about iptables J. Bakshi
2009-08-25 12:27 ` Problem with statistic module nth mode John Lister
2009-08-25 12:48 ` Patrick McHardy
2009-08-25 12:55 ` John Lister
2009-09-02 9:23 ` Checking line status John Lister
2009-09-02 10:23 ` Gáspár Lajos
2009-09-02 11:21 ` John Lister
2009-09-02 12:47 ` Thomas Jacob
2009-09-02 13:54 ` John Lister
2009-09-02 14:02 ` John Lister
2009-09-02 14:29 ` Pascal Hambourg
2009-09-02 14:42 ` John Lister
2009-09-02 15:16 ` Pascal Hambourg
2009-09-02 16:48 ` John Lister
2009-09-02 14:30 ` Thomas Jacob
2009-09-02 15:02 ` John Lister
2009-09-02 14:13 ` Tormod Nygård
2009-08-25 14:09 ` really need your help about iptables Oskar Berggren
2009-08-26 12:14 ` J. Bakshi
2009-08-26 12:36 ` Re:[possible solution] " J. Bakshi
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.