# routing



## Inc (Mar 29, 2012)

Hi,

I have a setup as follows :


```
WAN
                        I
                 FreeBSD
              (192.168.0.1)
                        I
             (192.168.0.109)
              Wireless Router
             (192.168.1.0/24)
             I                        I
 Computer                     Server
(192.168.1.200)       (192.168.1.2)
```
I want my FreeBSD box to be able to connect to "Server" (192.168.1.2) - so I added the following route :

`route add -net 192.168.1.0/24 192.168.0.109`

However - pinging 192.168.1.2 from FreeBSD (192.168.0.1) doesn't return answer. Traceroute comes in with * * * (timeout) on first.

Am I doing something wrong here?

Thanks,
Inc


----------



## SirDice (Mar 29, 2012)

Most likely it's the firewall on the wireless router that's blocking the traceroute(8).


----------



## Inc (Mar 29, 2012)

Unfortunately that's not it; it seems something isn't right in the routing - nothing ever reaches the Wireless Router.

/Inc


----------



## bbzz (Mar 29, 2012)

So follow the packet on each hop, see if it gets there.


----------



## Inc (Mar 29, 2012)

It never gets anywhere :


```
traceroute to 192.168.1.2 (192.168.1.2), 64 hops max, 40 byte packets
 1  * * *
```

/Inc


----------



## bbzz (Mar 29, 2012)

No, use something like *tcpdump*, or equivalent on router on each hop to see if packet gets there.


----------



## wblock@ (Mar 29, 2012)

The wireless router is 89.238% likely to be using NAT.  If the FreeBSD system is going to be the gateway/firewall, set the wireless router to be a bridge.


----------



## peetaur (Mar 30, 2012)

```
WAN
                |
                |
             FreeBSD
          (192.168.0.1)
                |
                |
         (192.168.0.109)
         Wireless Router
         (192.168.1.0/24)
                |
     -----------------------
     |                     |
(192.168.1.200)       (192.168.1.2)
   Desktop               Server
```


You have 2 networks: 192.168.0.0/24 and 192.168.1.0/24.

If you want the router to route, you need a "forward" rule to allow traffic to go from one to the other. You would also need a "forward" rule to allow the return packet for your pings. Make sure your router has this set up in the settings if possible. If you can't find any settings, call up the manufacturer and ask if you can do this or how.

Also, you need to set 2 routes, not just one. The FreeBSD machine must know which router to use (this is the route you added already). Also the "Server" machine must have a route set up for the return. *You probably missed this.*


----------



## SirDice (Mar 30, 2012)

peetaur said:
			
		

> Also the "Server" machine must have a route set up for the return. *You probably missed this.*


The server probably already has a default gateway. Since there's no other routes to go to the default is the only route that's needed.


----------



## peetaur (Mar 30, 2012)

Good point SirDice, so I think it is time to ask for the following:

Please provide output for the following commands on both "FreeBSD" and "Server" (which will show all routes including the default).

`# netstat -rn`
`# ifconfig`

On Windows, that would be:
`# route PRINT`
`# ipconfig`

And check /var/log/messages and whatever else you have for firewall logging when the connections fail. On some Linux distros (eg. OpenSuSE), it is /var/log/firewall or something other than messages. In my experience, Linux distros seem to always log all rejected and dropped packets somewhere by default. In Windows, it is probably in "Event log" buried somewhere in control panel, but I can't offer any details on that. (I can proudly say I have no experience at all with Windows servers.)

eg. run on both machines (on one it could deny the request, and on the other the response)
`# tail -F /var/log/messages`
Then run your ping or traceroute, and read any messages.

And I'm not sure if it is proper to ask for firewall setup (since it could be a small security breach [if you consider security through obscurity]), but if nothing else works, it could be helpful. Or to prove that it is not important, you could add a temporary test rule to allow anything from anywhere to anywhere, which must be the first rule, and see if it works.


----------

