Re: firewall stopped working unexpectedly
Are you referring to the recent IPV6 issue or another? -- John Brooks [EMAIL PROTECTED] 2007/4/3, [EMAIL PROTECTED] dmesg gateway# dmesg OpenBSD 3.5 (GENERIC) #1: Sat May 1 08:18:25 PDT 2004 Sorry for not being more helpfull, but why are you running a firewall with at least one known remote root exploit? Update! Best Martin
Re: firewall stopped working unexpectedly
On Thu, Apr 05, 2007 at 11:55:55AM -0500, John Brooks wrote: 2007/4/3, [EMAIL PROTECTED] dmesg gateway# dmesg OpenBSD 3.5 (GENERIC) #1: Sat May 1 08:18:25 PDT 2004 Sorry for not being more helpfull, but why are you running a firewall with at least one known remote root exploit? Update! Are you referring to the recent IPV6 issue or another? I'm pretty sure it's the IP6 issue. Joachim -- TFMotD: basename (1) - return filename portion of pathname
Re: firewall stopped working unexpectedly
2007/4/3, [EMAIL PROTECTED] dmesg gateway# dmesg OpenBSD 3.5 (GENERIC) #1: Sat May 1 08:18:25 PDT 2004 Sorry for not being more helpfull, but why are you running a firewall with at least one known remote root exploit? Update! Best Martin
Re: firewall stopped working unexpectedly
On Tue, Apr 03, 2007 at 02:21:07PM -0700, [EMAIL PROTECTED] wrote: I am the sysadmin for a small company that uses an OpenBSD 386 PC as a firewall behind a Covad DSL modem. It has been working (though with some intermiitent problems) for several years now but stopped working - it was fine on Sunday evening April 1 but dead on Monday morning April 2. Nobody was in between Sunday night when it worked and Monday morning when it didn't. If anyone can provide specific ideas based on the information below I would certainly appreciate it and am prepared to pay a consultantion fee for advise leading to a fix. Basic Hardware --- Covad DSL Modem --[ne3] firewall [xl0] -- switch -- internal network firewall = PII/256MB running Open BSD 3.5 with 2 NICs ne3 = external interface configured using DHCP (192.168.1.1) What part does 192.168.1.1 play here? You certainly get a different IP address when querying the DHCP server, as you wrote below. xl0 = internal interface fixed internal network (192.168.0.0/24) Symptoms - Nobody on the internal network can get out to check email or surf the net. Something happended in the hours between Sunday night around 8:30 pm and Monday morning at 8:00 am. But what? I initially assumed it was a hardware problem - DSL modem, network card or PC died. But initial checks showed everyting seemed to be working as it should: Eliminating the Obvious --- Cables - Ethernet cables checked out via susbstitution. Modem I - power cycled as recommended by Covad. Modem II - hooked laptop to modem and successfully got DHCP address and connection to Internet just fine using Windows XP. This eliminates the modem, the DHCP service, COVAD DSL service and cable from modem as the culprit. Network Cards - substituted known good network cards in firewall - no change. Firewall PC - rebooted; then substituted known good backup firewall machine no change. ping - I can ping from internal network to the internal interface on the firewall. I can SSH into the firewall from the internal network. I cannot ping from the firewall to a machine outside. But this may be due to the packet filter. Ethernet Switch - this is OK since we can log onto the firewall from any machine on the inside network via SSH. Time Change - I though that the early DST time might be somehow at fault - called COVAD support; the tech claimed this was not the case. Fiddled with the clock but it doesn't seem to have any affect. While annoying, wrong DST shouldn't shut down a firewall. Firewall Configuration? --- At this point I had to assume that something changed in the firewall's configuration -- either by accident or somehow maliciously -- though the malicious option seemed dubious since the backup machine was neither on-line or even switched on! However I decided to review the pertinent files and settings to see what might possibly be the problem. During boot, I did see an unusual message that indicated some kind of problem configuring the external network interface card using dhcp. I had trouble to capture the actual message (didn't appear in dmesg or var/log/messages) but I was able to reproduce it using the dhclient command: gateway# dhclient ne3 Internet Software Consortium DHCP Client 2.0pl5-OpenBSD Listening on BPF/ne3/00:20:78:14:f5:ed Sending on BPF/ne3/00:20:78:14:f5:ed Sending on Socket/fallback/fallback-net ifconfig: SIOCDIFADDR: Can't assign requested address -- DHCPDISCOVER on ne3 to 255.255.255.255 port 67 interval 7 DHCPOFFER from 192.168.1.1 DHCPREQUEST on ne3 to 255.255.255.255 port 67 DHCPACK from 192.168.1.1 New Network Number: 66.166.238.0 New Broadcast Address: 66.166.238.255 bound to 66.166.238.189 -- renewal in 30 seconds. What was the output of ifconfig beforehand? Afterwards? It seems to get the IP address from the COVAD DHCP server but then things go haywire. Within a few seconds I start seeing error messages on the console: Apr 2 14:54:18 gateway dhclient: send_fallback: No route to host Apr 2 14:54:18 gateway dhclient: send_fallback: No route to host this error message gets repeated constantly ... That's consistent with the error you report below. if I run ifconfig on ne3 I get: #ifconfig ne3 ne3: flags=8863UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST mtu 1500 address: 00:20:78:14:f5:ed media: Ethernet manual inet6 fe80::220:78ff:fe14:f5ed%ne3 prefixlen 64 scopeid 0x2 inet 66.166.238.189 netmask 0xff00 broadcast 66.166.238.255 which seems to be correct. But running ifconfig a few times eventually it appears to lose the correct IP address and go down: ifconfig ne3 ne3: flags=8863UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST mtu 1500
Re: firewall stopped working unexpectedly
Hi Steve, I've interspersed my comments, but first a preface: I've never used (although read a bit on) DHCP. I use Debian (looking at switching to BSD). I run old hardware boxes so can troubleshoot. I'm not expecting this to be a definitive answer but I hope its more help than noise. Doug. On Tue, Apr 03, 2007 at 02:21:07PM -0700, [EMAIL PROTECTED] wrote: Covad DSL Modem --[ne3] firewall [xl0] -- switch -- internal network firewall = PII/256MB running Open BSD 3.5 with 2 NICs ne3 = external interface configured using DHCP (192.168.1.1) xl0 = internal interface fixed internal network (192.168.0.0/24) Nobody on the internal network can get out to check email or surf the net. Something happended in the hours between Sunday night around 8:30 pm and Monday morning at 8:00 am. But what? Network Cards - substituted known good network cards in firewall - no change. Where they the same kind (same drivers, or did you change /etc/hostname.* to match? Firewall PC - rebooted; then substituted known good backup firewall machine no change. Does the modem (never used one) remember hardware ethernet address so get confused when a different box requests the same stuff? Did you reset the modem each time you changed boxes or NICs? Since you know the x10 NIC (internal interface) works, what happens if you swap them in your configuration? If the ne3 is now internal, does it work? In other words, first ensure that you have two NICs funtioning in all respects. ping - I can ping from internal network to the internal interface on the firewall. I can SSH into the firewall from the internal network. What happens if you log into the firewall via the console (not ssh)? DHCPACK from 192.168.1.1 New Network Number: 66.166.238.0 New Broadcast Address: 66.166.238.255 bound to 66.166.238.189 -- renewal in 30 seconds. ^^^ It seems to get the IP address from the COVAD DHCP server but then things go haywire. Within a few seconds I start seeing error messages on the console: Apr 2 14:54:18 gateway dhclient: send_fallback: No route to host Apr 2 14:54:18 gateway dhclient: send_fallback: No route to host #ifconfig ne3 inet 66.166.238.189 netmask 0xff00 broadcast 66.166.238.255 which seems to be correct. But running ifconfig a few times eventually it appears to lose the correct IP address and go down: ifconfig ne3 inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255 interface assignments -- /etc/hostname.ne3 dhcp /etc/hostname.xl0 inet 192.168.0.1 255.255.255.0 NONE /etc/sysctl.conf net.inet.ip.forwarding=1 net.inet6.ip6.forwarding=1 Hardware? -- dmesg gateway# dmesg OpenBSD 3.5 (GENERIC) #1: Sat May 1 08:18:25 PDT 2004 . xl0 at pci0 dev 14 function 0 3Com 3c905B 100Base-TX rev 0x30: irq 11 address 00:50:da:4f:e1:10 exphy0 at xl0 phy 24: 3Com internal media interface ne3 at pci0 dev 16 function 0 Winbond Linksys EtherPCI II rev 0x00: irq 9 ne3: address 00:20:78:14:f5:ed
Re: firewall stopped working unexpectedly
thanks for the replies -- I actually got a real time caller who helped me check various items until we narrowed the problem down further. Got the connection back manually. 1. 3.5 vs 4.0 -- I've just ordered the 4.0 CD's and as soon as they arrive I'll build a machine with 4.0 on it and hope everything gets back to normal. But in the meantime I still want to identify and fix the current problem. 2. 192.168.1.1 this is the address of the Covad modem's DHCP server -- not of the external NIC (ne3) 3. the problem seems to be that the Covad DHCP server is not providing a gateway IP address. Or possibly the dhclient is not accepting one. At least, by using the netstat -rn command we found no default route. This means that nothing gets out the door. 4. Manually adding the default route makes the firewall work again: add net default: gateway 66.166.238.1 so the question is why is no gateway getting passed from the DHCP server to the external NIC? I am examining the dhclient.conf file to see what I can do with that. I have no /etc/mygate file in place which seems to be consistent with the documentation for mygate: /etc/mygate contains the address of the gateway host, if it exists. The gateway is added to the routing tables by the route(8) utility. If /etc/mygate does not exist, no default gateway is added to the routing tables. The file should contain a single line specifying the gateway address, in dotted quad notation (e.g. 192.0.2.0). /etc/mygate is processed after all interfaces have been configured. It will therefore override any DHCP-supplied default route information. Steve DiBartolomeo Artwork Conversion Software, Inc. [EMAIL PROTECTED]/[EMAIL PROTECTED]
Re: firewall stopped working unexpectedly
On Tue, Apr 03, 2007 at 04:34:26PM -0700, [EMAIL PROTECTED] wrote: thanks for the replies -- I actually got a real time caller who helped me check various items until we narrowed the problem down further. Got the connection back manually. 1. 3.5 vs 4.0 -- I've just ordered the 4.0 CD's and as soon as they arrive I'll build a machine with 4.0 on it and hope everything gets back to normal. But in the meantime I still want to identify and fix the current problem. 2. 192.168.1.1 this is the address of the Covad modem's DHCP server -- not of the external NIC (ne3) 3. the problem seems to be that the Covad DHCP server is not providing a gateway IP address. Or possibly the dhclient is not accepting one. At least, by using the netstat -rn command we found no default route. This means that nothing gets out the door. 4. Manually adding the default route makes the firewall work again: add net default: gateway 66.166.238.1 so the question is why is no gateway getting passed from the DHCP server to the external NIC? I am examining the dhclient.conf file to see what I can do with that. I have no /etc/mygate file in place which seems to be consistent with the documentation for mygate: tcpdump your dhcp conversation; worst case you can -Xs1500 and look to see what the gateway coming down the pipe is; i don't remember offhand if any number of '-v' action makes tcpdump(8) deciper dhcp conversations. actually, yeah, it looks like it does do a protocol decode at least with '-vv' i'm of the opinion that if they weren't handing out a gateway address in a network topology where the subscribers required one (eg, not ppp), their world would be on fire. check for 'G:blahblah' in the tcpdump of the reply you get back to your dhcp request/discover. back to the mygate stuff, it's logical to have no /etc/mygate if you get your default route via dhcp. the 30 second lease time has me a bit weirded out. initially it's real easy to think that the DST thing is at fault there, but lease times are handed out in integers of seconds (LT:BLAHBLAH), so even if your clock and their clock are worlds apart, shouldn't trip each other out. if you still have an old dhclient.leases file, or if your dhclient.leases file has old lease stanzas, was it always 30s? if the 30s is new, what if you do dhclient, get your lease, kill dhclient and then at 15s do a renew? like: $ sudo /sbin/dhclient ne3 sudo pkill dhclient sleep 15 sudo /sbin/dhclient ne3 do you get a longer duration the second time around? makes me wonder if they're trying to do some sort of detect clients that waste our IP space by pulling IPs needlessly policy that perhaps their tech support doesn't know about yet. -- jared
