Hi -- My system specs: Small LAN, mixed Windows and SuSE Linux 7.1. One box is directly connected to the Internet via a cable modem, performing firewall and masquerading duty for the other machines on the system. This box is running the kernel from k_i386-2.4.16-34.i386.rpm. It also runs SuSEfirewall2 (2.1.0) and ICSA DHClient (from the 7.1 distribution CDRom). When it's working, it works very well. My problem: When the DHCP lease times out, the firewall box can't acquire a new one. It appears that the firewall's anti-spoofing rules are blocking the DHCP server's reply. At the time when this happens, I get numerous SuSE-FW-DROP-ANTI-SPOOFING messages with source port = 67 and destination port = 68. At this point, I lose all Internet connectivity until I reboot the firewall box. My configuration includes FW_SERVICE_DHCLIENT="yes". Although I have a reasonable theoretical understanding of iptables, I have to admit that the SuSEfirewall2 script, especially in the area of antispoofing, is well beyond me. If anyone can help with this, I'm all ears. Thanks, -- Alan Hadsell "Whatever does not kill me makes me stranger".
On Mon, 1 Apr 2002, Alan Hadsell wrote: AH> Hi -- AH> AH> My system specs: Small LAN, mixed Windows and SuSE Linux 7.1. One box AH> is directly connected to the Internet via a cable modem, performing AH> firewall and masquerading duty for the other machines on the system. AH> This box is running the kernel from k_i386-2.4.16-34.i386.rpm. It AH> also runs SuSEfirewall2 (2.1.0) and ICSA DHClient (from the 7.1 AH> distribution CDRom). When it's working, it works very well. AH> AH> My problem: When the DHCP lease times out, the firewall box can't AH> acquire a new one. It appears that the firewall's anti-spoofing rules AH> are blocking the DHCP server's reply. At the time when this happens, AH> I get numerous SuSE-FW-DROP-ANTI-SPOOFING messages with source port = AH> 67 and destination port = 68. At this point, I lose all Internet AH> connectivity until I reboot the firewall box. AH> AH> My configuration includes FW_SERVICE_DHCLIENT="yes". AH> AH> Although I have a reasonable theoretical understanding of iptables, I AH> have to admit that the SuSEfirewall2 script, especially in the area of AH> antispoofing, is well beyond me. If anyone can help with this, I'm AH> all ears. AH> AH> Thanks, AH> AH> Hello Alan, You also need to set FW_SERVICES_EXT_UDP="bootpc" Regards, Erwin Lam -- Erwin Lam (erwin.lam@gmx.net)
Erwin Lam
On Mon, 1 Apr 2002, Alan Hadsell wrote:
AH> My problem: When the DHCP lease times out, the firewall box can't AH> acquire a new one. It appears that the firewall's anti-spoofing rules AH> are blocking the DHCP server's reply. At the time when this happens, AH> I get numerous SuSE-FW-DROP-ANTI-SPOOFING messages with source port = AH> 67 and destination port = 68. At this point, I lose all Internet AH> connectivity until I reboot the firewall box. AH> AH> My configuration includes FW_SERVICE_DHCLIENT="yes".
You also need to set
FW_SERVICES_EXT_UDP="bootpc"
This should be equivalent to FW_SERVICES_EXT_UDP="68", right? OK, I'll try that. I guess I don't understand why it's necessary, though. The script says: ,----[ from SuSEfirewall2 ] | test "$FW_SERVICE_DHCLIENT" = yes && { | $LAA $IPTABLES -A INPUT -j LOG ${LOG}"-ACCEPT " -p udp --sport 67 -d 255.255.255.255/32 --dport 68 | $IPTABLES -A INPUT -j "$ACCEPT" -m state --state ESTABLISHED -p udp --sport 67 -d 255.255.255.255/32 --dport 68 | } `---- ...which seems to imply that any such packet would be accepted, and not hit the anti-spoofing rules (which are applied later). Or is it tripping over the "--state ESTABLISHED"? I also don't understand this: if this is an issue of not ACCEPTing the message, why don't I get UNALLOWED-TARGET messages, rather than ANTI-SPOOFING messages (in other words, I don't understand why it has decided this is a spoofed messaged rather than just one directed to a closed port). -- Alan Hadsell "Whatever does not kill me makes me stranger".
On Mon, 1 Apr 2002, Alan Hadsell wrote:
AH> Erwin Lam
Erwin Lam
When you first try to acquire an ip-address using dhcp, your computer doesn't have an ip-address yet. Therefore, your computer and the dhcp-server must use broadcasts (address 255.255.255.255) to exchange information (the dhcp-client uses udp port 68 and the dhcp-server uses udp port 67). That traffic is allowed by the above rule.
Duh. I should have figured that out. I was tripping over the fact that the DHCP setup happens before the firewall is created. Thanks for the whack in the head.
Once you have a valid lease and half of the lease time has expired, the dhcp-client (your computer) requests renewal of the lease from the dhcp-server. Because the client now has a valid ip-address and also knows the ip-address of the dhcp-server, this exchange of information uses the valid ip-addreses of both client and server, i.e. it no longer relies on broadcasts. However, this requires you to set FW_SERVICES_EXT_UDP="bootpc". Otherwise, response from the dhcp-server to port 68 at your ip-address will be blocked by your firewall.
OK, that makes sense.
AH> ANTI-SPOOFING messages (in other words, I don't understand why it has AH> decided this is a spoofed messaged rather than just one directed to a AH> closed port).
Well,... I am not an expert in this matter and I don't understand it either, but could you please post that log entry so we can have a look at it.
I'll post it as soon as I get back to my system, which will be this weekend. I'm on the road just now, and I can't get to my firewall from the outside. Thanks for your help. -- Alan Hadsell "Whatever does not kill me makes me stranger".
Erwin Lam
Well,... I am not an expert in this matter and I don't understand it either, but could you please post that log entry so we can have a look at it.
OK, finally back at home where I can get to my logs. Here's a log entry from this morning: ,---- | Apr 6 07:50:33 wally kernel: SuSE-FW-DROP-ANTI-SPOOFING IN=eth1 OUT= MAC= SRC=64.85.299.299 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=68 DPT=67 LEN=308 `---- Interestingly, the source address (which I have mangled in the message above, BTW) is actually *my* IP address, and that's consistent with the source port (bootpc) and the destination port (bootps). IOW, it looks like it's the request from my DHCP client that's being trapped. What I can't figure out is how this message is winding up in the INPUT table, which is where the anti-spoofing rules are. -- Alan Hadsell "Whatever does not kill me makes me stranger".
On Sat, 6 Apr 2002, Alan Hadsell wrote:
AH> Erwin Lam
Please note: this may be a duplicate post. If so, please disregard
it; I thought I had send it but could not find any evidence of having
done so.
Erwin Lam
Well,... I am not an expert in this matter and I don't understand it either, but could you please post that log entry so we can have a look at it.
OK, here it is. I have mangled my IP address, replacing it with 64.85.299.299. ,---- | Apr 6 07:50:33 wally kernel: SuSE-FW-DROP-ANTI-SPOOFING IN=eth1 OUT= MAC= SRC=64.85.299.299 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=68 DPT=67 LEN=308 `---- What's interesting here is that this appears to be the _request_ from dhclient to the server that's being dropped, rather than the response from the server. But if so, how did it wind up on the INPUT chain? Now I'm more confused than ever. -- Alan Hadsell "Whatever does not kill me makes me stranger".
Erwin Lam
On Mon, 1 Apr 2002, Alan Hadsell wrote:
You also need to set
FW_SERVICES_EXT_UDP="bootpc"
Yep, did that, and it fixed the problem. Thanks.
"John Trickey"
What I can't figure out is how this message is winding up in the INPUT table, which is where the anti-spoofing rules are.
There is no major deal here. DST is a broadcast address and your interface will see its own broadcast. If you run samba you would see the netbios broadcasts to the local broadcast address, 64.255.255.255 if it is a Class A or look at ifconfig to see what you're using.
Indeed, I figured this out after about 3 hours of banging my head against the wall. This message is a red herring; it's not the source of the problem.
I don't run SuSEFirewall so I cannot advise of any action to take. On my firewall I detect valid broadcasts on the LAN interface using --mac-source and quietly drop them.
Given the amount of other noise coming from various port scans, an occasional message like this is no big deal. Thank you for your help. -- Alan Hadsell "Whatever does not kill me makes me stranger".
participants (2)
-
Alan Hadsell
-
Erwin Lam