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=8863<UP,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 0xffffff00 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=8863<UP,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 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 Any messages in the logfiles? There should be a reason the IP address just vanishes... Is dhclient still running at this point? > Review of Configuration Files > ====================================================== > After reviewing the man pages I checked all of the pertinent configuration > files to see if there was something obviously wrong: > > > interface assignments > ---------------------- > > /etc/hostname.ne3 > dhcp > > > > /etc/hostname.xl0 > inet 192.168.0.1 255.255.255.0 NONE > > > hosts file > ---------- > there is no list of hosts other than the local host. > > /etc/hosts > ::1 localhost.artwork.com localhost > 127.0.0.1 localhost.artwork.com localhost gateway.artwork.com gateway > > > computer name > -------------- > /etc/myname > gateway.artwork.com > > DNS Servers > ------------ > no local DNS is run. The resolv.conf file should be updated by the > dhclient which appears to be happening. > > /etc/resolv.conf > nameserver 64.105.172.28 > nameserver 67.100.88.27 > lookup file bind > > > packet forwarding > ------------------ > > /etc/sysctl.conf > net.inet.ip.forwarding=1 > net.inet6.ip6.forwarding=1 > > > Packet Filter Configuration > --------------------------- > > > /etc/pf.conf > > ext_if="ne3" > int_if="xl0" > internal_net="192.168.0.0/24" > > scrub in all > #basic network translation > nat on $ext_if from $internal_net to any -> ($ext_if) > #filter rules > block return log on $ext_if all > pass on $ext_if inet proto icmp all icmp-type 8 code 0 keep state > pass out on $ext_if proto udp all keep state > pass out on $ext_if proto tcp all keep state > pass in on $int_if inet from $internal_net to any keep state > #allow DHCP for Covad DSL Line > pass in on $ext_if proto udp from any port 69 to any port 69 > pass in on $ext_if proto udp from any port 68 to any port 68 > pass in on $ext_if proto udp from any port 67 to any port 67 > > #allow ftp-proxy program to connect back to the firewall > pass in on $ext_if proto tcp from any to any port 21 flags S/SA keep state > pass in on $ext_if proto tcp from any to any port > 49141 keep state You'll want to look at tcpdump -envvvi pflog0 while trying to troubleshoot; pf might block stuff you don't want it to. (Although I couldn't see why; most errors here shouldn't result in vanishing IP addresses.) > DHCP Client Configuration > ------------------------- > there is a file that can be used to modify the dhclient behavior but > all items in it are commented out. > Hardware? > ---------- > here is a portion of the dmesg results showing the two network interfaces: > > 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 Upgrading is a good idea, but you've already been told so. > I don't see anything out of order; yet still can't get from the internal > network to the internet. People are getting tense - we'd be completely > disconnected if it were not for the bakery accross the street whose free > internet signal reaches into one end of our office. -- TFMotD: asa, fpr (1) - interpret carriage-control characters
