Aha, this explanation really make it almost as clear as mud.
It's rather technical, but if you bind a service to 192.168.10.4 for example, it's not going to matter on which interface that packet arrives on, the service is going to handle the connection. Even if you have a dozen other interfaces, all on different subnets and the packet comes in on any of the other interfaces, the service is still going to accept the connection. You would have some really dodgy routing on your network, but the service will happily accept the connection.
Also a bit of a network primer:
A TCP connection starts with a SYN packet, if that SYN packet is sent to a closed port (i.e. no service listening), it will respond with a RST packet. And you get a "connection refused" error. When you send a TCP SYN and there's no response you get a "connection timed out" error, that's usually because a firewall dropped that packet. If the firewall was open but there is no service listening (closed port) you would get a RST packet in return.
A UDP packet sent to a closed port will result in an ICMP destination port unreachable. Or just deafening silence, depends a bit on the router or the receiving OS settings. You typically don't want to sent an ICMP response because UDP is easily spoofed. UDP is more like a fire and forget missile, there's no state, you send the packet and it arrives or not. The sender has no way to find out.
Things to check on the FreeBSD host end:
ifconfig re0 (or whatever interface you use). You should see something similar to this:
Code:
% ifconfig re0
re0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
ether 00:01:2e:41:a3:e8
inet 192.168.10.40 netmask 0xffffff00 broadcast 192.168.10.255
inet6 fe80::201:2eff:fe41:a3e8%re0 prefixlen 64 scopeid 0x1
inet6 2a02:a46e:550b:10:201:2eff:fe41:a3e8 prefixlen 64 autoconf pltime 604800 vltime 2592000
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
Things to note, the UP in the first line to indicate the interface is actually up. Is the IP address correct and what you expect, same for the netmask. Don't worry too much about the inet6 addresses.
Second thing to look at is the media, this should be "Ethernet autoselect" and then "1000baseT <full-duplex>" is an indication it successfully negotiated a 1Gbps connection. Third and last is the "status", this has to be "active", this indicates the network card found a carrier signal. Which means it's been plugged in and should be working.
Then look at the routing table,
Code:
% netstat -rn4
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 192.168.10.1 UGS re0
127.0.0.1 link#2 UH lo0
192.168.10.0/24 link#1 U re0
192.168.10.40 link#2 UHS lo0
default is your default gateway. It should be there, but even without a gateway you should still be able to connect to anything on the so-called directly connected network. Which is the network associated with the interface. The gateway is really only important when you need to access something beyond your directly connected networks.
Which brings me to the final thing to look at. The ARP table. Whenever you need to send a packet to a directly connected host you first need to know the MAC address of the destination host. Here's were ARP comes in. An ARP request will be broadcast on the network like "Hey! Who has IP address 192.168.1.1?" And the host with that IP address will send a response ARP "I am 192.16.1.1". This information is cached in the ARP table. You can look at it with
arp -a. You should, at the very least, have an entry for your router's IP address,
myrouterhostname (192.168.10.1) at de:ad:be:ef:f0:0d on re0 expires in 324 seconds [ethernet].
If you
ping(1) your gateway address you SHOULD get its MAC address in your ARP table. If you don't get that there's something really fishy going on on layer 2. And everything on top of that IP/ICMP/TCP/UDP (layer3/4) is going to fail. And all layers above it (layer 7; HTTP for example) is certainly never going to work.
Now, your layer 2 is probably working fine, I understood you're using DHCP. If layer 2 wasn't working DHCP would fail too. So just the fact the host send out a DHCP DISCOVER and received a DHCP OFFER with an IP address, mask and router means things work.
And the router not responding to pings is probably because somebody turned its firewall up to 11 and it blocks all ICMP to itself. So start looking there.
