RE: [leaf-user] Bering/Shorewall question
On Mon, 22 Jul 2002, David Pitts wrote: This is exactly my problem with Bering and Dachstein (but not with Eigerstein!). Is it too lazy of me to ask someone to offer a script line that will allow packets from 10.96.4.1 for Shorewall and Dachstein?? I'm afraid so. For Bering, this is a variation of Shorewall FAQ #14 (http://www.shorewall.net/FAQ.htm#faq14). I have a couple of questions though that might help my understanding of this whole thing. One, how does this impact on my internal DHCP server? I'm using the default 192.168.1.x subnet. On Bering, there is no impact unless you unwisely specify 'norfc1918' on your internal interface in /etc/shorewall/interfaces. And two, does this mean the firewall loads before DHCLient runs? No, but the firewall had been loaded long before DHCLient renews its lease and that's what this thread has been about. Might be a silly question because I guess I wouldn't be getting this problem if the order was reverses? See above. And just one more thing. Is there a config file that controls the order the packages boot in?? It's controlled by the RCDLINKS line in each of the package init scripts. -Tom -- Tom Eastep\ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Bering/Shorewall question
Actually I thought you asked the question quite well... The packets you are seeing are from your ISP's DHCP server. To conserve public IP address space, many ISPs are apparently using RFC1918 addresses for pieces of their internal network, including their DHCP servers. In theory, RFC1918 packets should not be seen on the Internet so a rule blocking them is entirely appropriate as a default. There are a couple of approaches you can take. My preference is to change the rule to just drop these packets without logging them. To do this, just go into the Shorewall menu, choose option 16 (RFC1918) and change the 'logdrop' to 'DROP'. Do a back up and then restart Shorewall and that should take care of it. Alternately, you could create a rule for this one particular address. Regards! Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Cass Tolken Sent: Sunday, July 21, 2002 11:28 AM To: Leaf User Subject: [leaf-user] Bering/Shorewall question Hi there, I'm a networking newbie so excuse me if this question or my terminolgy seems strange ;). I'm logging a whole LOT of these hits: [snip] Jul 21 13:57:20 firewall kernel: Shorewall:rfc1918:DROP:IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:05:9a:d0:ec:54:08:00 SRC=10.122.64.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=37032 PROTO=UDP SPT=67 DPT=68 LEN=308 Jul 21 14:03:11 firewall kernel: Shorewall:rfc1918:DROP:IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:05:9a:d0:ec:54:08:00 SRC=10.122.64.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=37054 PROTO=UDP SPT=67 DPT=68 LEN=308 I think the DPT=68 is related to bootpc which I believe is dhcp related. I am running dhcpd on eth1. Everything seems to be working great on my internal network (of mostly windows boxen) except for the above hits being logged EVERY few minutes. I've searched the mailing list archives and have found statements like the above message is probably generated by a rule in the mangle table and that the underlying problem is probably that 'norfc1918' is specified on an interface where it shouldn't be. (both from Tom Eastep in http://www.mail-archive.com/leaf-user@lists.sourceforge.net/msg07342.htm l .) I'm using the default Bering /etc/shorewall/interfaces lines: net eth0detect dhcp,routefilter,norfc1918 loc eth1detect routestopped Should I take out the norfc1918 from the eth0 line? If Tom says it shouldn't be there, why is it in the default Bering install? Thanks for any help! __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall question
--- Kim Oppalfens [EMAIL PROTECTED] wrote: At 20:28 21/07/2002, Cass Tolken wrote: Taking out the norfc on should stop logging these. It is in there by default because you are not supposed to have an address in the 10.x.y.z range on an external interface. The norfc means to block anything in the source ip ranges of 10.x.y.z 169.254.y.z 172.16-31.y.z 192.168.0.1 224-239.x.y.z Looking at these logged messages I suspect you to have an external address of 10.x.y.z Just check by using the ip add command. If you are in the 10 range you should remove the norfc1918 Thanks for the quick response. Here is the output of ip add (I x-ed out my MAC addresses and eth0 IP which I get via pump from my cable modem ISP) # ip add 1: lo: LOOPBACK,UP mtu 16436 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 host lo 2: dummy0: BROADCAST,NOARP mtu 1500 qdisc noop link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 3: eth0: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:04:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet 24.46.xxx.xxx/22 brd 255.255.255.255 scope global eth0 4: eth1: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:a0:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet 192.168.1.254/24 brd 192.168.1.255 scope global eth1 Could it be someone from the outside net that's doing this? Again, excuse my newbie-ness ;). I'll try taking out the norcf1918 after any replies I get from this message. Thanks again! __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall question
At 21:13 21/07/2002, Cass Tolken wrote: Your external address 24.46.y.z doesn't appear to be in the rfc1918 range. So there is no reason to take the norfc1918 out. Is your intern dhcp server serving up addresses in this 10 range by any chance? I don't think so sonce your internal ip is in the 192.168 range. So apparently this is actually someone on the outside doing this. Most likely scenario is that someone on your segment got his configuration mixed up and is servicing up 10.x.y.z addressed on his external instead of his internal interface. I don't think an attack of some form is going on here. (Because there is no directed destination ip 255.255.255.255 means its a broadcast.) The guess that it is someone on your segment comes from the fact that it is a broadcast. If it is bothering you that it is being logged is bothering you you can allways add a line to the rfc1918 option file of shorewall (that is if you are using bering rc3 with the most recent shorewall). If you are using anything else just let me know and we will check to see what we can do. Just add a line above the 10.x.y.z logdrop with the folowing info in it. 10.122.64.1/32 DROP Kim Oppalfens --- Kim Oppalfens [EMAIL PROTECTED] wrote: At 20:28 21/07/2002, Cass Tolken wrote: Taking out the norfc on should stop logging these. It is in there by default because you are not supposed to have an address in the 10.x.y.z range on an external interface. The norfc means to block anything in the source ip ranges of 10.x.y.z 169.254.y.z 172.16-31.y.z 192.168.0.1 224-239.x.y.z Looking at these logged messages I suspect you to have an external address of 10.x.y.z Just check by using the ip add command. If you are in the 10 range you should remove the norfc1918 Thanks for the quick response. Here is the output of ip add (I x-ed out my MAC addresses and eth0 IP which I get via pump from my cable modem ISP) # ip add 1: lo: LOOPBACK,UP mtu 16436 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 host lo 2: dummy0: BROADCAST,NOARP mtu 1500 qdisc noop link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 3: eth0: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:04:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet 24.46.xxx.xxx/22 brd 255.255.255.255 scope global eth0 4: eth1: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:a0:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet 192.168.1.254/24 brd 192.168.1.255 scope global eth1 Could it be someone from the outside net that's doing this? Again, excuse my newbie-ness ;). I'll try taking out the norcf1918 after any replies I get from this message. Thanks again! __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall question
--- Kim Oppalfens [EMAIL PROTECTED] wrote: At 21:13 21/07/2002, Cass Tolken wrote: Your external address 24.46.y.z doesn't appear to be in the rfc1918 range. So there is no reason to take the norfc1918 out. Is your intern dhcp server serving up addresses in this 10 range by any chance? I don't think so sonce your internal ip is in the 192.168 range. Yes, it is on the 192.168 and not a 10 range. So apparently this is actually someone on the outside doing this. Most likely scenario is that someone on your segment got his configuration mixed up and is servicing up 10.x.y.z addressed on his external instead of his internal interface. Ah, that's what my guess was but I was not knowledgeable or confident enough to mention it ;). [snip] If it is bothering you that it is being logged is bothering you you can allways add a line to the rfc1918 option file of shorewall (that is if you are using bering rc3 with the most recent shorewall). [snip] My only concern is that it would totally fills up my log space. Just add a line above the 10.x.y.z logdrop with the folowing info in it. 10.122.64.1/32 DROP Ah, I'll do that. Man, this is one of the best supported project mailing-list I've ever used. Give yourselves all a good pat on the back ;). Thanks! __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall question
On Sunday 21 July 2002 14:30, Kim Oppalfens wrote: At 21:13 21/07/2002, Cass Tolken wrote: Your external address 24.46.y.z doesn't appear to be in the rfc1918 range. So there is no reason to take the norfc1918 out. Is your intern dhcp server serving up addresses in this 10 range by any chance? I don't think so sonce your internal ip is in the 192.168 range. Some ISP's use private ip's on their DHCP and DNS servers, though this is a bad way to save real ip's, it works for them. This is not the case in your situation however, you would not have received a DHCP lease if it was. So apparently this is actually someone on the outside doing this. Most likely scenario is that someone on your segment got his configuration mixed up and is servicing up 10.x.y.z addressed on his external instead of his internal interface. MS boxes running Proxy and/or NAT services spew information out of _all_ interfaces and this is probably what is going on here. I would imagine that someone using a 10.x.x.x private network range behind a M$ NAT machine is spewing DHCP requests from it's internal interface out it's external interface. You can safely disregard the packets and set the firewall to DROP them instead of logging them. -- ~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! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Bering/Shorewall question
Some ISP's use private ip's on their DHCP and DNS servers, though this is a bad way to save real ip's, it works for them. This is not the case in your situation however, you would not have received a DHCP lease if it was. Lynn - I'm curious as to your reasoning on this. Doesn't the DHCP lease request occur before the firewall rules are started? My ISP is using an RFC1918 DHCP server and I get and maintain a lease even with the default Shorewall settings. Paul --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Bering/Shorewall question
On Sunday 21 July 2002 16:02, Paul M. Wright, Jr. wrote: Lynn - I'm curious as to your reasoning on this. Doesn't the DHCP lease request occur before the firewall rules are started? My ISP is using an RFC1918 DHCP server and I get and maintain a lease even with the default Shorewall settings. Paul, There are tons of posts to the mailing list (even within the last day or rwo) from people without your experience. Tom also appears to think that this shouldn't happen (on lease renewal's anyway). I dunno why you haven't had any problems with this. Personally, my cox dhcp server is a 172.19.x.x server and pump won't renew the lease w/o allowing the address. -- ~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! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Bering/Shorewall question
At 02:02 PM 7/21/02 -0700, Paul M. Wright, Jr. wrote: Some ISP's use private ip's on their DHCP and DNS servers, though this is a bad way to save real ip's, it works for them. This is not the case in your situation however, you would not have received a DHCP lease if it was. Lynn - I'm curious as to your reasoning on this. Doesn't the DHCP lease request occur before the firewall rules are started? My ISP is using an RFC1918 DHCP server and I get and maintain a lease even with the default Shorewall settings. The first DHCP lease request (and delivery) occurs before the firewall rules are started. Renewals have to get through the firewall, though, and that is the usual source of problems like the ones discussed in this thread. Without knowing more about your (and your ISP's) setup, I cannot say why it works while the other poster's does not. -- ---Never tell me the odds!-- Ray Olszewski-- Han Solo Palo Alto, California, USA [EMAIL PROTECTED] --- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
