This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

I'm wondering...

Hi all,
 I'm quiet new with Astaro product so ... I have some question for you guys...
 I've installed ASL 4.0 (applied all the patches) ... and when I check the filtering log I got thhis information which seems to be a puzzle for me ... :
2004-Apr  9 00:02:19 (none) kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:12:82:6c:54:08:00 SRC=10.67.64.1 DST=255.255.255.255 LEN=358 TOS=0x00 PREC=0x00 TTL=255 ID=27106 PROTO=UDP SPT=67 DPT=68 LEN=338 
2004-Apr  9 00:02:22 (none) kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:12:82:6c:54:08:00 SRC=10.67.64.1 DST=255.255.255.255 LEN=358 TOS=0x00 PREC=0x00 TTL=255 ID=27112 PROTO=UDP SPT=67 DPT=68 LEN=338 
2004-Apr  9 00:06:48 (none) kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:12:82:6c:54:08:00 SRC=10.67.64.1 DST=255.255.255.255 LEN=382 TOS=0x00 PREC=0x00 TTL=255 ID=28101 PROTO=UDP SPT=67 DPT=68 LEN=362 
2004-Apr  9 00:06:48 (none) kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:12:82:6c:54:08:00 SRC=10.67.64.1 DST=255.255.255.255 LEN=382 TOS=0x00 PREC=0x00 TTL=255 ID=28105 PROTO=UDP SPT=67 DPT=68 LEN=362 
2004-Apr  9 00:07:34 (none) kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:12:82:6c:54:08:00 SRC=10.67.64.1 DST=255.255.255.255 LEN=382 TOS=0x00 PREC=0x00 TTL=255 ID=28275 PROTO=UDP SPT=67 DPT=68 LEN=362 
2004-Apr  9 00:08:01 (none) kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:12:82:6c:54:08:00 SRC=10.67.64.1 DST=255.255.255.255 LEN=382 TOS=0x00 PREC=0x00 TTL=255 ID=28378 PROTO=UDP SPT=67 DPT=68 LEN=362 
2004-Apr  9 00:08:01 (none) kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:12:82:6c:54:08:00 SRC=10.67.64.1 DST=255.255.255.255 LEN=382 TOS=0x00 PREC=0x00 TTL=255 ID=28382 PROTO=UDP SPT=67 DPT=68 LEN=362 
2004-Apr  9 00:08:58 (none) kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:12:82:6c:54:08:00 SRC=10.67.64.1 DST=255.255.255.255 LEN=400 TOS=0x00 PREC=0x00 TTL=255 ID=28652 PROTO=UDP SPT=67 DPT=68 LEN=380 
2004-Apr  9 00:08:59 (none) kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:12:82:6c:54:08:00 SRC=10.67.64.1 DST=255.255.255.255 LEN=399 TOS=0x00 PREC=0x00 TTL=255 ID=28688 PROTO=UDP SPT=67 DPT=68 LEN=379 
2004-Apr  9 00:09:00 (none) kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:12:82:6c:54:08:00 SRC=10.67.64.1 DST=255.255.255.255 LEN=400 TOS=0x00 PREC=0x00 TTL=255 ID=28708 PROTO=UDP SPT=67 DPT=68 LEN=380 
2004-Apr  9 00:09:00 (none) kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:12:82:6c:54:08:00 SRC=10.67.64.1 DST=255.255.255.255 LEN=400 TOS=0x00 PREC=0x00 TTL=255 ID=28712 PROTO=UDP SPT=67 DPT=68 LEN=380 
2004-Apr  9 00:09:01 (none) kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:12:82:6c:54:08:00 SRC=10.67.64.1 DST=255.255.255.255 LEN=400 TOS=0x00 PREC=0x00 TTL=255 ID=28736 PROTO=UDP SPT=67 DPT=68 LEN=380 
2004-Apr  9 00:09:01 (none) kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:12:82:6c:54:08:00 SRC=10.67.64.1 DST=255.255.255.255 LEN=399 TOS=0x00 PREC=0x00 TTL=255 ID=28752 PROTO=UDP SPT=67 DPT=68 LEN=379 
2004-Apr  9 00:09:01 (none) kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:12:82:6c:54:08:00 SRC=10.67.64.1 DST=255.255.255.255 LEN=399 TOS=0x00 PREC=0x00 TTL=255 ID=28756 PROTO=UDP SPT=67 DPT=68 LEN=379 
2004-Apr  9 00:09:01 (none) kernel: UDP Drop: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:09:12:82:6c:54:08:00 SRC=10.67.64.1 DST=255.255.255.255 LEN=400 TOS=0x00 PREC=0x00 TTL=255 ID=28760 PROTO=UDP SPT=67 DPT=68 LEN=380 

 Seems to me like a port scanning ... but ... I don't have anything in my internal network having an IP : 10.67.64.1 ...
 Could somebody tell me what's all this about ...  [:$] ...

