[auglan]

Do you have a route for it on your router?


ip route 192.168.5.0 255.255.255.0 BVI1

[zx128k]

I have it with a next hop like this:

ip route 192.168.5.0 255.255.255.0 BVI1 <WINDOWS WAN>

[zx128k]

yes, I do have it.

I had it with and without next hop

now it's

ip route 192.168.5.0 255.255.255.0 BVI1

I wonder how 192.168.2.0 subnet hosts can reach 192.168.5.0 hosts, with default gateway in their routing table? like 0.0.0.0 0.0.0.0 192.168.2.1?

[auglan]

0.0.0.0 0.0.0.0 192.168.2.1 is a default route that says for any destination not in the local routing table send it to 192.168.2.1.

On your windows server you could specify a static route:


route add 192.168.5.0 mask 255.255.255.0 192.168.2.1

Routing works both ways, so the issue may not be on the router at all. Easy way to tell is if you see packets to the 192.168.2.0 subnet being encapsulated in the tunnel

sh crypto ipsec sa

If they are then it could be the return traffic (server to router) that is the issue.

[zx128k]

Auglan, it's working even without routing table!

just like in config example by cisco. my router has no routing at all except of default gateway, and it's working.

Now I'm playing with loopback interface on windows. It seems like RRA isn't working as expected.

thank you very much for your help!!

[auglan]

Yeah the default route 0.0.0.0 0.0.0.0 192.168.2.1 should be all that you do need. Like I said that says send anything I don't have a more specific route for in my routing table to 192.168.2.1.

[zx128k]

by the way Auglan, as far as I know, cisco vpn client can do automatic route injection to the routing table of the client right?

[auglan]

The vpn client will only send traffic across the tunnel that is specified in the Proxy ACL on the vpn server (Router/ASA etc) when the policy is pushed down to the client and if split tunneling is enabled. If there is no split tunneling then it will send everything through the tunnel. The vpn server will inject a host route (reverse route injection) into its local routing table going back to the client when the vpn client connects successfully. Normally if you have other subnets behind the vpn server running a dynamic routing protocol then you would redistribute that static route into the IGP they are running so the client has full reachability.

[zx128k]

I see, well, I wanted to give VPN (PPTP) client joining to the 192.168.2.0 subnet reachability to 192.168.5.1. So I manually added static route to the client routing table. Like 192.168.5.0 255.255.255.0 192.168.2.1. Client connected successfully. But I think it should be done automatically. I guess that split tunneling will work only for cisco vpn client, not for microsoft's native vpn client (pptp, l2tp), right? also, dynamic routing protocol will work in router to router environment, I know it sounds strange but what if vpn client initiates connection from WAN interface that is connected directly to the ISP gateway?

[auglan]

Yeah I am not sure about the route injection on the microsoft vpn client as PPTP VPN's are totally different than IPSEC VPN's.

The split tunnel aspect is part of the vpn server configuration and is a policy pushed down the the vpn client. The cisco vpn client gets this policy and then knows what traffic is to be encrypted and which is not.

Dynamic routing will work with any Layer 3 device that supports that particular protocol.