RE: [LARTC] Linux bridging and cascaded switches
> On the bridged firewall - The simplest/ easiest/ well tested > method would be to run ebtables. A more complex method used > before the arrival of ebtables involved pseudo-bridging. Yes - thanks. I've been trying some ebtables experiments. Layer 2 filtering - takes some getting used to! More fundamentally, can I cascade these switches and my bridge/firewall this deep? How do the Internet router and internal servers find each others' MAC addresses when they are 4 "hops" (OSI layer 2 hops) separated? Or am I making this too complicated? > Internal---User---Core-Firewall---Internet---Internet router > Servers switch switch (Bridged)switch (and default GW for > internal servers) Thanks - Greg -Original Message- From: Mohan Sundaram [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 19, 2007 9:53 PM To: Greg Scott Subject: Re: [LARTC] Linux bridging and cascaded switches Greg Scott wrote: > Hi - > > Internal---User---Core-Firewall---Internet---Internet router > Servers switch switch (Bridged)switch (and default GW for > internal servers) > > The scenario is a little more complex than I drew above because the > internal side has more than one LAN segment participating in the bridge. > I'm working on a way to simulate all this here - before going into > production - but I have a big question; > > That firewall/bridge is no longer a router - it's a bridge. Well, a > bridge that also does a bunch of stateful IP layer 3 filtering. So > now, it will participate in a spanning tree setup with all those > switches, on both sides of it - right? I'm guessing I want to turn > off STP in this case. Am I on the right track? > > Thanks > > - Greg Scott From what you have drawn, it seems like we will not have multiple paths in the LAN and so STP will not be needed. On the bridged firewall - The simplest/ easiest/ well tested method would be to run ebtables. A more complex method used before the arrival of ebtables involved pseudo-bridging. Mohan ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] Linux bridging and cascaded switches
> out of curiosity why would you want to bridge at the firewall. is this meant to be a drop in-line firewall appliance Long story but yes, it is essentially a drop in-line system. It's a mess. So will that Internet router really see 4 "switches" - a switch, a bridge, and 2 switches - between it and the internal servers? I don't remember all my LAN rules but that feels way too deep to me. - Greg ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Linux bridging and cascaded switches
Hi - Still plugging away at my Linux bridge/firewall and thinking through the consequences. In a normal firewall situation, the Internet is on one side, the internal LAN on the other. Duh! But now, with a Linux bridge in the middle, the whole thing becomes one big messy LAN. So we have a scenario that looks like this: Internal---User---Core-Firewall---Internet---Internet router Servers switch switch (Bridged)switch (and default GW for internal servers) The scenario is a little more complex than I drew above because the internal side has more than one LAN segment participating in the bridge. I'm working on a way to simulate all this here - before going into production - but I have a big question; That firewall/bridge is no longer a router - it's a bridge. Well, a bridge that also does a bunch of stateful IP layer 3 filtering. So now, it will participate in a spanning tree setup with all those switches, on both sides of it - right? I'm guessing I want to turn off STP in this case. Am I on the right track? Thanks - Greg Scott ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] What I learned about Linux bridging
>> I want to block anything coming in from the Internet claiming to come >> from 10/8, or 172.16/12 or 192.168/16. > You should be able to easily do this with a few EBTables rules. Yup - I was off putting together something similar to what you did and just now saw your reply. It all tested good. I'll paste it in below: # # ebtables rules for bridging # echo "ebtables rules" echo " Directing anything between the Internet and private IP Addresses to the bogus_ip chain" $EBTABLES -A FORWARD -i $INET_IFACE -p IPv4 --ip-src 10.0.0.0/8 -j bogus_ip $EBTABLES -A FORWARD -i $INET_IFACE -p IPv4 --ip-src 172.16.0.0/12 -j bogus_ip $EBTABLES -A FORWARD -i $INET_IFACE -p IPv4 --ip-src 192.168.0.0/16 -j bogus_ip $EBTABLES -A FORWARD -i $INET_IFACE -p IPv4 --ip-dst 10.0.0.0/8 -j bogus_ip $EBTABLES -A FORWARD -i $INET_IFACE -p IPv4 --ip-dst 172.16.0.0/12 -j bogus_ip $EBTABLES -A FORWARD -i $INET_IFACE -p IPv4 --ip-dst 192.168.0.0/16 -j bogus_ip $EBTABLES -A INPUT -i $INET_IFACE -p IPv4 --ip-src 10.0.0.0/8 -j bogus_ip $EBTABLES -A INPUT -i $INET_IFACE -p IPv4 --ip-src 172.16.0.0/12 -j bogus_ip $EBTABLES -A INPUT -i $INET_IFACE -p IPv4 --ip-src 192.168.0.0/16 -j bogus_ip $EBTABLES -A INPUT -i $INET_IFACE -p IPv4 --ip-dst 10.0.0.0/8 -j bogus_ip $EBTABLES -A INPUT -i $INET_IFACE -p IPv4 --ip-dst 172.16.0.0/12 -j bogus_ip $EBTABLES -A INPUT -i $INET_IFACE -p IPv4 --ip-dst 192.168.0.0/16 -j bogus_ip # # Set up the bogus_ip chain to log and drop packets to/from private IP addresses # echo "Setting up the bogus_ip chain to LOG and DROP spoofed packets" $EBTABLES -A bogus_ip --log-prefix " spoofed packet" $EBTABLES -A bogus_ip -j DROP I might see if I can do this with one set of rules in the PREROUTING chain. > I don't think you are being too paranoid, but > I think you should be aware of something I have > run in to in my own testing. . . . Yup - I noticed similar behavior. So this is how I'll handle it. eth0 gets an IP Address of 1.2.3.6 during normal bootup. And then when I do the brctl stuff, br0 gets 1.2.3.2. That way there's never a conflict between the physical and logical. All the physical interfaces have unique addresses so I can route based on the address when it makes sense, or bridge based on the interface when that makes sense. I'm feeling lots better about all this. Hopefully this discussion can help others out there. - Greg ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] Wan optimizations with linux
> I'm researching for WAN optimizations with linux. Are you doing lots of HTTP and SSL traffic to an internal website? If so, maybe it makes sense to put Squid on your remote sites. Squid is an open source web proxy and I know at least some of the commercial stuff depends on it. I've had good luck at a few sites doing Squid. - Greg Scott ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] What I learned about Linux bridging
> Although I'm not sure how well EBTables would be able > to filter addresses on a raw interface verses on the > bridge interface. I ran some tests and it seemed to work. Here is a little test script: #!/bin/sh /firewall-scripts/allow-all EBTABLES="/usr/local/sbin/ebtables" IPTABLES="/sbin/iptables" $EBTABLES -F $EBTABLES -A INPUT -i eth0 -j DROP $EBTABLES -A INPUT -i eth1 -j ACCEPT $EBTABLES -A INPUT -i eth2 -j ACCEPT #$IPTABLES -A FORWARD -i eth0 -j DROP #$IPTABLES -A FORWARD -i eth1 -j ACCEPT #$IPTABLES -A FORWARD -i eth2 -j ACCEPT #$IPTABLES -A INPUT -i eth0 -j DROP #$IPTABLES -A INPUT -i eth1 -j ACCEPT #$IPTABLES -A INPUT -i eth2 -j ACCEPT [EMAIL PROTECTED] gregs]# The IP Address for br0 is 1.2.3.2. I setup a system at 1.2.3.1 and had it ping 1.2.3.2. Everything behaved as expected. With bridging turned on, none of the iptables rules made any difference, so I commented them out. With the cable plugged into eth0, none of the pings replied. Tcpdump on the 1.2.3.2 box didn't even show anything coming into br0. Connecting to eth1 or eth2, pings replied and tcpdump showed the ICMP going back and forth on br0. Setting br0 to 1.2.3.2 and eth1 to 10.0.0.1, my external host could ping both IP Addresses when I fudged in appropriate routes on my test system. Here are a couple of my challenges. I want to block anything coming in from the Internet claiming to come from 10/8, or 172.16/12 or 192.168/16. But anything from these address blocks from any trusted eth-- interface should be OK. Easy to do with pure routing, seems a little more challenging with bridging. I think I can whip up some rules, but they depend on ebtables filtering by physical eth-- port. I have a public /24 block, call it 1.2.3.nnn. Some of these are on eth0, some on eth1, a few others on eth2. Bridging seems to handle this nicely. eth0 faces the Internet. I am a little nervous in packaging all this. Let's say something goes haywire in startup, before I run the brctl stuff. Or let's say something bad happens and bridging goes haywire. If eth0 has no IP Address, I have no remote access to the box. So I'd like to at least give an IP Address to eth0. This seems to work, but like I said, it's not documented to work. It just hit me what's bugging me - it bugs me to give an IP Address to a logical device and cut off any kind of fallback access to the physical device. Maybe I'm looking for trouble that's not there and creating problems I don't need just because bridging is so new in my little world. I wonder what others have done in this situation? And then there's my PPTP clients. I give these guys a 10.0.0.xxx IP Address with a gateway of 10.0.0.1. This was all part of the eth1 LAN when it was a pure router. I suppose in this bridging setup, I could make 10.0.0.1 an alias for br0 and leave eth1 with no IP Address. This just takes a little getting used to I guess. - Greg ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] What I learned about Linux bridging
Here are some notes I have about Linux bridging. I'll try to separate what I know I know from what I think I know. Let's say I want to bridge eth0, eth1, and eth2 together, all with an IP Address of, say, 1.2.3.2. This is how to do it: echo "Setting up br0 to bridge eth0 with eth1 and eth2" /usr/sbin/brctl addbr br0 /usr/sbin/brctl addif br0 eth0 /usr/sbin/brctl addif br0 eth1 /usr/sbin/brctl addif br0 eth2 /sbin/ip addr add 1.2.3.2/24 dev br0 /sbin/ip link set br0 up Continuing with the above example, most of the writeups also say to remove any IP Addresses from eth0, eth1, and eth2. But I've found this doesn't seem necessary - well, sort of. Let's say that eth0 is at IP Address 1.2.3.2, and now I bridge eth0, eth1, and eth2 together and give bridge br0 the same IP Address of 1.2.3.2. Now I have a mess because both eth0 and br0 have the same IP Address. Doing this: ip addr del 1.2.3.2/24 dev eth0 cleans up the mess. But let's say that physical interface eth1 has IP Address 10.0.0.1. >From testing, it looks like other systems can ping 10.0.0.1 just fine, assuming they have a route to it. So I **think** I know that I can assign an IP Address to a raw interface, as long as it's a different IP Address than what I assigned to the overall bridge. But I haven't seen this capability documented anywhere. Let's say the bridge is up and working at IP Address 1.2.3.2. I have a system at IP Address 1.2.3.1 connected via eth0. That system can ping 1.2.3.2 easily. If I disconnect the Ethernet cable from eth0 and plug into eth1 or eth2, after about 30 seconds, that bridged system begins answering pings again. As indicated in the writeups, that spare PC with a bunch of NICs is now acting like a managed Ethernet switch. Cool! Filtering iptables is a super-sophisticated toolset to filter IP packets. ebtables is another toolset to filter at the OSI layer 2 (datalink) layer. iptables concerns itself (mostly) with routing across an IP network, computer to computer. ebtables concerns itself (mostly) with filtering packets across physical NIC interfaces in the same computer. Here is a great writeup on using ebtables and iptables together: http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html But - like everything I've been able to find so far, I don't think this writeup is completely accurate. iptables has a module called physdev. According to the writeup, I can use the iptables physdev module to filter among the raw interfaces in a bridge. But a discussion in the netfilter list essentially says that physdev is being removed because it creates all kinds of other problems. At least, I think that's what it says. The relevant discussion took place in early July 2006. Here is a pointer to the beginning of the discussion: https://lists.netfilter.org/pipermail/netfilter-devel/2006-July/024896.h tml So it looks like when filtering at the network layer, (IP in this case) use iptables. When filtering at the data link layer, use ebtables and maybe arptables. Avoid using -m physdev in iptables because it's going away. You can add IP Addresses to bridged eth-- interfaces as long as they don't conflict with the bridge IP Address(es). Next up will be to try some filtering scenarios with ebtables and iptables. - Greg Scott ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] Proxy ARP with a Coyote Point equalizer
I was thinking about what Grant said in his earlier reply about bridging, and the more I think about it, the more I think Grant is right. I was watching tcpdump and some firewall accounting rules when we tried this the other day and I saw all kinds of traffic that had absolutely nothing to do with my network - and I was blocking it! And I kept wondering, why was I blocking traffic that had a destination IP address nowhere near me that I should not care about? Well, this is a co-location site, so an Ethernet connects this network to the Internet, not a point to point serial or any kind of WAN. No doubt lots of other folks had their networks in racks in the same room on the same extended Ethernet as my stuff. But still, why did my box care about any of this traffic at all? Why would I specifically block it - why didn't the NIC in my box just ignore it, the way most normal systems do in an Ethernet for traffic it doesn't care about? Well, duh! It's proxy ARP. Every time anyone, anywhere on this Ethernet, sends out an ARP request and I see it, I answer - yup, here is my MAC Address and it belongs to the IP Address you just asked about. I don't care what IP Address, I answer ARP requests for ALL IP Addresses! I was essentialy ARP spoofing the whole world! Well, at least the whole world on that Ethernet that morning. Holy moley - based on that analysis, proxy ARP should be outlawed from any co-location site, at least anything directly exposed to all the public traffic. For that few minutes, I'll bet I messed up systems belonging to who-knows-how-many customers! Fortunately, it was in the middle of the night in my corner of the world. For Gypsy - it's not my own ARP cache I was messing with, it was everyone else's ARP caches. Anyway, lesson learned. Maybe this writeup will help somebody else out there. Definitely do bridging. - Greg Scott -Original Message- From: gypsy [mailto:[EMAIL PROTECTED] Sent: Thursday, May 31, 2007 1:50 AM To: lartc@mailman.ds9a.nl Cc: Greg Scott Subject: Re: [LARTC] Proxy ARP with a Coyote Point equalizer Greg Scott wrote: > > Here is a puzzle. > > I have a network with several servers. It's a mess. It's a /24 and > pieces and servers are all over the place inside this /24 block, on > both sides of the firewall. For example, the router at 1.2.3.1 is > outside the firewall and many of the servers at 1.2.3.nnn/24 are > behind the firewall. (Obviously, 1.2.3.nnn is a fudged network.) > > eth0 points outward to the Internet. > eth1 points inward to the serers. > > Both eth0 and eth1 have IP Address 1.2.3.2. I setup proxy ARP like > this: > > echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp > echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp > > And I set up appropriate routes to the systems on both sides of the > firewall. > > This all works - all the systems route the way they are supposed to > route. > > Here is the problem. Behind the firewall is a Coyote Point Equalizer > at 1.2.3.10, with a high-volume website behind it spread across > several servers. Every time I put this proxy ARP firewall in place, > that nasty Coyote Point box dies and this breaks the high volume > website behind it and makes lots of people mad. I've never seen a > Coyote Point Equalizer but I have a hunch it might not get along well > with a proxy ARP device in its same network. > > Here are my questions: > > Proxy ARP really means proxy ARP - that firewall answers ARP requests > for anything and everything it sees, for any network. This also has > consequences for new devices that try to be polite when they set IP > Addresses for themselves by ARPing to see if anyone else answers at > that address. Is there a way to limit proxy ARP to a list of IP Addresses? > > Or - should I forget proxy ARP and look at bridging instead? Can I do > bridging and still access the bridged interfaces remotely? > > Thanks > > - Greg Scott > [EMAIL PROTECTED] See http://yesican.chsoft.biz/lartc/proxy-arp.conf and http://yesican.chsoft.biz/lartc/proxy-arp.sh to see if that helps. The LAN interface (eth0) uses the /proc-/proxy_arp setting while the WAN (eth1) interface uses the script. FWIW, those are my working setups. One computer has a WAN connection (eth1) and all other servers inside connect to its eth0. The above script and config file are on that computer. Note that both eth1 and eth0 have the same IP (66.209.101.198) and netmask. This machine has a third interface (eth2) to the LAN, but that is not material here. If the ISP changes things, which they have done a couple of times, I have to ask them to flush their ARP cache manually because their retention is HUGE (~70 minutes), but except for that, I've never had any problems with this setu
[LARTC] Proxy ARP with a Coyote Point equalizer
Here is a puzzle. I have a network with several servers. It's a mess. It's a /24 and pieces and servers are all over the place inside this /24 block, on both sides of the firewall. For example, the router at 1.2.3.1 is outside the firewall and many of the servers at 1.2.3.nnn/24 are behind the firewall. (Obviously, 1.2.3.nnn is a fudged network.) eth0 points outward to the Internet. eth1 points inward to the serers. Both eth0 and eth1 have IP Address 1.2.3.2. I setup proxy ARP like this: echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp And I set up appropriate routes to the systems on both sides of the firewall. This all works - all the systems route the way they are supposed to route. Here is the problem. Behind the firewall is a Coyote Point Equalizer at 1.2.3.10, with a high-volume website behind it spread across several servers. Every time I put this proxy ARP firewall in place, that nasty Coyote Point box dies and this breaks the high volume website behind it and makes lots of people mad. I've never seen a Coyote Point Equalizer but I have a hunch it might not get along well with a proxy ARP device in its same network. Here are my questions: Proxy ARP really means proxy ARP - that firewall answers ARP requests for anything and everything it sees, for any network. This also has consequences for new devices that try to be polite when they set IP Addresses for themselves by ARPing to see if anyone else answers at that address. Is there a way to limit proxy ARP to a list of IP Addresses? Or - should I forget proxy ARP and look at bridging instead? Can I do bridging and still access the bridged interfaces remotely? Thanks - Greg Scott [EMAIL PROTECTED] ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] FW: 2.6.17.1 compile error with a netfilter module
Woops - sorry everyone. I sent this to the wrong list. - Greg Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Scott Sent: Thursday, June 29, 2006 5:08 PM To: lartc@mailman.ds9a.nl Subject: [LARTC] FW: 2.6.17.1 compile error with a netfilter module Does anyone know what this means and how to fix it? I know it looks like a file named lockhelp.h is missing. What can I do to fix it? I tried to put in some POM patches from patch-o-matic-ng-20060624. Could this have been my problem? . . . CC [M] net/ipv4/ipvs/ip_vs_nq.o CC [M] net/ipv4/ipvs/ip_vs_ftp.o scripts/Makefile.build:52: kbuild: net/ipv4/netfilter/Makefile - Usage of export-objs is obsolete in 2.6. Please fix! LD net/ipv4/netfilter/built-in.o CC [M] net/ipv4/netfilter/ip_conntrack_standalone.o In file included from include/linux/netfilter_ipv4/ip_conntrack.h:32, from net/ipv4/netfilter/ip_conntrack_standalone.c:35: include/linux/netfilter_ipv4/ip_conntrack_talk.h:7:43: error: linux/netfilter_ipv4/lockhelp.h: No such file or directory In file included from include/linux/netfilter_ipv4/ip_conntrack.h:32, from net/ipv4/netfilter/ip_conntrack_standalone.c:35: include/linux/netfilter_ipv4/ip_conntrack_talk.h:10: warning: data definition has no type or storage class include/linux/netfilter_ipv4/ip_conntrack_talk.h:10: warning: type defaults to 'int' in declaration of 'DECLARE_LOCK_EXTERN' include/linux/netfilter_ipv4/ip_conntrack_talk.h:10: warning: parameter names (without types) in function declaration make[3]: *** [net/ipv4/netfilter/ip_conntrack_standalone.o] Error 1 make[2]: *** [net/ipv4/netfilter] Error 2 make[1]: *** [net/ipv4] Error 2 make: *** [net] Error 2 You have new mail in /var/spool/mail/root [EMAIL PROTECTED] linux]# [EMAIL PROTECTED] linux]# [ thanks - Greg Scott ___ 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
[LARTC] FW: 2.6.17.1 compile error with a netfilter module
Does anyone know what this means and how to fix it? I know it looks like a file named lockhelp.h is missing. What can I do to fix it? I tried to put in some POM patches from patch-o-matic-ng-20060624. Could this have been my problem? . . . CC [M] net/ipv4/ipvs/ip_vs_nq.o CC [M] net/ipv4/ipvs/ip_vs_ftp.o scripts/Makefile.build:52: kbuild: net/ipv4/netfilter/Makefile - Usage of export-objs is obsolete in 2.6. Please fix! LD net/ipv4/netfilter/built-in.o CC [M] net/ipv4/netfilter/ip_conntrack_standalone.o In file included from include/linux/netfilter_ipv4/ip_conntrack.h:32, from net/ipv4/netfilter/ip_conntrack_standalone.c:35: include/linux/netfilter_ipv4/ip_conntrack_talk.h:7:43: error: linux/netfilter_ipv4/lockhelp.h: No such file or directory In file included from include/linux/netfilter_ipv4/ip_conntrack.h:32, from net/ipv4/netfilter/ip_conntrack_standalone.c:35: include/linux/netfilter_ipv4/ip_conntrack_talk.h:10: warning: data definition has no type or storage class include/linux/netfilter_ipv4/ip_conntrack_talk.h:10: warning: type defaults to 'int' in declaration of 'DECLARE_LOCK_EXTERN' include/linux/netfilter_ipv4/ip_conntrack_talk.h:10: warning: parameter names (without types) in function declaration make[3]: *** [net/ipv4/netfilter/ip_conntrack_standalone.o] Error 1 make[2]: *** [net/ipv4/netfilter] Error 2 make[1]: *** [net/ipv4] Error 2 make: *** [net] Error 2 You have new mail in /var/spool/mail/root [EMAIL PROTECTED] linux]# [EMAIL PROTECTED] linux]# [ thanks - Greg Scott ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] Sip Traffic
Why not just prioritize everything that comes to/from that SIP phone? So forget about ports, just prioritize the IP Address? Use the IP Address to identify traffic you want to move with elevated priority. Just a thought... - Greg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Francisco Sent: Friday, April 21, 2006 10:17 PM To: lartc@mailman.ds9a.nl Subject: Re: [LARTC] Sip Traffic eMule detection works very well, this has really changed the way I use my upload bandwidth. El Jueves, 20 de Abril de 2006 23:25, Jason Boxman escribió: > On Thursday 20 April 2006 22:19, Francisco wrote: > > L7 filter works very well too: > > http://l7-filter.sourceforge.net/ > > > > Although I didn't try it with sip, I use it to control my P2P and server > > applications and have a very usable ADSL link at almost 100% utilization > > of my upstream. > > Does any of that include eMule traffic? I stopped having success with > eMule protocols and L7 a year or two ago and the pattern hasn't been > updated in ages. ___ 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
RE: [LARTC] Proxy ARP and UDP
I found the problem! It was me and it was dumb... This was the network layout: 10.10.10.0/24 1.2.3.0/27 10.10.10.n internal hosts | <+-+++---+-->to the Internet | || | Proxied || | H.323 device Firewall Router eth1 eth0 1.2.3.1110.10.10.1 1.2.3.2 1.2.3.1 1.2.3.2 The problem was, before doing proxy ARP, my h.323 device was set up with NAT and it had a 10.nnn IP Address. The outside interface on my firewall had 1.2.3.11 as a secondary address and NATed the appropriate stuff to the H.323 device. I changed all that to use proxy ARP - but I forgot to get rid of the secondary IP Address on eth0 of the firewall. I changed all my scripts but forgot to change that IP Address in the live, running system. Woops! - Greg Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Scott Sent: Monday, February 27, 2006 6:28 AM To: gypsy; lartc@mailman.ds9a.nl Subject: RE: [LARTC] Proxy ARP and UDP OK - Here is how I am running tcpdump. Not really much to tell. In one window: tcpdump -i eth1 -n And then in another window: tcpdump -i eth0 -n If I were filtering anything with tcpdump I would be pretty embarrassed. :) eth0 is the interface pointing to the Internet. eth1 is inside. For every several thousand packets that tcpdump shows me on eth1, I see maybe one or two on eth0 when running any traffic at all between the Internet and my proxy ARP'd device. Since these are conversations with a host on the other side of the Internet I should see packets flying across both interfaces. But I don't. I only see packets flying across the inside interface, except for a very small subset that I see on the outside interface. This behavior makes no sense. How is it possible that any connection between my proxy ARP'd host and the Internet works if virtually no traffic is moving across the outside interface The obvious answer - it isn't. Traffic must in fact be moving across the outside interface, otherwise my proxy ARP'd device would never see it. So the only possible conclusion is, the traffic must he happening someplace where tcpdump and evidently also the traffic shaping code does not see it. Don't believe me? Try it yourself. Send a bunch of pings from somewhere across the Internet to your proxy ARP'd device and watch your outside interface. I'll bet you don't see them. But your proxy ARP'd device will see them, assuming you have some firewall rules that allow this. It will reply and the requesting host outside the Internet will see the echo reply packets coming back. But your outside firewall interface will look dead even though the echo request/reply packets are clearly flying across it. Look for yourself if you don't believe me. Here is my traffic shaping script. Again, pretty basic stuff - nothing fancy. And it isn't relevant to my issue. TC="/sbin/tc" $TC qdisc del dev $INET_IFACE root $TC qdisc del dev $TRUSTED1_IFACE root $TC qdisc del dev $DMZ_IFACE root $TC qdisc add dev $INET_IFACE root handle 1: prio # This *instantly* creates classes 1:1, 1:2, 1:3 $TC qdisc add dev $TRUSTED1_IFACE root handle 2: prio # This *instantly* creates classes 2:1, 2:2, 2:3 $TC qdisc add dev $INET_IFACE parent 1:1 handle 11: pfifo $TC qdisc add dev $INET_IFACE parent 1:2 handle 12: pfifo $TC qdisc add dev $INET_IFACE parent 1:3 handle 13: pfifo $TC qdisc add dev $TRUSTED1_IFACE parent 2:1 handle 21: pfifo $TC qdisc add dev $TRUSTED1_IFACE parent 2:2 handle 22: pfifo $TC qdisc add dev $TRUSTED1_IFACE parent 2:3 handle 23: pfifo # # This assigns traffic to/from $PUBLIC_VTC1_IP and $PRIVATE_VTC1_IP # to the highest priority band of the queue for the appropriate # interface, and the rest to the next-highest proirity band. # # VTC1 $TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 1 u32 \ match ip dst $PUBLIC_VTC1_IP flowid 1:1 $TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 1 u32 \ match ip src $PUBLIC_VTC1_IP flowid 1:1 # VTC2 $TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 1 u32 \ match ip dst $PUBLIC_VTC2_IP flowid 1:1 $TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 1 u32 \ match ip src $PUBLIC_VTC2_IP flowid 1:1 # Everyone else $TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 2 u32 \ match ip src 0.0.0.0/0 flowid 1:2 $TC filter add dev $TRUSTED1_IFACE parent 2:0 protocol ip prio 2 u32 \ match ip src 0.0.0.0/0 flowid 2:2 exit > Greg, > >Please, if you want answers, provide enough information for us to help. > >In the absence of any shaping configuration script, it is useless to >speculate about why you see nothing being shaped. I will say that UDP >is not "protocol ip". Neither is AR
[LARTC] What happened to the lartc mailing list?
Title: What happened to the lartc mailing list? I see it is posting to the archive website but not emailing them out. Is anyone else getting emails or is it just me? Thanks - Greg Scott ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Router stops forwarding packets when MAC Address changes
Here's one that makes me scratch my head. I have a layout like this: 172.16.0.0/16 1.2.3.48/28 172.16.n.n (fictional public IP range) internal hosts | <+-+--++--+-->to the Internet ||| | Internal|| | Host Firewall Outside eth1eth0 Router 172.16.16.99 172.16.16.3 1.2.3.50 1.2.3.49 I want to use my own MAC addresses on all the firewall NICs. This way, I should be able to swap firewall systems without disturbing the ARP caches on the outside router or internal hosts. I do it like this: ifdown eth1 ifconfig eth1 hw ether 17:20:16:01:60:03 ifup eth1 Similarly for eth0. >From my internal host, ping 1.2.3.49. This works before switching MAC Addresses and fails after doing it. The internal host can ping the firewall at 172.16.16.3. The firewall can ping 1.2.3.49. But that firewall will not forward anything after giving its NICs my made-up MAC Addresses. When I put the MAC Addresses back to their "real" values, the firewll forwards again. >From the internal host, arp -a shows what it is supposed to show. The firewall is running 2.4.27 from kernel.org. I am using 3Com 3C905B NICs. /proc/sys/net/ipv4/ip_forward is 1. What am I missing? Why does changing MAC Addresses mess up forwarding? Thanks - Greg Scott ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] Proxy ARP and UDP
OK - Here is how I am running tcpdump. Not really much to tell. In one window: tcpdump -i eth1 -n And then in another window: tcpdump -i eth0 -n If I were filtering anything with tcpdump I would be pretty embarrassed. :) eth0 is the interface pointing to the Internet. eth1 is inside. For every several thousand packets that tcpdump shows me on eth1, I see maybe one or two on eth0 when running any traffic at all between the Internet and my proxy ARP'd device. Since these are conversations with a host on the other side of the Internet I should see packets flying across both interfaces. But I don't. I only see packets flying across the inside interface, except for a very small subset that I see on the outside interface. This behavior makes no sense. How is it possible that any connection between my proxy ARP'd host and the Internet works if virtually no traffic is moving across the outside interface The obvious answer - it isn't. Traffic must in fact be moving across the outside interface, otherwise my proxy ARP'd device would never see it. So the only possible conclusion is, the traffic must he happening someplace where tcpdump and evidently also the traffic shaping code does not see it. Don't believe me? Try it yourself. Send a bunch of pings from somewhere across the Internet to your proxy ARP'd device and watch your outside interface. I'll bet you don't see them. But your proxy ARP'd device will see them, assuming you have some firewall rules that allow this. It will reply and the requesting host outside the Internet will see the echo reply packets coming back. But your outside firewall interface will look dead even though the echo request/reply packets are clearly flying across it. Look for yourself if you don't believe me. Here is my traffic shaping script. Again, pretty basic stuff - nothing fancy. And it isn't relevant to my issue. TC="/sbin/tc" $TC qdisc del dev $INET_IFACE root $TC qdisc del dev $TRUSTED1_IFACE root $TC qdisc del dev $DMZ_IFACE root $TC qdisc add dev $INET_IFACE root handle 1: prio # This *instantly* creates classes 1:1, 1:2, 1:3 $TC qdisc add dev $TRUSTED1_IFACE root handle 2: prio # This *instantly* creates classes 2:1, 2:2, 2:3 $TC qdisc add dev $INET_IFACE parent 1:1 handle 11: pfifo $TC qdisc add dev $INET_IFACE parent 1:2 handle 12: pfifo $TC qdisc add dev $INET_IFACE parent 1:3 handle 13: pfifo $TC qdisc add dev $TRUSTED1_IFACE parent 2:1 handle 21: pfifo $TC qdisc add dev $TRUSTED1_IFACE parent 2:2 handle 22: pfifo $TC qdisc add dev $TRUSTED1_IFACE parent 2:3 handle 23: pfifo # # This assigns traffic to/from $PUBLIC_VTC1_IP and $PRIVATE_VTC1_IP # to the highest priority band of the queue for the appropriate # interface, and the rest to the next-highest proirity band. # # VTC1 $TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 1 u32 \ match ip dst $PUBLIC_VTC1_IP flowid 1:1 $TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 1 u32 \ match ip src $PUBLIC_VTC1_IP flowid 1:1 # VTC2 $TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 1 u32 \ match ip dst $PUBLIC_VTC2_IP flowid 1:1 $TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 1 u32 \ match ip src $PUBLIC_VTC2_IP flowid 1:1 # Everyone else $TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 2 u32 \ match ip src 0.0.0.0/0 flowid 1:2 $TC filter add dev $TRUSTED1_IFACE parent 2:0 protocol ip prio 2 u32 \ match ip src 0.0.0.0/0 flowid 2:2 exit > Greg, > >Please, if you want answers, provide enough information for us to help. > >In the absence of any shaping configuration script, it is useless to >speculate about why you see nothing being shaped. I will say that UDP >is not "protocol ip". Neither is ARP nor ICMP. > >In the absence of the parameters you are passing to tcpdump, nothing can >be said about why you are not seeing the expected traffic on the external IF. > >Run 'cat /proc/net/ip_conntrack | grep udp' > >There is nothing wrong with your .27 kernel! I have done something >similar to what you seem to be trying to do for years running kernels >from 2.4.25 through .32 and never had any problem at all with proxy ARP >(except for the mental part ;) >-- >gypsy ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] Proxy ARP and UDP
As it turns out, not seeing proxy ARP traffic on the outside interface has other consequences. I do some traffic shaping and noticed in my testing that the outbound traffic isn't being shaped. This drove me crazy until it suddenly dawned on me - tcpdump shows almost no traffic on the outside interface even though a full H.323 UDP stream is flying across the Internet to and from my proxy ARP'd device behind my firewall. I know lots of data is flying across both interfaces because I can see the results. Yet as far as any software is concerned, almost nothing is going in or out of my outside interface. Is this a normal proxy ARP behavior? Traffic is definitely flying across both interfaces. Why doesn't any software see traffic in and out of the outside interface? Should I try a newer kernel than 2.4.27? I guess I could shape the internal interface for anything routing across to the Internet but it just makes more sense to shape the interface at the boundary. Here is the network layout again: 10.10.10.0/27 1.2.3.0/27 10.10.10.n (fictional public IP range) internal hosts | <+-+++---+-->to the Internet | || | Proxied || | H.323 device Firewall Router eth1 eth0 1.2.3.1110.10.10.1 1.2.3.2 1.2.3.1 1.2.3.2 /proc/sys/net/ipv4/conf/eth0/proxy_arp is 1. /proc/sys/net/ipv4/conf/eth1/proxy_arp is 1. /proc/sys/net/ipv4/conf/eth0/rp_filter is 0. /proc/sys/net/ipv4/conf/eth1/rp_filter is 0. /proc/sys/net/ipv4/conf/ip_forward is 1. My firewall has a route to 1.2.3.11 dev eth1. - Greg Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Scott Sent: Monday, February 20, 2006 8:52 PM To: gypsy; lartc@mailman.ds9a.nl Subject: RE: [LARTC] Proxy ARP and UDP H - I turned off rp_filter (echo 0 > /proc/sys/net/ipv4/eth0/rp_filter - and eth1) and ran several test calls. It all worked. But I still don't understand why I see less than 1 percent of the packets on the eth0 interface with tcpdump. - Greg > but I bet the problem is rp_filter. > -- > gypsy ___ 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
RE: [LARTC] Proxy ARP and UDP
H - I turned off rp_filter (echo 0 > /proc/sys/net/ipv4/eth0/rp_filter - and eth1) and ran several test calls. It all worked. But I still don't understand why I see less than 1 percent of the packets on the eth0 interface with tcpdump. - Greg > but I bet the problem is rp_filter. > -- > gypsy ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Proxy ARP and UDP
Woops - my fat fingers hit the send key before I could put in a subject a minute ago. Hello - I am using kernel 2.4.27 and running into behavior I don't know how to explain. I have 2 relevant interfaces. eth0 is external, eth1 is internal. My internal LAN is 10.10.10.0/24. My External range is 1.2.3.0/27 (dummied up). I have an H.323 videoconference device inside my internal LAN, but at IP Address 1.2.3.11/27. (IP Address dummied up.) I want to proxy ARP this device. Both eth0 and eth1 on my firewall have IP Addresses 1.2.3.2/27. eth1 also has IP Address 10.10.10.1/24 and is the default gateway for all my internal hosts. The router outside my firewall is 1.2.3.1. So the network looks like this (apologies if email butchers my ASCII art): 10.10.10.0/27 1.2.3.0/27 10.10.10.n internal hosts | <+-+++---+-->to the Internet | || | Proxied || | H.323 device Firewall Router eth1 eth0 1.2.3.1110.10.10.1 1.2.3.2 1.2.3.1 1.2.3.2 /proc/sys/net/ipv4/conf/eth0/proxy_arp is 1. /proc/sys/net/ipv4/conf/eth1/proxy_arp is 1. My firewall has a route to 1.2.3.11 dev eth1. The host at 1.2.3.11 has a default GW of 1.2.3.1. This is where it gets weird. The H.323 device should exchange a few TCP packets with the far end and then thousands of UDP packets. And I should see this stream on the firewall watching both interfaces. I run tcpdump in two different windows on the firewall - one for eth1, the other for eth0. When I initiate an outbound H.323 call from the device at .11, tcpdump on the firewall shows TCP packets flying on eth1, but nothing on eth0 - almost all the time. Calls don't complete most of the time, although one call kind of completed. Watching on the firewall, I saw a TCP conversation on eth1, but nothing on eth0. Very strange! One time a call completed all the way and UDP started flying - as it should. I saw a few UDP packets on eth0 and lots (thousands) of UDP packets on eth1. For the call that really completed, I would expect to see thousasnds of UDP packets on both eth0 and eth1 - but instead saw only a few on eth0. This behavior happens even with no firewall filtering rules in place. My NATed 10.10.10.nn internal hosts work fine - in fact, my email server posting this item to the list is one of those hosts. The obvious question - why such an old kernel? Because it's worked for everything I need so far and every 2.6.nn I try has other bugs with one module or another. My questions - was proxy ARP broken in the 2.4.27 days? Why doen't tcpdump show me packets on both interfaces of the firewall? Am I missing a setup ingredient someplace? Should the default GW on that H.323 device be .2 (the firewall) or .1 (the Internet router)? Does mixing NAT and proxy ARP create problems? Should I put the H.323 device in its own little DMZ? Thanks - Greg Scott ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] (no subject)
Hello - I am using kernel 2.4.27 and running into behavior I don't know how to explain. I have 2 relevant interfaces. eth0 is external, eth1 is internal. My internal LAN is 10.10.10.0/24. My External range is 1.2.3.0/27 (dummied up). I have an H.323 videoconference device inside my internal LAN, but at IP Address 1.2.3.11/27. (IP Address dummied up.) I want to proxy ARP this device. Both eth0 and eth1 on my firewall have IP Addresses 1.2.3.2/27. eth1 also has IP Address 10.10.10.1/24 and is the default gateway for all my internal hosts. The router outside my firewall is 1.2.3.1. So the network looks like this (apologies if email butchers my ASCII art): 10.10.10.0/27 1.2.3.0/27 10.10.10.n internal hosts | <+-++ +---+-->to the Internet | | | | Proxied | | | H.323 device Firewall Router eth1 eth0 1.2.3.11 10.10.10.1 1.2.3.2 1.2.3.1 1.2.3.2 /proc/sys/net/ipv4/conf/eth0/proxy_arp is 1. /proc/sys/net/ipv4/conf/eth1/proxy_arp is 1. My firewall has a route to 1.2.3.11 dev eth1. The host at 1.2.3.11 has a default GW of 1.2.3.1. This is where it gets weird. The H.323 device should exchange a few TCP packets with the far end and then thousands of UDP packets. And I should see this stream on the firewall watching both interfaces. I run tcpdump in two different windows on the firewall - one for eth1, the other for eth0. When I initiate an outbound H.323 call from the device at .11, tcpdump on the firewall shows TCP packets flying on eth1, but nothing on eth0 - almost all the time. Calls don't complete most of the time, although one call kind of completed. Watching on the firewall, I saw a TCP conversation on eth1, but nothing on eth0. Very strange! One time a call completed all the way and UDP started flying - as it should. I saw a few UDP packets on eth0 and lots (thousands) of UDP packets on eth1. For the call that really completed, I would expect to see thousasnds of UDP packets on both eth0 and eth1 - but instead saw only a few on eth0. This behavior happens even with no firewall filtering rules in place. My NATed 10.10.10.nn internal hosts work fine - in fact, my email server posting this item to the list is one of those hosts. The obvious question - why such an old kernel? Because it's worked for everything I need so far and every 2.6.nn I try has other bugs with one module or another. My questions - was proxy ARP broken in the 2.4.27 days? Why doen't tcpdump show me packets on both interfaces of the firewall? Am I missing a setup ingredient someplace? Should the default GW on that H.323 device be .2 (the firewall) or .1 (the Internet router)? Does mixing NAT and proxy ARP create problems? Should I put the H.323 device in its own little DMZ? Thanks - Greg Scott ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] failover routing
Your script could have the backup router take on the IP Address of the primary after it loses its heartbeat. You'll run into a problem with ARP caches. I saw some code floating around earlier that allowed one box to listen to the MAC address of another and respond to its ARP requests. You would need to incorporate something like this in any solution. And this all assumes routers A and B are in parallel; all clients and both routers are on the same LAN. So you have a separate NIC between routers A and B for heartbeat. Each router has a NIC on the LAN side, and each has a NIC connecting to the Internet. - Greg Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jandre Olivier Sent: Wednesday, February 01, 2006 5:52 AM To: lartc@mailman.ds9a.nl Subject: [LARTC] failover routing Hi Guys, I would just like to have advice and pointers of the best way would be, Someting like BGP or OSPF? I have 2 internet connections at diffrent locations. let say connection A and B 1.) router A has a fast internet connection and a seperate interface for clients using /lan/pppoe/ipsec etc and another ethernet interface going to router B 2.) router B has similiar setup as router A and also a seperate ether interface for clients and one going to router A 3.) all clients gets masqueraded as there is limited amount of internet routable ips Now my first thought was to write some perl/bash scripts to just ping your internet gateway address of Router A and if its down, just change your default route to router B and everyone and vice versa and u can still get access. This way for me is not very clean though as Im the one writing the scripts as something like zebra might do this perfectly? just a basic idea of what my setup is. What would be my best way of doing this.? -- /*-* / __ _ -- / / (_)__ __ __ - --- / /__/ / _ \/ // /\ \/ / //_/_//_/\_,_/ /_/\_\ -- [EMAIL PROTECTED] ___ 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
RE: [LARTC] nat table remenbering nat's
> Well, at least the coneections belonging to NAT should be destroyed > because there is no authorization to these data flow anymore. > Don't you agree? Don't know. The Netfilter developers would have to answer that one. The netfilter guys have a userspace conntrack program that (I think) lets look at the conntrack database. And I think there are some data structures in the /proc filesystem. But I haven't dug into them. - Greg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ethy H. Brito Sent: Thursday, January 26, 2006 9:16 AM Cc: lartc@mailman.ds9a.nl Subject: Re: [LARTC] nat table remenbering nat's On Thu, 26 Jan 2006 08:58:34 -0600 "Greg Scott" <[EMAIL PROTECTED]> wrote: > No, it just flushes the rules and changes the policy to ACCEPT. The > connections are still connected. I do this all the time with > firewalls up and running. If flushing the rules killed all the active > connections, it would be super disruptive. Well, at least the coneections belonging to NAT should be destroyed because there is no authorization to these data flow anymore. Don't you agree? > > I suppose if you want to stop connections, flush the rules and then > set the policy to DROP - do 2 commands instead of just flushing. I did this. Stoped (flushed) all (I really mean all) rules and started them again with a diferent source adderss for NAT rules. My surprise was that that old NAT connection continued to flow despite the fact there was no rule at NAT filter for it. I suppose this old connection is still flowing because conntrack database state it as ESTABLISHED and it is grabbed by "ESTABLISHED, RELATED -j ACCEPT" rule. Did I made myself clear? I suppose that once a data flow is establisehd its conntrack database entry is only deleted if you or the other party kills the applications tha holds the connetions alive. BTW rebooting the machine stops the old data flow and only accepts the second (new) one. (unnecessary to say that rebooting clears the conntrack database, of course). > > Take what I say for what it's worth. I am not a netfilter developer, > just a long-time user. And so am I. Just a long-time user since ipfwadm. (Any developer reading this could please shed some like on this?) Ethy ___ 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
RE: [LARTC] nat table remenbering nat's
No, it just flushes the rules and changes the policy to ACCEPT. The connections are still connected. I do this all the time with firewalls up and running. If flushing the rules killed all the active connections, it would be super disruptive. I suppose if you want to stop connections, flush the rules and then set the policy to DROP - do 2 commands instead of just flushing. Take what I say for what it's worth. I am not a netfilter developer, just a long-time user. - Greg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ethy H. Brito Sent: Thursday, January 26, 2006 8:51 AM Cc: lartc@mailman.ds9a.nl Subject: Re: [LARTC] nat table remenbering nat's On Thu, 26 Jan 2006 08:22:51 -0600 "Greg Scott" <[EMAIL PROTECTED]> wrote: > Doesn't the policy change to ACCEPT after you flush the rules? Try an > iptables -L -v -n after doing iptables -F and see what the default > policy says. Yes it does. It changes to ACCEPT in all chains. So you are saying that I cannot stop the pre-established data flow because it will keep flowing because the default policy changed to ACCEPT updating the timout timer? But I flushed nat table. This should kill all conntrack entries related to the rules on this table. Ethy > > - Greg Scott > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ethy H. Brito > Sent: Thursday, January 26, 2006 8:09 AM > To: lartc@mailman.ds9a.nl > Subject: [LARTC] nat table remenbering nat's > > > Dear All > > Why NAT rules stays valid even if I flush nat anf table chains?? > > I have: > > iptables -P FORWARD DROP > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > iptables -A FORWARD -s SOME_IP -d SOME_BCP_5_IP --dport 1234 -j ACCEPT > iptables -i nat -A PREROUTING -s SOME_IP -d MY_INTERNET_IP \\ > --dport 1234 -j DNAT --to-destination SOME_BCP_5_IP > > The conection is established and the data is flowing normaly. > Suddenly I decide to not authorize this data flow anymore. So I > > iptables -t nat -F PREROUTING > iptables -F FORWARD > > For my surprise the data flow (observed with tcpdump) is still there! > It is like the state machine does not let go this data flow. > > What to do to block this data flow?? > Is there any way to flush the conntrack database? > > Regards > > -- > > Ethy H. Brito /"\ > InterNexo Ltda. \ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML > +55 (12) 3941-6860 X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL > S.J.Campos - Brasil / \ > ___ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- Ethy H. Brito /"\ InterNexo Ltda. \ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML +55 (12) 3941-6860 X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL S.J.Campos - Brasil / \ ___ 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
RE: [LARTC] nat table remenbering nat's
Doesn't the policy change to ACCEPT after you flush the rules? Try an iptables -L -v -n after doing iptables -F and see what the default policy says. - Greg Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ethy H. Brito Sent: Thursday, January 26, 2006 8:09 AM To: lartc@mailman.ds9a.nl Subject: [LARTC] nat table remenbering nat's Dear All Why NAT rules stays valid even if I flush nat anf table chains?? I have: iptables -P FORWARD DROP iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -s SOME_IP -d SOME_BCP_5_IP --dport 1234 -j ACCEPT iptables -i nat -A PREROUTING -s SOME_IP -d MY_INTERNET_IP \\ --dport 1234 -j DNAT --to-destination SOME_BCP_5_IP The conection is established and the data is flowing normaly. Suddenly I decide to not authorize this data flow anymore. So I iptables -t nat -F PREROUTING iptables -F FORWARD For my surprise the data flow (observed with tcpdump) is still there! It is like the state machine does not let go this data flow. What to do to block this data flow?? Is there any way to flush the conntrack database? Regards -- Ethy H. Brito /"\ InterNexo Ltda. \ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML +55 (12) 3941-6860 X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL S.J.Campos - Brasil / \ ___ 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
RE: [LARTC] FS: Cyclades PC300/TE2 Dual T1 Interface PCI Card For LinuxPC!
Title: Message I hope this isn't too far off topic. I did a little bit of pricing homework a few months ago on new T1 cards. The idea was to build a Linux based router/firewall. After all, Ethernet NICs are easily available for less than $10 today. But all the T1 cards I found cost a fortune. And about a year ago, I learned the list price for a complete Adtran Netvanta 3200 router with T1 card is in the $700 range. Cisco 17xx routers are considerably more expensive. With that kind of cost, I have a difficult time justifying the time and effort to build a Linux T1 router. Am I nuts? Does anyone know of an ongoing supply for low cost and reliable PCI <--> T1 cards? - Greg Scott -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian HammersteinSent: Monday, January 16, 2006 1:26 PMTo: lartc@mailman.ds9a.nlSubject: [LARTC] FS: Cyclades PC300/TE2 Dual T1 Interface PCI Card For LinuxPC! Hi. I have a Cyclades PC300/TE2 card that turns a Linux PC into a Dual T1 interface router. It is well made and high performance. I used it for a few years. It includes two T1 cables. Cyclades has gotten out of this business but the Linux kernel developer community supports this card so no additional driver is needed. It cost me $700+. I would like to sell it for about $300. Put this in a PC with Linux and you get a dual T1 router. Run BGP4 with freeware like Zebra. Way way cool. http://www.cyclades.com/products/6/pc300 http://www.cyclades.com/resources/?wp=6 http://www.kernel.org/pub/linux/utils/net/hdlc/#cards ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] routing decision based on sorce port
What's wrong with using iptables to mark the packets? That is what it's for... - Greg Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sebastian Heidl Sent: Friday, January 06, 2006 8:31 AM To: lartc@mailman.ds9a.nl Subject: [LARTC] routing decision based on sorce port Hello Routing Gurus ;-) I'd like to know if it's possible to make a routing decision for pakets originating from a specific port of the local machine without using ipfilter/iptables to mark the pakets. I read about the tc filter stuff but that seems only to be able to sort the pakets to a different queue on the same interface and not choose a different interface for example. Is that at all possible and if yes how ? regards, _sh_ ___ 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
RE: Fwd: [LARTC] Several IP's, one mail and http server
> What you proposed is kind of the thing I had in mind. Instead of all the > forwarding rules I use "echo 1 > /proc/sys/net/ipv4/ip_forward". Is the > additional checking you propose worth it? Even with the approach I proposed you still have to turn on ip_forward. If you're going to use multiple IP Addresses, somebody has to listen on all those addresses and the firewall is the right box to do it - that is its job. So then you set up appropriate DNAT, SNAT, and FORWARDing rules so the application servers only see traffic they are supposed to see. There are probably other ways to do it, but this is the way I use and it works well. Re: Postfix - I spent lots of time inside this book: Postfix, Richard Blum, Sams Publishing, 2001. I'll bet there's a newer edition out by now. - Greg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aleksander Sent: Tuesday, January 03, 2006 1:16 AM To: lartc@mailman.ds9a.nl Subject: Re: Fwd: [LARTC] Several IP's, one mail and http server Greg Scott wrote: >I wish! I've run across places that seem to check that the reverse DNS >matches the forward DNS name. I've seen it with Comcast and I gotta believe there are others doing it. It is a pain for me because I have to consume a precious IP Address for each email domain I host here. It may be possible that the big hosters know about each other and make special arrangements with each other to which little ol' me is not privvy. If anyone out there has any connections with the Comcast DNS people, I'd love to talk to you about this and other issues - but we're straying off the original topic. > >- Greg > > My mailservers will have their own reverse. ATM they don't and work fine too. It's not an issue. Sorry to hear you have to mess with that. What you proposed is kind of the thing I had in mind. Instead of all the forwarding rules I use "echo 1 > /proc/sys/net/ipv4/ip_forward". Is the additional checking you propose worth it? So the question, if I have to create virtual interfaces on the internal box should be answered "YES, that's the only way"? Have you had experience setting up postfix to work on several interfaces? I have an idea, how to make apache work, quite familiar with virtual hosts, but not postfix. It's not really a topic for this list though. Thanks, Alex Note: I seem to be missing the the first email of Greg, the one Robert quoted. No idea why, there's even no spam filtering at my end. Found it in the archives anyway. ___ 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
RE: Re[2]: Fwd: [LARTC] Several IP's, one mail and http server
>> IMHO it is not true. Novadays, it is required for a mail server to have a >> valid >> reverse dns record. But it doesn't have to point back to the same name. It >> would >> lead to very very poor IP space usage - eg. virtual hosting provider, which >> has >> 300 domains would need 300 IP's even if all of them are hosted on 1 machine, >> and number of domains can MUCH higher than all of the IPs. I wish! I've run across places that seem to check that the reverse DNS matches the forward DNS name. I've seen it with Comcast and I gotta believe there are others doing it. It is a pain for me because I have to consume a precious IP Address for each email domain I host here. It may be possible that the big hosters know about each other and make special arrangements with each other to which little ol' me is not privvy. If anyone out there has any connections with the Comcast DNS people, I'd love to talk to you about this and other issues - but we're straying off the original topic. - Greg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Kurjata Sent: Monday, January 02, 2006 4:02 PM To: lartc@mailman.ds9a.nl Subject: Re[2]: Fwd: [LARTC] Several IP's, one mail and http server W Twoim liście datowanym 2 stycznia 2006 (18:51:25) można przeczytać: GS> You want multiple IP Addresses for email if you are hosting more GS> than one domain. The reason is, everyone now checks for reverse DNS GS> with email so you need a different public IP Address for each email GS> domain. This way, all the reverse DNS translations will be unique. IMHO it is not true. Novadays, it is required for a mail server to have a valid reverse dns record. But it doesn't have to point back to the same name. It would lead to very very poor IP space usage - eg. virtual hosting provider, which has 300 domains would need 300 IP's even if all of them are hosted on 1 machine, and number of domains can MUCH higher than all of the IPs. mail.domainA.com - WW.XX.YY.ZZ ZZ.YY.XX.WW.in-addr.arpa PTR - host.domainB.com host.domainB.com - WW.XX.YY.ZZ for an egzample one of the bigest portals - yahoo: dig yahoo.com MX - mx1.mail.yahoo.com - 67.28.113.10, 67.28.113.11 dig 10.113.28.67.in-addr.arpa PTR - mta-v4.level3.mail.yahoo.com. dig mta-v4.level3.mail.yahoo.com. - 67.28.113.10 Citation from one of the mail server manuals: If you have a PTR record for your IP address, and the target of the PTR record has an A record pointing back to that same IP address, mail will not be rejected from your server due to an invalid PTR. -- Pozdrowienia, Robert Kurjata ___ 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
RE: Fwd: [LARTC] Several IP's, one mail and http server
IVATE_EMAIL2_IP $IPTABLES -t nat -A PREROUTING -i eth0 -d $PUBLIC_EMAIL2_IP \ -p tcp --dport 143 -j DNAT --to $PRIVATE_EMAIL2_IP Note that you can inmprove on the rules in the FORWARD chain. You'll want to test for RELATED and ESTABLISHED and not just blindly ACCEPT incoming packets on those ports. Think about jumping to a user defined table that tests for this instead of directly to ACCEPT. - Greg Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aleksander Sent: Monday, January 02, 2006 10:08 AM To: lartc@mailman.ds9a.nl Subject: Re: Fwd: [LARTC] Several IP's, one mail and http server Edmundo Carmona wrote: >There was a typo. It was DNAT, and not DAN > >-- Forwarded message -- >From: Edmundo Carmona <[EMAIL PROTECTED]> >Date: Jan 2, 2006 11:47 AM >Subject: Re: [LARTC] Several IP's, one mail and http server >To: lartc > > >If I understand correctly, the server is not directly connected to the >internet, right? > >There are some boxes connected to the internet instead... am I right? > > One connection, several IP addrs with their own host names. One gateway with these several external IPs. The gateway has one internal IP too, of course. The gateway does SNAT for the internal LAN. Clients connect to the gateway using different hostnames and therefore different IP's. They are connecting to a webserver, which is in the internel LAN. They can connect thanks to DNAT (one DNAT for each IP to the same box in the LAN). When the server on the internal LAN answers the requests, his external IP is assigned by the SNAT rule. If that external IP is not the same as the one to which the client connected, the client will drop the servers responses --- they come from a different IP, as he connected to in the first place. The only way I see to make it work would have apache to use IP based virtual hosts. That requires virtual interfaces, correct? By clients I mean random users all over the Internet who connect to different IPs on the same gateway. How other machines in the LAN connect to the webserver using valid hostnames is another business, easily resolved with DNS zones. Hope you can figure this out. Thanks for interest, I'll be back tomorrow. Alex ___ 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
RE: [LARTC] Optimizing linux for the routing of realtime video
Title: Message Are you sending anything else besides the H.263 stream over that wireless link? As an earlier reply mentioned, your problem could be related to radio issues - and if so, nothing you can do about it. Well maybe there is. You would need something that would watch the queue of outbound H.263 packets and get rid of anything older than (some number) of milliseconds. I don't know of any packages that do this. If the issue is contention with other packet streams from other apps inside your network, then you can prioritize the H.263 stuff so that these packets tend to the top of the outbound queue. - Greg Scott -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin ToddSent: Tuesday, November 29, 2005 1:03 PMTo: lartc@mailman.ds9a.nlSubject: [LARTC] Optimizing linux for the routing of realtime video I'm currently trying to optimize a linux machine which acts as a Layer 3 router of RTP H.263 video. Occassionally I'll get delays related to layer 2 wireless retries, thus rendering the video on the recieving end stale/useless.Is there way to optimize a linux machine to route realtime video? In my case, losing a few frames of H.263 is better than having the video delayed for 5 seconds (H.263 has its own methods for error concealing which work pretty good).As far as I know, there are a few things I could do:- Sysctl options allow for some minimal TCP/IP stack configuration- iptables?- tc?Basically, I need some way to discard old data thats sitting in the transmit queue.Regards,Justin ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] Very simple traffic shaping script for H.323
Yup, Andy is right. This is traffic to/from the Internet. After brooding all day about this, my simple scheme to set TOS bits and let nature take its course had major holes: (1) Other apps could set the same TOS bits to any value they want, and those apps would slog it out with my H.323 stuff. Some apps, such as telnet, ssh, and others behave this way by default. This is not good. (2) I could not come up with any way to see what bands the packets were really going to anyway. So I could have the best settings in the world, but with no way to monitor them, they are useless. I needed a way to really control which packets go to what queues and I need a mechanism to monitor the results. So I threw everything out and started over again. Here's the latest script: Thanks to Bert H for that howto. I lifted code directly from chapter 9 and I'm standing on the shoulders of a giant. I set up PRIO qdiscs on each interface and even waded into some details around the u32 filter. Each PRIO qdisc has 3 bands. I set up PFIFO qdiscs for each band. The idea is, traffic will flow with its default behavior within each band. So traffic to/from the VTC device will hopefully honor the TOS bits inside its band, and lower priority traffic will also sort itself out within its band. If I'm reading all the documentation correctly, that's what PFIFO is supposed to do, right? I got really gutsy and used U32 for my filter. I may change this to use FWMARK later on. I read that U32 is the fastest filter - and this is good. But I couldn't come up with a good way to directly monitor which packets hit what filter. But if I use FWMARK, I can log packets for debuggig purposes, and I track exactly which packets trigger what filter if I want. This would be extremely useful for debugging. With U32, the best I can do is watch the end result by looking at qdisc statistics. But I haven't found a direct way to tell which filter sent what packets to which band. Well, here is the script. If anyone else is trying to shape H.323, I would love to hear your ideas. [EMAIL PROTECTED] firewall-scripts]# more priotest3.sh #!/bin/sh # Useful commands: # # $TC qdisc show Show the various qdiscs # $TC -s qdisc ls dev eth0 Show packet stats on eth0 # $TC filter show Show filters # $TC qdisc del dev eth0 root Set eth0 back to its defaults # # This script sets up 3 band PRIO qdiscs on both the external and # internal interfaces. Each band, in turn, has a PFIFO qdisc. # I chose PFIFO qdiscs in each band to preserve default behavior # within each band. Any traffic to/from the VTC device is # directed to the highest priority PRIO band. Hopefully, within # that band, the trafic follows default behavor and prioritizes # according to the TOS bits set by the application. # Everything else goes to the next priority band, # which should also follow default behavior within that # band. The idea is, we want the VTC traffic to get the highest # priority service, no matter what. Everything else should # follow default behavior, underneath the VTC flow. # # Greg Scott May 31, 2005 # IPTABLES="/usr/local/sbin/iptables" TC="/sbin/tc" INET_IFACE="eth0" TRUSTED1_IFACE="eth1" VTC1_PUBLIC="abc.def.ghi.jkl" VTC1_PRIVATE="192.168.16.4" $TC qdisc del dev $INET_IFACE root $TC qdisc del dev $TRUSTED1_IFACE root $TC qdisc add dev $INET_IFACE root handle 1: prio # This *instantly* creates classes 1:1, 1:2, 1:3 $TC qdisc add dev $TRUSTED1_IFACE root handle 2: prio # This *instantly* creates classes 2:1, 2:2, 2:3 $TC qdisc add dev $INET_IFACE parent 1:1 handle 11: pfifo $TC qdisc add dev $INET_IFACE parent 1:2 handle 12: pfifo $TC qdisc add dev $INET_IFACE parent 1:3 handle 13: pfifo $TC qdisc add dev $TRUSTED1_IFACE parent 2:1 handle 21: pfifo $TC qdisc add dev $TRUSTED1_IFACE parent 2:2 handle 22: pfifo $TC qdisc add dev $TRUSTED1_IFACE parent 2:3 handle 23: pfifo # # This assigns traffic to/from $VTC1_PUBLIC and $VTC1_PRIVATE # to the highest priority band of the queue for the appropriate # interface, and the rest to the next-highest proirity band. # $TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 1 u32 \ match ip dst $VTC1_PUBLIC flowid 1:1 $TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 1 u32 \ match ip src $VTC1_PUBLIC flowid 1:1 $TC filter add dev $TRUSTED1_IFACE parent 2:0 protocol ip prio 1 u32 \ match ip src $VTC1_PRIVATE flowid 2:1 $TC filter add dev $TRUSTED1_IFACE parent 2:0 protocol ip prio 1 u32 \ match ip dst $VTC1_PRIVATE flowid 2:1 $TC filter add dev $INET_IFACE parent 1:0 protocol ip prio 2 u32 \ match ip src 0.0.0.0/0 flowid 1:2 $TC filter add dev $TRUSTED1_IFACE parent 2:0 protocol ip prio 2 u32 \ match ip src 0.0.0.0/0 flowid 2:2 [EMAIL PROTECTED] firewall-scripts]# -Original Message- From: Andy Furniss [mailto:[EMAIL PROTECTED] Sent: Monda
RE: [LARTC] Very simple traffic shaping script for H.323
I may have the answer to my own questions: (1) When the value for the DSCP field for EF (Expedited Flow) is hex 2E, why does tcpdump display it as hex B8? I think there's some bit shifting going on. The DSCP field is the left most 6 bits of the DS octet in the packet header. 2E is 0010 1110. But really, we only care about the leftmost 6 bits, so it's really 10 1110. I'll bet tcpdump displays the whole octet, not just those 6 bits. The rightmost bits are 0. So add them on to the right and it's 10 1110 00. Or, putting it together like hex digits, 1011 1000, or hex b8. And, sure enough, this is what tcpdump shows me. So it's gotta be that tcpdump displays the whole DS octet, but it confuses me by calling it tos. (2) Assuming the tos value tcpdump shows me makes sense, why do some packets in the tcpdump output stream show tos values and others don't? This just hit me. Examining the output more closely, the packets do NOT show tos values are inbound. The packets that DO show tos values are outbound. As I think about it, this kind of makes sense. TCPDUMP puts the NIC in promiscous mode and listens directly to it. So it grabs and displays inbound packets right off the NIC, before they ever get into the kernel. i.e. - tcpdump displays them before the kernel puts in those bits in the mangle table. Outbound is opposite. On the way out, the packets have gone through all the kernel processing and now they're on their way out. So outbound packets will show the tos values because my firewall rules put them in. Cool! It also occurs to me, I can test this by looking at the internal interface, which moves packets to/from the internal LAN. If my theory is correct, and given the rules in my little script, then I should see the opposite behavior. Outbound packets should NOT show a tos value, and inbound from the Internet should show the tos value my firewall rules put in, shiftet by 2 bits. So trying my little experiment, the results are not exactly what I expected, but they still fit the theory: [EMAIL PROTECTED] firewall-scripts]# /usr/sbin/tcpdump -i eth1 host 192.168.16.4 -n tcpdump: listening on eth1 . . . 15:57:15.244738 mno.pqr.stu.vwx.3230 > 192.168.16.4.3230: udp 92 [tos 0xb8] 15:57:15.268208 192.168.16.4.3232 > mno.pqr.stu.vwx.3232: udp 219 [tos 0x80] 15:57:15.298114 192.168.16.4.3230 > mno.pqr.stu.vwx.3230: udp 92 [tos 0xa0] 15:57:15.310663 192.168.16.4.3231 > mno.pqr.stu.vwx.3231: udp 64 15:57:15.338424 192.168.16.4.3232 > mno.pqr.stu.vwx.3232: udp 427 [tos 0x80] 15:57:15.358067 192.168.16.4.3230 > mno.pqr.stu.vwx.3230: udp 92 [tos 0xa0] . . . 452 packets received by filter 0 packets dropped by kernel [EMAIL PROTECTED] firewall-scripts]# I think I know what's going on. The near-end H.323 device has its own QOS settings and I'll bet it's putting these in when it asembles IP packets. H.323 has a bunch of separate sub-conversations, including audio, video, and remote camera control. When I look at the settings on the device, each of these has its own QOS value. The far-end device has all its QOS stuff turned off. So the internal interface has QOS stuff already set when each packet hits the NIC. Of course, the firewall replaces these with its own QOS values in the mangle table later on, but we don't see that yet for outbound packets. If anyone has waded through all this, am I making sense? Also, now that I'm convinced I really am writing the DSCP values I want, how do I know whether the packets really go into that first priority PFIFO band? Thanks - Greg Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Scott Sent: Monday, May 30, 2005 10:10 AM To: lartc@mailman.ds9a.nl Subject: RE: [LARTC] Very simple traffic shaping script for H.323 Maybe my idea from the other day isn't so simple. When I run tcpdump and watch my h.323 packet stream, tcpdump shows a stream that looks like this: . . . 09:16:09.031943 abc.def.ghi.jkl.3230 > mno.pqr.stu.vwx.3230: udp 92 [tos 0xb8] 09:16:09.048128 mno.pqr.stu.vwx.3230 > abc.def.ghi.jkl.3230: udp 92 09:16:09.071137 abc.def.ghi.jkl.3232 > mno.pqr.stu.vwx.3232: udp 245 [tos 0xb8] 09:16:09.071535 abc.def.ghi.jkl.3232 > mno.pqr.stu.vwx.3232: udp 245 [tos 0xb8] 09:16:09.076762 mno.pqr.stu.vwx.3232 > abc.def.ghi.jkl.3232: udp 262 . . . where abc.dev... is the IP Addr of the listening H.323 device and mno.pqr... is the IP Addr of the calling system. This spawns 2 questions. First, what's up with the tos bits? The TOS field is only 5 bits and it's obsolete anyway, so clearly when tcpdump shows tos bits it must mean something else. Is tcpdump showing me the whole DS octet? Or the leftmost 6 bits of the DS octet? Or what? From what I've been reading, that DS octet has been carved up so many different ways over the years that I am now hopelessly confused. Next, why don&
RE: [LARTC] Very simple traffic shaping script for H.323
Maybe my idea from the other day isn't so simple. When I run tcpdump and watch my h.323 packet stream, tcpdump shows a stream that looks like this: . . . 09:16:09.031943 abc.def.ghi.jkl.3230 > mno.pqr.stu.vwx.3230: udp 92 [tos 0xb8] 09:16:09.048128 mno.pqr.stu.vwx.3230 > abc.def.ghi.jkl.3230: udp 92 09:16:09.071137 abc.def.ghi.jkl.3232 > mno.pqr.stu.vwx.3232: udp 245 [tos 0xb8] 09:16:09.071535 abc.def.ghi.jkl.3232 > mno.pqr.stu.vwx.3232: udp 245 [tos 0xb8] 09:16:09.076762 mno.pqr.stu.vwx.3232 > abc.def.ghi.jkl.3232: udp 262 . . . where abc.dev... is the IP Addr of the listening H.323 device and mno.pqr... is the IP Addr of the calling system. This spawns 2 questions. First, what's up with the tos bits? The TOS field is only 5 bits and it's obsolete anyway, so clearly when tcpdump shows tos bits it must mean something else. Is tcpdump showing me the whole DS octet? Or the leftmost 6 bits of the DS octet? Or what? From what I've been reading, that DS octet has been carved up so many different ways over the years that I am now hopelessly confused. Next, why don't all packets show a tos field? My iptables rules should put a value in the DS octet for everything to/from that IP Address (see below). So why aren't they in there? Here are some test results. In the test below, the conversation used 768 packets. Yet it only set the DSCP bits in 472 packets. And tcpdump shows a different value anyway. What's going on here (Note that I modified the script from last night slightly as a troubleshooting step. That's why there are 4 rules below instead of two rules.) [EMAIL PROTECTED] firewall-scripts]# /usr/sbin/tcpdump -i eth0 host abc.def.ghi.jkl -n . . . 768 packets received by filter 0 packets dropped by kernel [EMAIL PROTECTED] firewall-scripts]# /usr/local/sbin/iptables -L -v -n -t mangle Chain PREROUTING (policy ACCEPT 25M packets, 14G bytes) pkts bytes target prot opt in out source destination 293 64981 DSCP all -- * * 192.168.16.4 0.0.0.0/0 DSCP set 0x2e 0 0 DSCP all -- * * 0.0.0.0/0 192.168.16.4DSCP set 0x2e 0 0 DSCP all -- * * abc.def.ghi.jkl 0.0.0.0/0 DSCP set 0x2e 179 36722 DSCP all -- * * 0.0.0.0/0 abc.def.ghi.jkl DSCP set 0x2e Here is the exact script that generated the rules above: [EMAIL PROTECTED] firewall-scripts]# more vtc-ds.sh #!/bin/sh VTC1_PRIVATE="192.168.16.4" VTC1_PUBLIC="abc.def.ghi.jkl" IPTABLES="/usr/local/sbin/iptables" $IPTABLES -t mangle -F $IPTABLES -t mangle -A PREROUTING -s $VTC1_PRIVATE -j DSCP --set-dscp-class EF $IPTABLES -t mangle -A PREROUTING -d $VTC1_PRIVATE -j DSCP --set-dscp-class EF $IPTABLES -t mangle -A PREROUTING -s $VTC1_PUBLIC -j DSCP --set-dscp-class EF $IPTABLES -t mangle -A PREROUTING -d $VTC1_PUBLIC -j DSCP --set-dscp-class EF [EMAIL PROTECTED] firewall-scripts]# - Greg Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Scott Sent: Sunday, May 29, 2005 11:15 PM To: lartc@mailman.ds9a.nl Subject: [LARTC] Very simple traffic shaping script for H.323 Hello - What I want to do seems very simple - I want to make sure any H.323 traffic gets processed before anything else entering or leaving this network. The network has a videoconferencing device on the LAN at 192.168.16.4. A Linux firewall NATs an external IP Address to this internal address and I have appropriate SNAT and DNAT rules that work. The NAT and connection tracking rules all work great. Now I need to make sure other traffic in and out of this network does not interfere with the H.323 flow. After pouring over several RFCs, Howto documents, and lots of other documentation, I think this very simple script will do the trick. The theory - by default, all interfaces have a classless PFIFO queue with three bands. So all I need to do is set the appropriate DS bits in the packet header to the EF (Expedited Forward) value and everything else will just work. Linux will put the packets in the top PFIFO priority band and they'll go thru my Firewall at Warp 9.9 regardless of other traffic from other users. Assumptions: (1) I don't care about slowing down other traffic flows. H.323 packets should be serviced first no matter what. (2) Any traffic with source or destination public IP Address "abc.def.ghi.jkl" or private IP Address 192.168.16.4 is to/from from the videoconference device. After all the reading and studying, is it really this simple? Does anyone have ideas on how to test this? How do I watch packets to see which packets go into what PFIFO band? #!/bin/sh VTC1_PRIVATE="192.168.16.4" VTC1_PUBLIC="abc.def.ghi.jkl" IPTABLES="/usr/local/sbin/iptables" $IPTABLES -t mangle -F $IPTABLES -t mangle -A PREROUTING -s $V
[LARTC] Very simple traffic shaping script for H.323
Hello - What I want to do seems very simple - I want to make sure any H.323 traffic gets processed before anything else entering or leaving this network. The network has a videoconferencing device on the LAN at 192.168.16.4. A Linux firewall NATs an external IP Address to this internal address and I have appropriate SNAT and DNAT rules that work. The NAT and connection tracking rules all work great. Now I need to make sure other traffic in and out of this network does not interfere with the H.323 flow. After pouring over several RFCs, Howto documents, and lots of other documentation, I think this very simple script will do the trick. The theory - by default, all interfaces have a classless PFIFO queue with three bands. So all I need to do is set the appropriate DS bits in the packet header to the EF (Expedited Forward) value and everything else will just work. Linux will put the packets in the top PFIFO priority band and they'll go thru my Firewall at Warp 9.9 regardless of other traffic from other users. Assumptions: (1) I don't care about slowing down other traffic flows. H.323 packets should be serviced first no matter what. (2) Any traffic with source or destination public IP Address "abc.def.ghi.jkl" or private IP Address 192.168.16.4 is to/from from the videoconference device. After all the reading and studying, is it really this simple? Does anyone have ideas on how to test this? How do I watch packets to see which packets go into what PFIFO band? #!/bin/sh VTC1_PRIVATE="192.168.16.4" VTC1_PUBLIC="abc.def.ghi.jkl" IPTABLES="/usr/local/sbin/iptables" $IPTABLES -t mangle -F $IPTABLES -t mangle -A PREROUTING -s $VTC1_PRIVATE -j DSCP --set-dscp-class EF $IPTABLES -t mangle -A PREROUTING -d $VTC1_PUBLIC -j DSCP --set-dscp-class EF thanks - Greg Scott ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] Multihome routing question
I'll take a stab at this . . . Try a traceroute to your ISP's DNS server or even the ISP's gateway to you. (This is the next hop beyond your onsite gateway to the world.) This will tell you what interface your stuff chooses when you want to go out to the public Internet. Also check your firewall rules on this box (iptables -L -v -n) to see if you're blocking anything. And also look to see if you have any alternate routing tables going on (ip rule list and stuff like that). - Greg Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, January 30, 2004 3:06 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [LARTC] Multihome routing question Hello, I am new to network routing and I need help configuring a linux box with two ethernet cards. In this case it's a Linux RH 7.3 box, in a cabinet that already has a couple of Windows servers. The Windows server routing is below as an example. The Linux box has an out-of-band interface at 10.130.36.38 and a public eth at 62.50.8.84. I had to add a route for the private interface so I could access its ports. However, since I did that, the Linux box cannot access the internet. The incoming requests to 62.50.8.84 are fine, I can hit the web service fine, but the net is not visible from the linux box. I think it's just a matter of adding a route but am not sure how. Interestingly enough I can ping the outside machines but cannot browse over the net. I remember that this worked fine before I added the route to the private interface, so it must be a routing problem and not some other issue. The Linux routing table: [EMAIL PROTECTED] root]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 62.50.8.80 0.0.0.0 255.255.255.248 U 0 00 eth0 10.130.36.320.0.0.0 255.255.255.240 U 0 00 eth1 172.17.1.0 10.130.36.34255.255.255.240 UG0 00 eth1 10.0.0.010.130.36.33255.0.0.0 UG0 00 eth1 127.0.0.0 0.0.0.0 255.0.0.0 U 0 00 lo 0.0.0.0 62.50.8.81 0.0.0.0 UG0 00 eth0 [EMAIL PROTECTED] root]# ip route 62.50.8.80/29 dev eth0 scope link 10.130.36.32/28 dev eth1 scope link 172.17.1.0/28 via 10.130.36.34 dev eth1 10.0.0.0/8 via 10.130.36.33 dev eth1 127.0.0.0/8 dev lo scope link default via 62.50.8.81 dev eth0 The Windows server routing, which works fine: [c:\4nt]route PRINT === Interface List 0x1 ... MS TCP Loopback interface 0x2 ...44 45 53 54 42 00 .. NOC Extranet Access Adapter 0x104 ...00 0b cd 1c 99 84 .. Compaq NC7780 Gigabit Server Adapter 0x105 ...00 0b cd 1c 96 95 .. Compaq NC7780 Gigabit Server Adapter === === Active Routes: Network DestinationNetmask Gateway Interface Metric 0.0.0.0 0.0.0.0 62.50.8.81 62.50.8.83 1 10.0.0.0255.0.0.0 10.130.36.3310.130.36.36 1 10.130.36.32 255.255.255.240 10.130.36.3610.130.36.36 1 10.130.36.36 255.255.255.255127.0.0.1 127.0.0.1 1 10.255.255.255 255.255.255.255 10.130.36.3610.130.36.36 1 62.50.0.221 255.255.255.255 10.130.36.3310.130.36.36 1 62.50.0.222 255.255.255.255 10.130.36.3310.130.36.36 1 62.50.8.80 255.255.255.248 62.50.8.83 62.50.8.83 1 62.50.8.83 255.255.255.255127.0.0.1 127.0.0.1 1 62.255.255.255 255.255.255.255 62.50.8.83 62.50.8.83 1 127.0.0.0255.0.0.0127.0.0.1 127.0.0.1 1 172.17.1.0 255.255.255.240 10.130.36.3410.130.36.36 1 224.0.0.0224.0.0.0 10.130.36.3610.130.36.36 1 224.0.0.0224.0.0.0 62.50.8.83 62.50.8.83 1 255.255.255.255 255.255.255.255 62.50.8.83 2 1 Default Gateway:62.50.8.81 === Persistent Routes: Network Address Netmask Gateway Address Metric 10.0.0.0255.0.0.0 10.130.36.33 1 62.50.0.221 255.255.255.255 10.130.36.33 1 62.50.0.222 255.255.255.255 10.130.36.33 1 172.17.1.0 255.255.255.240 10.130.36.34 1 Any help would be appreciated. Eduard ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://ma
RE: [LARTC] Multiple rate limited networks and transparent http proxy - tricky problem
Wouldn't stuff coming from Squid have a defined source port number? If so, would a fwmark on all packets from that IP Address and Squid's TCP source port do the trick? - Greg Scott -Original Message- From: Aaron A. Wolfe [mailto:[EMAIL PROTECTED]] Sent: Monday, December 23, 2002 3:40 PM To: [EMAIL PROTECTED] Subject: [LARTC] Multiple rate limited networks and transparent http proxy - tricky problem Hello, We have a box with good connectivity which we divide among several internal networks by having a different interface for each internal network and rate limiting outgoing traffic on each of these interfaces. We are using cbq and a u32 match on the destination to organize the packets. This works very well for us, but there may be a better way, I'm no expert at this! We also use a squid proxy set up in transparent mode with a NAT rule to send all outgoing http requests to the proxy. This also works very well to save some of our bandwidth. My "problem" is that of course the rate limiting applies to *all* traffic going out the internal interfaces, so even objects that are in the squid cache are given to the clients at a fairly slow speed. I am trying to figure out a way to allow cached objects to be sent at full ethernet speed while still rate limiting objects that have to be fetched from the internet. It is puzzling to me because I cannot differentiate cached and noncached data coming from squid at the packet level. I was actually think about a quick hack on Squid to set some qos or other bit in the tcp headers for connections containting cached objects but this is probably beyond my limited skills. I havent found anyone on the web doing something similar in a quick search. The other theory I had was to limit the traffic on it's way to squid rather than after.. This would eliminate the need to distinguish between cache and noncache post squid. The problem here is how do I apply the different rate limits to the different internal networks, since all incoming traffic will be bound for the squid proxy not the destination clients. I have considered creating several external interfaces, running a separate squid for each internal network and having each squid use a different outgoing interface.. This allows what I want I think but gets very complicated, and I'm not sure if I can have all the instances share a cache directory.. If not the usefulness of the cache is quite limited. Any thoughts on this are much appreciated! -Aaron ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] Can't keep up with all these file sharing programs!
You could try a completely different approach: First, set up an iptables rule that redirects anything outbound that's port 80 or 20 or 21 to, say, squid or some other proxy server. Then block **everything** else going out. So for the outbound web stuff, get one of the commercial filtering packages and put that on top of the proxy server redirected above. That will do the layer 7 filtering within the context of outbound web access and will block inappropriate sites. This will also solve your Kazaah du jor problem cuz nothing will go out except legit web and ftp stuff. Just a thought - facing similar issues myself. I don't think you can fight this problem with low level traffic shaping. - Greg Scott -Original Message- From: Jason Tackaberry [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 8:55 PM To: [EMAIL PROTECTED] Subject: [LARTC] Can't keep up with all these file sharing programs! Hi everyone, I'm using HTB to shape traffic for students in our residences. We're an extremely small college (about 50 Internet users in our residences) and we don't have a good deal of bandwidth to work with, so I must do what I can to make what we do have tolerable to our students. I am right now using the following approach: I have allotted a portion of our total bandwidth (R) to the residence subnet on the upstream interface on our router. This class is sub-divided into two classes: a p2p class for all those pesky file sharing programs, which has a ceiling of about R/2, and an "everything else" class, which has a guaranteed rate of R/2, and a ceililng of R. I have put SYN and ACK packets in a separate class (under root) to improve responsiveness. In theory, this scheme works pretty good. The problem is that every day some of these p2p programs are using different ports, and they manage to suck up all available downstream bandwidth. So, the student who wants to send their friend a file over ICQ is going to get starved by every other student running Kazaa-du-jour. Now it would be _really_ nice if there was some ability to examine packets at layer 7 to determine what class a particular session belongs in (like, for instance, the way Packeteer's Packet Shaper works). I'm assuming I can't get this functionality (unless I write it myself), so can someone suggest a remedy to my problem? Is there some magic adjustment I can make? Or, perhaps I should try a different approach, and give each IP a guaranteed rate? The only drawback I see with this is that with 50 users, I could only guarantee each user 5kbps. :) Any guidance would be appreciated. Best, Jason. -- Jason Tackaberry :: [EMAIL PROTECTED] :: 705-949-2301 x330 Academic Computing Support Specialist Information Technology Services Algoma University College :: www.auc.ca ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] Iptables, SNAT/MASQ, Multiple gateways
> ip route add default nexthop via $CONN1_IP dev $ETHX weight $X \ > nexthop via $CONN2_IP dev $ETHX weight $Y > Would this technique work for more than two gateways? How many nexthop clauses are allowed? Is there a limit? thanks - Greg Scott ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Why multiple NICs in a multiple route situation?
In a situation with multiple routers to the Internet and a Linux firewall/router that either makes a choice about which route to use or load balances among the routes: > I don't think you *need* to have a separate NIC for each > router, but if I were doing it, I'd want each router on a > separate network. This has been bugging me - if a single NIC will work then what value does another NIC add? Let's say the circuits are both T1. With two possible circuits, that's just a little more than 3mb per second. At 100 mbit per NIC, it would take more than 50 T1s to swamp it. So why a NIC per T1? Why not just give a single NIC an IP address in all the networks for each T1? Or am I missing something important? thanks - Greg Scott ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] Multipath route problem
> # ip route add default nexthop via 10.10.10.2 dev eth0 nexthop via > 10.10.10.1 dev eth0 I wonder if this is a problem going out over the same NIC to the two providers? All the docs I can find show each provider on its own NIC. I am setting up something similar and was just about to ask if I can do it with one NIC connecting all the providers. That would save me a bunch of precious PCI slots! In my case there are 4 - count 'em - 4 external routers to the Internet! 3 of them are supposed to load-balance for user traffic and the fourth is for a bunch of internal servers with known IP Addresses. So there will be a fwmark policy that puts the routes for those servers into its own table. Life would be great if I could do all this on a single NIC connecting all of those routers. Or do Neils and I both need a separate NIC for each router? thanks - Greg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 31, 2002 8:42 AM To: [EMAIL PROTECTED] Subject: [LARTC] Multipath route problem Hi ... I have 2 DSL lines all up and running on one RedHat box... I want to balance traffic going out over the two providers The 2 DSL routers Have IP's 10.10.10.1 / 10.10.10.2 ... my linux box (eth0) has IP 10.10.10.10 connected on a separate ethernet SO I read the http://lartc.org/howto/lartc.rpdb.multiple-links.html guide (chapter 4.2.2) In my case I have to make these routes # ip route add default nexthop via 10.10.10.1 dev eth0 nexthop via 10.10.10.2 dev eth0 Works Fine!! every connection request going is perfectly balanced sent out via both gateways But works only on the linux box itself! from the (masqueraded) clients it doesn't: Every first request which is masqueraded -> gateway 10.10.10.1 (works fine) Every second request which is masqueraded -> gateway 10.10.10.2 (don't get reply back) When I change the multipath route so that 10.10.10.2 is the first hop # ip route add default nexthop via 10.10.10.2 dev eth0 nexthop via 10.10.10.1 dev eth0 Gw 10.10.10.2 (fine) Gw 10.10.10.1 (doesn't work ... Only from the linux box itself) So it every time seems to be the second "hop" in the multipath route which isn't beeing masqueraded properly! Can anyone help? Thanks in advance! Niels! ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] RE: [Users] FreeS/Wan on Redhat 7.3
27;t forget to build another copy of initrd (see above PPTP stuff) to support the ext3 file system at boot time. Take a look at /etc/grub.conf to make sure the right edits are in place. May need to run Xconfigurator to make X windows work again. May need to set /proc/sys/net/ipv4/conf/eth0/rp_filter = '0' for KLIPS to work. Can also do this with /etc/sysctl.conf *** -Original Message----- From: Brian [mailto:[EMAIL PROTECTED]] Sent: Saturday, July 06, 2002 2:35 PM To: Greg Scott Subject: RE: [Users] FreeS/Wan on Redhat 7.3 I had no problems installing FreeS/Wan with SuSE 8.0 Pro, it has FreeS/Wan 1.96 using kernel 2.4.18??? hummm. Can you please clean-up your notes and send it to me.. Thank you for doing that. It's work great under SuSE 8.0 , I even posted a step by step installing and compiling IPSec under SuSE 8.0. I got FreeS/Wan working with SSH Sent and it work GREAT. -Original Message- From: Greg Scott [mailto:[EMAIL PROTECTED]] Sent: Saturday, July 06, 2002 3:37 PM To: Brian; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [Users] FreeS/Wan on Redhat 7.3 Brian, did you have the same problem with FreeS/WAN 1.97? I was able to get 1.97 to work after some struggles but have not yet tried 1.98. I am using the kernel configuration answers from configs/kernel-2.4.18-i386.config. Here is an extract from my notes on how to set it all up. cd /usr/src Be sure to make a symbolic link, linux, that points to the real source tree, like this: ln --symbolic linux-2.4.18-3 linux cd linux make mrproper I use the Red Hat configuration answers to initially start out, like this: cp configs/kernel-2.4.18-i386.config .config Next, I build a kernel without FreeS/WAN, then do make xgo and and build a kernel with FreeS/WAN support. There was a 1.97 bug and I had to pull out an error checking tool from the 1.98 candidate release. I can clean up my detailed notes and post here if you want - but I have not yet tried a 1.98 build. - Greg -Original Message- From: Brian [mailto:[EMAIL PROTECTED]] Sent: Saturday, July 06, 2002 1:14 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [Users] FreeS/Wan on Redhat 7.3 I have been trying to install FreeS/Wan 1.98b for about one week now and have gotten NO Where. My advice to anyone that wants to run FreeS/Wan buy SuSE 8.0 Pro with FreeS/Wan already included , it will save you from pulling all your hair out, unless you have no hair to begin with. It seems like redhat does not like FreeS/Wan for some reason, everytime I get FreeS/Wan to work I need add another fuction to the kernel then after I think I have it, when I re-start and get to the part starting IPSEc, IT BOMBS out, telling KLIPS is now not part of the kernel...LOL I have tryed to re-compile the kernel and de-slect the options that I think caused the problem but with no luck... when I slect the netfilter option, which I need to setup routing , It bombs out when I restart redhat... ___ Users mailing list [EMAIL PROTECTED] http://lists.freeswan.org/mailman/listinfo/users ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] RE: Redhat 7.3 / SuSE 8.0
I'll bet something is messed up in your source tree. All the distros use the same base kernel after all (don't they?) As I recall, the .config from Red Hat sets up the netfilter stuff as modules. I'll work on cleaning up my compile notes. - Greg -Original Message- From: Brian [mailto:[EMAIL PROTECTED]] Sent: Saturday, July 06, 2002 5:36 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Greg Scott Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Redhat 7.3 / SuSE 8.0 I have a question here? why in SuSE 8.0 pro I can slect all the networking options and none of them are gray out? while under Redhat 7.3 most of them are? I can't modify the IP:Netfilter Config under Redhat 7.3? ANY IDEA's why I can't? I am using make xconfig... ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Load balancing
I am trying to figure out how to do this: I've tried the howto but just become hopelessly confused. (I don' think this is a problem in the howto, it's a problem with my comprehension.) Anyway, here's the scenario: Internal Linux Router/ 4 - T1 circuits to Another Networks Firewall the InternetInternet circuit | | | || | | | | | +-+ | |++--+--+--+---+ + | + There are really three internal networks for various departments. The router/firewall will have 4 NICs. For one of the internal departments, I want the router to load-balance outbound packets among those 4 T1 circuits, which will be connected to Cisco (I think) routers. I want the other departments to all share that other Internet circuit. And I need the ability to change this policy at will, so I can let other departments use the combined T1s as needed. I think I can figure out how to route based on the source network, that all makes sense in the how-to. I can set up different routing tables based on the source IP address/network. It's the load balancing that is making me crazy - how do I put together a load-balancing mechanism for those combined T1s that makes sense? Any advice or pointers? thanks - Greg Scott ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] How to
Take a look here: http://netfilter.samba.org/documentation/ for pointers to lots and lots of detailed explanations. The answers you want are in there - but you'll need to do some studying. > I don't see any FORWARD rule here. You know, like between the > interfaces. And what's '-t mangle' got to do with anything? That's right. You don't need any for your application. Remember that netfilter rules are generally for **filtering** packets, not for forwarding packets. Take a look at the line towards the bottom of the script I sent that turns on IP forwarding. That line turns your Linux system into a router. It tells the kernel to forward packets from one ethernet interface to the other and out to the network on the other end. The -t mangle stuff is just being thorough. Netfilter has several tables and the mangle table is one of them. It's good practice to flush and zero all tables when you set these scripts up. Take it out if you want. - Greg -Original Message- From: Tony Earnshaw [mailto:[EMAIL PROTECTED]] Sent: Saturday, June 01, 2002 10:05 AM To: Greg Scott Cc: Stef Coene; Neil Aggarwal; Linux Advanced Routing & Traffic Control List Subject: RE: [LARTC] How to lør, 2002-06-01 kl. 16:55 skrev Greg Scott: > I know the other list is for netfilter stuff but heck, if I can help > I'll give it a try... Sigh. I don't see any FORWARD rule here. You know, like between the interfaces. And what's '-t mangle' got to do with anything? *Let the fellow go to a list that will look after him properly* Best, Tony -- Tony Earnshaw e-post: [EMAIL PROTECTED] www:http://www.billy.demon.nl gpg public key: http://www.billy.demon.nl/tonni.armor Telefoon: (+31) (0)172 530428 Mobiel: (+31) (0)6 51153356 GPG Fingerprint = 3924 6BF8 A755 DE1A 4AD6 FA2B F7D7 6051 3BE7 B981 3BE7B981 ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] How to
I know the other list is for netfilter stuff but heck, if I can help I'll give it a try... Here is a more general script that should work: ** #!/bin/sh EX_IP="11.22.33.55" IN_IP="192.168.1.253" IPTABLES="/sbin/iptables" # # Be sure to modprobe the modules you need here - an exercise # for the reader. # echo "Zeroing all iptables, deleting all user defined chains" $IPTABLES -F $IPTABLES -X $IPTABLES -t nat -F $IPTABLES -t nat -X $IPTABLES -t mangle -F $IPTABLES -t mangle -X echo "Setting up default policies to ACCEPT" $IPTABLES -P INPUT ACCEPT $IPTABLES -P OUTPUT ACCEPT $IPTABLES -P FORWARD ACCEPT echo "setting up masquerading rules" IPTABLES -t nat -A PREROUTING -d $EX_IP -j DNAT --to $IN_IP IPTABLES -t nat -A POSTROUTING -s $IN_IP -j SNAT --to $EX_IP echo "Turning on IP forwarding" echo "1" > /proc/sys/net/ipv4/ip_forward exit Note that this rule set provides absolutely no security. Any packet, any protocol, any port of any protocol (for protocols like TCP and UDP that have ports) that comes in bound for EX_IP will be NAT-ed and redirected to IN_IP. And any new conversation initiated by IN_IP will be masqueraded to look to the outside world like it came from EX_IP. Also note, I copied and pasted this from sections of my own firewall script. I have not tested the above script anyplace, so take that for what it's worth. - Greg -Original Message- From: Stef Coene [mailto:[EMAIL PROTECTED]] Sent: Saturday, June 01, 2002 2:38 AM To: Tony Earnshaw; Neil Aggarwal Cc: Linux Advanced Routing & Traffic Control List Subject: Re: [LARTC] How to > In as much as this is a perfectly normal use of Netfilter (iptables), I > reckon that you're asking in the wrong group. Copy-paste can never hurt :) iptables -t nat -A PREROUTING -p tcp -d $EX_IP --dport 8080 -j DNAT --to 192.168.1.253:80 All traffic entering the external ip of my firewall on port 8080 is forwarded to my internal web-server. Stef -- [EMAIL PROTECTED] "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] Beginner
Why not just do a topology like this: LAN--Firewall | | DMZ with webserver-+ The perimeter network approach with 2 firewalls seems much too complex for little if any benefit. - Greg -Original Message- From: Rens Houben [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 23, 2002 6:11 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [LARTC] Beginner On Thu, 2002-05-23 at 12:58, Alex Bennee wrote: > ewan said: > > > >> #Lan--Internal Firewall--- External firewall -- Internet > >> | > >> | > >>webserver > > > > > > what purpose does the internal firewall serve? just plug everything > > into one firewall and write rules accordingly > There is nothing wrong with having multiple layers of firewalls. It means > your haxor has several layers of security to beat - security through depth. More to the point, you can tell the inner firewall to do masquerading, while the outer wall does filter-only, so your office LAN is safe where the haxor can't even touch it until and unless he compromises the inner firewall (which you can hammer shut to Fort Knoxian levels without compromising accessibility) while the webserver (and maybe other servers as well as the need arises) are in the perimeter -- not as well defended, but accessible from the outside. > But you can just use iptables on your internal firewall as well. No point > learning new semantics :-) Other than the fact that it's fun. :) > Alex > www.bennee.com/~alex/ -- Rens Houben |opinions are mine Resident linux guru and sysadmin | if my employers have one Systemec Internet Services. |they'll tell you themselves PGP public key at http://suzaku.systemec.nl/shadur.key.asc -- new Dec 12 2001 ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] Exchange server 5.5 Disaster Recovery
If you can afford the down time, you could stop all your Exchange services on the primary system, copy all files in the exchsrvr directory, then startup the services again. Another option would be to buy Backup Exec and buy the Exchange backup agent and use this agent to backup the files. I think BUEXEC has the ability to go disk to disk. I don't remember the particulars about Exchange itself, but I vaguely remember some capability for Exchange to keep redundant copies of the data stores across the same site. I'd have to look this up to be sure. - Greg -Original Message- From: Azad Mahmoud [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 5:56 AM To: [EMAIL PROTECTED] Subject: [LARTC] Exchange server 5.5 Disaster Recovery Hi, As a plan for a disaster recovery network (in a second location), is there any way of synchronising the current Exchange server remotly with the DR one in our location, or is there any way of doing this process through a backup and restore procedure? Thanks * Disclaimer: This e-mail and any attachments are confidential. It may contain privileged information and is intended for the named addressee(s) only. It must not be distributed without Dionach Ltd consent. If you are not the intended recipient, please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Unless expressly stated, opinions in this e-mail are those of the individual sender, and not of Dionach Ltd. * __ This message has been checked by Dionach for all known viruses using MessageLabs Virus Scanning Service. For further information visit http://www.dionach.com ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] Re: Routing that doesn't route
Julian, I want to thank you for your help on this one.
After pouring over books and every google reference I
could find, I think I finally understand what ICMP_REDIRECT
is all about. I'm still not clear about RP_FILTER but
getting better.
I gathered some more data on the problem. (The problem
was two routers connected in parallel to the inside
and outside networks. The Linux router is everyone's
default gateway and has a route for one subnet to the
other router. The other router then VPNs it across the
Internet to a remote branch office.)
The deal with ICMP_REDIRECT is, if you have more than one
router and one router gets a packet bound for somewhere, and
that router knows there is a better first hop, that router
will send an ICMP_REDIRECT message back to the original
sender and the original sender is supposed to update its
routing tables. That is what's supposed to happen.
The Linux router is running Red Hat Linux 7.1, which is
kernel 2.4-2. I found out that ICMP Echo Reply packets
weren't being handled right and I took a bunch of
tcpdump output showing details.
Based on Julian's advice with ICMP_REDIRECT, I got back to
the customer site a few days ago and took advantage of an
internal DNS server named igor. If I did telnet igor 53
from across the VPN and then sent some illegal junk to that
DNS server, then I could ping igor across the network. And
sure enough, ICMP_REDIRECT set up the route in igor.
But if I removed the route in igor and tried to ping igor,
igor would reply, but the original "pinger" never saw it
and gor would never get an updated route from the Linux router.
tcpdump on the Linux router showed me that igor was replying,
but the router never forwarded the reply anywhere.
The Linux router did handle my TCP port 53 stuff, but not ICMP.
So the problem had to be some kind of kernel bug around
ICMP redirects.
I got some more time to work the problem today and finally
reproduced the problem at my place. Then I setup a system
with Red Hat 7.2, which uses kernel 2.4-7. Still old, but not
as old! I set this sytem up as a router in parallel with my
other Linux router and ran the same tests again. This time,
everything did what it was supposed to do.
So I think the whole thing was a bug with the 2.4-2 kernel.
So for people running the 2.4-2 kernel with routing turned
on and in parallel with another router, one workaround is
to send any kind of TCP packet first to the other side, which
will make ICMP_REDIRECT do its thing.
A better workaround - as Julian pointed out:
echo 1 > /proc/sys/net/ipv4/conf/eth0/send_redirects
echo 1 > /proc/sys/net/ipv4/conf/eth1/send_redirects
An even better fix - upgrade from Red Hat 7.1 to 7.2.
And maybe the best fix is to just bite the bullet
and upgrade to the latest stable kernel. That's the
next challenge I'm going to work on!
thanks
- Greg
-Original Message-
From: Julian Anastasov [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 28, 2002 4:49 PM
To: Greg Scott
Cc: [EMAIL PROTECTED]; Patsy Rossow (E-mail)
Subject: RE: [LARTC] Re: Routing that doesn't route
Hello,
On Thu, 28 Feb 2002, Greg Scott wrote:
> > What is the value in /proc/sys/net/ipv4/conf/eth1/send_redirects ?
>
> [root@csfampls-fw /]# more /proc/sys/net/ipv4/conf/eth1/send_redirects
> 1
This is one of the values you can try to alter. Try to set
both all/send_redirects and eth1/send_redirects to 0.
> > On each Linux try to check with
> > ip route get from to iif
>
> [root@csfampls-fw /]#
> [root@csfampls-fw /]# /sbin/ip route get from 172.16.16.2 to 172.16.0.252
> iif eth1
> 172.16.0.252 from 172.16.16.2 via 172.16.16.3 dev eth1 src 172.16.16.1
> cache mtu 1500 iif eth1
OK, traffic is not dropped from rp_filter. But this box
should send ICMP redirects (note the "redirect" flag), i.e. it
redirects traffic from 16.2 to 0.252 through 16.3. If you try
with {all,eth1}/send_redirects=0 the traffic will be silently
accepted and then forwarded to 16.3.
> [root@csfampls-fw /]#
> [root@csfampls-fw /]# /sbin/ip route show
> aaa.bbb.228.32/27 dev eth0 proto kernel scope link src aaa.bbb.228.33
> ccc.ddd.200.64/27 via aaa.bbb.228.34 dev eth0
> 172.16.16.0/20 dev eth1 proto kernel scope link src 172.16.16.1
you are trying alternative routes which work only by using my patches,
the following can't work in plain kernel:
> 172.16.0.0/20 via 172.16.16.3 dev eth1
> 172.16.0.0/20 via 172.16.16.151 dev eth1
Note also that the above routes should have a preferred
source IP. Avoid using the "route" tool in advanced routing setups.
Try with "ip":
ip route add 172.16.0.0/20 via 172.16.16.3 dev eth1 src 172.16.16.1
> 127.0.0.0/8 dev lo scope link
same here, make sure all your routes have right preferred source IP:
> default via aaa.bbb.228.62
RE: [LARTC] Routing based on source port - Solution ?
What about some sort of DNAT redirection with iptables? - Greg -Original Message- From: Tobias [mailto:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 8:18 AM To: [EMAIL PROTECTED] Subject: Re: [LARTC] Routing based on source port - Solution ? Hello bert I have the same problem and tried all possibities i know. "ip rule" in fact doesnt route based on port because IP protocol dont know about ports. BUT u can solve the problem by using iptables/ipchains with help of MARKs - as u said. Unfortinuatly netfilter can only set MARKs in the moment the packets travers the INPUT Queue (of corresponding interface). --> netfilter is not able to set mark for _local_ created packets, because the INPUT Queue of netfilter is not passed. => In fact the MARK mechanism can only be used for incoming packets. In my scenario i would like to do port based routing on local sockets i cannot use the MARK feature at all. :( I dont know of any other method to solve the problem. Any other solutions ?? I have only one "hack" in mind: + Setup my routing based on source-ip. + Change the socket() call via LD_PRELOAD to change the namespace to a predefined IP (= source-IP change) + on exection of programs on the shell i preload the new socket() when i want to route the network datas other ways (not default one). That way specified network transfers are done via an alternate route defined in "ip route". Possible one needs to HACK the source code of programs. Anyone got ideas on this medthod ? Thx Tobias On Fri, 19 Apr 2002 10:44:53 +0200 "bert hubert" <[EMAIL PROTECTED]> wrote: > On Fri, Apr 19, 2002 at 09:09:35AM +0200, Daniel Ahlberg wrote: > > Hello, > > > > I have two ISPs connected to my router. Using "ip rule" I can easily divert > > traffic to the diffrent uplinks. However, "ip rule" only seems to be able to > > send packets according to their source or destination adress. What I want is > > to be able to route based on protocol and source port. Is this possible, and > > how? > > I think ip rule has a syntax for that; if it doesn't, use iptables or > ipchains to attach a mark to packets with certain source or destination port > and create a rule that works on that mark. > > Regards, > > bert > > -- > http://www.PowerDNS.com Versatile DNS Software & Services > http://www.tk the dot in .tk > http://lartc.org Linux Advanced Routing & Traffic Control HOWTO > ___ > LARTC mailing list / [EMAIL PROTECTED] > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] Neighborhood Question
You must have a DHCP server someplace in your local network. It's probably your Internet router supplied by your ISP. For those clients you don't want DHCP assigned, just give them hard IP addresses. - Greg -Original Message- From: Arindam Haldar [mailto:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 7:11 AM Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [LARTC] Neighborhood Question hi all I have a query related to network neighborhood. all my clients(their network) can see each other on the metwork. the ip of the linux box is 10.0.0.1 & mask 255.0.0.0. and clients being given ip's according to their need for network ! how can i stop this ?.. thnx in anticipation... A.H ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] Firewall Question?
A rule like: /sbin/iptables -A FORWARD -i eth0 -s 192.168.0.0/24 -j DROP would do the trick. Kind of a sledgehammer solution, but it should block everyone. - Greg -Original Message- From: Ross Skaliotis [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 14, 2002 11:15 AM To: Brian Cc: [EMAIL PROTECTED] Subject: Re: [LARTC] Firewall Question? When you use NAT to route traffic from eth0 out to the internet, it flows through the FORWARD table, bypassing the INPUT and OUTPUT tables completely. You'll need to setup a rule in your firewall blocking access using the FORWARD table. -Ross Skaliotis On Sun, 14 Apr 2002, Brian wrote: > > I have a iptables firewall version 1.2.5, I LOVE IPTABLES SO MUCH MORE > THINGS YOU CAN DO. I have a small network off my eth0 interface > 192.168.0.X network and my ppp0 is my DSL connection, with the current > firewall how would I block someone going to the Internet from my eth0 > interface. I have tried many of things here and had no luck. > > Both my INPUT and OUTPUT used a DROP policy by default and I am using > NAT to route my traffic to the Internet. > > > > echo "1" > /proc/sys/net/ipv4/ip_dynaddr > echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter > echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts > echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route > echo 0 > /proc/sys/net/ipv4/tcp_timestamps > echo 1 > /proc/sys/net/ipv4/tcp_syncookies > echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects > echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses > echo 1 > /proc/sys/net/ipv4/conf/all/log_martians > echo "32768 61000" > /proc/sys/net/ipv4/ip_local_port_range > echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout > echo 2400 > /proc/sys/net/ipv4/tcp_keepalive_time > echo 0 > /proc/sys/net/ipv4/tcp_window_scaling > echo 0 > /proc/sys/net/ipv4/tcp_sack > > modprobe ip_conntrack > modprobe ip_tables > modprobe iptable_filter > modprobe iptable_mangle > modprobe iptable_nat > modprobe ipt_LOG > modprobe ipt_REJECT > modprobe ipt_MASQUERADE > modprobe ip_conntrack_ftp > modprobe ipt_owner > modprobe ip_conntrack_irc > > echo 1 > /proc/sys/net/ipv4/ip_forward > iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE > iptables -A FORWARD -j ACCEPT > > > iptables -A INPUT -i eth0 -j ACCEPT > iptables -A INPUT -i lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT > iptables -A INPUT -i ppp0 -p udp --dport 1024: -j ACCEPT > iptables -A INPUT -i ppp0 -p udp --sport 67 --dport 68-j ACCEPT > iptables -A INPUT -i ppp0 -p udp -s 208.188.197.4 --sport 53 --dport > 1024:65535 -j ACCEPT iptables -A INPUT -i ppp0 -p udp -s 206.148.122.8 > --sport 53 --dport 1024:65535 -j ACCEPT > iptables -A INPUT -i ppp0 -p udp -s 206.148.122.2 --sport 53 --dport > 1024:65535 -j ACCEPT iptables -A INPUT -i ppp0 -p tcp ! --syn -j ACCEPT > iptables -A INPUT -i ppp0 -p icmp -j DROP iptables -P INPUT DROP > > > > iptables -A OUTPUT -d 192.168.0.0/24 -j ACCEPT > iptables -A OUTPUT -d 255.255.255.255 -j ACCEPT > iptables -A OUTPUT -d 127.0.0.1 -j ACCEPT > iptables -P OUTPUT DROP > > > > > > > > ___ > LARTC mailing list / [EMAIL PROTECTED] > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] long delays with NNTP after switching T1 to other ser vcie provider
I'll bet that's the right direction. I've seen other services, especially ftp, where the ftp server tries a reverse DNS and gets mad or times out if it can't resolve it. One of the dumbest engineering decisions I've ever seen! I'll bet that nntp service you're trying to get at does the same thing. But the deal is, the nntp server might be having reverse DNS problems resolving your IP address to a name, not you resolving its address to a name. So **you** having reverse DNS problems might not be the key. Remember, I am just speculating here. - Greg -Original Message- From: David Koski [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 14, 2002 12:37 AM To: Greg Scott; LARTC Subject: Re: [LARTC] long delays with NNTP after switching T1 to other ser vcie provider Reverse DNS does not work. Could that be it? David On Sat, 13 Apr 2002 12:51:35 -0500 Greg Scott <[EMAIL PROTECTED]> wrote: > Or maybe some kind of DNS issue is going on. > > - Greg > > > -Original Message- > From: David Koski [mailto:[EMAIL PROTECTED]] > Sent: Saturday, April 13, 2002 10:31 AM > To: LARTC > Subject: [LARTC] long delays with NNTP after switching T1 to other > servcie provider > > > After moving a Linux server serving as a wireless gateway/router to another > ISP, > I noticed a problem with NNTP. When attempting to communicate NNTP through > the > Linux server, there are long delays that often result in timeouts. For > example, > when using the newsreader pan, I get the following errors in the log file, > in > reverse chronological order: > > Connect Failure > NNTP handshake failed: Error reading from socket. > Handshake failed: Error reading from socket. > NNTP handshake failed: Error reading from socket. > Timed out waiting to read from the server. > > > The Linux server is fed with a T1 from a different source. Before changing > over, there was no problem with NNTP. The only other difference that would > seem > to matter is the reconfiguration of the server. I only took some services > off > line (qmail for example) and reconfigured the routing. All other traffic > through the server works well, with the exception of dhcp which I haven't > resolved yet. > > I suspect a QoS control issue from upstream. Is it possible that NNTP > requests > are sitting in a queue somewhere waiting for a the "right" time to dequeue? > If > so, would there be something I could do with the TOS that might help? Or Am > I > on the wrong track? > > TIA, > David Koski > [EMAIL PROTECTED] > ___ > LARTC mailing list / [EMAIL PROTECTED] > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] long delays with NNTP after switching T1 to other servcie provider
Or maybe some kind of DNS issue is going on. - Greg -Original Message- From: David Koski [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 13, 2002 10:31 AM To: LARTC Subject: [LARTC] long delays with NNTP after switching T1 to other servcie provider After moving a Linux server serving as a wireless gateway/router to another ISP, I noticed a problem with NNTP. When attempting to communicate NNTP through the Linux server, there are long delays that often result in timeouts. For example, when using the newsreader pan, I get the following errors in the log file, in reverse chronological order: Connect Failure NNTP handshake failed: Error reading from socket. Handshake failed: Error reading from socket. NNTP handshake failed: Error reading from socket. Timed out waiting to read from the server. The Linux server is fed with a T1 from a different source. Before changing over, there was no problem with NNTP. The only other difference that would seem to matter is the reconfiguration of the server. I only took some services off line (qmail for example) and reconfigured the routing. All other traffic through the server works well, with the exception of dhcp which I haven't resolved yet. I suspect a QoS control issue from upstream. Is it possible that NNTP requests are sitting in a queue somewhere waiting for a the "right" time to dequeue? If so, would there be something I could do with the TOS that might help? Or Am I on the wrong track? TIA, David Koski [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] Yay!
Now that your VPN is working, you really have two LANs separated by routers. So the issues with browse lists etc. are the same as in any other WAN situation and really not related to Linx Advanced Routing. (But who am I to make that call - I'm just a skinny bald guy from Minnesota!) NetBIOS broadcast name resolution does you no good, so you'll either need a WINS server or local lmhosts files. That's for NetBIOS name resolution. For DNS name resolution, you'll need a DNS server. - Greg -Original Message- From: Patrick Dench [mailto:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 11:11 AM To: [EMAIL PROTECTED] Subject: [LARTC] Yay! Looks like my GRE problems were due to ipchains. I went to IP Tables, and it looks like it is working. Next issue: name resolution.. Right now the only way I know my home PC is connected is because I turned it on this morning. Is there anyway to resolve PC names through the VPN? Specifically to make it possible to browse another subnet via the Windoze 'network neighborhood'? -Pat Dench ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
