Routing Issue

[nootgevallen]

We Have a netasq f200 with intern adress of 192.0.0.254
and it can't route a application that needs to go to 172.16.10.2 through a vpn adress to 192.168.1.4 on the other location.

The server has a adress of 192.0.0.5 windows 2003.
Can't use route add 173.16.10.2 192.168.1.4
on windows 2003

route add 172.16.10.2 192.0.0.5
The route addition failed: Either the interface index is wrong or the gateway does not lie on the same network as the interface. Check the IP Address Table for
the machine.

Is there another way to route this to the other side without using my netasq because he knows where 192.168.1.4 is ?

thanx

 

[pansophic]

Can you describe your configuration a little better?

Is it something like this?

Internal 192.168.0.254 192.168.1.4
| |
Windows NetASQ NetASQ Windows
2003 --------- F200 ------------- F200 --------- XP
Server VPN VPN Client
| |
External 172.16.10.2 172.16.10.x

Also, is your VPN already established and moving other traffic?

If it looks like this, you would just route add 192.168.1.0 netmask 255.255.255.0 gw 192.168.0.254 (I'm doing the route command off the top of my head, syntax may be incorrect).


pansophic

 

[nootgevallen]

The other company we connect uses a public adress as internal range....... 192.0.0.0 Stupid but that is no problem with other traffic .

Application needs to go to adress
172.16.10.2
\|/
192.0.0.254 netasq f200 (Router) City 1
\|/
City 1 Vpn<----------->Vpn City 2
|
192.168.1.252
Symantec 360
|
192.168.1.4 (Route to 172.16.10.2)
|
route to Extern Application


All other trafic between subnet 192.0.0.0 and 192.168.1.0 Works perfect but 172.16.10.2 is a other subnet that does'nt go through the vpn. And there is no option on the netasq to route this subnet through the vpn.

 

[pansophic]

I think that I see your issue. Try "route add 172.16.10.2 192.168.1.252 (assuming that your netmask for 192.168.1.0 is 255.255.255.0). I believe that should work for you.


pansophic

 

[pansophic]

Oh, and of course, don't forget to use the /p switch once you get it working or you will lose the route after a reboot.


pansophic

 

[nootgevallen]

192.168.1.252 doesn't work because it is not on the same network.

Route add 172.16.10.2 192.168.1.252

The route addition failed: Either the interface index is wrong or the gateway does not lie on the same network as the interface. Check the IP Address Table for
the machine.

 

[pansophic]

What is the IP address of the machine that you are trying to run the route command on? I thought that it was 192.168.1.4. What is the network mask for that machine as well?

Can you do an "ipconfig /all" on that machine?


pansophic

 

[nootgevallen]

This is the machine that starts the application to ->(172.16.10.2)

Hostnaam . . . . . . . . . . . . : tserver2
Primair DNS-achtervoegsel. . . . .: test.local
Knooppunttype: . . . . . . . . . .: onbekend
IP-routering ingeschakeld. . . . .: ja
WINS-proxy ingeschakeld . . . . . : nee
DNS-achtervoegselzoeklijst. . . . : test.local

ernet-adapter Local Area Connection:

Verbindingsspec. DNS-achtervoegsel:
Beschrijving . . . . . . . . . . .: NetServer 10/100TX PCI LAN Adapter
Fysiek adres. . . . . . . . . . . : 00-10-83-FD-05-D0
DHCP ingeschakeld:. . . . . . . . : nee
IP-adres. . . . . . . . . . . . . : 192.0.0.4
Subnetmasker. . . . . . . . . . . : 255.255.255.0
Standaard-gateway . . . . . . . . : 192.0.0.250
DNS-servers . . . . . . . . . . . : 192.0.0.5

 

[pansophic]

OK, you are defining the route to the wrong place. You need to define a route on your machine as:

route add 172.16.10.2 192.0.0.254 /p

From your drawing, I thought that 192.168.1.4, since you showed the destination IP at the other end. This will point your machine to the local gateway that knows about the tunnel (the tunnel endpoint). This assumes that 192.0.0.254 actually knows where to send 172.16.10.2. If it doesn't, then it will forward the packet to its default gateway (the route that looks like 0.0.0.0 0.0.0.0 which matches any host on any network.

Unless you are doing dynamic routing across your tunnel (RIP, EGRP, BGP, etc) there must be a static route defined.

Once you have those two routes defined, then you should see your packets come out the other end of the tunnel, but they may not be able to find their way back from 172.16.10.2 unless the reciprocal route is defined.


pansophic