Default gateway always used even if a specific route is specified.

We have 2 gateway on the same subnet. One is 192.168.0.3(default) and .2 The gateway .2 has access to some device that .3 doesn't. We have created the following route to have traffic of 10.10.x.x to be routed directly to 192.168.0.2.

Destination Gateway Flags Refs Use Netif Expire
default 192.168.0.3 UGS 0 3808954 re0
10.10.0.0 192.168.0.2 UGS 0 24 re0

Now the issue is everything wants to route through the .3 gateway.

traceroute to 10.10.18.118 (10.10.18.118), 64 hops max, 52 byte packets
1 192.168.0.3 (192.168.0.3) 0.536 ms 1.323 ms 0.355 ms
2 * * *

As a work around, we have created a route on the .3 gateway to forward 10.10 traffic through 192.168.0.2 gateway.

traceroute to 10.10.18.118 (10.10.18.118), 64 hops max, 52 byte packets
1 192.168.0.3 (192.168.0.3) 0.536 ms 1.323 ms 0.355 ms
2 192.168.0.2 (192.168.0.2) 0.601 ms 0.642 ms 0.636 ms
3 one.one.one.one (1.0.0.1) 20.558 ms 18.371 ms 18.127 ms
4 10.10.18.118 (10.10.18.118) 19.632 ms 21.249 ms 17.772 ms

Now this work for ping but we are having other issue that is being caused by routing the traffic through 192.168.0.3. All we are trying to do is route 10.10.0.0 directly to 192.168.0.2 without going through 192.168.0.3.
 
What command did you use to create that static route? Since it does not list a subnet mask or prefix length, my guess would be you created it for the /32, only that single IP address.
 
Was create with /16. We also tried, 10.10.18.0/24 and 10.10.18.118/32 all with same result.
Code:
netstat -nr
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            192.168.0.3       UGS         0  3840785    re0
10.10.0.0/16       192.168.0.2       UGS         0       48    re0
 
Supply the second route with a network mask /16. The default is /24 /0 and this is why the 10.10.18.118 address does not match.
You need to set the destination to "10.10.0.0/16" instead of "10.10.0.0"

Edit: In your first post the mask "/16" was not displayed, so I assume your initial configuration had a "/24" mask.
Use this command to test if the routing table is used correctly: route get 10.10.18.118
It should show a line:
gateway: 192.168.0.2

Traceroute should also work. The first hop should go to 192.168.0.2.
If not, post the complete current output of netstat -rn4.

We have 2 gateway on the same subnet. One is 192.168.0.3(default) and .2 The gateway .2 has access to some device that .3 doesn't. We have created the following route to have traffic of 10.10.x.x to be routed directly to 192.168.0.2.

Destination Gateway Flags Refs Use Netif Expire
default 192.168.0.3 UGS 0 3808954 re0
10.10.0.0 192.168.0.2 UGS 0 24 re0

Now the issue is everything wants to route through the .3 gateway.

traceroute to 10.10.18.118 (10.10.18.118), 64 hops max, 52 byte packets
1 192.168.0.3 (192.168.0.3) 0.536 ms 1.323 ms 0.355 ms
2 * * *

As a work around, we have created a route on the .3 gateway to forward 10.10 traffic through 192.168.0.2 gateway.

traceroute to 10.10.18.118 (10.10.18.118), 64 hops max, 52 byte packets
1 192.168.0.3 (192.168.0.3) 0.536 ms 1.323 ms 0.355 ms
2 192.168.0.2 (192.168.0.2) 0.601 ms 0.642 ms 0.636 ms
3 one.one.one.one (1.0.0.1) 20.558 ms 18.371 ms 18.127 ms
4 10.10.18.118 (10.10.18.118) 19.632 ms 21.249 ms 17.772 ms

Now this work for ping but we are having other issue that is being caused by routing the traffic through 192.168.0.3. All we are trying to do is route 10.10.0.0 directly to 192.168.0.2 without going through 192.168.0.3.
 
Last edited:
Something else, you might have another rule overriding the destination network. If you post the complete routing table we could take a look.
 
Thanks all for the quick reply to my post.

Here's the result of the request. I find interesting that it the route get shows the proper gateway but the traceroute still goes through the default gateway.
Code:
/usr/local/etc(29): route get 10.10.18.118
   route to: 10.10.18.118
destination: 10.10.0.0
       mask: 255.255.0.0
    gateway: 192.168.0.2
  interface: re0
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0

/usr/local/etc(29): traceroute 10.10.18.118
traceroute to 10.10.18.118 (10.10.18.118), 64 hops max, 52 byte packets
 1  192.168.0.3 (192.168.0.3)  0.568 ms  0.329 ms  0.244 ms
 2 * * * 

 
/usr/local/etc(31): netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            192.168.0.3       UGS         0  4034591    re0
10.16.239.0/24     link#10            U           0   110750 re1_vl
10.16.239.2        link#10            UHS         0        0    lo0
10.10.0.0/16       192.168.0.2       UGS         0       24    re0
192.168.0.0/24     link#1             U           0   573269    re0
192.168.0.254      link#1             UHS         0        0    lo0
10.254.239.0/24    link#11            U           0       57 re1_vl
10.254.239.2       link#11            UHS         0        0    lo0
10.255.1.0/29      link#3             U           0        0    re2
10.255.1.1         link#3             UHS         0        0    lo0
127.0.0.1          link#4             UH          0   555289    lo0
192.168.10.0/24    link#8             U           1 19256801 re1_vl
192.168.10.1       link#8             UHS         0        0    lo0
 
FreeBSD 8.3-RELEASE-p16 amd64
I assumed as much.

Why are you using an OS which has met its EOL ("End of Life") over 6 years ago? See also this overview? That's just asking for problems...

(edit)

You also might want to check the forum rules:
(I'm not one to throw rulebooks at people but there's a very good reason why using obsolete versions is highly discouraged).
 
Sorry, I'm new to freebsd and didn't realize the OS was at EOL. This a server which is administer by a 3rd party and I'm just trying to figure why this "simple" route is not working. Maybe it's time for me to go back and read release note of post version and see if this is an issue that was address. But if anybody has any insight, I would appreciate the help but I since it's EOL, I understand if people chose not to help or waste time on my issue.
 
Look "on the wire" as they say, using tcpdump(1). Your routing table looks fine but there's a possibility the 192.168.0.2 is sending ICMP redirects instructing the client to route through 192.168.0.2.
Supply the second route with a network mask /16. The default is /24 and this is why the 10.10.18.118 address does not match.
No, the default gateway has a subnet mask of /0. The directly connected network on re0 is a /24. These two are not the same thing. The /24 on 192.168.0.0/24 defines which network segment is considered 'local' (i.e. doesn't need to be routed), in other words "directly connected".
 
No, the default gateway has a subnet mask of /0.
I believe he means to say that the default subnet mask applied to any static route is 255.255.255.0 when no subnet mask or prefix-length is specified; not the subnet mask of the default route.
 
I believe he means to say that the default subnet mask applied to any static route is 255.255.255.0 when no subnet mask or prefix-length is specified; not the subnet mask of the default route.
That makes more sense, yes. But 10.x.x.x is a class A network and the implicit netmask would be /8. A quick test shows that's what happens with route add -net 10.x.x.x 1.2.3.4.

 
Back
Top