Hi folks,
I'm confused about another thing too.
I have an external backup drive, connected via a network cable. When things boot up, it gets IP addresses for its drives from my dhcp server.
This used to work fine. Recently however, I find that the drive's complaining of a "DHCP network addressing problem" (according to the blinking light code!). If, before the drive boots I disable my UFW firewall with sudo ufw disable, then boot the drive, then enable the firewall, everything's OK. If I don't disable the firewall while the drive's getting an IP address, I get the error.
I'm running dnsmasq as a dhcp server.
My ufw rules are like this
$ sudo ufw status Status: active
To Action From -- ------ ---- 67 ALLOW 169.254.0.0/16 68 ALLOW 169.254.0.0/16 67 ALLOW 0.0.0.0 68 ALLOW 0.0.0.0 192.168.55.66 ALLOW 192.168.55.0/24
I've omitted 4 rules which open up specific ports, with a format like this as they're not relevant (at least I think they're not relevant) 192.168.55.66 123 ALLOW Anywhere 192.168.55.66 456/tcp ALLOW Anywhere
As I understand it, the ports I need to allow access to are 67 and 68. When something asks for an IP address and it hasn't already got one, it broadcasts from the broadcast address 0.0.0.0. Sometimes, a machine will assign itself an IP address in the 169.254.0.0/16 range - e.g. a Windows machine that can't find a DHCP server on the network. If I allow this range then such machines can contact the DHCP server. The final line should allow anything with an address in the range 192.168.55.0 - 192.168.55.255 to contact any port on my server 192.168.55.66, which is where the DHCP server is.
It seems to me I must have something wrong with the UFW rules, otherwise why would disabling it allow the drive to get a DCHP lease? What have I got wrong?
Any ideas appreciated. Cheers Steve
On 21/05/13 11:54, steve-alug@hst.me.uk wrote:
It seems to me I must have something wrong with the UFW rules, otherwise why would disabling it allow the drive to get a DCHP lease? What have I got wrong?
Could it be port 53 DNS? Dnsmasq is listening to it and to port 67, but I haven't opened up 53. I'll give it a go and see what happens!
Steve
On 21/05/13 12:03, steve-alug@hst.me.uk wrote:
On 21/05/13 11:54, steve-alug@hst.me.uk wrote:
It seems to me I must have something wrong with the UFW rules, otherwise why would disabling it allow the drive to get a DCHP lease? What have I got wrong?
Could it be port 53 DNS? Dnsmasq is listening to it and to port 67, but I haven't opened up 53. I'll give it a go and see what happens!
Steve
Hmm, enabling port 53 did nothing. Actually, I said that the drive couldn't get a DHCP address, that's not strictly correct. It gets 4 ip addresses in total when it works - 2 for the drive partitions. When it doesn't work, it only gets 2.
It's a netgear SC101. Any ideas?
Steve
On 21 May 13:13, steve-ALUG@hst.me.uk wrote:
On 21/05/13 12:03, steve-alug@hst.me.uk wrote:
On 21/05/13 11:54, steve-alug@hst.me.uk wrote:
It seems to me I must have something wrong with the UFW rules, otherwise why would disabling it allow the drive to get a DCHP lease? What have I got wrong?
Could it be port 53 DNS? Dnsmasq is listening to it and to port 67, but I haven't opened up 53. I'll give it a go and see what happens!
Steve
Hmm, enabling port 53 did nothing. Actually, I said that the drive couldn't get a DHCP address, that's not strictly correct. It gets 4 ip addresses in total when it works
- 2 for the drive partitions. When it doesn't work, it only gets 2.
It's a netgear SC101. Any ideas?
Not using ufw, but apparently you should be able to get it to work by adding:
-A ufw-before-input -p udp --sport 68 --dport 67 -j ACCEPT
To the file: /etc/ufw/before.rules
Cheers,
On 21/05/13 14:40, Brett Parker wrote:
Not using ufw, but apparently you should be able to get it to work by adding: -A ufw-before-input -p udp --sport 68 --dport 67 -j ACCEPT To the file: /etc/ufw/before.rules Cheers,
Thanks Brett, it's not that I'm afraid. I suspect it's not actually a DHCP at all.
I ran dhcpdump on the server whilst trying to connect, once with the firewall on, and once with it off. The output was identical, apart from the time stamps. Part way through the process, while the firewall was on, the drive started signalling DHCP error, whilst it was still being granted leases etc.
I suspect it's after something else, like the DCOM port, or samba ports or something like that. I'll give that a try. But in the meantime, any suggestions for any good, simple to understand (use of and output of) traffic monitoring apps so I can see what the drive is trying to connect to? Wireshark comes to mind. Am I right?
Cheers!
Steve
On 21/05/13 14:40, Brett Parker wrote:
Not using ufw, but apparently you should be able to get it to work by adding: -A ufw-before-input -p udp --sport 68 --dport 67 -j ACCEPT To the file: /etc/ufw/before.rules Cheers,
Thanks Brett, it's not that I'm afraid. I suspect it's not actually a DHCP at all.
I ran dhcpdump on the server whilst trying to connect, once with the firewall on, and once with it off. The output was identical, apart from the time stamps. Part way through the process, while the firewall was on, the drive started signalling DHCP error, whilst it was still being granted leases etc.
I suspect it's after something else, like the DCOM port, or samba ports or something like that. I'll give that a try. But in the meantime, any suggestions for any good, simple to understand (use of and output of) traffic monitoring apps so I can see what the drive is trying to connect to? Wireshark comes to mind. Am I right?
Cheers!
Steve
On Tue, 21 May 2013 14:59:27 +0100 steve-ALUG@hst.me.uk allegedly wrote:
I suspect it's after something else, like the DCOM port, or samba ports or something like that. I'll give that a try. But in the meantime, any suggestions for any good, simple to understand (use of and output of) traffic monitoring apps so I can see what the drive is trying to connect to? Wireshark comes to mind. Am I right?
Certainly. Or if running on a server, try tcpdump and then run the output file through wireshark.
But, there are a bunch of other tools I find useful when looking at traffic. Try iptraf, iftop and tcptrack (curses based so will run in a terminal window. Nethogs is good for seeing what is chewing up all your bandwidth and it is also useful because it aggregates traffic by program.
If you have an X display available then etherape is a good way to visualise connections (and can be a scary experience when running a browser).
Meanwhile, I'll have a think about your problems. My first reaction was that you /must/ have UPnP running on the router, but you say not.
Mick ---------------------------------------------------------------------
blog: baldric.net gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312
---------------------------------------------------------------------
On 21/05/13 17:06, mick wrote:
On Tue, 21 May 2013 14:59:27 +0100 steve-ALUG@hst.me.uk allegedly wrote:
{}Wireshark comes to mind. Am I right?
Certainly. Or if running on a server, try tcpdump and then run the output file through wireshark.
But, there are a bunch of other tools I find useful when looking at traffic. Try iptraf, iftop and tcptrack (curses based so will run in a terminal window. Nethogs is good for seeing what is chewing up all your bandwidth and it is also useful because it aggregates traffic by program.
If you have an X display available then etherape is a good way to visualise connections (and can be a scary experience when running a browser).
Thanks for the suggestions! I'll have a look and see what's what.
Meanwhile, I'll have a think about your problems. My first reaction was that you /must/ have UPnP running on the router, but you say not.
Well, the user interface for the router definitely says it's off. I would hope the router is honouring that - it has been turned off and on again and it still says it's off, but perhaps it's lying!
Cheers Steve
On 21/05/13 18:09, steve-ALUG@hst.me.uk wrote:
On 21/05/13 17:06, mick wrote:
On Tue, 21 May 2013 14:59:27 +0100 steve-ALUG@hst.me.uk allegedly wrote:
{}Wireshark comes to mind. Am I right?
Certainly. Or if running on a server, try tcpdump and then run the output file through wireshark.
I used tcpdump and ran it through wireshark. I switched on the drive both with the firewall and without.
I discovered that the drive connects from port 20001 (microsan) to 42469 and back again (udp) (though I don't know how, as there's nothing listening AFAIK)
The problem though turned out to be SSDP - Simple Service Discovery Protocol - the basis for UPnP. "Services are announced by the hosting system with multicast addressing to a specifically designated IP multicast address at UDP port number 1900. In IPv4, the multicast address is 239.255.255.250" (Wikipedia)
Which made me remember my firewall rule 192.168.55.66 ALLOW 192.168.55.0/24 had previously been ANYWHERE ALLOW 192.168.55.0/24
I had updated it to "try to make it more secure". I had reasoned that there was only 127.0.0.1 and 192.168.55.66 being used on my server, so limiting the ip address to just the one address would be fine. It obviously isn't!
Thanks for the pointers Steve
-
Brett Parker -
mick -
Steve -
steve-ALUG＠hst.me.uk -
steve-alug＠hst.me.uk