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)
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.



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.

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 ...

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


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


DHCP Client Configuration
-------------------------
there is a file that can be used to modify the dhclient behavior but
all items in it are commented out. It is included for completeness:

/etc/dhclient.conf
# $OpenBSD: dhclient.conf,v 1.1 1998/09/08 20:26:41 marc Exp $
#
# DHCP Client Configuration
#
# See dhclient.conf(5) for possible contents of this file.
# When empty default values are used:
#
# Example:
#
# send dhcp-lease-time 3600;
# send host-name "myhost";
# supersede host-name "myhost";
# supersede domain-name "my.domain";
# request subnet-mask, broadcast-address, time-offset, routers,
# domain-name, domain-name-servers, host-name, lpr-servers, ntp-servers;
# require subnet-mask, domain-name-servers, routers;
# media "link0 link1", "link0 link1", "link0 link1", "-link0 link1";
# initial-interval 1;
# send host-name "www2";
# request subnet-mask,
#       broadcast-address,
#       routers,
#       domain-name,
#       domain-name-servers,


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


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.



Steve DiBartolomeo
Artwork Conversion Software
Santa Cruz, CA
[EMAIL PROTECTED]/[EMAIL PROTECTED]

Reply via email to