Antony Stone wrote:
About the identd stuff:On Saturday 10 July 2004 3:12 pm, Erik Wikström wrote:
Hi
I've been thinking for some time now about the rules needed to allow the
firewallbox to receive its public IP from a DHCP-server but everywhere I
look it's done in different ways.
But then I realised that since I don't have a source or destination
address netfilter will probably not be able to track the connection.
You'll find it (almost?) impossible to use netfilter to control DHCP requests.
You can do all the usual stuff with follow-up lease renewals and so on, but as you already said, before the first DHCP request, you don't have an IP address, and you're right - the IP stack and netfilter don't do much under those circumstances.
Another way to look at what I'm saying is "you don't have to do anything special with netfilter to allow your machine to get an address by DHCP", so I wouldn't worry about it.
$IPTABLES -I INPUT -i $LAN_IFACE -p udp --dport 67:68 --sport \ 67:68 -j ACCEPT
But this opens two ports and the only protocol I know of that uses two
ports is FTP, so If someone could give me some hints I'd be happy.
UDP 67 is used by the DHCP server - this is the port the client sends requests to, and it's the port the responses (and, often, informational messages once you have your lease) come from on the server
UDP 68 is used by the DHCP client - this is the port the client sends requests from, and it's the port the response from the server are sent to.
So, if you're running the client end, you only need to allow packets in to port 68 (and they'll be coming from the server's port 67)
RFC2131 is the definitive reference.
Just as a point of information, by the way, I get a DHCP address from my ISP on a cable modem, and I allow the requests out from my firewall, and the replies back again, but I block any new connections initiated from the outside (including the ISP). My logs show a DHCP packet from ISP port 67 to my firewall port 68 about every 20 seconds (the lease time is 86400 seconds = 24 hours).
I was also wondering if about Ident, today I use it only when connecting
to IRC-servers and have port 113 forwarded to the computer running the
IRC-client but this solution is not so good if another computer on my
network should have a need of Ident. So I was wondering: If I install an
Identd on my firewallbox and let it take care of requests would it work,
considering that the connection does not origin from the firewallbox?
My experience of most things which want an ident response is that if they get any response at all, they're happy. It doesn't matter whether it's accurate or not - they just want some sort of response.
This may depend on the particular IRC server, however, and as always, YMMV.
For some "fake identd" software, see for example:
http://www.guru-group.fi/~too/sw/identd.readme http://hangout.de/fakeidentd
And even a trivial Perl script to do it for you:
http://www.bovine.net/~jlawson/coding/fake-identd/identd.txt
Regards,
Antony.
If you're DROPing it (or like most cases - default DROP policies), not forwarding it to the clients or not having identd server that will probably cause slow irc connecting. The irc server will wait for some kind of response (any kind in most cases ;-) as -j DROP really drops requests without replying.
So the solution is to forward identd requests to the clients or use something like on the router/gw/fw:
iptables -A INPUT -p tcp --dport 113 -j REJECT
that will return icmp-port-unreachable (or just port-unreachable, not sure) to the server and will resolve the irc issue.
regards, Georgi Alexandrov
