Re: [Leaf-user] martians on internal network ??? [LONG!]
On Fri, 8 Mar 2002, Michael D. Schleif wrote: Jeff Newmiller wrote: On Fri, 8 Mar 2002, Michael D. Schleif wrote: We are seeing martians on internal networks on a regular basis. Usually, it is traceable to users logging into AOL over our high speed internet connections: 172.128.0.0 - 172.191.255.255 Today, we saw one from United Airlines: 205.174.16.0 - 205.174.23.255 [1] How does this happen? I often wonder how it happens that people who should know better fail to provide specific error and log messages and explain what they know about the particulars of the ip addresses, routes, machines and connections involved. It is hard to trust reports as sanitized as this. Jeff, I respect your intelligence and firewall skills; however, if you read exactly what I posted, then you will know exactly what there is to know. Troubleshooting is like a tree... if you only describe the trunk and one branch, we cannot be expected to describe the right twig for you to look at. On the surface, the idea that packets should be generated within your LAN with source addresses outside your network would suggest something is seriously broken (accidentally or purposefully) with the workstation generating the packets. That is one idea, isn't it? [2] Why does this happen? Speculation: if your AOL users are actually dialling into AOL while being on the network, they may be temporarily acquiring an IP from AOL, and Windows could possibly screw up and ships packets out the wrong interface. However, something would have to be pretty weird with the AOL software if it decided it had an AOL IP even if no dialup had occurred. There could possibly be overlap when a dialup connection was lost as well. Please, please, please, read my post and respond accordingly: `` ... users logging into AOL over our high speed internet connections ... '' I read that. See below. They are *NOT* _dialing_ into AOL !!! Or, even if they were, the questions remain the same -- what's the difference? Each interface is supposed to have an ip address. If the wrong IP address is appearing on an outbound packet, the first possibility that presents itself to my mind is that a port bound on one interface is somehow sending packets out on another interface. The second interface may not be a dialup interface... but it is an obvious one that you did not explicitly rule out in your first post. If some tunnelling is going on, then virtual interfaces could be involved. However, Occam's Razor suggests that the simplest solution is the most likely one. Since I am not aware of tunnelling in the described software, and dialups are very common with that software, I speculated. [3] Is this exploitable? Insufficient data. How much data will suffice? A smattering of log entries: Feb 26 08:17:36 redtrout kernel: martian source 0b49a2ac for , dev eth1 Feb 26 08:21:11 redtrout kernel: martian source 490b99ac for , dev eth1 [...] While you may feel like you are conveying some message about the unreasonableness of my request, you are actually spewing on a public mailing list. A few samples, with a summary of the interfaces involved, and the routing table for one of these AOL computers would be much more effective. For those who cannot be bothered to find their hex calculators: 0.0.234.239 efea 12.248.73.21 1549f80c 24.147.110.151976e9318 [...] 172.128.190.181 b5be80ac 172.129.46.164a42e81ac [...] What more do you need? On an offending workstation, ipconfig netstat -rn netstat -a I am not as familiar with networking on Windows as I am on Linux, but I have some reference books and the problem here is not on the firewall. On Linux I would use lsof also, but I don't know what the equivalent would be under Windows. MSINFO.EXE? --- Jeff NewmillerThe . . Go Live... DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] martians on internal network ??? [LONG!]
Michael D. Schleif wrote: Jeff Newmiller wrote: Jeff I'm sorry you ended up with that reply. Please don't take it home with you, so to speak. We highly value your contributions to LEAF, and we appreciate your willingness to help Michael. On Fri, 8 Mar 2002, Michael D. Schleif wrote: We are seeing martians on internal networks on a regular basis. Usually, it is traceable to users logging into AOL over our high speed internet connections: 172.128.0.0 - 172.191.255.255 Today, we saw one from United Airlines: 205.174.16.0 - 205.174.23.255 [1] How does this happen? If that's all there was to the original post, I'm surprised Jeff even responded. In case you haven't been reading leaf-devel lately, we've been rehashing out the Howto request help document that clearly states what will help us help you. You chose to ignore it twice in a row. Fine. I often wonder how it happens that people who should know better fail to provide specific error and log messages and explain what they know about the particulars of the ip addresses, routes, machines and connections involved. It is hard to trust reports as sanitized as this. Jeff, I respect your intelligence and firewall skills; however, if you read exactly what I posted, then you will know exactly what there is to know. You will know exactly what there is to know ? Oh my God, Michael. This is a technical list for a science project. This is not metaphysics. Quantify. Don't qualify. On the surface, the idea that packets should be generated within your LAN with source addresses outside your network would suggest something is seriously broken (accidentally or purposefully) with the workstation generating the packets. That is one idea, isn't it? What purpose does your question serve? I can't fathom that you want an answer to it. In addition, you have proffered it to one of our most experienced, knowledgable, dedicated, and accurate members. You'll find it difficult to persue a worse course of action. [2] Why does this happen? Speculation: if your AOL users are actually dialling into AOL while being on the network, they may be temporarily acquiring an IP from AOL, and Windows could possibly screw up and ships packets out the wrong interface. However, something would have to be pretty weird with the AOL software if it decided it had an AOL IP even if no dialup had occurred. There could possibly be overlap when a dialup connection was lost as well. Please, please, please, read my post and respond accordingly: `` ... users logging into AOL over our high speed internet connections ... '' They are *NOT* _dialing_ into AOL !!! Yes, ok we can see that. Please excuse Jeff if he's unclear on your setup. He stated he was unclear and asked for the usual details that are laid out in the FAQ. You ignored that request and instead followup with yelling in CAPS, numerous exclamtion points, redundant pleases all in a chiding, demeaning tone. That's uncalled for. God forbid you should explain what the heck our high speed internet connections in plural refers to or any real details of your network. Or, even if they were, the questions remain the same -- what's the difference? [3] Is this exploitable? Insufficient data. How much data will suffice? How many times do we have to repeat ourselves? Use the Troubleshooting FAQ. Post what it says to post plus any other details you think would help. I don't think that's so difficult. I don't think that's too much to ask. A smattering of log entries: Feb 26 08:17:36 redtrout kernel: martian source 0b49a2ac for , dev eth1 Feb 26 08:21:11 redtrout kernel: martian source 490b99ac for , dev eth1 [snip] For those who cannot be bothered to find their hex calculators: What? Are you serious? For the love of Pete. 0.0.234.239 efea 12.248.73.21 1549f80c 24.147.110.151976e9318 [snip] What more do you need? Nothing more on this thread, ever. I'm going to chalk this one up to something got lost in the translation from Michael's native language to English. Take it easy, Jeff. Matthew ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] OSPF on LEAF?
Does anyone have any experience of using OSPF on leaf (e.g. with gated or zebra) that they would care to share? I am trying to establish a multihomed service at my colo facility and the provider is offering OSPF to manage my connections to his two routers. He then manages outbound with BGP4. I am currently planning to use Bering/Shorewall but (a) don't know how this would fit with OSPF and (b) would love to hear of similar experiences with any LEAF release. Thanks Andy ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] Please Please Help me...!
Hi everybody, Please Please help me! I'm trying to do it since last One month but could not then only I have sent a mail to this mailing list. I 'm running the Dachstein LEAF firewall. I'm not able to forwarding the external traffice which is coming to my valid IPaddr (eth0) to my internal web server which is a windows 2000 server. I have allready gone through all the related mailing list archive but could not solve the problem and hence I'm writing to this list. The error I'm getting in my browser is Connection faild Connection timed out. My configuration is as follows. EXTERN_IP=111.222.333.444 EXTERN_IF =eth0 INTERNAL_IP=10.24.33.224 INTERNAL_IF =eth1 INT_NET = 10.0.0.0/8 IPFWDING_KERNEL= FILTER_ON IPALWAYSDEFRAG_KERNEL = YES CONFIG_HOSTNAME = YES CONFIG_HOSTSFILE = YES CONFIG_DNS = NO IPFILTER_SWITCH = firewall SNMP_BLOCK = YES EXTERN_DHCP = NO EXTERN_DHCP = NO EXTERN_TCP_PORT0=0/0 www 111.222.333.444 INTERN_SERVERS=tcp_111.222.333.444_www_10.24.33.150_www My IPCHAINS RULES looks like they are accepting the connection at 111.222.333.444. But could not find the solution. Could anybody help me in that regard. When I see in weblet through brouser I'm seeing this. but no byte(packet) in Chain port forward policy. :: Masqueraded Connections :: IP masquerading entries prot expire source destination ports tcp 0:58.64 10.24.33.150 203.163.160.2 80 2678 (80) Regards . Thanks. Sudhir Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Please Please Help me...!
Greeting Sudhir: A thought might be that you have not enabled the 10.0.0.0 subnet on the internal network. The Dachstein CD has as its default the 192.168.1.0 subnet so to get the 10.0.0.0 working you must edit the configuration. 1) In /etc/network.conf lines 164, 349, 350 2) in /etc/sh-httpd.conf lines 2 and 3 3) in /etc/dhcpd.conf lines 4,5,7,8 4) in /etc/hosts.allow line 9 5) # lrcfg and in the dnscache package pick menu items 1 and 2. Regards, Bill --- barwals [EMAIL PROTECTED] wrote: Hi everybody, Please Please help me! I'm trying to do it since last One month but could not then only I have sent a mail to this mailing list. I 'm running the Dachstein LEAF firewall. I'm not able to forwarding the external traffice which is coming to my valid IPaddr (eth0) to my internal web server which is a windows 2000 server. I have allready gone through all the related mailing list archive but could not solve the problem and hence I'm writing to this list. The error I'm getting in my browser is Connection faild Connection timed out. My configuration is as follows. EXTERN_IP=111.222.333.444 EXTERN_IF =eth0 INTERNAL_IP=10.24.33.224 INTERNAL_IF =eth1 INT_NET = 10.0.0.0/8 IPFWDING_KERNEL= FILTER_ON IPALWAYSDEFRAG_KERNEL = YES CONFIG_HOSTNAME = YES CONFIG_HOSTSFILE = YES CONFIG_DNS = NO IPFILTER_SWITCH = firewall SNMP_BLOCK = YES EXTERN_DHCP = NO EXTERN_DHCP = NO EXTERN_TCP_PORT0=0/0 www 111.222.333.444 INTERN_SERVERS=tcp_111.222.333.444_www_10.24.33.150_www My IPCHAINS RULES looks like they are accepting the connection at 111.222.333.444. But could not find the solution. Could anybody help me in that regard. When I see in weblet through brouser I'm seeing this. but no byte(packet) in Chain port forward policy. :: Masqueraded Connections :: IP masquerading entries prot expire source destination ports tcp 0:58.64 10.24.33.150 203.163.160.2 80 2678 (80) Regards . Thanks. Sudhir Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] ipsec errors
i did not find that specific line in the net ipfilter list command, however I did change the setting in the networ.conf file. however I still did not find that line in the above command. I got to thinking about the specific problem i'm having and thought I might try to give a little more information .. here goes the machines are mostly stock dachstein, running udhcpd (instead of dhcpd/dhclient), w/ slightly modified subnets. Both machines are routing as designed, and all machines can ping the other gateway, internet is working fine). Although the ip address for each gateway is dynamic, they have stayed the same for atleast the last 2 months, so I have based my works on the assumed fact that these IPs will stay the same for a while longer. At any rate, for testing purpose they have stayed the same. subnet-home--home-internet-office--subnet-of fice 192.168.3.0/2466.25.44.147-66.25.18.71192.168.1.0/24 IPSec loads without any noticable errors, except something out abour rp_filter should be 0, but reads 1 (or vice versa). If I understand correclty, once both machines are at this point I could ping the office subnet from the home subnet, and the opposite, however this does not work. So then I tried ' ipsec auto --up office ' .. and then this just hangs. sits for awhile (reading the logs says something about itializing office on MAIN). After a minute or so, I ctrl-break this and am unable to go any further. Thats about where I am .. and am stuck... joey - Original Message - From: Charles Steinkuehler [EMAIL PROTECTED] To: [EMAIL PROTECTED]; LRP Support [EMAIL PROTECTED] Sent: Friday, March 08, 2002 5:46 PM Subject: Re: [Leaf-user] ipsec errors Where do I check to see if protocol 50 packets are being allowed through? I'll be working more on it this weekend.. I'd really like to get this working so I'll try just about anything.. even possibly step/by/step support via phone (I'd beg someone to call my 800 number for a little assistance... The primary source is the output of net ipfilter list, which shows you exactly how your firewall rules are setup. You're looking for a line allowing protocol 50, preferrably with non-zero byte/packet counts: 1843 356K ACCEPT 50 -- 0xFF 0x00 eth0 snip You open protocol 50 traffic with the following in network.conf: EXTERN_PROTO0=50 0/0 Of course, you can change the 0/0 (the entire internet) to the address (or network) of your remote VPN link, if it's static. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] ipsec errors
yes u gota problem Sir: now u do this: echo 1 /proc/sys/net/ipv4/conf/eth0/rp_filter echo 0 /proc/sys/net/ipv4/conf/ipsec0/rp_filter then: ipsec setup --restart I don't know how u setup your /etc/ipsec.conf... if u have it auto=add line to your conn.. then ready to go.. u almost there... good luck Upnet Joe. - Original Message - from: joey officer [EMAIL PROTECTED] To: Charles Steinkuehler [EMAIL PROTECTED]; LRP Support [EMAIL PROTECTED] Sent: Saturday, March 09, 2002 11:21 AM Subject: Re: [Leaf-user] ipsec errors i did not find that specific line in the net ipfilter list command, however I did change the setting in the networ.conf file. however I still did not find that line in the above command. I got to thinking about the specific problem i'm having and thought I might try to give a little more information .. here goes the machines are mostly stock dachstein, running udhcpd (instead of dhcpd/dhclient), w/ slightly modified subnets. Both machines are routing as designed, and all machines can ping the other gateway, internet is working fine). Although the ip address for each gateway is dynamic, they have stayed the same for atleast the last 2 months, so I have based my works on the assumed fact that these IPs will stay the same for a while longer. At any rate, for testing purpose they have stayed the same. subnet-home--home-internet-office--subnet-of fice 192.168.3.0/2466.25.44.147-66.25.18.71192.168.1.0/24 IPSec loads without any noticable errors, except something out abour rp_filter should be 0, but reads 1 (or vice versa). If I understand correclty, once both machines are at this point I could ping the office subnet from the home subnet, and the opposite, however this does not work. So then I tried ' ipsec auto --up office ' .. and then this just hangs. sits for awhile (reading the logs says something about itializing office on MAIN). After a minute or so, I ctrl-break this and am unable to go any further. Thats about where I am .. and am stuck... joey - Original Message - From: Charles Steinkuehler [EMAIL PROTECTED] To: [EMAIL PROTECTED]; LRP Support [EMAIL PROTECTED] Sent: Friday, March 08, 2002 5:46 PM Subject: Re: [Leaf-user] ipsec errors Where do I check to see if protocol 50 packets are being allowed through? I'll be working more on it this weekend.. I'd really like to get this working so I'll try just about anything.. even possibly step/by/step support via phone (I'd beg someone to call my 800 number for a little assistance... The primary source is the output of net ipfilter list, which shows you exactly how your firewall rules are setup. You're looking for a line allowing protocol 50, preferrably with non-zero byte/packet counts: 1843 356K ACCEPT 50 -- 0xFF 0x00 eth0 snip You open protocol 50 traffic with the following in network.conf: EXTERN_PROTO0=50 0/0 Of course, you can change the 0/0 (the entire internet) to the address (or network) of your remote VPN link, if it's static. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] martians on internal network ???
I am sorry for offending everyone. I will proffer no excuses. I was in one of my bullheaded moods and acted inappropriately. Again, I am sorry. Is it possible to ask a generic question? In general, is it possible to answer my original questions? Since I don't see this as a setup question -- is it a setup question to you? -- I asked these questions in the most generic way, hoping to spare bandwidth. Apparently, I made a mistake. I submitted log information -- apparently, that is also inadequate. I humble myself to this list: what do we need to know to answer these questions? We have already analyzed the environments in which this happens and it always happens on internal networks. All of these sites have T1, dsl, cable, c. connections to the internet. From the ``ll header'' entries that accompany each martian, we have identified the mac address of culprit workstations and determined that they are not dialing out on modems; but, even if they were, I do not see any change to my questioning. What is the difference? This only occurs on a small percentage of workstations; otherwise, all of these networks behave as we expect. We have been told that, apparently, logging into aol over a lan connection results in some kind of connection to a special aol network. I have never used aol and I do not understand this -- hence the first two questions. Since this happens on several different networks, if some kind helper really wants to see all of the setup and configuration information, then I will comply; but, it will be a very long post. Again, I am sorry to be so abrasive. Although, I do not see this as a setup issue and, therefore, I do not see in the troubleshooting documents anything applicable to these issues, please, point me to the information required and I will comply. Thank you. Michael D. Schleif wrote: We are seeing martians on internal networks on a regular basis. Usually, it is traceable to users logging into AOL over our high speed internet connections: 172.128.0.0 - 172.191.255.255 Today, we saw one from United Airlines: 205.174.16.0 - 205.174.23.255 [1] How does this happen? [2] Why does this happen? [3] Is this exploitable? What do you think? -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Please Please Help me...!
OK before u jum into NASA Tech...do this ping your internal machine from LRP yes or no ? no = fix it (cables, config etc..) ping internet from your lrp/internal machine yes or no ? no fix it ping LRP from anywhere out side of your network yes or no ? no = fix it.. (allow www trafic with 0.0.0.0/0 your lrp and internal web_computer) if you have no way out... do this ipchains -P forward ACCEPT ipchains -P input ACCEPT ipchains -P output ACCEPT ipchains -F ipchains -A forward -j MASQ -s 10.0.0.0/8 -d 0/0 -i eth0 this time portforward by hand ipmasqadm portfw -a -P tcp -L 111.222.333.444 80 -R 10.24.33.150 80 if u want now do ipchains -P forward DENY goto a internet_cafe...fireup IE6/netscape of what every type your ip address http://111.222.333.444 remember you are not allowed to do that form your internal Network OK...Please remember... then u have to do by http://10.24.33.150 u know what I mean... thats it baby... once everything working don't drink beer...time to setup your firewall rules in /etc/ipfilter.conf be sure to check /etc/network.conf too... if u still have a problem...talk to Charles, James...like real teches...or hire me...heheheeh good luck.. Upnet Joe - Original Message - From: barwals [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, March 09, 2002 6:24 AM Subject: [Leaf-user] Please Please Help me...! Hi everybody, Please Please help me! I'm trying to do it since last One month but could not then only I have sent a mail to this mailing list. I 'm running the Dachstein LEAF firewall. I'm not able to forwarding the external traffice which is coming to my valid IPaddr (eth0) to my internal web server which is a windows 2000 server. I have allready gone through all the related mailing list archive but could not solve the problem and hence I'm writing to this list. The error I'm getting in my browser is Connection faild Connection timed out. My configuration is as follows. EXTERN_IP=111.222.333.444 EXTERN_IF =eth0 INTERNAL_IP=10.24.33.224 INTERNAL_IF =eth1 INT_NET = 10.0.0.0/8 IPFWDING_KERNEL= FILTER_ON IPALWAYSDEFRAG_KERNEL = YES CONFIG_HOSTNAME = YES CONFIG_HOSTSFILE = YES CONFIG_DNS = NO IPFILTER_SWITCH = firewall SNMP_BLOCK = YES EXTERN_DHCP = NO EXTERN_DHCP = NO EXTERN_TCP_PORT0=0/0 www 111.222.333.444 INTERN_SERVERS=tcp_111.222.333.444_www_10.24.33.150_www My IPCHAINS RULES looks like they are accepting the connection at 111.222.333.444. But could not find the solution. Could anybody help me in that regard. When I see in weblet through brouser I'm seeing this. but no byte(packet) in Chain port forward policy. :: Masqueraded Connections :: IP masquerading entries prot expire source destination ports tcp 0:58.64 10.24.33.150 203.163.160.2 80 2678 (80) Regards . Thanks. Sudhir Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] martians on internal network ??? [LONG!]
Jeff Newmiller wrote: On Fri, 8 Mar 2002, Michael D. Schleif wrote: Jeff Newmiller wrote: On Fri, 8 Mar 2002, Michael D. Schleif wrote: We are seeing martians on internal networks on a regular basis. Usually, it is traceable to users logging into AOL over our high speed internet connections: 172.128.0.0 - 172.191.255.255 Today, we saw one from United Airlines: 205.174.16.0 - 205.174.23.255 [1] How does this happen? I often wonder how it happens that people who should know better fail to provide specific error and log messages and explain what they know about the particulars of the ip addresses, routes, machines and connections involved. It is hard to trust reports as sanitized as this. Jeff, I respect your intelligence and firewall skills; however, if you read exactly what I posted, then you will know exactly what there is to know. Troubleshooting is like a tree... if you only describe the trunk and one branch, we cannot be expected to describe the right twig for you to look at. I did not see your reply until after my reply to Matt. Again, allow me to apologize to everyone for my abrasiveness. Is it possible to ask a generic question on this list? I was trying to ask generic questions, answers to which can lead me to understand the extent of these issues and the direction to take in fixing the problems -- if, indeed, these issues are truly problems and require fixing. If I ``should know better'', then I am truly the dummy here, because I truly did not know what information to include -- hence, my closing ``What do you think?'' I do not see this as a firewall setup/configuration issue; but, I am willing to consider any compelling arguments. On the surface, the idea that packets should be generated within your LAN with source addresses outside your network would suggest something is seriously broken (accidentally or purposefully) with the workstation generating the packets. Yes. And, what information that will lead to resolving this issue remains unspecified. [2] Why does this happen? Speculation: if your AOL users are actually dialling into AOL while being on the network, they may be temporarily acquiring an IP from AOL, and Windows could possibly screw up and ships packets out the wrong interface. However, something would have to be pretty weird with the AOL software if it decided it had an AOL IP even if no dialup had occurred. There could possibly be overlap when a dialup connection was lost as well. Please, please, please, read my post and respond accordingly: `` ... users logging into AOL over our high speed internet connections ... '' I read that. See below. Or, even if they were, the questions remain the same -- what's the difference? Each interface is supposed to have an ip address. If the wrong IP address is appearing on an outbound packet, the first possibility that presents itself to my mind is that a port bound on one interface is somehow sending packets out on another interface. The second interface may not be a dialup interface... but it is an obvious one that you did not explicitly rule out in your first post. I thought that I had -- what phrase ought I to use, instead of ``high speed internet connection'', to convey this information? If some tunnelling is going on, then virtual interfaces could be involved. However, Occam's Razor suggests that the simplest solution is the most likely one. Since I am not aware of tunnelling in the described software, and dialups are very common with that software, I speculated. Yes, speculation can be powerful. I do not object to speculation. I did, however, bristle at ``people who should know better fail'' -- I did not, and still do not, know what information is required to resolve these issues. [3] Is this exploitable? Insufficient data. How much data will suffice? A smattering of log entries: Feb 26 08:17:36 redtrout kernel: martian source 0b49a2ac for , dev eth1 Feb 26 08:21:11 redtrout kernel: martian source 490b99ac for , dev eth1 [...] While you may feel like you are conveying some message about the unreasonableness of my request, you are actually spewing on a public mailing list. A few samples, with a summary of the interfaces involved, and the routing table for one of these AOL computers would be much more effective. Please, make such a suggestion earlier in your responses. I do not know about others; but, if I'm a dummy and do not know the proper way to present the problem, a simple suggestion like this -- upfront -- goes a long way toward effective communications. Again, it is difficult for me to know how much data to provide and at what point -- either I submit inadequate data or it is excessive. That is why, as a general rule, I search the archives first and, if that search proves fruitless,
Re: [Leaf-user] MSN MESSENGER FT
need more info about your network...and What is your Client PC xp or w2k, 98 ... I notice on XP if you have Firewall protection enable...you can't send files... I know ManyNetwork use Hardware Router/Firewalls, users having problems with UP/down Loads files... however Hackers got no problem nadda... Upnet Joe - Original Message - From: Jim Van Eeckhoutte [EMAIL PROTECTED] To: , [EMAIL PROTECTED] Sent: Saturday, March 09, 2002 2:06 AM Subject: [Leaf-user] MSN MESSENGER FT I know this is a non leaf question but you guys might be my only hope. Im using MikroTik RouterOS which is usin input , forward, and output chains with src-nat and dest-nat. I have it set up usint masq and nat for internal services . Heres my question: I have tried everything to get file transfer (msmessenger) to work, I can receive files but cant send them. Can you guys shed some light on how this process could work. MikroTik response is somewhat limited. ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] martians on internal network ???
Michael -- It is unlikely that there is a lot of AOL expertise here on this list (others, please correct me if I am wrong), so the most valuable information to provide here would be a better description of what users logging into AOL over our high speed internet connections means ... particularly the logging in part. I just went to www.aol.com and was offered there the option to enter a Screenname and Password, then sign on. Since I'm not an AOL member, I couldn't actually do this, but I poked around enough that I *think* the info is sent over an unencrypted (http, not https) connection. That's a jolly little security hole right there, to answer your question #3 in part. Whether a successful sign on creates additional security holes is unclear, since I can't test that level of access. In any case, I don't know if this is what the users at the offending workstations are doing, and really *you* are the only one in a position to find this out. So ... Are they running some proprietary AOL software that does secret things? (If so, what does sniffing the traffic tell you?) Are they just connecting to an http(s) site and authenticating themselves somehow? (Might this be launching spyware apps or the like?) Are they doing something else? (What?) I do note that you wrote ... We have been told that, apparently, logging into aol over a lan connection results in some kind of connection to a special aol network. I have never used aol and I do not understand this -- hence the first two questions. ... so please don't reply with one of your read what I wrote more carefully responses. Even if you don't know yet, only you are in a position to find out what the users at your client site are actually doing. We're troubleshooters here, not the Psychic Friends Network. As a general matter, if what you are looking for is ONLY someone who has already seen the exact problem you are seeing and knows the exact answer, then what you've sent up to now is fine (and I'm wasting both your and my time by replying), since it is probably enough to find such a person. But in that case, you might do better on an AOL support list than here. And I am certainly not the person whose help you want. If you want help analyzing something that is a new problem to all of us ... then my suggestion above is a good place to start. So are Jeff's suggestions (about reporting the routing table and such on an offending workstation when it is logged in to AOL). This would probably be a good topic to explore further, either here or on the -devel list, and that is why I am bothering to reply at all. It is (or may be) a concrete, and potentially widespread, instance of a general problem with firewalling ... what is the difference between a tunnel and a hole? If users can run software that punches hard-to-find holes in firewalls (and we know they can, as a general matter), what's a sysadmin to do? But for that sort of discussion to work, you need to be interested enough in exploring the problem with us, not just finding a known answer quickly, to share the sorts of information I mention above and that others have already suggested. Your call. Let me close with one specific response. You wrote: From the ``ll header'' entries that accompany each martian, we have identified the mac address of culprit workstations and determined that they are not dialing out on modems; but, even if they were, I do not see any change to my questioning. What is the difference? The difference is that holes caused by dialout workstations are old news, and there is really no way to address this problem at the firewall (except by blocking traffic routed through it with the martians rules, as you are already doing). So it's not really a LEAF issue. If, OTOH, the traffic occurs because users are tunneling through the firewall, it is at least possible in principle to address that at the firewall level. PS. After I finished this reply, I saw your latest response (to Jeff's messqge), in which you write: It maybe interesting to know that aol installs a special ``adapter'' that is purported to behave similarly to an hardware nic. In fact, on win9x, at least, it is next to the nic in network neighborhood properties and is near identically configured. This certainly suggests to me that AOL is somehow tunneling through your firewall, causing the behaviors you note, and creating the sort of hole that is at least potentially exploitable. When you have access to an offending workstation, perhaps you will be able to tell us if this characteristic applies to the sorts of logins your users are doing or just to AOL's dial-up service. At 10:53 AM 3/9/02 -0600, Michael D. Schleif wrote: I am sorry for offending everyone. I will proffer no excuses. I was in one of my bullheaded moods and acted inappropriately. Again, I am sorry. Is it possible to ask a generic question? In general, is
[Leaf-user] I am Happy to tell you all
Charles Steinkuehler's LEAF/LRP mixed Dachstein and EigerStein2BETA Router Firewall dhcpd dhclient dnscache weblet sshd ipsec VPN Pentium 125 with 128MB mem... 32MB IDE Flash Card from Lexmark Printer...heh 2 NICs attached to Internet using network bonding module... this is cool my Quake3 Exssive Server can handle 20 users...no single packet drop.. while doing other things like WEB, EMAIL, FTP, IPSEC VPN... i have 6 clients, doing all kind of yak napster..msn what not.. watch internet TV...oh boy... LRP is real busy , I love it.. i tried to do same thing with Linksys BEFSR41 Hardware Router no way however Linksys Router is good... but He can't beat LRP LRP is Linux he can do much more than Router thats why its fiton me... I would like to say Thanks to Linus Travoldus, Charles Steinkuehler, and all Linux Gurus...around the World... here is my network INTERNET-NoteBooks (Road Worrys) Web, Email, etc... all over the world | | SWITCH || LRP Router | | SWITCH-Clients here some out put from my router myrouter: -root- # uname -a Linux myrouter 2.2.19-3-LEAF #7 Sat Dec 1 14:00:22 CST 2001 i386 unknown myrouter: -root- # w 13:18:50 up 3 Days (76h), load average: 0.08 0.02 0.01 USER TTY PID TIMEON FROM root ttyp15051 63 192.168. myrouter: -root- # uptime 13:18:55 up 3 Days (76h), load average: 0.07 0.02 0.00 myrouter: -root- # ip r s 24.101.135.30 via 24.101.136.1 dev ipsec0 192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.1 24.101.136.0/24 dev bond0 proto kernel scope link src 24.101.136.77 24.101.136.0/24 dev ipsec0 proto kernel scope link src 24.101.136.77 10.0.10.0/24 dev eth3 proto kernel scope link src 10.0.10.1 default via 24.101.136.1 dev eth0 # ps aux USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND daemon1240 0.0 1.0 1964 1288 ? S Mar 6 0:00 /usr/sbin/dnscache root 1 0.0 0.2 756 364 ? S Mar 6 0:07 init [2] root 2 0.0 0.0 0 0 ? SW Mar 6 0:00 (kflushd) root 3 0.0 0.0 0 0 ? SW Mar 6 0:00 (kupdate) root 4 0.0 0.0 0 0 ? SW Mar 6 0:00 (kswapd) root 5 0.0 0.0 0 0 ? SW Mar 6 0:00 (keventd) root 663 0.0 0.1 1100 248 ? S Mar 6 0:00 update root 898 0.0 0.3 816 468 ? S Mar 6 1:06 /sbin/syslogd -m 240 root 900 0.0 0.5 1068 680 ? S Mar 6 0:00 /sbin/klogd root 904 0.0 0.3 776 388 ? S Mar 6 0:00 /usr/sbin/inetd root 908 0.0 0.1 720 220 ? S Mar 6 0:00 /usr/sbin/watchdog root 911 0.0 0.3 800 440 ? S Mar 6 0:00 /usr/sbin/cron root 1231 0.0 0.4 936 536 ? S Mar 6 0:00 /usr/sbin/dhclient eth0 eth1 root 1241 0.0 0.3 784 396 1 S Mar 6 0:00 /sbin/getty 38400 tty1 root 2459 0.0 0.2 824 360 ? S Mar 7 0:00 sh /usr/local/lib/ipsec/_plutorun --debug none --uniqueids yes --d root 2460 0.0 0.2 756 352 ? S Mar 7 0:00 logger -p daemon.error -t ipsec__plutorun root 2464 0.0 0.2 824 360 ? S Mar 7 0:00 sh /usr/local/lib/ipsec/_plutorun --debug none --uniqueids yes --d root 2465 0.0 0.2 824 356 ? S Mar 7 0:00 sh /usr/local/lib/ipsec/_plutoload --load %search --start %search root 2468 0.0 0.2 824 360 ? S Mar 7 0:00 sh /usr/local/lib/ipsec/_plutorun --debug none --uniqueids yes --d root 2469 0.0 0.5 1236 700 ? S Mar 7 0:38 /usr/local/lib/ipsec/pluto --nofork --debug-none --uniqueids root 3217 0.0 0.4 964 572 ? S Mar 7 0:00 /usr/sbin/dhcpd eth2 root 5042 0.0 0.6 1224 836 ? S12:13 0:01 sshd -i root 5051 0.0 0.2 844 368 p1 S12:15 0:00 -sh root 5132 0.0 0.3 840 472 p1 R13:25 0:00 ps aux myrouter: -root- Networking is FUN if anyone wanna check me here is my webaddress http://www.upnet.dhs.org/lrp/ UPNET JOE ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] routing more than 1 hop
Bob Pocius wrote: Sometimes LEAF distros are configured to block traffic destined for the private address space from going out eth0. It's designed that way because private addresses are in general for internal use only. Rarely, an ISP uses these, and adjustments are made to ipfilter.conf or wherever your rules are defined. That makes good sense, but I stripped Whorewall out to try to simplify things for myself. It's funny how the keys slip sometimes, huh :-) There's definitely no unsend button :-) Ok. Be aware that you're going to want to check your syslog a lot during this phase to see what's really going on. Hopefully, all denied or rejected packets will be logged and we can get somewhere. I'm deciding not to comment on the routes at all until you post the output of ifconfig -a on all four sites. I've included the useful data with each of the routing tables (I hope I didn't leave out anything that you were looking for). Yes, it looks complete, and it seems to make sense. I don't see any lo, localhost routes. Why not? Did you just omit them? There's also an occasion or two where I'd think the gateway would simply be 0.0.0.0, but I'm not convinced that's an issue. The routes look logical. I point that out inllne. Most likely, we're at the point of traceroute and ping to bang our heads against any rules that are getting in the way. I will mention that I don't get the concept of having both 10.10.1.254 and 10.10.1.40 assigned to the same eth0, for instance. I did this because that router is connected via 100Mb fibre to another building where the rest of the routing happens. eth0 on Site 1 connects to a switch, and 10.10.1.254 (my main gateway router) connects to a different port on that same switch. Ok. I get that now. As long as you're not using some really expensive 3COM switch or router that has traffic filtering/routing rules, we should be in good shape. Didn't you mention this exact setup worked with a full blown RH distro? If that's the case, I'm leaning more toward Shorewall, heh heh. Site 1: 10.10.1.0 eth0 10.10.1.40/24 eth1 192.168.1.254/24 Destination MaskGatewayDev 0.0.0.0 0.0.0.0 10.10.1.254eth0 (to internet) 10.10.1.0255.255.255.0 10.10.1.40 eth0 (wired interface) 10.10.12.0 255.255.255.0 192.168.1.253 eth1 (wireless to site 2) 10.10.13.0 255.255.255.0 192.168.1.253 eth1 (wireless to site 2) 192.168.1.0 255.255.255.0 192.168.1.254 eth1 (wireless interface) 192.168.2.0 255.255.255.0 192.168.1.253 eth1 (wireless to site 2) Above is a line that I thought would have 0.0.0.0 for the gateway, like this 192.168.1.0 255.255.255.0 0.0.0.0eth1 (wireless interface) Because you're not saying to the kernel that 192.168.1.254 is *another router*, *another gateway* or a thing that does routing, but rather you're just trying to say, put all that traffic out eth1. Although I know netstat and routing in general, I've never set something up this complicated and can't be sure. I just know how a routing table usually looks, and it does not specify the external nic ip address for routes like this one. Here's mine, for example: Destination Gateway Genmask FlagsIface 10.1.1.00.0.0.0 255.255.255.0 Ueth1 63.194.213.00.0.0.0 255.255.255.0 Ueth0 127.0.0.0 0.0.0.0 255.0.0.0 Ulo 0.0.0.0 63.194.213.254 0.0.0.0 UG eth0 Now it's done on Oxygen. So it looks a bit different, but still. To be honest, I think ip route show does a better job of detailing the low level workings, but it's hard to read. Ok then. I'll leave it at this point until we find out about the localhost route (127.0.0.0/8) sort of thing and the 0.0.0.0 gateway issue. If that's not it, then try a ping from one end to the other. Try to decipher if NAT is occuring and getting in the way. Try to get all packets logged into your syslog. You can write the rules yourself for that. 1) Set default policies to ACCEPT 2) Flush all routes 3) Add a rule that logs all traffic in one direction for one nic, and watch the log to see if the traffic gets through that nic. Let me know if you need examples of that. Btw, how do you pronounce Pocius? Poe'-shuss? Poe'-she-us? Regards, Matthew Site 2a: 10.10.12.0 eth0 10.10.12.254/24 eth1 192.168.1.253/24 Destination MaskGatewayDev 0.0.0.0 0.0.0.0 192.168.1.254 eth1 (wireless to site 1) 10.10.12.0 255.255.255.0 10.10.12.254 eth0 (wired interface) 10.10.13.0 255.255.255.0 10.10.12.253 eth0 (to other local router) 192.168.1.0 255.255.255.0 192.168.1.253 eth1 (wireless interface) 192.168.2.0 255.255.255.0 10.10.12.253 eth0 (to other local router) (Site 2a and 2b are connected to the same switch)
RE: [Leaf-user] I am Happy to tell you all
2 NICs attached to Internet using network bonding module. Can u please gimme some INFO on above mention qoute. thnks -Original Message- From: Upali Weerasinghe [mailto:[EMAIL PROTECTED]] Sent: Saturday, March 09, 2002 19:36 To: [EMAIL PROTECTED] Subject: [Leaf-user] I am Happy to tell you all Charles Steinkuehler's LEAF/LRP mixed Dachstein and EigerStein2BETA Router Firewall dhcpd dhclient dnscache weblet sshd ipsec VPN Pentium 125 with 128MB mem... 32MB IDE Flash Card from Lexmark Printer...heh 2 NICs attached to Internet using network bonding module... this is cool my Quake3 Exssive Server can handle 20 users...no single packet drop.. while doing other things like WEB, EMAIL, FTP, IPSEC VPN... i have 6 clients, doing all kind of yak napster..msn what not.. watch internet TV...oh boy... LRP is real busy , I love it.. i tried to do same thing with Linksys BEFSR41 Hardware Router no way however Linksys Router is good... but He can't beat LRP LRP is Linux he can do much more than Router thats why its fiton me... I would like to say Thanks to Linus Travoldus, Charles Steinkuehler, and all Linux Gurus...around the World... here is my network INTERNET-NoteBooks (Road Worrys) Web, Email, etc... all over the world | | SWITCH || LRP Router | | SWITCH-Clients here some out put from my router myrouter: -root- # uname -a Linux myrouter 2.2.19-3-LEAF #7 Sat Dec 1 14:00:22 CST 2001 i386 unknown myrouter: -root- # w 13:18:50 up 3 Days (76h), load average: 0.08 0.02 0.01 USER TTY PID TIMEON FROM root ttyp15051 63 192.168. myrouter: -root- # uptime 13:18:55 up 3 Days (76h), load average: 0.07 0.02 0.00 myrouter: -root- # ip r s 24.101.135.30 via 24.101.136.1 dev ipsec0 192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.1 24.101.136.0/24 dev bond0 proto kernel scope link src 24.101.136.77 24.101.136.0/24 dev ipsec0 proto kernel scope link src 24.101.136.77 10.0.10.0/24 dev eth3 proto kernel scope link src 10.0.10.1 default via 24.101.136.1 dev eth0 # ps aux USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND daemon1240 0.0 1.0 1964 1288 ? S Mar 6 0:00 /usr/sbin/dnscache root 1 0.0 0.2 756 364 ? S Mar 6 0:07 init [2] root 2 0.0 0.0 0 0 ? SW Mar 6 0:00 (kflushd) root 3 0.0 0.0 0 0 ? SW Mar 6 0:00 (kupdate) root 4 0.0 0.0 0 0 ? SW Mar 6 0:00 (kswapd) root 5 0.0 0.0 0 0 ? SW Mar 6 0:00 (keventd) root 663 0.0 0.1 1100 248 ? S Mar 6 0:00 update root 898 0.0 0.3 816 468 ? S Mar 6 1:06 /sbin/syslogd -m 240 root 900 0.0 0.5 1068 680 ? S Mar 6 0:00 /sbin/klogd root 904 0.0 0.3 776 388 ? S Mar 6 0:00 /usr/sbin/inetd root 908 0.0 0.1 720 220 ? S Mar 6 0:00 /usr/sbin/watchdog root 911 0.0 0.3 800 440 ? S Mar 6 0:00 /usr/sbin/cron root 1231 0.0 0.4 936 536 ? S Mar 6 0:00 /usr/sbin/dhclient eth0 eth1 root 1241 0.0 0.3 784 396 1 S Mar 6 0:00 /sbin/getty 38400 tty1 root 2459 0.0 0.2 824 360 ? S Mar 7 0:00 sh /usr/local/lib/ipsec/_plutorun --debug none --uniqueids yes --d root 2460 0.0 0.2 756 352 ? S Mar 7 0:00 logger -p daemon.error -t ipsec__plutorun root 2464 0.0 0.2 824 360 ? S Mar 7 0:00 sh /usr/local/lib/ipsec/_plutorun --debug none --uniqueids yes --d root 2465 0.0 0.2 824 356 ? S Mar 7 0:00 sh /usr/local/lib/ipsec/_plutoload --load %search --start %search root 2468 0.0 0.2 824 360 ? S Mar 7 0:00 sh /usr/local/lib/ipsec/_plutorun --debug none --uniqueids yes --d root 2469 0.0 0.5 1236 700 ? S Mar 7 0:38 /usr/local/lib/ipsec/pluto --nofork --debug-none --uniqueids root 3217 0.0 0.4 964 572 ? S Mar 7 0:00 /usr/sbin/dhcpd eth2 root 5042 0.0 0.6 1224 836 ? S12:13 0:01 sshd -i root 5051 0.0 0.2 844 368 p1 S12:15 0:00 -sh root 5132 0.0 0.3 840 472 p1 R13:25 0:00 ps aux myrouter: -root- Networking is FUN if anyone wanna check me here is my webaddress http://www.upnet.dhs.org/lrp/ UPNET JOE ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] ipsec errors
i did the below, and restarted ipsec, and got an error about eth0, so i changed it back, then I started scanning the /var/log/syslog and noticed that port 500 was being denied : Mar 9 14:46:43 firewall kernel: Packet log: input DENY eth0 PROTO=17 66.25.18.71:500 66.25.44.147:500 L=204 S=0x00 I=31 F=0x T=62 (#41) now I modifed was able to get this to stop being denied on one side, but I cannot do it on the home side. I have a feeling I am just one step away, can someone push me in the right direction... joey - Original Message - From: Charles Steinkuehler [EMAIL PROTECTED] To: [EMAIL PROTECTED]; LRP Support [EMAIL PROTECTED] Sent: Friday, March 08, 2002 5:46 PM Subject: Re: [Leaf-user] ipsec errors Where do I check to see if protocol 50 packets are being allowed through? I'll be working more on it this weekend.. I'd really like to get this working so I'll try just about anything.. even possibly step/by/step support via phone (I'd beg someone to call my 800 number for a little assistance... The primary source is the output of net ipfilter list, which shows you exactly how your firewall rules are setup. You're looking for a line allowing protocol 50, preferrably with non-zero byte/packet counts: 1843 356K ACCEPT 50 -- 0xFF 0x00 eth0 snip You open protocol 50 traffic with the following in network.conf: EXTERN_PROTO0=50 0/0 Of course, you can change the 0/0 (the entire internet) to the address (or network) of your remote VPN link, if it's static. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] martians on internal network ???
Thank you. Although, I can be pretty daft on occasion, I am trying to ``do the right thing.'' It is not always easy knowing what that maybe in a variety of contexts. For me, from my humble experience, when I do not know something, it works best to try to summarize what it is that I know, especially when I am asking for help. Either this is an erroneous process on this list or I did a very poor job of communicating, or both . . . Whether or not I am believed, I always try to present the minimum amount of data/information necessary to get to the next step. For example, in my original post, I hoped to either find somebody experienced with this problem (highest hope) or, in lieu of that, suggestions on where to go and what to do next. Finally, today, I am receiving responses that address the latter. Thank you. Ray Olszewski wrote: Michael -- It is unlikely that there is a lot of AOL expertise here on this list (others, please correct me if I am wrong), so the most valuable information to provide here would be a better description of what users logging into AOL over our high speed internet connections means ... particularly the logging in part. OK -- good point. [ snip ] In any case, I don't know if this is what the users at the offending workstations are doing, and really *you* are the only one in a position to find this out. So ... Are they running some proprietary AOL software that does secret things? (If so, what does sniffing the traffic tell you?) Are they just connecting to an http(s) site and authenticating themselves somehow? (Might this be launching spyware apps or the like?) Are they doing something else? (What?) OK. I do note that you wrote ... We have been told that, apparently, logging into aol over a lan connection results in some kind of connection to a special aol network. I have never used aol and I do not understand this -- hence the first two questions. ... so please don't reply with one of your read what I wrote more carefully responses. Even if you don't know yet, only you are in a position to find out what the users at your client site are actually doing. We're troubleshooters here, not the Psychic Friends Network. As a general matter, if what you are looking for is ONLY someone who has already seen the exact problem you are seeing and knows the exact answer, then what you've sent up to now is fine (and I'm wasting both your and my time by replying), since it is probably enough to find such a person. But in that case, you might do better on an AOL support list than here. And I am certainly not the person whose help you want. To me, it is obvious that that is what I wanted; but, also obviously, it was not so obvious to those who responded. I am sorry for my poor communications. If you want help analyzing something that is a new problem to all of us ... then my suggestion above is a good place to start. So are Jeff's suggestions (about reporting the routing table and such on an offending workstation when it is logged in to AOL). Just as you say, ``We're ... not the Psychic Friends Network.'' Nor am I! What does it hurt to test the waters for somebody already experienced in addressing these issues? If there is one, I cannot know it without asking; nor can I know that there is not one without asking. However, if there is, then a considerable amount of bandwidth is saved by asking brief questions. Also, I, for one, learn alot regarding where to go and what to do next by probing List Services (20!), not the least of which is this one. I do not and cannot know everything, so I ask questions, starting simple and progressing in complexity as need arises. Is this a bad process? This would probably be a good topic to explore further, either here or on the -devel list, and that is why I am bothering to reply at all. It is (or may be) a concrete, and potentially widespread, instance of a general problem with firewalling ... what is the difference between a tunnel and a hole? If users can run software that punches hard-to-find holes in firewalls (and we know they can, as a general matter), what's a sysadmin to do? YES! This is exactly why I posted, yesterday. Prior to yesterday, I had only noticed the aol connections; and, being busy managing other fires across thousands of users, hundreds of servers and dozens of networks, I put off indepth root-cause analysis of these issues and assumed that the martian-blocking nature of the firewalls was adequate protection. Then, I noticed the United Airlines log entry! Yesterday, I questioned that assumption, took note of what I did know, searched the archives and posted three (3) simple questions. But for that sort of discussion to work, you need to be interested enough in exploring the problem with us, not just finding a known answer quickly, to share the sorts of information I
Re: [Leaf-user] martians on internal network ???
Ray Olszewski wrote: This would probably be a good topic to explore further, either here or on the -devel list, and that is why I am bothering to reply at all. It is (or may be) a concrete, and potentially widespread, instance of a general problem with firewalling ... what is the difference between a tunnel and a hole? If users can run software that punches hard-to-find holes in firewalls (and we know they can, as a general matter), what's a sysadmin to do? Yup, an interesting topic! My personal ten cents is that too many sysadmins are not doing a good network analysis to start with... what needs to be protected, why? What has to talk to the outside and why? A combination of firewalls, proxy servers, ipsec, internal virtual networks and tunnels, stateful packet inspection, etc., while not guaranteeing anything, does make it possible to make a graded effort in protecting within a view of specific guideline criteria. Anyone in this line of work for a living knows that all the software running inside your network by your ever-faithful users/clients is the stuff that really gives you the fits and makes for nightmares at night. Keeping stuff inside is at least just as important as keeping stuff outside too. The comment above on internal clients running tunneling software. you will have to go to stateful inspection in addition enforcing bottlenecks via proxies or other methods to restrict, in order to control or limit them... ie firewall rules, etc., have to be just as tight on what goes out (protocol IP)as what comes in. Like my bumper sticker says, Linux, it's not just for breakfast anymore!, that breakfast bowl that used to hold all of it has sort of been outgrown a little bit as both linux, and internet/networking technologies have just exploded in size. Firewalling and security isn't very simple anymore either. Requires a continual learning curve for the administrator. Watching the list, there's a number of people that want multiple apps running on the firewall I've never done that in the business world as I'm one of the ones that falls on the side that a firewall is a firewall. If you need somthing else, fire off another server. One size doesn't fit all, and goes back to my original and main point here -- You have to do a strenuous network analysis to determine what your security posture requirements are, and then build it. Keep it modular, and layered. It makes it much easier than rebuilding an entire network when it comes time to change your security model. Just some comments learned through several years in the commercial world, maybe it will help someone, maybe it won't. grin At any rate, to Charles and the others who build and maintain leaf variants, your efforts are truly appreciated. Sam ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] martians on internal network ???
A selective reply ... At 02:01 PM 3/9/02 -0600, Michael D. Schleif wrote: [...] The difference is that holes caused by dialout workstations are old news, and there is really no way to address this problem at the firewall (except by blocking traffic routed through it with the martians rules, as you are already doing). So it's not really a LEAF issue. Perhaps, this is ``old news'' to you; but, not to me -- hence, my question. Again, I do not find this in the troubleshooting docs, nor did I find such in the archives. Please, point me to the documentation and I will rtfm . . . This is not a LEAF issue, so it is unlikely to be covered in any LEAF materials. It is abasic routing observation that I would think doesn't need explaining to any experienced sysadmin -- if you have 2 routes out of the LAN (in this case, one via a LEAF router, the other via a dialup connection), both routes need to be protected. It's so old a problem that I'm at a loss to figure out what to say about it, let alone to suggest any docs that explain it. What is, perhaps, less obvious is that a tunneled route is still a route, and its security needs to be addressed as well. That is what is different, and interesting, about the tunneled AOL topic you introduced here. [ snip ] It maybe interesting to know that aol installs a special ``adapter'' that is purported to behave similarly to an hardware nic. In fact, on win9x, at least, it is next to the nic in network neighborhood properties and is near identically configured. This certainly suggests to me that AOL is somehow tunneling through your firewall, causing the behaviors you note, and creating the sort of hole that is at least potentially exploitable. When you have access to an offending workstation, perhaps you will be able to tell us if this characteristic applies to the sorts of logins your users are doing or just to AOL's dial-up service. Thank you, for this useful suggestion. Do you know how to quantify this? What do you mean by quantify in this context? Either the special adapter you refer to is present or it is not. If it is present, either it is used by this connection or it is not. These are threshhold questions, not quantitative ones. Also, since I do not know everything there is to know about networks and quantifying everything quantifiable about same, regarding your sniffer questions, can you describe a simple, open source process to accomplish these tasks? The usual Linux apps for sniffing are tcpdump and sniffit; I suppose there are Windows-based sniffers too, but I'm not acquainted with them. Any full-size Linux distro will include them, as well as specialized small distros like Trinux and tomsrtbt (look for them at www.ibiblio.org or via any search engine). I think David may have packaged tcpdump for Oxygen, but I'm not sure, since I don't use LEAF in heavyweight settings ... but you can check that as easily as I can. -- Never tell me the odds!--- Ray Olszewski-- Han Solo Palo Alto, CA[EMAIL PROTECTED] ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Multicast Routing
Yes i had compiled the kernel for multicast support from the fist time becouse i plan to use multicast. But when i try to find some multicasting software were the problem. I try to find mrouted becouse this support other protocols than PIM. I have others cisco router. The problem is: if this PIM sparse mode multicast daemon can interact with the router cisco serie 2500. If yes, I thanks to you if you can compile and make the lrp package pimd.lrp for me. From: Dan Mønster [EMAIL PROTECTED] To: cntv1 cntv1 [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: [Leaf-user] Multicast Routing Date: Fri, 8 Mar 2002 21:18:53 +0100 (MET) Hi, Can someone tell me where i would find mrouted.lrp or some other lrp that support multicasting routing protocolos. I made an .lrp package of pimd, which is a PIM Sparse Mode multicast daemon. I had to patch and compile my own kernel as well in order to get multicast support. Do: echo 1 /proc/sys/net/ipv4/conf/all/mc_forwarding; cat /proc/sys/net/ipv4/conf/all/mc_forwarding to see if your kernel supports multicast forwarding (if my memory serves me right, since I do not have access to my lrp box right now). So if you have multicast enabled I can probably compile and make a pimd.lrp package for you. I also have a Linux 2.2.19 LRP kernel with multicast enabled that might be useful to you. -Dan _ Dan Mønster, PhD E-mail: [EMAIL PROTECTED] UNI·C, Research Phone: (+45) 8937 6621 Olof Palmes Allé 38 Fax: (+45) 8937 6677 DK-8200 Århus N, DenmarkWWW: http://www.uni-c.dk _ ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user _ Con MSN Hotmail súmese al servicio de correo electrónico más grande del mundo. http://www.hotmail.com/ES ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] I am Happy to tell you all
Ok u know howto complie your kernel and u must have a flash or hard_drive installed on your LRP system... then follow this.. Linux Bonding Driver mini-howto Initial release : Thomas Davis tadavis at lbl.gov Corrections, HA extensions : 2000/10/03-15 : - Willy Tarreau willy at meta-x.org - Constantine Gavrilov const-g at xpert.com Note : -- The bonding driver originally came from Donald Becker's beowulf patches for kernel 2.0. It has changed quite a bit since, and the original tools from extreme-linux and beowulf sites will not work with this version of the driver. For new versions of the driver, patches for older kernels and the updated userspace tools, please follow the links at the end of this file. Installation 1) Build kernel with the bonding driver --- For the latest version of the bonding driver, use kernel 2.2.18 or above (otherwise you will need to apply a patch). Configure kernel with `make menuconfig/xconfig/config', and select Bonding driver support in the Network device support section. It is recommended to configure the driver as module since it is currently the only way to pass parameters to the driver and configure more than one bonding device. Build and install the new kernel and modules. 2) Get and install the userspace tools -- This version of the bonding driver requires updated ifenslave program. The original one from extreme-linux and beowulf will not work. Kernels 2.2.18 and above include the updated version of ifenslave.c in Documentation/network directory. For older kernels, please follow the links at the end of this file. To install ifenslave.c, do: # gcc -O2 -s -o ifenslave ifenslave.c # cp ifenslave /sbin/ifenslave 3) Configure your system Also see the following section on the module parameters. You will need to add at least the following line to /etc/conf.modules (or /etc/modules.conf): alias bond0 bonding Use standard distribution techniques to define bond0 network interface. For example, on modern RedHat distributions, create ifcfg-bond0 file in /etc/sysconfig/network-scripts directory that looks like this: DEVICE=bond0 IPADDR=192.168.1.1 NETMASK=255.255.255.0 NETWORK=192.168.1.0 BROADCAST=192.168.1.255 ONBOOT=yes BOOTPROTO=none USERCTL=no (put the appropriate values for you network instead of 192.168.1). All interfaces that are part of the trunk, should have SLAVE and MASTER definitions. For example, in the case of RedHat, if you wish to make eth0 and eth1 (or other interfaces) a part of the bonding interface bond0, their config files (ifcfg-eth0, ifcfg-eth1, etc.) should look like this: DEVICE=eth0 USERCTL=no ONBOOT=yes MASTER=bond0 SLAVE=yes BOOTPROTO=none (use DEVICE=eth1 for eth1 and MASTER=bond1 for bond1 if you have configured second bonding interface). Restart the networking subsystem or just bring up the bonding device if your administration tools allow it. Otherwise, reboot. (For the case of RedHat distros, you can do `ifup bond0' or `/etc/rc.d/init.d/network restart'.) If the administration tools of your distribution do not support master/slave notation in configuration of network interfaces, you will need to configure the bonding device with the following commands manually: # /sbin/ifconfig bond0 192.168.1.1 up # /sbin/ifenslave bond0 eth0 # /sbin/ifenslave bond0 eth1 (substitute 192.168.1.1 with your IP address and add custom network and custom netmask to the arguments of ifconfig if required). You can then create a script with these commands and put it into the appropriate rc directory. 4) Module parameters. - The following module parameters can be passed: mode= Possible values are 0 (round robin policy, default) and 1 (active backup policy). See HA section for additional info. miimon= Use integer value for the frequency (in ms) of MII link monitoring. Zero value is default and means the link monitoring will be disabled. A good value is 100 if you wish to use link monitoring. See HA section for additional info. downdelay= Use integer value for delaying disabling a link by this number (in ms) after the link failure has been detected. Must be a multiple of miimon. Default value is zero. See HA section for additional info. updelay= Use integer value for delaying enabling a link by this number (in ms) after the link up status has been detected. Must be a multiple of miimon. Default value is zero. See HA section for additional info. If you need to configure several bonding devices, the driver must be loaded several times. I.e. for two bonding devices, your /etc/conf.modules must look like this: alias bond0 bonding alias bond1 bonding options bond0 miimon=100 options bond1 -o bonding1 miimon=100 5) Testing configuration You can test the configuration and transmit policy with ifconfig. For example, for round
Re: [Leaf-user] martians on internal network ???
I don't know if this will approach the problem being asked to help much, but I did reverse engineer the AOL software many years ago to connect with Linux. You can only connect to AOL via a special proxy adapter that is integrated with their software. The martian errors are due to the built in advertising (pop-up ads and the the like) being run on internal servers that are not resolvable by internet URL. If someone clicks on one of these, the information is sent to the server holding the information (internal). There may be other servers (such as American Airlines) that are also built in to their proxy, but rest assured that these errors are a part of the AOL proxy and you won't be able to do much about it unless you can get AOL to fix their software/practices to deal with your filtering. Maybe running one of the available SOCKS proxies packages would reduce the martian errors, but I haven't dealt with the said company in any respect for several years, so I don't know. Your only hope is cooperation with AOL itself (pretty pointless) or backwards engineering their compiled software and building your own proxy adapter if the available ones do not help. I hope this helps, ~Lynn Avants ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] martians on internal network ???
guitarlynn wrote: I don't know if this will approach the problem being asked to help much, but I did reverse engineer the AOL software many years ago to connect with Linux. You can only connect to AOL via a special proxy adapter that is integrated with their software. The martian errors are due to the built in advertising (pop-up ads and the the like) being run on internal servers that are not resolvable by internet URL. If someone clicks on one of these, the information is sent to the server holding the information (internal). There may be other servers (such as American Airlines) that are also built in to their proxy, but rest assured that these errors are a part of the AOL proxy and you won't be able to do much about it unless you can get AOL to fix their software/practices to deal with your filtering. See? There is useful information on this list regarding this issue! Regardless how exhaustive this example maybe, it directly addresses my first two question. Thank you. Maybe running one of the available SOCKS proxies packages would reduce the martian errors, but I haven't dealt with the said company in any respect for several years, so I don't know. Reducing these particular martian errors is moot. The real question is my third, Is this exploitable? If not, then we can live with spurious martian errors. If -- conceivably -- it is exploitable, then it warrants redirecting resources to eliminating the underlying problem. Treating symptoms rarely contributes value. Resolving the root-cause always eliminates the symptoms ; So, my question remains, assuming your response to my first two questions, is this -- conceivably -- exploitable? If some maybe and others not, how can we differentiate between them? Your only hope is cooperation with AOL itself (pretty pointless) or backwards engineering their compiled software and building your own proxy adapter if the available ones do not help. I hope this helps, Yes. -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] martians on internal network ???
At 2002-03-09 14:01 -0600, Michael D. Schleif wrote: Also, since I do not know everything there is to know about networks and quantifying everything quantifiable about same, regarding your sniffer questions, can you describe a simple, open source process to accomplish these tasks? Michael, The best Security Audit OSS is Nessus, and the three best network traffic/protocol analyzers are: Ethereal, IPTraf, and Tcpdump. Nessus http://www.nessus.org/ Ethereal http://www.ethereal.com/ IPTraf http://cebu.mozcom.com/riker/iptraf/ Tcpdump http://www.tcpdump.org/ Kismet is supposed to be good for 802.11b networks. http://www.kismetwireless.net/ Oxygen can be used as a telemetry box with tcpdump. Ask David for the details. -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] DNScache and hosts config question
Scott C. Best wrote: Heyaz. So I'm using a fairly stock DS relase, and I've a question about properly setting up dnscache and my host entries in network.conf. So, these host entries are visible from the DS system. How can I keep my LAN machines from making PTR? requests to my ISP's DNS when trying to get host names for internal LAN machines? How do your LAN machines know what is in /etc/hosts on you DS system? How is your dns resolver setup on these LAN machines? If each LAN machine has entries for each other in its own hosts file, then it should not need to query dnscache? What am I missing? I've setup the HOSTS section of network.conf to give a hostname to my private.network collection, but I can still see the network traffic (using tcpdump) leaving my LAN. Did I miss setting something for dnscache, to tell it to use /etc/hosts for machines in the private.network domain? Thanks in advance for any leads. -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] martians on internal network ???
Mike Noyes wrote: At 2002-03-09 14:01 -0600, Michael D. Schleif wrote: Also, since I do not know everything there is to know about networks and quantifying everything quantifiable about same, regarding your sniffer questions, can you describe a simple, open source process to accomplish these tasks? Michael, The best Security Audit OSS is Nessus, and the three best network traffic/protocol analyzers are: Ethereal, IPTraf, and Tcpdump. Nessus http://www.nessus.org/ Ethereal http://www.ethereal.com/ IPTraf http://cebu.mozcom.com/riker/iptraf/ Tcpdump http://www.tcpdump.org/ Kismet is supposed to be good for 802.11b networks. http://www.kismetwireless.net/ Oxygen can be used as a telemetry box with tcpdump. Ask David for the details. Yes, the tools are useful and it is excellent that we will now find this fine list in the archives. However, having the tools is one thing and having a sound process by which to use said tools is quite another. Sometimes, the logistics involved in properly setting up an investigative environment is the single most daunting task. Since I do not have direct access to the offending workstations and I cannot predict when a potential offender will actually offend, I must either expend a great deal of my own sparsely available resources or I need rely on effective instructions to the naive user of said offending system. Again, this is a very good list of tools that is readily visible from the archives . . . -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] martians on internal network ???
It maybe interesting to know that aol installs a special ``adapter'' that is purported to behave similarly to an hardware nic. In fact, on win9x, at least, it is next to the nic in network neighborhood properties and is near identically configured. As mentioned in other replies, and strenghtened by the above, it sure sounds like AOL is setting up a virtual network (or tunnel) of some sort from the client system to somewhere in AOL land. One piece of behavior I've noticed on Windows systems with multiple network interfaces, is broadcast packets (DHCP packets in my case) seem to be sent out *ALL* interfaces, with the same source IP used on all packets. I first noticed this when I put an LRP system on the same upstream network as an NT Proxy server...I kept getting martian packets with source IP's of the NT Proxy server's internal network interface...the errant packets were DHCP responses to clients, probably being sent out all currently connected interfaces as a side affect of Windows tendancy to use broadcast packets for basic connectivity, and not enough wire-level sniffers running in Redmond... Anyway, I suspect this is what's happening with at least some of your martians...most of them looked like they're headed for the all-ones broadcast IP. I don't know why the other martians are showing up...I'm not that familiar with the MS networking stack, and how windows systems handle routing, forwarding, etc. As mentioned elsewhere, apparently the AOL traffic is creating a tunnel through your firewall for it's traffic, which fundamentally represents a 'back door' to your internal net. Anyone seen a recent security review of the AOL client source code, to know if this is safe or not? Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] DNScache and hosts config question
Michael: Heya. Each of the LAN machines gets a DHCP lease from the DS box, with the DS box indicated as the DNS server. Only the DS box has the /etc/hosts entries. For example, in the /etc/hosts file it reads: 192.168.123.1 pc.private.network pc1 192.168.123.2 winnt.private.network winnt I can see my WinNT Box (at .2) query the DS box for a reverse-lookup (PTR?) for 1.123.168.192, and I cannot see that the DH box replying with pc.private.network. Hope this helps clarify. -Scott On Sat, 9 Mar 2002, Michael D. Schleif wrote: Scott C. Best wrote: Heyaz. So I'm using a fairly stock DS relase, and I've a question about properly setting up dnscache and my host entries in network.conf. So, these host entries are visible from the DS system. How can I keep my LAN machines from making PTR? requests to my ISP's DNS when trying to get host names for internal LAN machines? How do your LAN machines know what is in /etc/hosts on you DS system? How is your dns resolver setup on these LAN machines? If each LAN machine has entries for each other in its own hosts file, then it should not need to query dnscache? What am I missing? I've setup the HOSTS section of network.conf to give a hostname to my private.network collection, but I can still see the network traffic (using tcpdump) leaving my LAN. Did I miss setting something for dnscache, to tell it to use /etc/hosts for machines in the private.network domain? Thanks in advance for any leads. ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] DCD Port forwarding not working
Hi all,
I'm still having a problem with port forwarding packets to the internal web
server... I am on a Cox network that supposedly blocks packets coming inward
via port 80. I've set up an account with DynDNS that forwards packets
directed at http://www.cybersampson.com to http://www2.cybersampson.com:8080.
I am getting an error message that essentially says connection request
refused.
Here is the data for analysis:
Running DCD 1.02 on a system with 2 NICs.
NETWORK.CONF
snip
# Traffic to completely ignore...define here to prevent filling your logs
# Space seperated list: protocol_srcip[/mask][_dstport]
#SILENT_DENY=udp_207.235.84.1_route udp_207.235.84.0/24_37
SILENT_DENY=udp_10.8.238.1_68 tcp_10.8.238.1_68 icmp_192.168.100.1_65535
# Extra rule scripts added by Charles Steinkuehler to more easily support
# non-standard extentions of the pre-configured ipchains rules
IPCH_IN=/etc/ipchains.input
IPCH_FWD=/etc/ipchains.forward
IPCH_OUT=/etc/ipchains.output
# ICMP types to open
# Indexed list: SrcAddr/Mask type [ DestAddr[/DestMask] ]
#EXTERN_ICMP_PORT0=0/0 : 1.1.1.12
## UDP Services open to outside world
# Space seperated list: srcip/mask_dstport
# NOTE: bootpc port is used for dhcp client
# EXTERN_UDP_PORTS=0/0_domain 0/0_bootpc
EXTERN_UDP_PORTS=0/0_bootpc
# -or-
# Indexed list: SrcAddr/Mask port [ DestAddr[/DestMask] ]
#EXTERN_UDP_PORT0=0/0 domain
#EXTERN_UDP_PORT1=5.6.7.8 500 1.1.1.12
# TCP services open to outside world
# Space seperated list: srcip/mask_dstport
#EXTERN_TCP_PORTS=216.70.236.234/29_ssh 0/0_www 0/0_1023 0/0_8080
# -or-
# Indexed list: SrcAddr/Mask port [ DestAddr[/DestMask] ]
#EXTERN_TCP_PORT0=5.6.7.8 domain 1.1.1.12
#EXTERN_TCP_PORT1=0/0 www
EXTERN_TCP_PORT0=216.70.236.236/29 ssh
EXTERN_TCP_PORT1=0/0 www
EXTERN_TCP_PORT2=0/0 8080
#EXTERN_TCP_PORT3=0/0 8080
# Generic Services open to outside world
# Space seperated list: protocol_srcip/mask_dstport
#EXTERN_PORTS=50_5.6.7.8 51_5.6.7.8
# -or-
# Indexed list: Protocol SrcAddr/Mask [ DestAddr[/DestMask] ]
#EXTERN_PROTO0=50 5.6.7.8/32
#EXTERN_PROTO1=51 5.6.7.8/32
#EXTERN_PROTO0=8080 0/0 192.168.1.1/32
##
#
# Port Forwarding
##
#
# Remember to open appropriate holes in the firewall rules, above
# Uncomment following for port-forwarded internal services.
# The following is an example of what should be put here.
# Tuples are as follows:
# protocol_local-ip_local-port_remote-ip_remote-port
#INTERN_SERVERS=tcp_${EXTERN_IP}_ftp_192.168.1.200_ftp
tcp_${EXTERN_IP}_smtp_19
#INTERN_SERVERS=tcp_${EXTERN_IP}_8080_192.168.1.200_80
# These lines use the primary external IP address...if you need to
port-forward
# an aliased IP address, use the INTERN_SERVERS setting above
#INTERN_FTP_SERVER=192.168.1.200# Internal FTP server to make
available
INTERN_WWW_SERVER=192.168.1.200 # Internal WWW server to make
available
#INTERN_SMTP_SERVER=192.168.1.200 # Internal SMTP server to make
available
#INTERN_POP3_SERVER=192.168.1.200 # Internal POP3 server to make
available
#INTERN_IMAP_SERVER=192.168.1.200 # Internal IMAP server to make
available
#INTERN_SSH_SERVER=192.168.1.200# Internal SSH server to make
available
#EXTERN_SSH_PORT=24 # External port to use for internal
SSH
# Advanced settings: parameters passed directly to portfw and autofw
# Indexed list: ipmasqadm portfw options
#INTERN_SERVER0=-a -P PROTO -L LADDR LPORT -R RADDR RPORT [-p PREF]
INTERN_SERVER0=tcp ${EXTERN_IP} 8080 192.168.1.200 80
# Indexed list: ipmasqadm autofw options
#INTERN_AUTOFW0=-A -r tcp 2 20050 -h 192.168.1.1
#INTERN_AUTOFW0=-A -r tcp 8080 -h 192.168.1.200
##
#
# DMZ setup (optional)
##
#
# Whether you want a DMZ or not (YES, PROXY, NAT, PRIVATE, NO)
DMZ_SWITCH=NO
DMZ_IF=eth2
DMZ_NET=192.168.2.0/24
# DMZ switches for all flavors except PRIVATE
/snip
# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
68.7.204.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0
0.0.0.0 68.7.204.1 0.0.0.0 UG0 0 0 eth0
# netstat -nre
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 00 eth1
68.7.204.0 0.0.0.0 255.255.252.0 U 0 00 eth0
0.0.0.0 68.7.204.1 0.0.0.0 UG0 00 eth0
# ip addr show
1: lo: LOOPBACK,UP mtu 3924 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope
Re: [Leaf-user] vpn routing
Charles, I did find a way to test it and the reverse masquerading WORKED! ( which I think is cute as hell and solves a major problem of multiple routes to the internet. ) With one problem. When the ipsec connection is made, ipsec INSERTS rules into the forward chain. They appear BEFORE the MASQ rules. These rules put in ACCEPTS for destinations to the vpn clients. Clever fellows, made sure any reverse traffic would be accepted. Problem is they superceded my MASQ rules. No NAT, the packet can't get back into ipsec. If I rerun my firewall script after the connection is established, destroying their rules, MASQ happens again and I can communicate fine. If they had ADDED those rules rather than INSERTING them, I believe all would be well. You don't happen to know of an option which overrides this behaviour? I can't think of a clever way to watch for this situation and override it that would be timely without being burdensome. Thanx, Phil. Charles Steinkuehler [EMAIL PROTECTED] on 03/08/2002 03:27:44 PM To: Phillip Watts/austin/Nlynx@Nlynx, [EMAIL PROTECTED] cc: Subject: Re: [Leaf-user] vpn routing It seems that I've seen this problem here before: There are two dsl connections to the internet behind one is an NT Proxy server. behind the other is an Eiger router running LRP/IPSec. Both masquerade Behind both of those is a lan 123.x.x.x AS400 123.x.x.1 Exchange Server 123.x.x.2 So the internal subnet for the Eiger is 123.x.x.0/24 A remote laptop with a dynamic address establishes a VPN connection to the Eiger. And access mail on 123.x.x.2 How does the traffic back from the Exchange Server to the laptop find its way back thru the correct router, the eiger. I mean it can only have one default gateway. ?? You either have to have the Eiger VPN gateway as the default route for the exchange box, or setup a static route on the Exchange box pointing to the remote endpoint of the VPN. I've done the latter with subnet-subnet VPN's, but I don't think it will work well with a host-subnet VPN, as the far end IP isn't static... It sounds like you're wanting to just use the Eiger box as a VPN gateway. Another option would be to setup proxy-arp on the Eiger box, with two internal NIC's. Something like: Internet - DSL1 DSL2 || | NT Proxy Server || | Internal net (123.x.x.0/24) || | eth2 eth0-Eiger/Dachstein VPN gateway eth1 | Internal net (123.x.x.0/24) | Exchange server This gets around the routing problem because all packets will go through the VPN gateway, even if destined for the IP of your NT proxy-server. The routing rules on the VPN gateway should make everything work properly, but I haven't actually tested this setup. NOTE: While the above diagram may look kind of scary, it really isn't. The big problem will be getting the routing on the VPN box setup to use the alternate DSL link (it would be much more straight-forward if the VPN gateway simply routed all data out the NT Proxy server, and had one default gateway), but you should be able to setup advanced routing rules based on either firewall marks or protocol that sends VPN traffic out the DSL1 link, and all other traffic out the NT proxy... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] vpn routing
I did find a way to test it and the reverse masquerading WORKED! ( which I think is cute as hell and solves a major problem of multiple routes to the internet. ) With one problem. When the ipsec connection is made, ipsec INSERTS rules into the forward chain. They appear BEFORE the MASQ rules. These rules put in ACCEPTS for destinations to the vpn clients. Clever fellows, made sure any reverse traffic would be accepted. Problem is they superceded my MASQ rules. No NAT, the packet can't get back into ipsec. If I rerun my firewall script after the connection is established, destroying their rules, MASQ happens again and I can communicate fine. If they had ADDED those rules rather than INSERTING them, I believe all would be well. You don't happen to know of an option which overrides this behaviour? I can't think of a clever way to watch for this situation and override it that would be timely without being burdensome. This is done by the _updown script. You can either customize the _updown script, or use [left|right]firewall=no in your ipsec.conf file, which will also prevent holes from being automatically created for the protocol 50 traffic, so you'll have to explicitly allow that as well. IPSec scripts are in /usr/local/lib/ipsec IIRC... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] DNScache and hosts config question
Scott C. Best wrote: Heyaz. So I'm using a fairly stock DS relase, and I've a question about properly setting up dnscache and my host entries in network.conf. Scott! I hope all is well in the South Bay. Are you going to make it up to SF for the Linux Embedded conference this week: http://www.esconline.com/sf/ Just wondering. As far as your post goes How can I keep my LAN machines from making PTR? Properly configure dnscache and tinydns-private on the LEAF box, and point your resolv.conf nameserver entry on the LEAF box to the LEAF box IP address to which dnscache is bound. Ok, that didn't come out too smoothly :) I just went through this whole issue about two weeks ago, figured it out, and submitted patches to JN's tinydns howto and dnscache howto, which didn't quite get the config correct. The docs also needed a blurb or two about how to set resolv.conf. You can go read up on those, and you'll have it working in no time, I'm sure. It could be as little of a thing as changing the +entries to =entries, which create both A and PTR records. That's in the docs now. requests to my ISP's DNS when trying to get host names for internal LAN machines? I've setup the HOSTS section of network.conf to give a hostname to my private.network collection, but I can still see the network traffic (using tcpdump) leaving my LAN. Did I miss setting something for dnscache, to tell it to use /etc/hosts for machines in the private.network domain? It's unnecessary to have anything in /etc/hosts besides 127.0.0.1 localhost if your tinydns-private and dnscache are set up correctly. Though, I'll admit, there's nothing wrong with putting the IPaddr/name of your external nic in there if it's a static IP/name, because data for that public nic does not go into tinydns-private. 63.194.217.179 adsl-63-194-213-179.dsl.snfc21.pacbell.net I'm not convinced that entry will ever be used though, unless the recursive resolution to the SOA for your public domain doesn't get an answer (which would be bad :) ) Thanks in advance for any leads. No problem. He just updated the docs. So it's new to a lot of people. cheers, Scott ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] DNScache and hosts config question
At 10:37 PM 3/9/02 +, Scott C. Best wrote: Michael: Heya. Each of the LAN machines gets a DHCP lease from the DS box, with the DS box indicated as the DNS server. Only the DS box has the /etc/hosts entries. For example, in the /etc/hosts file it reads: 192.168.123.1 pc.private.network pc1 192.168.123.2 winnt.private.network winnt I can see my WinNT Box (at .2) query the DS box for a reverse-lookup (PTR?) for 1.123.168.192, and I cannot see that the DH box replying with pc.private.network. Hope this helps clarify. Clear as a bell, now. Entries in /etc/hosts are useless for DNS; they get used only for *local* resolution on the host (and not always even then; MTAs are particularly bad about this). Not sure if there is a way to provide local-resolution information to dnscache directly, since it is designed to act as a forwarder, and you're presumably forwarding to off-LAN nameservers that don't know anything about your NAT'd machines. The only ways I know to get around this are: 1. Have an /etc/hosts file (or Windows or Mac equivalent) on each workstation, so they can resolve LAN names and addresses without using DNS. 2. Run a real nameserver (BIND, I suppose, if tinydns won't serve the purpose) on the LAN and have all hosts use it to resolve names and addresses. I'd imagine tinydns will do this, as long as you provide it with suitable zone files (I'm using BIND terminology here, but tinydns must have an equivalent) both for name lookup -AND- for reverse lookup. I do a mix of the two here, and it's worked nicely for eons now. But my LAN is mostly Linux machines, with only a sprinking of WinXX clients. [old stuff deleted] -- Never tell me the odds!--- Ray Olszewski-- Han Solo Palo Alto, CA[EMAIL PROTECTED] ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] martians on internal network ???
snip of various authors I'm not that familiar with the MS networking stack, and how windows systems handle routing, forwarding, etc. With the Win9x/ME family, the stack is all proxy...ISC or some other proxy. As mentioned elsewhere, apparently the AOL traffic is creating a tunnel through your firewall for it's traffic, which fundamentally represents a 'back door' to your internal net. Anyone seen a recent security review of the AOL client source code, to know if this is safe or not? I wouldn't bet on it being too safe, but I think it is all tied into AOL's internal servers, being advertisements, popups, and the like. AOL doesn't let source code out the door, period. RH is working on some type of client with AOL, so your best bet on finding something out from someone who _may_ have seen some client socket source would be there. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] ipsec errors
On Saturday 09 March 2002 10:21, joey officer wrote: i did not find that specific line in the net ipfilter list command, however I did change the setting in the networ.conf file. however I still did not find that line in the above command. I got to thinking about the specific problem i'm having and thought I might try to give a little more information .. here goes IPSec loads without any noticable errors, except something out abour rp_filter should be 0, but reads 1 (or vice versa). If I understand correclty, once both machines are at this point I could ping the office subnet from the home subnet, and the opposite, however this does not work. So then I tried ' ipsec auto --up office ' .. and then this just hangs. sits for awhile (reading the logs says something about itializing office on MAIN). After a minute or so, I ctrl-break this and am unable to go any further. The rp_filter has to do with the network.conf setup, turn off eth0_IPSPOOF to fix this. ipsec barf will check the connection attempt(s) and give you any errors there. Also, did you add leftfirewall=yes and rightfirewall=yes assuming these boxes are both being run with fiter=firewall or router. Personally, it sounds like the RSA authentication problem. ipsec barf or cat /var/log/auth.log should show the point of failure. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] ipsec errors
I modified the eth0_IP_SPOOF=NO now, but that does not fix the error of being denied.. which I posted a little while ago... any other thoughts joey - Original Message - From: guitarlynn [EMAIL PROTECTED] To: joey officer [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, March 09, 2002 6:21 PM Subject: Re: [Leaf-user] ipsec errors On Saturday 09 March 2002 10:21, joey officer wrote: i did not find that specific line in the net ipfilter list command, however I did change the setting in the networ.conf file. however I still did not find that line in the above command. I got to thinking about the specific problem i'm having and thought I might try to give a little more information .. here goes IPSec loads without any noticable errors, except something out abour rp_filter should be 0, but reads 1 (or vice versa). If I understand correclty, once both machines are at this point I could ping the office subnet from the home subnet, and the opposite, however this does not work. So then I tried ' ipsec auto --up office ' .. and then this just hangs. sits for awhile (reading the logs says something about itializing office on MAIN). After a minute or so, I ctrl-break this and am unable to go any further. The rp_filter has to do with the network.conf setup, turn off eth0_IPSPOOF to fix this. ipsec barf will check the connection attempt(s) and give you any errors there. Also, did you add leftfirewall=yes and rightfirewall=yes assuming these boxes are both being run with fiter=firewall or router. Personally, it sounds like the RSA authentication problem. ipsec barf or cat /var/log/auth.log should show the point of failure. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] DCD Port forwarding not working
At 02:44 PM 3/9/02 -0800, Doug Sampson wrote:
Hi all,
I'm still having a problem with port forwarding packets to the internal web
server... I am on a Cox network that supposedly blocks packets coming inward
via port 80. I've set up an account with DynDNS that forwards packets
directed at http://www.cybersampson.com to http://www2.cybersampson.com:8080.
I am getting an error message that essentially says connection request
refused.
I would be happier knowing what it says rather than what it essentially
says. Also what it is (what browser is reporting the error). From here,
Netscape (on Win95) gets the right translated address from DynDNS, but times
out with its standard The server is not responding ... message.
Here is the data for analysis:
Where in the config file are you setting up the port forwarding? If I look
at the section on port forwarding, all I see is a commented-out line to
specify the port-forwarding link:
#INTERN_SERVERS=tcp_${EXTERN_IP}_8080_192.168.1.200_80
(You do uncomment the line to identify the internal WWW server, but that
doesn't include any port-8080 information.)
INTERN_WWW_SERVER=192.168.1.200 # Internal WWW server to make
available
You might want to check if the port-forwarding rule you desire is actually
in place. I always forget this command, but I think it is --
ipmasqadm mfw -L -n
Running DCD 1.02 on a system with 2 NICs.
[details deleted]
--
Never tell me the odds!---
Ray Olszewski-- Han Solo
Palo Alto, CA[EMAIL PROTECTED]
___
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
