Letting DHCP requests through iptables
This is a fairly simple task really, once you get to know how DHCP works, however, you must be a little bit cautious with what you do let in and what you do not let in. First of all, we should know that DHCP works over the UDP protocol. Hence, this is the first thing to look for. Second, we should check which interface we get and send the request from. For example, if our eth0 interface is set up with DHCP, we should not allow DHCP requests on eth1. To make the rule a bit more specific, we only allow the actual UDP ports used by DHCP, which should be ports 67 and 68. These are the criteria that we choose to match packets on, and that we allow. The rule would now look like this:
$IPTABLES -I INPUT -i $LAN_IFACE -p udp --dport 67:68 --sport \
67:68 -j ACCEPT
Do note that we allow all traffic to and from UDP port 67 and 68 now, however, this should not be such a huge problem since it only allows requests from hosts doing the connection from port 67 or 68 as well. This rule could, of course, be even more restrictive, but it should be enough to actually accept all DHCP requests and updates without opening up too large of holes. If you are concerned, this rule could of course be made even more restrictive.
mIRC DCC problems
mIRC uses a special setting which allows it to connect through a firewall and to make DCC connections work properly without the firewall knowing about it. If this option is used together with iptables and specifically the ip_conntrack_irc and ip_nat_irc modules, it will simply not work. The problem is that mIRC will automatically NAT the inside of the packets for you, and when the packet reaches the firewall, the firewall will simply not know how and what to do with it. mIRC does not expect the firewall to be smart enough to take care of this by itself by simply querying the IRC server for its IP address and sending DCC requests with that address instead.
Turning on the "I am behind a firewall" configuration option and using the ip_conntrack_irc and ip_nat_irc modules will result in Netfilter creating log entries with the following content "Forged DCC send packet".
The simplest possible solution is to just uncheck that configuration option in mIRC and let iptables do the work. This means, that you should tell mIRC specifically that it is not behind a firewall.
Appendix C. ICMP types
This is a complete listing of all ICMP types. Note the reference pointing to the RFC or person who introduced the type and code. For a complete and absolute up to date listing of all ICMP types and codes, look at the icmp-parameters document at Internet Assigned Numbers Authority.
Note Iptables and netfilter uses ICMP type 255 internally since it is not reserved for any real usage, and most likely will never have any real usage. If you set a rule to match iptables -A INPUT -p icmp --icmp-type 255 -j DROP, this will DROP all ICMP packets. It is in other words used to match all ICMP types.
Table C-1. ICMP types
TYPE | CODE | Description | Query | Error | Reference |
---|---|---|---|---|---|
Echo Reply | x | RFC792 | |||
3 | Network Unreachable | x | RFC792 | ||
3 | 1 | Host Unreachable | x | RFC792 | |
3 | 2 | Protocol Unreachable | x | RFC792 | |
3 | 3 | Port Unreachable | x | RFC792 | |
3 | 4 | Fragmentation needed but no frag. bit set | x | RFC792 | |
3 | 5 | Source routing failed | x | RFC792 | |
3 | 6 | Destination network unknown | x | RFC792 | |
3 | 7 | Destination host unknown | x | RFC792 | |
3 | 8 | Source host isolated (obsolete) | x | RFC792 | |
3 | 9 | Destination network administratively prohibited | x | RFC792 | |
3 | 10 | Destination host administratively prohibited | x | RFC792 | |
3 | 11 | Network unreachable for TOS | x | RFC792 | |
3 | 12 | Host unreachable for TOS | x | RFC792 | |
3 | 13 | Communication administratively prohibited by filtering | x | RFC1812 | |
3 | 14 | Host precedence violation | x | RFC1812 | |
3 | 15 | Precedence cutoff in effect | x | RFC1812 | |
4 | Source quench | RFC792 | |||
5 | Redirect for network | RFC792 | |||
5 | 1 | Redirect for host | |||
5 | 2 | Redirect for TOS and network | RFC792 | ||
5 | 3 | Redirect for TOS and host | RFC792 | ||
8 | Echo request | x | RFC792 | ||
9 | Router advertisement - Normal router advertisement | RFC1256 | |||
9 | 16 | Router advertisement - Does not route common traffic | RFC2002 | ||
10 | Route selection | RFC1256 | |||
11 | TTL equals 0 during transit | x | RFC792 | ||
11 | 1 | TTL equals 0 during reassembly | x | RFC792 | |
12 | IP header bad (catchall error) | x | RFC792 | ||
12 | 1 | Required options missing | x | RFC1108 | |
12 | 2 | IP Header bad length | x | RFC792 | |
13 | Timestamp request (obsolete) | x | RFC792 | ||
14 | Timestamp reply (obsolete) | x | RFC792 | ||
15 | Information request (obsolete) | x | RFC792 | ||
16 | Information reply (obsolete) | x | RFC792 | ||
17 | Address mask request | x | RFC950 | ||
18 | Address mask reply | x | RFC950 | ||
20-29 | Reserved for robustness experiment | Zaw-Sing Su | |||
30 | Traceroute | x | RFC1393 | ||
31 | Datagram Conversion Error | x | RFC1475 | ||
32 | Mobile Host Redirect | David Johnson | |||
33 | IPv6 Where-Are-You | x | Bill Simpson | ||
34 | IPv6 I-Am-Here | x | Bill Simpson | ||
35 | Mobile Registration Request | x | Bill Simpson | ||
36 | Mobile Registration Reply | x | Bill Simpson | ||
39 | SKIP | Tom Markson | |||
40 | Photuris | RFC2521 |