Re: [LARTC] ?OT? Linux 2.6: bridge + routing firewall
I have some experience. It seems that you should explicitely allow bridging in iptables as well as in ebtables. So, in addition to my bridge roules in ebtables I also have this rule in iptables: iptables -A FORWARD -i br0 -o br0 -j ACCEPT Otherwise, it could block bridging by later rules or the policy. В Чтв, 15/02/2007 в 13:44 -0200, Edesio Costa e Silva пишет: > Hi All! > > I need to deploy a bridge firewall using linux kernel 2.6. I had success > using kernel 2.4 plus br-nf patch. But the configuration does not work with > kernel 2.6. > > If the default policy for the iptables FORWARD chain is ACCEPT I have a > bridge. If iptables FORWARD chain is DROP I have an insulator (no packet > flows). Any hint? > > I did some google search and in many places they say "kernel 2.6 is not > recommended", "no luck with kernel 2.6", etc. > > Any link to a success story of a bridge firewall with kernel 2.6? Any > personal experience? > > Thanks in advance, > > Edésio > ___ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > -- Покотиленко Костик <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] iptables rules disappearing!!!
Hi all. I have got to see a strange thing. Some of my iptables' rules are disaprearing after several days!!! I have many rules like: # iptables -t mangle -A $MYCHAIN -s $SRC_IP -d $DST_IP -j MARK --set-mark $MARK for classifying traffic for shaping, total about 100 rules with different 20 marks, and rules like # iptables -A FORWARD -m mark --mark $MARK for accounting shaping classes, total 20 rules (for all marks). The are also many other filtering and nat rules. Some of the mark rules in FORWARD chain are disapearing after several days. How can this happen? Can this happen without user intrusion? Considering that all those rules are inserted during boot by iptables-restore. I double checked that during ppp up/down rules inserted/removed only in "-t mangle", "-t nat" and "-A USERCHAIN". System: Debian Sarge, 2.6.8-3-k7, iptables v1.2.11 -- Покотиленко Костик <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] load balacing with https home banking
Look at this: iptables v1.3.6 Kernel 2.6.17 man iptables search for "SAME" target: SAME Similar to SNAT/DNAT depending on chain: it takes a range of addresses (`--to 1.2.3.4-1.2.3.7') and gives a client the same source-/destina- tion-address for each connection. --to - Addresses to map source to. May be specified more than once for multiple ranges. --nodst Don't use the destination-ip in the calculations when selecting the new source-ip В Вто, 19/12/2006 в 21:21 -0300, Luciano Ruete пишет: > On Monday 11 December 2006 08:15, Marco Berizzi wrote: > > Hello everybody. > > I'm running linux 2.6.19 with nth match to > > alternatively snat outgoing connections to > > two different ip addresses for load balancing > > between two adsl lines: > > Here is: > > > > $IPTABLES -t nat -A POSTROUTING -s my_ip --protocol tcp -m > > multiport --dports 80,443 -m statistic --mode nth --every 2 -j SNAT --to > > adslA > > $IPTABLES -t nat -A POSTROUTING -s my_ip --protocol tcp -m > > multiport --dports 80,443 -j SNAT --to adslB > > > > Things are working pretty good, but some > > applications (https home banking for example), > > don't work correctly (because the remote > > server see two different ip addresses). Is > > there any trick to tell iptables to snat > > always with the same source ip for the same > > destination host? I have also modified SNAT > > with SAME, but no luck. > > You need to use iptables CONNMARK to keep track of "wich conn" with "wich > ISP", see this[1] thread for reference and a nano HOWTO. > > [1]http://mailman.ds9a.nl/pipermail/lartc/2006q2/018964.html -- Покотиленко Костик <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] catching DNAT'ed packet
Maybe my question was too complex, I would try to make it simple... Is it possible to catch un-DNAT'ed packet with -j ULOG target? В Птн, 15/12/2006 в 19:44 +0200, Покотиленко Костик пишет: > Hi. > > I have a Server's network with some servers in it, all with > 192.168.1.0/25 ips. There is also a router in that network with ip > 192.168.1.1. This router also connected to a client's network > 10.10.0.0/16 with ip 10.10.100.1. > > All services on each server are given their virtual address from one of > two virtual networks 192.168.1.128/28 and 192.168.1.144/28. > 192.168.1.128/28 is for freely available services, and 192.168.1.144/28 > is for services available only to authenticated ips. > > There is a DNAT working on the router to map virtual ip/port to > realip/realport. That all works fine. > > For axample: > users connecting to 192.168.1.129:80 are brought to 192.168.1.2:80 > users connecting to 192.168.1.145:80 are brought to 192.168.1.2:81 > > I have to put all traffic I need for accounting to "-j ULOG > --ulog-nlgroup 10". And, packets should have ips seen to users. For > axample: > > 10.10.102.50 -> 192.168.1.145:80 > 192.168.1.145:80 -> 10.10.102.50 > and > 10.10.102.50 -> 192.168.1.129:80 > 192.168.1.129:80 -> 10.10.102.50 > > BUT, instead I have: > > 10.10.102.50 -> 192.168.1.145:80 > 192.168.1.2:81 -> 10.10.102.50 > and > 10.10.102.50 -> 192.168.1.129:80 > 192.168.1.2:80 -> 10.10.102.50 > > So, I can ulog the packet's in "state seen by users" only in > client->server direction, and I was unable to do that in server-clients > direction! > > Here are iptables rules (I don't want to ulog packets to/from the router > itself): > > iptables -t mangle -A PREROUTING -i br0 -j IPCAD_out > iptables -t mangle -A POSTROUTING -o br0 -j IPCAD_in > > iptables -t mangle -A IPCAD_out -d 10.10.100.1 -j RETURN > iptables -t mangle -A IPCAD_out -d 192.168.1.1 -j RETURN > iptables -t mangle -A IPCAD_out -j ULOG --ulog-nlgroup 10 > > iptables -t mangle -A IPCAD_in -s 10.10.100.1 -j RETURN > iptables -t mangle -A IPCAD_in -s 192.168.1.1 -j RETURN > iptables -t mangle -A IPCAD_in -j ULOG --ulog-nlgroup 10 > > Is it possible to catch un-DNAT'ed packet??? > -- Покотиленко Костик <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] catching DNAT'ed packet
Hi. I have a Server's network with some servers in it, all with 192.168.1.0/25 ips. There is also a router in that network with ip 192.168.1.1. This router also connected to a client's network 10.10.0.0/16 with ip 10.10.100.1. All services on each server are given their virtual address from one of two virtual networks 192.168.1.128/28 and 192.168.1.144/28. 192.168.1.128/28 is for freely available services, and 192.168.1.144/28 is for services available only to authenticated ips. There is a DNAT working on the router to map virtual ip/port to realip/realport. That all works fine. For axample: users connecting to 192.168.1.129:80 are brought to 192.168.1.2:80 users connecting to 192.168.1.145:80 are brought to 192.168.1.2:81 I have to put all traffic I need for accounting to "-j ULOG --ulog-nlgroup 10". And, packets should have ips seen to users. For axample: 10.10.102.50 -> 192.168.1.145:80 192.168.1.145:80 -> 10.10.102.50 and 10.10.102.50 -> 192.168.1.129:80 192.168.1.129:80 -> 10.10.102.50 BUT, instead I have: 10.10.102.50 -> 192.168.1.145:80 192.168.1.2:81 -> 10.10.102.50 and 10.10.102.50 -> 192.168.1.129:80 192.168.1.2:80 -> 10.10.102.50 So, I can ulog the packet's in "state seen by users" only in client->server direction, and I was unable to do that in server-clients direction! Here are iptables rules (I don't want to ulog packets to/from the router itself): iptables -t mangle -A PREROUTING -i br0 -j IPCAD_out iptables -t mangle -A POSTROUTING -o br0 -j IPCAD_in iptables -t mangle -A IPCAD_out -d 10.10.100.1 -j RETURN iptables -t mangle -A IPCAD_out -d 192.168.1.1 -j RETURN iptables -t mangle -A IPCAD_out -j ULOG --ulog-nlgroup 10 iptables -t mangle -A IPCAD_in -s 10.10.100.1 -j RETURN iptables -t mangle -A IPCAD_in -s 192.168.1.1 -j RETURN iptables -t mangle -A IPCAD_in -j ULOG --ulog-nlgroup 10 Is it possible to catch un-DNAT'ed packet??? -- Покотиленко Костик <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] iptables -m dstlimit
В Чтв, 07/12/2006 в 11:09 +0100, Kajetan Staszkiewicz пишет: > Dnia czwartek, 7 grudnia 2006 10:40, Покотиленко Костик napisał(a): > > > Which kernel supports the iptables' -m dstlimit? > > Do I need a patch or something else to get it to work? > > Is it too experimental? > > Now it is called hashlimit, it is in new 2.6 kernels already. Thanks for explaination. I don't have ipt_hashlimit.ko in 2.6.8, but I have one in 2.6.17. Will check later. -- Покотиленко Костик <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] iptables -m dstlimit
Which kernel supports the iptables' -m dstlimit? Do I need a patch or something else to get it to work? Is it too experimental? -- Покотиленко Костик <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Troubles DNATing UDP
Well, I did more testing/research today... 1. I've found some posts telling about the bug in the kernel prior to 2.6.13 about ip_conntack and UNREPLIED connections probably related to my problem. Later I've found some posts telling that the bug still appear in most modern kernels. 2. I tryed to reproduce this problem in other inveronment. I've written program that sends udp packets (source and destination ports 4000) similar to those produced by HW pingers. And I felt no problem DNAT'ing packets sent from 2 machines on both 2.6.8 and 2.6.17 kernels. While doing that I've mentioned one strange thing. The output of "tcpdump -v -v" in reproduced case always show different UDP ID for each packet, while in real case it show the same UDP ID for all HW pingers for all packets. Does somebody know that is UDP ID and should it be related to this problem? Just in case: # tcpdump -i br0 port 4000 -v -n tcpdump: listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes 20:58:21.636684 IP (tos 0x0, ttl 64, id 6552, offset 0, flags [none], length: 102) 10.10.100.22.4000 > 192.168.1.2.4000: UDP, length: 74 20:58:22.888548 IP (tos 0x0, ttl 64, id 6552, offset 0, flags [none], length: 102) 10.10.100.21.4000 > 192.168.1.2.4000: UDP, length: 74 20:58:23.065247 IP (tos 0x0, ttl 64, id 6552, offset 0, flags [none], length: 102) 10.10.100.22.4000 > 192.168.1.2.4000: UDP, length: 74 20:58:23.351091 IP (tos 0x0, ttl 64, id 6552, offset 0, flags [none], length: 102) 10.10.100.23.4000 > 192.168.1.2.4000: UDP, length: 74 3. I've played with the router in real case and found out that the problem not always appear. Having the rule: iptables -t nat -A PREROUTING -d 10.10.100.1 -p udp -m udp --dport 4000 -j DNAT --to-destination 192.168.1.2 and doing ifdown br0, then ifup br0, and looking in /proc/net/ip_conntrack: One time I got: udp 17 29 src=10.10.100.23 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=192.168.1.2 dst=10.10.100.23 sport=4000 dport=4000 use=1 udp 17 28 src=10.10.100.21 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=10.10.100.1 dst=10.10.100.21 sport=4000 dport=4000 use=2 udp 17 29 src=10.10.100.22 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=192.168.1.2 dst=10.10.100.22 sport=4000 dport=4000 use=1 (note this "src=10.10.100.1" for second rule). 10.10.100.23 and 10.10.100.22 got through. Several next times I got 2 others to work. And finally I got all of them to work: udp 17 29 src=10.10.100.23 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=192.168.1.2 dst=10.10.100.23 sport=4000 dport=4000 use=1 udp 17 28 src=10.10.100.21 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=192.168.1.2 dst=10.10.100.21 sport=4000 dport=4000 use=1 udp 17 29 src=10.10.100.22 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=192.168.1.2 dst=10.10.100.22 sport=4000 dport=4000 use=1 To conclude, right now I have all packets being DNAT'd like I want, but I guess this is until next reboot :/ -- Покотиленко Костик <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] NAT/MASQ with multiple external static IPs
В Вто, 14/11/2006 в 16:15 +0300, Ron McKown пишет:
> Hello everyone,
> really not sure if this is a LARTC question or not, but I have several
> hundred users all MASQ'd behind a single static IP. Users are reporting
> that certain websites are blacklisting that single static external IP
> for various reasons.
>
> What I would like to do is use several external IP's and have a MASQ'd
> user getting a random one each time.
>
> Here is a very simplified example:
>
> eth0:1.2.3.4
> eth0:1 1.2.3.5
> eth0:2 1.2.3.6
> eth0:3 1.2.3.7
>
> eth1: 192.168.0.0/16
>
> Whereas, a user will sent out and given one of the eth0 addresses by random.
>
> Any clue where to start looking?
# man iptables
..
SNAT
This target is only valid in the nat table, in the POSTROUTING chain.
It specifies that the source address of the packet should be modified
(and all future packets in this connection will also be mangled), and
rules should cease being examined. It takes one type of option:
--to-source ipaddr[-ipaddr][:port-port]
which can specify a single new source IP address, an inclusive
range of IP addresses, and optionally, a port range (which is
only valid if the rule also specifies -p tcp or -p udp). If no
port range is specified, then source ports below 512 will be
mapped to other ports below 512: those between 512 and 1023
inclusive will be mapped to ports below 1024, and other ports
will be mapped to 1024 or above. Where possible, no port alter-
ation will occur.
You can add several --to-source options. If you specify more
than one source address, either via an address range or multiple
--to-source options, a simple round-robin (one after another in
cycle) takes place between these adresses.
..
--
Покотиленко Костик <[EMAIL PROTECTED]>
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Troubles DNATing UDP
В Птн, 10/11/2006 в 10:31 -0600, Taylor, Grant пишет: > Покотиленко Костик wrote: > > > > > As the pingers ping (send UDP packets) to 10.10.100.1 I was trying to > > redirect them to 192.168.1.2 by: > > > > iptables -t nat -I PREROUTING 1 -p udp --dport 4000 -j DNAT > > --to-destination 192.168.1.2:4000 > > iptables -I FORWARD -p udp --dport 4000 -d 192.168.1.2 -j ACCEPT > > (Before morning coffee...) > > One quick question / point. Your source and destination ports are both 4000 > right? (I presuming yes.) Your PREROUTING rule is looking to DNAT any UDP > traffic that has a destination port of 4000 to 192.168.1.2. What happens to > the reply traffic from 192.168.1.2 that is destined to port 4000 on 10.0.x.y? There is not such traffic as that kind of ping not supposed to do replay. Explain latter. > > Neither of those rules not catching the packets, they all reach > > 10.10.100.1 INPUT chain. Those rule counters are zero. > > Hum. Try adding a rule similar to this: > > iptables -t nat -I PREROUTING 1 -p udp --dport 4000 -j LOG > > To see if you can match the packets at all. I did that, nothing is matched. This is strange. > > If I do: > > > > iptables -t mangle -I PREROUTING 1 -p udp --dport 4000 > > > > this rule catch needed packets, but not in NAT tables! Why? > > I would expect that you could match the packets any where they traverse the > kernel. > > > > > Here is tcpdump from 10.10.100.1: > > > > # tcpdump -i br0 port 4000 -n > > tcpdump: verbose output suppressed, use -v or -vv for full protocol > > decode > > listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes > > 16:36:53.202130 IP 10.10.100.23.4000 > 10.10.100.1.4000: UDP, length: 74 > > 16:36:54.092413 IP 10.10.100.21.4000 > 10.10.100.1.4000: UDP, length: 74 > > 16:36:54.143128 IP 10.10.100.22.4000 > 10.10.100.1.4000: UDP, length: 74 > > 16:36:55.291886 IP 10.10.100.23.4000 > 10.10.100.1.4000: UDP, length: 74 > > 16:36:55.545621 IP 10.10.100.22.4000 > 10.10.100.1.4000: UDP, length: 74 > > 16:36:55.743096 IP 10.10.100.21.4000 > 10.10.100.1.4000: UDP, length: 74 > > Hum... > > > Once again, all those packets reach INPUT chain, rules in -t nat -I > > PREROUTING not working. > > You appear to be using a bridge interface, not a real network interface. > (Not that this is a problem.) > > Do you have the "Bridged IP/ARP packets filtering" option enabled in the > kernel? If you do, this option will enable NetFilter Layer 3 filtering at > the EBTables Layer 2 level. I.e. you can use IPTables to filter bridged > traffic. In this case you will need to write rules to allow your bridged > traffic to flow through, as it is dependent on your Table / CHAIN default > policies. There are alot of other udp and tcp traffic already comming through. > > So here is the question: Does the UDP is being DNAT'ed differently > > comparing with TCP? What is the difference? How can I DNAT them? > > I do not think that the problem is with the protocol(s) per say, but rather > the filtering that is in place. > > Will you please do an iptables-save output so that we can see your entire > firewall script to better evaluate what is going on. I'll study the situation once again today and send the entire rules if no luck. > > Thanks in advance. > > No problem. > > > P.S. This king of UDP ping doesn't require responce, its just to see > > which remote point is still alive. > > Sorry, I have to ask. How are you going to be able to tell if a point is > active if you do not get a reply? Are you looking for some sort of anomaly > in reply / error (or lack there of) traffic to determine if a point is active? You should get 1 packet per second from each HW pinger, if you don't get or get less than 1packet/s from particular HW pinger, then there are problems with the route to that HW pinger. For debugging purpose it's possible to ping clients in between and figure out where the problem starts to take place. -- Покотиленко Костик <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: Troubles DNATing UDP
В Птн, 10/11/2006 в 16:39 +0100, dAm2K пишет: > > > Once again, all those packets reach INPUT chain, rules in -t nat -I > > > PREROUTING not working. > > > > > > So here is the question: Does the UDP is being DNAT'ed differently > > > comparing with TCP? What is the difference? How can I DNAT them? > > If your HW UDP pinger's default gateway is your natting firewall, try > to ping directly the 192.168.1.2 web server. If default gateway is > another router, try adding the route 192.168.1.0/25 to you HW pingers > and ping directly 192.168.1.2. That would probably help, but it is not desirable. The topology may change, so it's better ping the closest roouter and to natting in it. > If this is not possible (and you are UDP pinging you firewall) open > dport 4000 udp in INPUT chain on your firewall and do natting: > > iptables -t filter -A INPUT -p udp -m udp -s 10.10.0.0/16 -d > 10.10.100.1 --dport 4000 -j ACCEPT > iptables -t nat -A PREROUTING -p udp -m udp -s 10.10.0.0/16 -d > 10.10.100.1 --dport 4000 -j DNAT --to-destination 192.168.1.2 > > This way 192.168.1.2 host should receive udp packets coming from the firewall. This is what I've done. But, packets are reaching INPUT chain, counters of the first rule are increasing, and packets are not reaching second rule, it's counters are zero all the time. And DNAT'ing not working :/ > My setup is running smoothly with UDP and NAT, I'm using with > playstation online games... > > Hope this help. Bye, Dino. > -- Покотиленко Костик <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Troubles DNATing UDP
Did my message hit the list? Once again, is there any difference in DNAT'ing TCP and UDP, maybe there is difference related to different kinds/types of UDP packet? В Вто, 07/11/2006 в 16:40 +0200, Покотиленко Костик пишет: > Hi. > > I have strange troubles with DNATing UDP packets. > > The situation: > > 1. We have local network 10.10.0.0/16 > 2. We have a "server network" 192.168.1.0/25 connected with local > network by a router 10.10.100.1 (other ip 192.168.1.1). > 3. Web server is located at 192.168.1.2 > 4. There are HW pingers in the net 10.10.0.0/16 whose do ping > 10.10.100.1 every second. The ping is the UDP packet with both source > and destination ports set to 4000. > 5. There is software to decode ping packets and produce/update html > report. > > I want to install the ping-analizing software at the web-server > (192.168.1.2) and connect it with localy running apache to have a web > page with ping-report. > > As the pingers ping (send UDP packets) to 10.10.100.1 I was trying to > redirect them to 192.168.1.2 by: > > iptables -t nat -I PREROUTING 1 -p udp --dport 4000 -j DNAT > --to-destination 192.168.1.2:4000 > iptables -I FORWARD -p udp --dport 4000 -d 192.168.1.2 -j ACCEPT > > Neither of those rules not catching the packets, they all reach > 10.10.100.1 INPUT chain. Those rule counters are zero. > > If I do: > > iptables -t mangle -I PREROUTING 1 -p udp --dport 4000 > > this rule catch needed packets, but not in NAT tables! Why? > > I tryed same with TCP: > > iptables -t nat -I PREROUTING 1 -p tcp --dport 4000 -j DNAT > --to-destination 192.168.1.2:4000 > iptables -I FORWARD -p tcp --dport 4000 -d 192.168.1.2 -j ACCEPT > > and this works fine, I can see packets at 192.168.1.2 when doing telnet > 10.10.100.1 4000 from the localnet. > > Here is tcpdump from 10.10.100.1: > > # tcpdump -i br0 port 4000 -n > tcpdump: verbose output suppressed, use -v or -vv for full protocol > decode > listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes > 16:36:53.202130 IP 10.10.100.23.4000 > 10.10.100.1.4000: UDP, length: 74 > 16:36:54.092413 IP 10.10.100.21.4000 > 10.10.100.1.4000: UDP, length: 74 > 16:36:54.143128 IP 10.10.100.22.4000 > 10.10.100.1.4000: UDP, length: 74 > 16:36:55.291886 IP 10.10.100.23.4000 > 10.10.100.1.4000: UDP, length: 74 > 16:36:55.545621 IP 10.10.100.22.4000 > 10.10.100.1.4000: UDP, length: 74 > 16:36:55.743096 IP 10.10.100.21.4000 > 10.10.100.1.4000: UDP, length: 74 > > Once again, all those packets reach INPUT chain, rules in -t nat -I > PREROUTING not working. > > So here is the question: Does the UDP is being DNAT'ed differently > comparing with TCP? What is the difference? How can I DNAT them? > > Thanks in advance. > > P.S. This king of UDP ping doesn't require responce, its just to see > which remote point is still alive. > -- Покотиленко Костик <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Troubles DNATing UDP
Hi. I have strange troubles with DNATing UDP packets. The situation: 1. We have local network 10.10.0.0/16 2. We have a "server network" 192.168.1.0/25 connected with local network by a router 10.10.100.1 (other ip 192.168.1.1). 3. Web server is located at 192.168.1.2 4. There are HW pingers in the net 10.10.0.0/16 whose do ping 10.10.100.1 every second. The ping is the UDP packet with both source and destination ports set to 4000. 5. There is software to decode ping packets and produce/update html report. I want to install the ping-analizing software at the web-server (192.168.1.2) and connect it with localy running apache to have a web page with ping-report. As the pingers ping (send UDP packets) to 10.10.100.1 I was trying to redirect them to 192.168.1.2 by: iptables -t nat -I PREROUTING 1 -p udp --dport 4000 -j DNAT --to-destination 192.168.1.2:4000 iptables -I FORWARD -p udp --dport 4000 -d 192.168.1.2 -j ACCEPT Neither of those rules not catching the packets, they all reach 10.10.100.1 INPUT chain. Those rule counters are zero. If I do: iptables -t mangle -I PREROUTING 1 -p udp --dport 4000 this rule catch needed packets, but not in NAT tables! Why? I tryed same with TCP: iptables -t nat -I PREROUTING 1 -p tcp --dport 4000 -j DNAT --to-destination 192.168.1.2:4000 iptables -I FORWARD -p tcp --dport 4000 -d 192.168.1.2 -j ACCEPT and this works fine, I can see packets at 192.168.1.2 when doing telnet 10.10.100.1 4000 from the localnet. Here is tcpdump from 10.10.100.1: # tcpdump -i br0 port 4000 -n tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes 16:36:53.202130 IP 10.10.100.23.4000 > 10.10.100.1.4000: UDP, length: 74 16:36:54.092413 IP 10.10.100.21.4000 > 10.10.100.1.4000: UDP, length: 74 16:36:54.143128 IP 10.10.100.22.4000 > 10.10.100.1.4000: UDP, length: 74 16:36:55.291886 IP 10.10.100.23.4000 > 10.10.100.1.4000: UDP, length: 74 16:36:55.545621 IP 10.10.100.22.4000 > 10.10.100.1.4000: UDP, length: 74 16:36:55.743096 IP 10.10.100.21.4000 > 10.10.100.1.4000: UDP, length: 74 Once again, all those packets reach INPUT chain, rules in -t nat -I PREROUTING not working. So here is the question: Does the UDP is being DNAT'ed differently comparing with TCP? What is the difference? How can I DNAT them? Thanks in advance. P.S. This king of UDP ping doesn't require responce, its just to see which remote point is still alive. -- Покотиленко Костик <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] linux-2.4.22 + bridge + traffic control by MAC.
В Вто, 07/11/2006 в 14:25 +0800, Henry Bin пишет: > Dear all, > > I am working on a linux box (2.4.22 kernel) which is used as a > bridge. And I want to add traffic control rules on it by client's MAC. Does > anyone has such experience on how to do that? Thank you very much!! bridge-utils iptables ebtables -- Покотиленко Костик <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] Applying the same class to multiple interfaces
Then probably you was on correct way, mark packets with ebtables and direct them to shaping classes you need. В Пнд, 28/08/2006 в 17:41 +1000, Leigh Sharpe пишет: > I don't actually want to shape incoming traffic. I want to limit the > bandwidth of the bridge, so that their total throughput doesn't exceed a > particular rate. To do this, I can’t limit on only one interface. I need to > configure it so that eth0+eth1 never exceeds the bandwidth limit. > > > > Regards, > Leigh > > Leigh Sharpe > Network Systems Engineer > Pacific Wireless > Ph +61 3 9584 8966 > Mob 0408 009 502 > email [EMAIL PROTECTED] > web www.pacificwireless.com.au > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, August 28, 2006 4:26 PM > To: Leigh Sharpe > Cc: lartc > Subject: Re: [LARTC] Applying the same class to multiple interfaces > > As you probably red there is no good way to shape incoming traffic. > Shaping of incoming traffic is not recommended. This is no problem with > this because you can (this is recomended) shape outgoing traffice on > multiple interfaces. > > For example if you have a client on eth0 and Internet on eth1, and you > want to shape client's traffic both direction: > > - to shape client's incoming traffic you shape its outgoing traffic on > eth0 > > - to shape client's outgoing traffic you shape its outgoing traffic on > eth1 > > Also, for your needs you can MARK packets with iptables on br0 > interface. ebtables are more suitable for implementation of "smart > switch". > > ÷ ðÎÄ, 28/08/2006 × 14:09 +1000, Leigh Sharpe ÐÉÛÅÔ: > > Hi All, > > I'm trying to do some traffic shaping on an ethernet bridge. > > Currently, I have the following setup working: > > > > ifconfig eth0 down > > brctl addbr br0 > > brctl addif br0 eth0 > > brctl addif br0 eth1 > > brctl stp br0 off > > ifconfig eth0 0.0.0.0 up > > ifconfig eth1 0.0.0.0 up > > ifconfig br0 up > > > > This creates a bridge consisting of eth0 and eth1. So far so good. > > > > I now want to use tc to shape traffic through this bridge. By applying > > the following, I am able to limit the given MAC address to 128K in > > each direction: > > > > tc qdisc add dev eth0 root handle 1:0 cbq bandwidth 100Mbit avpkt 1000 > > mpu 64 > > tc qdisc add dev eth1 root handle 1:0 cbq bandwidth 100Mbit avpkt 1000 > > mpu 64 > > tc class add dev eth0 parent 1:0 classid 1:1 cbq rate 128Kbit allot > > 1514 prio 1 avpkt 1000 bounded > > tc class add dev eth1 parent 1:0 classid 1:1 cbq rate 128Kbit allot > > 1514 prio 1 avpkt 1000 bounded > > tc filter add dev eth0 parent 1:0 protocol ip handle 1 fw flowid 1:1 > > tc filter add dev eth1 parent 1:0 protocol ip handle 1 fw flowid 1:1 > > ebtables -A FORWARD -s 00:10:A4:EC:65:E8 -j mark --set-mark 1 > > --mark-target ACCEPT > > ebtables -A FORWARD -d 00:10:A4:EC:65:E8 -j mark --set-mark 1 > > --mark-target ACCEPT > > > > This works OK, but it isn't quite what I want. I want to limit the > > traffic to 128K total. ie, 128K in one direction or the other, or 64K > > in each direction simultaneously, or 100K in one direction and 28K in > > the other, etc... > > I can't see anything in the tc docs which indicates that I can apply > > the same class and filter to multiple interfaces at once. > > I'd be happy enough with applying the same rate limit to a single > > interface, but measuring both ingress and egress traffic to come up > > with the lmit. > > > > Ultimately, of course, I'll be using different criteria to mark the > > packets. > > > > > > Regards, > > Leigh > > > > Leigh Sharpe > > Network Systems Engineer > > Pacific Wireless > > Ph +61 3 9584 8966 > > Mob 0408 009 502 > > email [EMAIL PROTECTED] > > web www.pacificwireless.com.au > > > > ___ > > LARTC mailing list > > LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- Покотиленко Костик <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Applying the same class to multiple interfaces
As you probably red there is no good way to shape incoming traffic. Shaping of incoming traffic is not recommended. This is no problem with this because you can (this is recomended) shape outgoing traffice on multiple interfaces. For example if you have a client on eth0 and Internet on eth1, and you want to shape client's traffic both direction: - to shape client's incoming traffic you shape its outgoing traffic on eth0 - to shape client's outgoing traffic you shape its outgoing traffic on eth1 Also, for your needs you can MARK packets with iptables on br0 interface. ebtables are more suitable for implementation of "smart switch". В Пнд, 28/08/2006 в 14:09 +1000, Leigh Sharpe пишет: > Hi All, > I'm trying to do some traffic shaping on an ethernet bridge. > Currently, I have the following setup working: > > ifconfig eth0 down > brctl addbr br0 > brctl addif br0 eth0 > brctl addif br0 eth1 > brctl stp br0 off > ifconfig eth0 0.0.0.0 up > ifconfig eth1 0.0.0.0 up > ifconfig br0 up > > This creates a bridge consisting of eth0 and eth1. So far so good. > > I now want to use tc to shape traffic through this bridge. By applying > the following, I am able to limit the given MAC address to 128K in > each direction: > > tc qdisc add dev eth0 root handle 1:0 cbq bandwidth 100Mbit avpkt 1000 > mpu 64 > tc qdisc add dev eth1 root handle 1:0 cbq bandwidth 100Mbit avpkt 1000 > mpu 64 > tc class add dev eth0 parent 1:0 classid 1:1 cbq rate 128Kbit allot > 1514 prio 1 avpkt 1000 bounded > tc class add dev eth1 parent 1:0 classid 1:1 cbq rate 128Kbit allot > 1514 prio 1 avpkt 1000 bounded > tc filter add dev eth0 parent 1:0 protocol ip handle 1 fw flowid 1:1 > tc filter add dev eth1 parent 1:0 protocol ip handle 1 fw flowid 1:1 > ebtables -A FORWARD -s 00:10:A4:EC:65:E8 -j mark --set-mark 1 > --mark-target ACCEPT > ebtables -A FORWARD -d 00:10:A4:EC:65:E8 -j mark --set-mark 1 > --mark-target ACCEPT > > This works OK, but it isn't quite what I want. I want to limit the > traffic to 128K total. ie, 128K in one direction or the other, or 64K > in each direction simultaneously, or 100K in one direction and 28K in > the other, etc... > I can't see anything in the tc docs which indicates that I can apply > the same class and filter to multiple interfaces at once. > I'd be happy enough with applying the same rate limit to a single > interface, but measuring both ingress and egress traffic to come up > with the lmit. > > Ultimately, of course, I'll be using different criteria to mark the > packets. > > > Regards, > Leigh > > Leigh Sharpe > Network Systems Engineer > Pacific Wireless > Ph +61 3 9584 8966 > Mob 0408 009 502 > email [EMAIL PROTECTED] > web www.pacificwireless.com.au > > ___ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- Покотиленко Костик <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Bonding + Shaping --> Is it Possible?
So there is no difference between bonded interfaces. I mean that the same traffic goes on both. This case you can make shaping on your bond0 interface. This will work. Well, if the interface that looks to Clients is bond0, and interface that looks to Internet if eth0, then you make shaping of incoming traffic on bond0 and shaping of outgoing traffic on eth0. В Пнд, 21/08/2006 в 17:30 +0100, KartheeK пишет: > I have bonded two interfaces in mode 0 for load balancing and link > sharing. > My understanding is that "traffic control" happens, below bonding and > hence this should be possible. I am currently short of lab equipments > and am planning to try this some time this week end... > I am curious about similar implemantations and/or thoughts,, > > ðÏËÏÔÉÌÅÎËÏ ëÏÓÔÉË <[EMAIL PROTECTED]> wrote: > I tryed to do some iptables rules on bonded interfaces and > that didn't > worked. I had to use "ebtables". > > BTW, what kind of bonding do you use? > > ÷ ðÎÄ, 21/08/2006 × 13:05 +0100, KartheeK ÐÉÛÅÔ: > > Hello All > > > > Any Body, Any Thoughts? > > Any Kind of feedback or suggestion is a welcome... > > > > KartheeK > > > > KartheeK wrote: > > Hello All, > > > > Has Any body of you worked on such a set up? > > > > KartheeK > > > > KartheeK wrote: > > Date: Thu, 17 Aug 2006 07:31:25 +0100 (BST) > > From: KartheeK > > To: lartc@mailman.ds9a.nl > > Subject: [LARTC] Bonding + Shaping --> Is it Possible? > > > > Hello All, > > > > I was curious to know if I can do traffic shaping on > > abonded Interface? > > Ex: I have to interfaces eth1 and eth2 which i have > > bonded together as bond0 , now the question is can I > > do shaping on eth1 and eth2 ?? > > > > Thanks > > KartheeK > > > > > > __ > > Here's a new way to find what you're looking for - > > Yahoo! Answers > > Send FREE SMS to your friend's mobile from Yahoo! > > Messenger Version 8. Get it > > NOW___ > > LARTC mailing list > > LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > > > > > > > > > __ > > Here's a new way to find what you're looking for - Yahoo! > > Answers > > Send FREE SMS to your friend's mobile from Yahoo! Messenger > > Version 8. Get it > > NOW___ > > LARTC mailing list > > LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > > ___ > > LARTC mailing list > > LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > > > > > > > > > > > __ > > Here's a new way to find what you're looking for - Yahoo! > Answers > > Send FREE SMS to your friend's mobile from Yahoo! Messenger > Version 8. > > Get it NOW > > ___ > > LARTC mailing list > > LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > -- > ðÏËÏÔÉÌÅÎËÏ ëÏÓÔÉË > > > > > > __ > Here's a new way to find what you're looking for - Yahoo! Answers > Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. > Get it NOW -- Покотиленко Костик <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Bonding + Shaping --> Is it Possible?
I tryed to do some iptables rules on bonded interfaces and that didn't worked. I had to use "ebtables". BTW, what kind of bonding do you use? В Пнд, 21/08/2006 в 13:05 +0100, KartheeK пишет: > Hello All > > Any Body, Any Thoughts? > Any Kind of feedback or suggestion is a welcome... > > KartheeK > > KartheeK <[EMAIL PROTECTED]> wrote: > Hello All, > > Has Any body of you worked on such a set up? > > KartheeK > > KartheeK <[EMAIL PROTECTED]> wrote: > Date: Thu, 17 Aug 2006 07:31:25 +0100 (BST) > From: KartheeK <[EMAIL PROTECTED]> > To: lartc@mailman.ds9a.nl > Subject: [LARTC] Bonding + Shaping --> Is it Possible? > > Hello All, > > I was curious to know if I can do traffic shaping on > abonded Interface? > Ex: I have to interfaces eth1 and eth2 which i have > bonded together as bond0 , now the question is can I > do shaping on eth1 and eth2 ?? > > Thanks > KartheeK > > > __ > Here's a new way to find what you're looking for - > Yahoo! Answers > Send FREE SMS to your friend's mobile from Yahoo! > Messenger Version 8. Get it > NOW___ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > > > > __ > Here's a new way to find what you're looking for - Yahoo! > Answers > Send FREE SMS to your friend's mobile from Yahoo! Messenger > Version 8. Get it > NOW___ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > ___ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > > > > > __ > Here's a new way to find what you're looking for - Yahoo! Answers > Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. > Get it NOW > ___ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- Покотиленко Костик <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] iproute2, alternative tables, no default route: routing trouble for localhost [SOLVED]
I've found the answer in [EMAIL PROTECTED] First: I'm sorry, there was a typo while writing message. The correct subnets are 10.10.101.0/24 and 10.10.100.0/24, not 10.10.100.101/24 and 10.10.100.100/24. The solution is: # ip rule add dev lo table Servers as Pascal Hambourg <[EMAIL PROTECTED]> advised, I'll quote: > > So, the question is: how does the routing of packets comming from > > localhost is being accomplished? > > In the same way as the routing of forwarded packets. From "ip rule" > point of view, locally generated traffic is selected with "iif lo" (see > iproute manual). Be aware that when the local source address is not > explicitly specified by the sending application, none of your custom > rules will match, so the "main" table will be used. But it contains no > default route. В Птн, 18/08/2006 в 14:31 +0300, Покотиленко Костик пишет: > Hi. > > The task: > > 1. There 3 servers and a router with 2 PPPoE connections (let call them: > ppp0, ppp1). > 2. There are several groups of Inet-clients to be served (Servers, > Clients and Club). > 3. The task is: >- to route Club through the ppp1; >- to Servers and Clients through ppp0; > > (Next is reproduced from memory and may be slightly incorrect) > > router # netstat -nr > Kernel IP routing table > Destination Gateway Genmask Flags MSS Window irtt > Iface > 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 > eth0 > a1.a2.a3.a4 0.0.0.0 255.255.255.255 U 0 0 0 > ppp0 > b1.b2.b3.b4 0.0.0.0 255.255.255.255 U 0 0 0 > ppp1 > > router # cat /etc/iproute2/rt_tables > # > # reserved values > # > 255 local > 254 main > 253 default > 0 unspec > # > # local > # > #1 inr.ruhep > 200 Servers > 201 Clients > 202 Club > > router # ip rule ls > 0: from all lookup local > 32763: from 10.10.100.101/24 lookup Club > 32764: from 10.10.100.100/24 lookup Clients > 32765: from 192.168.1.0/24 lookup Servers > 32766: from all lookup main > 32767: from all lookup default > > router # ip route ls table Clients > default via a1.a2.a3.a4 dev ppp0 > > router # ip route ls table Servers > default via a1.a2.a3.a4 dev ppp0 > > router # ip route ls table Club > default via b1.b2.b3.b4 dev ppp1 > > > > So, to summarize, the is no default route in main routing table. Each > group of clients is to be routed through its respective connection, and, > when its connection is down it is not to be routed. > > This scheme works almost fine, 10.10.100.100/24 addresses are really > being routed through ppp0, 10.10.100.101/24 through ppp1 and > 192.168.1.0/24 (3 Servers) through ppp0. BUT the router itself > (192.168.1.4) has no route to any host. I get "network is unreachable" > to any connectiion attempt from 192.168.1.4. And I can't connect to this > router from outside, because the packets have no route to be sent back. > > I thought that there is different routing politics for localhost and > added default route to "local" table. 192.168.1.4 has started to have > the route, but the rest of the scheme started to work incorrectly. > > So, the question is: how does the routing of packets comming from > localhost is being accomplished? > > As to me there is a kind of "vicious circle" situation, because to enter > alternative routing table there should already be "source address", but > for localhost which have many source addresses it should decide which > route it needs to have the corresponding "source address" be set. > -- Покотиленко Костик <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] iproute2, alternative tables, no default route: routing trouble for localhost
В Птн, 18/08/2006 в 14:52 +0200, Marek Kierdelewicz пишет: > > Hi. > > Hi > > > router # cat /etc/iproute2/rt_tables > > # > > # reserved values > > # > > 255 local > > 254 main > > 253 default > > 0 unspec > > # > > Add default route to the "default" table .. it gets hit after your > custom tables as you can see here: > > router # ip rule ls > 0: from all lookup local > 32763: from 10.10.100.101/24 lookup Club > 32764: from 10.10.100.100/24 lookup Clients > 32765: from 192.168.1.0/24 lookup Servers > 32766: from all lookup main > 32767: from all lookup default > > This should allow your router to connect out and receive connections. Would 10.10.100.101/24 and 10.10.100.100/24 hit that table too? That's not desirable because 10.10.100.101/24 should have no route if there is no one in Club table, and 10.10.100.100/24 should have no route if there no one in Clients table. -- Покотиленко Костик <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] iproute2, alternative tables, no default route: routing trouble for localhost
Hi. The task: 1. There 3 servers and a router with 2 PPPoE connections (let call them: ppp0, ppp1). 2. There are several groups of Inet-clients to be served (Servers, Clients and Club). 3. The task is: - to route Club through the ppp1; - to Servers and Clients through ppp0; (Next is reproduced from memory and may be slightly incorrect) router # netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 a1.a2.a3.a4 0.0.0.0 255.255.255.255 U 0 0 0 ppp0 b1.b2.b3.b4 0.0.0.0 255.255.255.255 U 0 0 0 ppp1 router # cat /etc/iproute2/rt_tables # # reserved values # 255 local 254 main 253 default 0 unspec # # local # #1 inr.ruhep 200 Servers 201 Clients 202 Club router # ip rule ls 0: from all lookup local 32763: from 10.10.100.101/24 lookup Club 32764: from 10.10.100.100/24 lookup Clients 32765: from 192.168.1.0/24 lookup Servers 32766: from all lookup main 32767: from all lookup default router # ip route ls table Clients default via a1.a2.a3.a4 dev ppp0 router # ip route ls table Servers default via a1.a2.a3.a4 dev ppp0 router # ip route ls table Club default via b1.b2.b3.b4 dev ppp1 So, to summarize, the is no default route in main routing table. Each group of clients is to be routed through its respective connection, and, when its connection is down it is not to be routed. This scheme works almost fine, 10.10.100.100/24 addresses are really being routed through ppp0, 10.10.100.101/24 through ppp1 and 192.168.1.0/24 (3 Servers) through ppp0. BUT the router itself (192.168.1.4) has no route to any host. I get "network is unreachable" to any connectiion attempt from 192.168.1.4. And I can't connect to this router from outside, because the packets have no route to be sent back. I thought that there is different routing politics for localhost and added default route to "local" table. 192.168.1.4 has started to have the route, but the rest of the scheme started to work incorrectly. So, the question is: how does the routing of packets comming from localhost is being accomplished? As to me there is a kind of "vicious circle" situation, because to enter alternative routing table there should already be "source address", but for localhost which have many source addresses it should decide which route it needs to have the corresponding "source address" be set. -- Покотиленко Костик <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
