Second Gateway

[Amiel Tutolo]

I am not a networky type person and from everything I have read I am doing this "correctly". Here is my question: I have a L3000 with an IP of 125.0.0.61. My subnet mask is 255.255.255.0 and the default gateway/firewall is 125.0.0.60. The .60 address is where all internet traffic including VPN tunnels currently goes out this addreess. The Network people have added a new gateway/firewall that has an ip of 125.0.0.57. The want all VPN traffic to come through this address. I have tried the following command to get this to work: route add net 192.168.100.0 netmask 255.255.255.0 125.0.0.57 1. This doesn't seem to be working. All I want is traffic from the .57 to be routed back through it. We have other clients on the new firewall/gateway and we cannot talk between there unix system and ours. Any help or if I can clarify anymore would be greatly appreciated. Thanks in advance.

[Christopher Caldwell · Accepted solution]

Generally, routes are destination based.

Your route says any traffic destined _for_ 192.168.100.0/24 should travel through the gate 125.0.0.57. The route doesn't say anything about what should happen to traffic sourced from the 192.168.100/24 network or the 125.0.0.57 host.

Traffic bound for 125.0.0.61 that comes through 125.0.0.57 should do the right thing (both hosts are on the same subnet and most devices build a directly connected network route when configured with an IP on a give subnet).

If you're trying to use 125.0.0.61 to forward traffic, you'll need to do some configuration on the 125.0.0.57 host.

[Ron Kinner]

Looks like it should work. Is it accepting the command? Does
netstat -rn
show the new route?

What does a traceroute to a host on the 192.168.100 show?

You realize, of course that the first reboot will wipe your new route out. You need to add it to your /etc/rc.config.d/netconf
file so it will stay after a reboot.

ROUTE_DESTINATION[2]="192.168.100.0"
ROUTE_MASK[2]="255.255.255.0"
ROUTE_GATEWAY[2]="125.0.0.57"
ROUTE_COUNT[2]="1"
ROUTE_ARGS[2]=""

Integer in the brackets should be the next one free.

With your IP address you might run into problems with 11.0's enforcement of an obsolete RFC but you should have already noticed that.


ndd -set /dev/ip ip_check_subnet_add 0

and edit /etc/rc,config.d/nddconf to add:

TRANSPORT_NAME[0]=ip
NDD_NAME[0]= ip_check_subnet_add
NDD_VALUE[0]=0

Again the integer in the brackets should be the next one free.

Do not rely on netstat -rnv to show you the usage info correctly. It's broken on mine.



If you are running RIP or OSPF (via named) then you will have to talk to the router owners to get that straightened out.



The only traffic that will be routed via the .57 is traffic to the 192.168.100. (Unless the .60 does an icmp redirect. Which come to think of it might be the easiest way to get it to work assuming your systems take redirects. Just have the .60 router add a route to the 192.168.100 via the .57)

Ron

[rick jones]

Indeed, route lookups by default only consider the destination IP address. If one wants the source IP address included in the route lookups, setting the ndd variable ip_strong_es_model to a value of 1 will do that.

It will also have the effect that traffic destined for IP address A on the host will only be accepted on the NIC to which IP address A is assigned and no other NIC on the system.

Is VPN traffic sourced from IPs different from non-VPN traffic?

Sooo, if the VPN traffic destined for your host is sent to an IP address other than 125.0.0.61 you can likely use ip_strong_es_model to get replies from that other address to go through the other gateway. Otherwise, you need to find some way for the router at 125.0.0.60 to send ICMP redirects whenever your host sends VPN traffic through it.