Best regards to all and a Happy Easter


This thread was automatically locked due to age.
Parents
  • Your attached log is rather too long and repetitive. The issue can be spotted by just looking at a single log entry. Ports 67 & 68 are used for BOOTP requests. That is how a DHCP client goes about trying to obtain an IP address automatically when the machine it is running on starts up. If it can't get an address assigned to it, it will eventually time out and give up.

    You have two choices as to how you can fix this:

    1. Configure a DHCP (Dynamic Host Configuration Protocol) server on your internal network. This is the preferred choice, and is what most people do. The DHCP server, in addition to providing addresses from an address pool relevant to the network number, generally will also be configured to give out default gateway address and the addresses of the primary and secondary DNS servers. You can use the DHCP server that is built into ASL for this, or you can use another one, if you have another server on your internal network. Just don't run two conflicting DHCP servers. With a properly configured DHCP server, all client PCs can stay with the TCPIP stack default, which is to obtain an address automatically, and everything will work.

    2. You can manually configure IP addresses, default gateway and primary and secondary DNS server addresses on every machine on the internal network. In the case of Windows PCs, they will all try to obtain an address automatically, until you go into the property page of the TCPIP stack and change it by explicitly entering the info that is required. This is a real nuicance to do if you have a lot of machines, which is why the DHCP server software was invented, so that you wouldn't have to.
  • Hi,
     Probably if you have read the whole message .. instead of mocking me ... you had been noticed that I MENTIONED the fact ... there IS NO machine in my network having an IP with that value ... 
    Second ... the request is coming onto the external card (used for INTERNET) ...
    Third ... no computer in my network require a DHCP server ... all computers have STATIC IP...

    After all this ... maybe you would like to give me another solution ...
     
    Best regards,
     Alin
  • Ok.

    Go int Definitions --> Networks, and create a new definition:

    Name: Broadcast32   Addr: 255.255.255.255  Mask: 255.255.255.255

    Then go into Packet Filter --> Rules, and create a new rule:

    Any  Any  Broadcast32   Drop

    Enable the rule and move it up, so that it is rule # 1

    That will eliminate all general broadcasts to the Internet's global broadcast address (255.255.255.255) from being log dropped, something ASL does by default. From then on the packets will simply be dropped.

    And you may want to point out to your ISP that you were seeing somebody else's BOOTP or DHCP broadcast requests on your WAN interface. That should not be happening, if your ISP  is doing things properly.
  • Hi,
     First .. thanks for the quick answer ...
     I've already done that ... yes, my question was related to the fact ... is something wrong happening ... or it's my fault ...
     From what I heard is my ISP fault ... COGECO ... 

    Best regards,
     Alin
  • [ QUOTE ]
    I've already done that ... yes, my question was related to the fact ... is something wrong happening ... or it's my fault ...
     From what I heard is my ISP fault ... COGECO ... 

    [/ QUOTE ] Probably one of their other customers on the same subnet as you, or, it could be one of their own pieces of gear looking for a remote boot image without getting an answer from a BOOTP server. Anyhow, you got the problem fixed in your end, as far as your logs are concerned.

    By the way, you were not being mocked. You were simply given some constructive criticism by me, for pasting way too many identical log lines into a BBS memo. Two or three of them would be enough to get the point across. Instead of all the rest, a simple sentence pointing out that you were seeing hundreds of lines like that in your logs, would have done the trick.
  • It is not anybody's "fault". That is the way cable modem networks work. 10.67.64.1 is the IP of Cogeco's DHCP server, handing out IP's to the clients on their network, probably in the range of 24.x.x.x .

    For example, my ISP here uses 10.100.0.1 as the gateway for all our cable modems, and 10.100.0.1 hands out the 24.x.x.x addresses to the client machines.

    So, what you are seeing is their DHCP server answering queries, and since the clients do not yet have an IP address, the server has to answer to the b-cast address.

    Hope this helps.

     
  • Good explanation.  [:)]

    I never thought about that part of the issue. I dumped my cable modem in favour of ADSL years ago, and put in the "Any  Any  Broadcast32  Drop"  rule immediately when I first installed my ASL v4 box.
Reply
  • Good explanation.  [:)]

    I never thought about that part of the issue. I dumped my cable modem in favour of ADSL years ago, and put in the "Any  Any  Broadcast32  Drop"  rule immediately when I first installed my ASL v4 box.
Children
No Data