Illegal targeting from E.ROOT-SERVERS.NET.
Now and them I see strange log entries like this, coming from dns servers: Jun 12 13:27:48 nimrodel kernel: SuSE-FW-ILLEGAL-TARGET IN=ppp0 OUT= MAC= SRC=192.203.230.10 DST=81.41.200.5 LEN=124 TOS=0x00 PREC=0x00 TTL=44 ID=24563 PROTO=UDP SPT=53 DPT=1024 LEN=104 (repeated four times within one second) If I reverse search for the name, I find that: cer@nimrodel:~> host 192.203.230.10 10.230.203.192.in-addr.arpa. domain name pointer E.ROOT-SERVERS.NET. This port is marked as: # 1024/udp Reserved Now, what on earth (pardon me!) is that machine - a dns root server of all things - trying to send to that port? Should I open it on the firewall? My machine doesn't have a permanent network connection, but a V90 modem now and then. I have bind9 set up as a cache (forwarding queries to my ISP, then to the root servers if that fails), with SuSE 8.1. -- Cheers, Carlos Robinson
* Carlos E. R. (robin1.listas@tiscali.es) [030612 17:19]:
Jun 12 13:27:48 nimrodel kernel: SuSE-FW-ILLEGAL-TARGET IN=ppp0 OUT= MAC= SRC=192.203.230.10 DST=81.41.200.5 LEN=124 TOS=0x00 PREC=0x00 TTL=44 ID=24563 PROTO=UDP SPT=53 DPT=1024 LEN=104 (repeated four times within one second)
It's probably a query response from the root server -- it's coming from port 53 to a high port on your system. Then again, since it's udp the source IP could be fake but that's doubtful given that 192.203.230.10 really is E.ROOT-SERVERS.NET. -- -ckm
The 03.06.12 at 21:56, Christopher Mahmood wrote:
It's probably a query response from the root server -- it's coming from port 53 to a high port on your system. Then again, since it's udp the source IP could be fake but that's doubtful given that 192.203.230.10 really is E.ROOT-SERVERS.NET.
Then I suppose the firewall should let it pass, automatically, as part of an ungoing conversation... I have seen a number of them from several domain name servers. -- Cheers, Carlos Robinson
* Carlos E. R. (robin1.listas@tiscali.es) [030613 09:56]:
Then I suppose the firewall should let it pass, automatically, as part of an ungoing conversation... I have seen a number of them from several domain name servers.
Yeah, do you have FW_ALLOW_INCOMING_HIGHPORTS_UDP set to 'yes' or 'DNS'? Since you're running a nameserver it should be 'yes'. -- -ckm
The 03.06.13 at 10:30, Christopher Mahmood wrote:
Then I suppose the firewall should let it pass, automatically, as part of an ungoing conversation... I have seen a number of them from several domain name servers.
Yeah, do you have FW_ALLOW_INCOMING_HIGHPORTS_UDP set to 'yes' or 'DNS'? Since you're running a nameserver it should be 'yes'.
Yes, I have: FW_ALLOW_INCOMING_HIGHPORTS_UDP="DNS domain" (although 1024 might not be really a high port :-? ) But, during boot, I always see: Starting Firewall Initialization (phase 3 of 3) <notice>'/etc/init.d/rc5.d/S10cups start' exits with status 0 <notice>/etc/init.d/rc5.d/S11SuSEfirewall2_final start Warning: FW_SERVICE_DNS defined, but no DNS server found running! I have never botthered about that, because DNS is in fact running (as cache, I'm not interested in serving queries from outside, so it listens only on the internal interface), and anyway, after the modem goes up, the script calls susefirewall again and the rules get reloaded: Jun 13 20:48:11 nimrodel SuSEfirewall2: Firewall rules successfully set from /etc/sysconfig/SuSEfirewall2 Jun 13 20:48:11 nimrodel ip-up.local: --> Up ppp0 /dev/ttyS1 115200 L: 81.41.201.128 R: 80.58.197.105 Par: -- Cheers, Carlos Robinson
* Carlos E. R. (robin1.listas@tiscali.es) [030613 13:54]:
Yes, I have:
FW_ALLOW_INCOMING_HIGHPORTS_UDP="DNS domain"
That should work then. It's OK to just open all of the high udp ports though.
(although 1024 might not be really a high port :-? )
It is, the inequality in "ports below than 1024" is strict.
But, during boot, I always see:
Starting Firewall Initialization (phase 3 of 3) <notice>'/etc/init.d/rc5.d/S10cups start' exits with status 0 <notice>/etc/init.d/rc5.d/S11SuSEfirewall2_final start Warning: FW_SERVICE_DNS defined, but no DNS server found running!
I have never botthered about that, because DNS is in fact running (as cache, I'm not interested in serving queries from outside, so it listens only on the internal interface), and anyway, after the modem goes up, the script calls susefirewall again and the rules get reloaded:
It seems like it's doing the right thing. Maybe you have the nameserver bound to 127.0.0.1? -- -ckm
On Fri, 2003-06-13 at 23:08, Christopher Mahmood wrote:
* Carlos E. R. (robin1.listas@tiscali.es) [030613 13:54]:
Yes, I have:
FW_ALLOW_INCOMING_HIGHPORTS_UDP="DNS domain"
That should work then. It's OK to just open all of the high udp ports though.
Isn't the interesting bit here that the log message is ILLEGAL-TARGET? I mean, I would expect either ACCEPT or DROP-DEFAULT, but I don't think you should ever see ILLEGAL-TARGET unless there's something really wrong. I get illegal target on DNS reply packets from time to time when I restart the firewall. I'm not sure exactly what, but something gets messed up on a restart. I find that "rcnamed restart" makes it go away
The 03.06.13 at 23:13, Anders Johansson wrote:
Isn't the interesting bit here that the log message is ILLEGAL-TARGET? I mean, I would expect either ACCEPT or DROP-DEFAULT, but I don't think you should ever see ILLEGAL-TARGET unless there's something really wrong.
That's what I thought, yes... If the packet rejected is part of an ongoing conversation, it should not not matter if I close every port on the firewall, because it is a response, and thus will get in. In fact, I'm not getting rejects or anything coming from port 53 to any of my ports (which are in fact closed), except if it goes to 1024. Therefore, port 1024 must be special for some reason; but which one?
I get illegal target on DNS reply packets from time to time when I restart the firewall. I'm not sure exactly what, but something gets messed up on a restart. I find that "rcnamed restart" makes it go away
I'l try to set up ethereal or something to try capture dns conversations. Now, I wonder how to fire up ethereal (or soemthing else) automatically when networks goes up - perhaps tcpdump would be better [...] Ok, I have inserted this into my ip-up script: /usr/sbin/tcpdump -i ppp0 -s0 -X -a -e -vvv "src or dst port 53" >> /root/captura.tcpdump -- Cheers, Carlos Robinson
The 03.06.15 at 13:53, Carlos E. R. wrote:
The 03.06.13 at 23:13, Anders Johansson wrote:
I get illegal target on DNS reply packets from time to time when I restart the firewall. I'm not sure exactly what, but something gets messed up on a restart. I find that "rcnamed restart" makes it go away [...]
Ok, I have inserted this into my ip-up script:
/usr/sbin/tcpdump -i ppp0 -s0 -X -a -e -vvv "src or dst port 53" >> /root/captura.tcpdump
You must be right, it onnly happens at start, or sometimes. Look, I'm capturing a lot of trafic going to port 1024 (second time I fire up my modem after boot up): (outgoing queries) 13:55:28.100627 > ip 100: 243.Red-81-41-199.pooles.rima-tde.net.1024 > ns1.recol.es.domain: [udp sum ok] 24659+ [1au] PTR? 10.128.155.210.in-addr.arpa. ar: . OPT UDPsize=2048 (56) (DF) [tos 0x10] (ttl 64, id 16383, len 84) 0x0000 4510 0054 3fff 4000 4011 1dd3 5129 c7f3 E..T?.@.@...Q).. 0x0010 c195 0205 0400 0035 0040 850c 6053 0110 .......5.@..`S.. 0x0020 0001 0000 0000 0001 0231 3003 3132 3803 .........10.128. 0x0030 3135 3503 3231 3007 696e 2d61 6464 7204 155.210.in-addr. 0x0040 6172 7061 0000 0c00 0100 0029 0800 0000 arpa.......).... 0x0050 8000 0000 .... 13:55:30.108608 > ip 89: 243.Red-81-41-199.pooles.rima-tde.net.1024 > ramblas.red.retevision.es.domain: [udp sum ok] 44850+ PTR? 10.128.155.210.in-addr.arpa. (45) (DF) [tos 0x10] (ttl 64, id 16390, len 73) 0x0000 4510 0049 4006 4000 4011 925b 5129 c7f3 E..I@.@.@..[Q).. 0x0010 3e51 10c5 0400 0035 0035 3302 af32 0100 >Q.....5.53..2.. 0x0020 0001 0000 0000 0000 0231 3003 3132 3803 .........10.128. 0x0030 3135 3503 3231 3007 696e 2d61 6464 7204 155.210.in-addr. 0x0040 6172 7061 0000 0c00 01 arpa..... (incoming response) 13:55:30.588264 < ip 180: ramblas.red.retevision.es.domain > 243.Red-81-41-199.pooles.rima-tde.net.1024: [udp sum ok] 44850* q: PTR? 10.128.155.210.in-addr.arpa. 1/2/2 10.128.155.210.in-addr.arpa. PTR ns1.mex.ad.jp. ns: 128.155.210.in-addr.arpa. NS ns0.mex.ad.jp., 128.155.210.in-addr.arpa. NS ns1.mex.ad.jp. ar: ns0.mex.ad.jp. A ns0.mex.ad.jp, ns1.mex.ad.jp. A ns1.mex.ad.jp (136) (DF) (ttl 243, id 22132, len 164) 0x0000 4500 00a4 5674 4000 f311 c8a1 3e51 10c5 E...Vt@.....>Q.. 0x0010 5129 c7f3 0035 0400 0090 c7d8 af32 8580 Q)...5.......2.. 0x0020 0001 0001 0002 0002 0231 3003 3132 3803 .........10.128. 0x0030 3135 3503 3231 3007 696e 2d61 6464 7204 155.210.in-addr. 0x0040 6172 7061 0000 0c00 01c0 0c00 0c00 0100 arpa............ 0x0050 0151 8000 0f03 6e73 3103 6d65 7802 6164 .Q....ns1.mex.ad 0x0060 026a 7000 c00f 0002 0001 0001 5180 0006 .jp.........Q... 0x0070 036e 7330 c03d c00f 0002 0001 0001 5180 .ns0.=........Q. 0x0080 0002 c039 c054 0001 0001 0001 5180 0004 ...9.T......Q... 0x0090 d29b 8006 c039 0001 0001 0001 5180 0004 .....9......Q... 0x00a0 d29b 800a .... There are a lot more going to my port 1024, and no report shows on the firewall logs - except normal script kiddies probing me :-) -- Cheers, Carlos Robinson
On Sun, 2003-06-15 at 13:53, Carlos E. R. wrote:
If the packet rejected is part of an ongoing conversation, it should not not matter if I close every port on the firewall, because it is a response, and thus will get in.
Not necessarily. You would have to allow packets of state ESTABLISHED, otherwise everything would be blocked.
I'l try to set up ethereal or something to try capture dns conversations. Now, I wonder how to fire up ethereal (or soemthing else) automatically when networks goes up - perhaps tcpdump would be better [...]
Let us know what you find out. I've suspected for a while that there is something subtly wrong in the SuSEfirewall, but I've never suffered enough from it to muster up the energy to research it :)
The 03.06.15 at 14:18, Anders Johansson wrote:
If the packet rejected is part of an ongoing conversation, it should not not matter if I close every port on the firewall, because it is a response, and thus will get in.
Not necessarily. You would have to allow packets of state ESTABLISHED, otherwise everything would be blocked.
Well, I hope the susefirewall script takes care of that for me - I'm not capable of doing it meself ;-)
I'l try to set up ethereal or something to try capture dns conversations. Now, I wonder how to fire up ethereal (or soemthing else) automatically when networks goes up - perhaps tcpdump would be better [...]
Let us know what you find out. I've suspected for a while that there is something subtly wrong in the SuSEfirewall, but I've never suffered enough from it to muster up the energy to research it :)
Gotcha! :-) At least, I think I have captured some (after booting). My firewall log says: Jun 15 23:26:18 nimrodel kernel: SuSE-FW-ILLEGAL-TARGET IN=ppp0 OUT= MAC= SRC=192.36.148.17 DST=81.41.200.185 LEN=122 TOS=0x00 PREC=0x00 TTL=39 ID=46511 DF PROTO=UDP SPT=53 DPT=1024 LEN=102 (repeated 13 times, in one second) Now, lets see what I have captured. [...] Nothing :-( The first capture occurs at 23:26:20.414464, two seconds later. tcpdump didn't see a thing :-( 23:26:20.414464 < ip 138: rns.arl.army.mil.domain > 185.Red-81-41-200.pooles.rima-tde.net.1024: [udp sum ok] 24957*- q: AAAA? A.ROOT-SERVERS.NET. 0/1/0 ns: ROOT-SERVERS.NET. SOA A.ROOT-SERVERS.NET. nstld.verisign-grs.com. 2003050200 14400 7200 1209600 3600000 (94) (DF) (ttl 40, id 0, len 122) I guess the firewall is impeding it... no, tcpdump is starting one second too late: Jun 15 23:26:19 nimrodel ip-up.local: --> Up ppp0 /dev/ttyS1 115200 L: 81.41.200.185 R: 80.58.197.104 Par: Ok, I'll change my script a bit, and we'll see what happens tomorrow (I can not start tcpdump manually because the interface ppp0 doesn't exist till I connect). I'll put a five second before the stuff sending/reciving mail etc. -- Cheers, Carlos Robinson
The 03.06.15 at 14:18, Anders Johansson wrote:
Let us know what you find out. I've suspected for a while that there is something subtly wrong in the SuSEfirewall, but I've never suffered enough from it to muster up the energy to research it :)
No luck :-( My sequence of events is this: Jun 19 14:11:34 nimrodel poll.tcpip: _NOT_ starting mail and news send/fetch Jun 19 14:11:34 nimrodel ip-up.local: --> Up ppp0 /dev/ttyS1 115200 L: 81.41.199.207 R: 80.58.197.103 Par: Jun 19 14:11:34 nimrodel ip-up.local: --> Waiting for tcpdump activation Jun 19 14:11:44 nimrodel ip-up.local: --> Launching fetch/send tasks now Jun 19 14:11:44 nimrodel ip-up.local.doit: --> Starting mail and news send/fetch, and fidonet poll (expensive) Jun 19 14:11:44 nimrodel postfix/postqueue[5739]: warning: unix_trigger: write to public/qmgr: Broken pipe And I'm getting illegal packets (second connection on the day, so it is not always the first connection after booting): Jun 19 14:11:33 nimrodel kernel: SuSE-FW-ILLEGAL-TARGET IN=ppp0 OUT= MAC= SRC=198.41.0.10 DST=81.41.199.207 LEN=122 TOS=0x00 PREC=0x00 TTL=44 ID=0 DF PROTO=UDP SPT=53 DPT=1024 LEN=102 Jun 19 14:11:33 nimrodel kernel: SuSE-FW-ILLEGAL-TARGET IN=ppp0 OUT= MAC= SRC=198.41.0.10 DST=81.41.199.207 LEN=124 TOS=0x00 PREC=0x00 TTL=44 ID=0 DF PROTO=UDP SPT=53 DPT=1024 LEN=104 But they are not logged by tcpdump, it is still one second earlier than tcpdump is called :-( And I don't know who/what is sending the original request, because I start the send/receive sequence a full 10 seconds after the connection is established and tcpdump started. I wonder if I can set tcpdump to log packets from all interfaces :-? -- Cheers, Carlos Robinson
A little bit OT, Is it worth it to install SuSEFirewall on a system with only a DSL router connection going right into my server nic.. that is no second nic for an internal network? Does SuSEFirewall require the two nic configuration? Thanks, Jim
The 03.06.15 at 14:18, Anders Johansson wrote:
Let us know what you find out. I've suspected for a while that there is something subtly wrong in the SuSEfirewall, but I've never suffered enough from it to muster up the energy to research it :)
No luck :-(
My sequence of events is this:
Jun 19 14:11:34 nimrodel poll.tcpip: _NOT_ starting mail and news send/fetch Jun 19 14:11:34 nimrodel ip-up.local: --> Up ppp0 /dev/ttyS1 115200 L: 81.41.199.207 R: 80.58.197.103 Par: Jun 19 14:11:34 nimrodel ip-up.local: --> Waiting for tcpdump activation Jun 19 14:11:44 nimrodel ip-up.local: --> Launching fetch/send tasks now Jun 19 14:11:44 nimrodel ip-up.local.doit: --> Starting mail and news send/fetch, and fidonet poll (expensive) Jun 19 14:11:44 nimrodel postfix/postqueue[5739]: warning: unix_trigger: write to public/qmgr: Broken pipe
And I'm getting illegal packets (second connection on the day, so it is not always the first connection after booting):
Jun 19 14:11:33 nimrodel kernel: SuSE-FW-ILLEGAL-TARGET IN=ppp0 OUT= MAC= SRC=198.41.0.10 DST=81.41.199.207 LEN=122 TOS=0x00 PREC=0x00 TTL=44 ID=0 DF PROTO=UDP SPT=53 DPT=1024 LEN=102 Jun 19 14:11:33 nimrodel kernel: SuSE-FW-ILLEGAL-TARGET IN=ppp0 OUT= MAC= SRC=198.41.0.10 DST=81.41.199.207 LEN=124 TOS=0x00 PREC=0x00 TTL=44 ID=0 DF PROTO=UDP SPT=53 DPT=1024 LEN=104
But they are not logged by tcpdump, it is still one second earlier than tcpdump is called :-(
And I don't know who/what is sending the original request, because I start the send/receive sequence a full 10 seconds after the connection is established and tcpdump started.
I wonder if I can set tcpdump to log packets from all interfaces :-?
-- Cheers, Carlos Robinson
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
Yes it is worthwhile, unless your DSL router has a firewall. It may be worthwhile even then, just in case something gets past the DSL router firewall. I have a broadband firewall/router and firewalls on each box inside the firewall too. Yes, SuSEfirewall and SuSEfirewall2 will work with one NIC. Jeffrey Quoting Jim Norton <jrn@oregonhanggliding.com>:
A little bit OT,
Is it worth it to install SuSEFirewall on a system with only a DSL router connection going right into my server nic.. that is no second nic for an internal network?
Does SuSEFirewall require the two nic configuration?
Thanks, Jim
The 03.06.15 at 14:18, Anders Johansson wrote:
Let us know what you find out. I've suspected for a while that there is something subtly wrong in the SuSEfirewall, but I've never suffered enough from it to muster up the energy to research it :)
No luck :-(
My sequence of events is this:
Jun 19 14:11:34 nimrodel poll.tcpip: _NOT_ starting mail and news send/fetch Jun 19 14:11:34 nimrodel ip-up.local: --> Up ppp0 /dev/ttyS1 115200 L: 81.41.199.207 R: 80.58.197.103 Par: Jun 19 14:11:34 nimrodel ip-up.local: --> Waiting for tcpdump activation Jun 19 14:11:44 nimrodel ip-up.local: --> Launching fetch/send tasks now Jun 19 14:11:44 nimrodel ip-up.local.doit: --> Starting mail and news send/fetch, and fidonet poll (expensive) Jun 19 14:11:44 nimrodel postfix/postqueue[5739]: warning: unix_trigger: write to public/qmgr: Broken pipe
And I'm getting illegal packets (second connection on the day, so it is not always the first connection after booting):
Jun 19 14:11:33 nimrodel kernel: SuSE-FW-ILLEGAL-TARGET IN=ppp0 OUT= MAC= SRC=198.41.0.10 DST=81.41.199.207 LEN=122 TOS=0x00 PREC=0x00 TTL=44 ID=0 DF PROTO=UDP SPT=53 DPT=1024 LEN=102 Jun 19 14:11:33 nimrodel kernel: SuSE-FW-ILLEGAL-TARGET IN=ppp0 OUT= MAC= SRC=198.41.0.10 DST=81.41.199.207 LEN=124 TOS=0x00 PREC=0x00 TTL=44 ID=0 DF PROTO=UDP SPT=53 DPT=1024 LEN=104
But they are not logged by tcpdump, it is still one second earlier than tcpdump is called :-(
And I don't know who/what is sending the original request, because I start the send/receive sequence a full 10 seconds after the connection is established and tcpdump started.
I wonder if I can set tcpdump to log packets from all interfaces :-?
Notice that the source port is 53. This is DNS (AKA domain). It is almost certainly legitimate. Looking at the IPchains rules on my box (cable modem) the SuSE-FW-ILLEGAL-TARGET rule applies to packets to the box that do not have the "correct" destination address. Try this: iptables-save | grep -e "-j input_ext" The -d address is what the firewall expects all incoming packets to have as a destination address. Try starting/restarting the firewall in ip_up. HTH, Jeffrey Quoting Carlos E. R. <robin1.listas@tiscali.es>:
The 03.06.15 at 14:18, Anders Johansson wrote:
Let us know what you find out. I've suspected for a while that there is something subtly wrong in the SuSEfirewall, but I've never suffered enough from it to muster up the energy to research it :)
No luck :-(
My sequence of events is this:
Jun 19 14:11:34 nimrodel poll.tcpip: _NOT_ starting mail and news send/fetch Jun 19 14:11:34 nimrodel ip-up.local: --> Up ppp0 /dev/ttyS1 115200 L: 81.41.199.207 R: 80.58.197.103 Par: Jun 19 14:11:34 nimrodel ip-up.local: --> Waiting for tcpdump activation Jun 19 14:11:44 nimrodel ip-up.local: --> Launching fetch/send tasks now Jun 19 14:11:44 nimrodel ip-up.local.doit: --> Starting mail and news send/fetch, and fidonet poll (expensive) Jun 19 14:11:44 nimrodel postfix/postqueue[5739]: warning: unix_trigger: write to public/qmgr: Broken pipe
And I'm getting illegal packets (second connection on the day, so it is not always the first connection after booting):
Jun 19 14:11:33 nimrodel kernel: SuSE-FW-ILLEGAL-TARGET IN=ppp0 OUT= MAC= SRC=198.41.0.10 DST=81.41.199.207 LEN=122 TOS=0x00 PREC=0x00 TTL=44 ID=0 DF PROTO=UDP SPT=53 DPT=1024 LEN=102 Jun 19 14:11:33 nimrodel kernel: SuSE-FW-ILLEGAL-TARGET IN=ppp0 OUT= MAC= SRC=198.41.0.10 DST=81.41.199.207 LEN=124 TOS=0x00 PREC=0x00 TTL=44 ID=0 DF PROTO=UDP SPT=53 DPT=1024 LEN=104
But they are not logged by tcpdump, it is still one second earlier than tcpdump is called :-(
And I don't know who/what is sending the original request, because I start the send/receive sequence a full 10 seconds after the connection is established and tcpdump started.
I wonder if I can set tcpdump to log packets from all interfaces :-?
The 03.06.19 at 13:14, Jeffrey L. Taylor wrote:
Notice that the source port is 53. This is DNS (AKA domain). It is almost certainly legitimate. Looking at the IPchains rules on my box (cable modem) the SuSE-FW-ILLEGAL-TARGET rule applies to packets to the box that do not have the "correct" destination address. Try this:
iptables-save | grep -e "-j input_ext"
None now, ppp0 (ext) conection is down. If you look at the whole thread, the problem seems to be that the firewall is restarted and network traffic starts a bit too soon, and get rejected. I'm trying to log those few seconds to verify that hypothesis.
Try starting/restarting the firewall in ip_up.
No need: the ip-up script was written by SuSE, and they do just that. That is shown in another log: Jun 19 14:11:34 nimrodel SuSEfirewall2: Firewall rules successfully set from /etc/sysconfig/SuSEfirewall2 Jun 19 14:11:34 nimrodel ip-up.local: --> Up ppp0 /dev/ttyS1 115200 L: 81.41.199.207 R: 80.58.197.103 Par: Jun 19 14:11:34 nimrodel ip-up.local: --> Waiting for tcpdump activation Jun 19 14:11:44 nimrodel ip-up.local: --> Launching fetch/send tasks now -- Cheers, Carlos Robinson
On 06/20/2003 08:28 AM, Carlos E. R. wrote:
None now, ppp0 (ext) conection is down. If you look at the whole thread, the problem seems to be that the firewall is restarted and network traffic starts a bit too soon, and get rejected. I'm trying to log those few seconds to verify that hypothesis.
I believe that is correct. I see it on my dial-in lines, they start checking mail, etc. before the firewall is ready, and get the illegal routing for the first few packets. Ignore it, it is no problem. You must be checking a name resolution (if you check the root-server, IMO, your named is misconfigured, or your ISPs), and the replies are blocked until the firewall resets with the correct IP addresses. -- Joe & Sesil Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Web Address: http://www.mydestiny.net/~joe_morris Registered Linux user 231871 God said, I AM that I AM. I say, by the grace of God, I am what I am.
The 03.06.20 at 18:09, Joe Morris (NTM) wrote:
I believe that is correct. I see it on my dial-in lines, they start checking mail, etc. before the firewall is ready, and get the illegal routing for the first few packets.
I inserted a three second delay for that reason :-)
Ignore it, it is no problem. You must be checking a name resolution (if you check the root-server, IMO, your named is misconfigured, or your ISPs), and the replies are blocked until the firewall resets with the correct IP addresses.
¡Ah! I think I have it. Somewhere in wvdial there is a check of routing and nameserver, and tries to find suse.de. --> pppd: Script /etc/ppp/ip-up run successful --> Default route Ok. --> Nameserver (DNS) Ok. --> Connected... Press Ctrl-C to disconnect It must be the nameserver check. I don't remember where that is done or configured, though. -- Cheers, Carlos Robinson
The 03.06.13 at 14:08, Christopher Mahmood wrote:
FW_ALLOW_INCOMING_HIGHPORTS_UDP="DNS domain"
That should work then. It's OK to just open all of the high udp ports though.
Probably... but I like the school of thought that says "close everything, and open something when you get to hear the complains" ;-)
(although 1024 might not be really a high port :-? )
It is, the inequality in "ports below than 1024" is strict.
Yeah, I know: but it would not be the first time that a programmer get it wrong there - as I can testify, being a programmer myself (or was). ;-)
It seems like it's doing the right thing. Maybe you have the nameserver bound to 127.0.0.1?
Well, of course: Jun 15 11:11:00 nimrodel /usr/sbin/named[1618]: listening on IPv4 interface lo, 127.0.0.1#53 Jun 15 11:11:00 nimrodel /usr/sbin/named[1618]: listening on IPv4 interface eth0, 192.168.100.2#53 -- Cheers, Carlos Robinson
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 13 June 2003 21:41, Carlos E. R. wrote:
The 03.06.13 at 10:30, Christopher Mahmood wrote:
Then I suppose the firewall should let it pass, automatically, as part of an ungoing conversation... I have seen a number of them from several domain name servers.
Yeah, do you have FW_ALLOW_INCOMING_HIGHPORTS_UDP set to 'yes' or 'DNS'? Since you're running a nameserver it should be 'yes'.
Yes, I have:
FW_ALLOW_INCOMING_HIGHPORTS_UDP="DNS domain"
(although 1024 might not be really a high port :-? )
But, during boot, I always see:
Starting Firewall Initialization (phase 3 of 3) <notice>'/etc/init.d/rc5.d/S10cups start' exits with status 0 <notice>/etc/init.d/rc5.d/S11SuSEfirewall2_final start Warning: FW_SERVICE_DNS defined, but no DNS server found running!
Why do you not run the DNS server before the firewall is called when booting then this message will disappear.
<snip> - -- A child of five would understand this. Send someone to fetch a child of five. Groucho Marx - ---------------------------------------------------- This mail has been scanned for virus by AntiVir for UNIX Copyright (C) 1994-2003 by H+BEDV Datentechnik GmbH. PGP ID: 589F8449 Fingerprint: EB1C FACF 6BEB 540E 8AC0 F04E 2A25 A2F1 589F 8449 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+6leIKiWi8VifhEkRAj2iAKCXafETy2MUv46hfvZT4xw9X6T7/gCfbyQv tVxKpLAXqU2R5QwT6qEqAGY= =et4q -----END PGP SIGNATURE-----
The 03.06.14 at 01:00, Ian David Laws wrote:
Why do you not run the DNS server before the firewall is called when booting then this message will disappear.
It is started before, as per suse init scripts. The sequence is: Master Resource Control: previous runlevel: N, switching to runlevel: 5 Starting Firewall Initialization (phase 1 of 3) INIT: Entering runlevel: 5 ... <notice>/etc/init.d/rc5.d/S05network start <notice>/etc/init.d/rc5.d/S06syslog start <notice>/etc/init.d/rc5.d/S07hotplug start <notice>/etc/init.d/rc5.d/S08spamd start <notice>'/etc/init.d/rc5.d/S08spamd start Starting Firewall Initialization (phase 2 of 3) Starting name server bind9 <notice>'/etc/init.d/rc5.d/S09SuSEfirewall2_setup start' exits with status 0 <notice>/etc/init.d/rc5.d/S09portmap start Starting service scanlogd <notice>/etc/init.d/rc5.d/S09sshd start <notice>/etc/init.d/rc5.d/S10cups start Starting Firewall Initialization (phase 3 of 3) <notice>'/etc/init.d/rc5.d/S10cups start' exits with status 0 <notice>/etc/init.d/rc5.d/S11SuSEfirewall2_final start Warning: FW_SERVICE_DNS defined, but no DNS server found running! If you look at /var/log/messages the situation is clarified: Jun 15 11:10:39 nimrodel syslogd 1.4.1: restart. Jun 15 11:10:40 nimrodel /etc/hotplug/usb.rc[857]: loaded HCD: uhci Jun 15 11:10:56 nimrodel SuSEfirewall2: Firewall rules successfully set from /etc/sysconfig/SuSEfirewall2 Jun 15 11:10:58 nimrodel /usr/sbin/named[1548]: starting BIND 9.1.3 -u named Jun 15 11:10:58 nimrodel /usr/sbin/named[1548]: using 1 CPU Jun 15 11:10:59 nimrodel root: spamd starting Jun 15 11:10:59 nimrodel /usr/sbin/named[1618]: loading configuration from '/etc/named.conf' Jun 15 11:10:59 nimrodel SuSEfirewall2: Firewall rules successfully set from /etc/sysconfig/SuSEfirewall2 Jun 15 11:11:00 nimrodel /usr/sbin/named[1618]: the default for the 'auth-nxdomain' option is now 'no' Jun 15 11:11:00 nimrodel /usr/sbin/named[1618]: listening on IPv4 interface lo, 127.0.0.1#53 Jun 15 11:11:00 nimrodel /usr/sbin/named[1618]: listening on IPv4 interface eth0, 192.168.100.2#53 Jun 15 11:11:00 nimrodel insmod: insmod: a module named ipv6 already exists Jun 15 11:11:00 nimrodel insmod: insmod: insmod net-pf-10 failed Jun 15 11:11:00 nimrodel sshd[1917]: Server listening on :: port 22. Jun 15 11:11:00 nimrodel /usr/sbin/named[1618]: running Jun 15 11:11:08 nimrodel smpppd[2003]: smpppd version 0.78 started Service named is started before stage three of the firewall setup; but it finishes after, thus the error message. -- Cheers, Carlos Robinson
participants (7)
-
Anders Johansson -
Carlos E. R. -
Christopher Mahmood -
Ian David Laws -
Jeffrey L. Taylor -
Joe Morris (NTM) -
jrn＠oregonhanggliding.com