Hi JPP
Iam not at all from Cisco or working for Cisco, but before you start berating the entire cisco organization and its products, you should first calm down and think logically by tracing out the network flow and try to understand what's happening....so see whether the below points help you in solving your issues with RV340
If i understand from your description, your deployment is as below (i maybe wrong i guess...but i think what i mentioned below is almost correct...correct me with more complete info)
First and foremost important point to note:
- On RV34X routers (and generally its a standard practice in almost all standard & correct deployment of VPN-servers - these vpn servers could be pptp-server, l2tp-server, ipsec-vpn servers, openvpn-servers), the IP-Pool that you define/configure in a VPN-server (in this case the pptp-server) cannot be in the same subnet as any of the ipaddress configured on the router's lan-interface. The ip-pool/ip-range MUST be in a different subnet
a) for eg: if you have configured 10.0.0.1/16 on your vlan1/lan interface of RV340, then you cannot configure your ip-pool as 10.0.9.1-10.0.9.10 in the pptp-server config.
- Instead you have to configure the ip-pool as say for example 10.1.0.1-10.1.0.10
- or you could configure as 10.1.9.1-10.1.9.10
- or you could configure as 10.2.0.1-10.2.0.10 or 10.2.9.1-10.2.9.10
becos you are using 10.0.0.0/16 on lan interface, the ip-pools: 10.1.0.0/16, 10.2.0.0/16, etc are all valid subnets/range that you can use in pptp-server or other vpn-servers
b) The reason why the ip-pool/ip-ranges used in vpn-servers are different from the subnet that is configured on the lan-interfaces of the routers is to avoid the need to configure/enable "Proxy-ARP" which is quite dangerous to enable or use in any proper network
c) So if the "Chinese routers" allow the use of ip-pool in same subnet as your lan-interface ipaddress, then its becos they dont give a **bleep** or 2-hoots about the proper working of your networks...if tomorrow suddenly you face issues of your lan-network not working due to the proxy-arp enabled/configured on your "chinese routers" you are squarely to blame...and the chinese couldnt care less about standard behavior and standard configs of networking
Now coming back to your issue: your network deployment must be like below:
(lannetwork-10.0.0.0/24)---10.0.0.1/24(vlan1)[RV340]wan----wan[windows-pptp-client]192.168.10.1/24-----192.168.10.2[intranet-router]10.40.1.1/24-----[host-10.40.1.2]
and/or
(lannetwork-10.0.0.0/24)---10.0.0.1/24(vlan1)[RV340]wan----wan[windows-pptp-client]192.168.10.1/24-----192.168.10.2[intranet-router]10.50.1.1/24-----[host-10.50.1.2]
You have also mentioned that on the pptp-client which must be a Windows-host, you have NOT enabled "use default-gw of remote-network)
OK, so now consider your configuration of the IP-Pool in PPTP-server on RV340, 10.0.9.1-10.0.9.10
Note: in case you want to know, the above ip-pool is allowed becos, the vlan1 ipaddr-subnet is 10.0.0.0/24 (10.0.0.1), whereas the pptp-ip-pool subnet would be 10.0.9.0/24..both are different in the /24 range, so its allowed
Now you mentioned that after the pptp-connection is UP on the windows-pptp client the following route is added automatically
>>>route print
>>>10.0.0.0 mask 255.0.0.0 10.0.9.1
>>>this route is automaticly added when I connect the pptp client.
- and you are concerned as to how will you send traffic to 10.40.x.x/10.50.x.x networks which are connected via the 192.168.10.x interface of your pptp-client host
Well, in this case you should know very clearly that this automatic route that gets added on your pptp-client is NOT added by RV340 or neither is this config sent by RV340 during the pptp-tunnel negotiation...its the windows problem...and Microsoft should be blamed if any
I dont have a windows-host with me at this immediate point of time, but i tried the same config as yours on my RV340 using a Linux-pptp-client, and this is what i see below after the pptp-tunnel is UP
root@host1:/etc/ppp/peers# ifconfig
eth0 Link encap:Ethernet HWaddr 00:50:56:b6:3a:15
inet addr:192.168.173.2 Bcast:192.168.73.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:feb6:3a15/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:120 (120.0 B) TX bytes:1058 (1.0 KB)
eth1 Link encap:Ethernet HWaddr 00:50:56:b6:04:d0
inet addr:100.232.191.14 Bcast:100.232.191.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:feb6:4d0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1300 Metric:1
RX packets:21164695 errors:0 dropped:5710 overruns:0 frame:0
TX packets:2721504 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:9959015358 (9.9 GB) TX bytes:1632565158 (1.6 GB)
eth2 Link encap:Ethernet HWaddr 00:50:56:b6:46:3b
inet addr:172.29.1.73 Bcast:172.29.1.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:feb6:463b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:509996 errors:0 dropped:1738 overruns:0 frame:0
TX packets:380224 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:261244212 (261.2 MB) TX bytes:30089066 (30.0 MB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:859069 errors:0 dropped:0 overruns:0 frame:0
TX packets:859069 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:395910539 (395.9 MB) TX bytes:395910539 (395.9 MB)
ppp0 Link encap:Point-to-Point Protocol
inet addr:10.0.9.2 P-t-P:10.0.9.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1496 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:60 (60.0 B) TX bytes:66 (66.0 B)
root@host1:/etc/ppp/peers# ip route
default via 100.232.191.1 dev eth1
10.0.9.1 dev ppp0 proto kernel scope link src 10.0.9.2
100.232.191.0/24 dev eth1 proto kernel scope link src 100.232.191.14
169.254.0.0/16 dev eth1 scope link metric 1000
172.29.1.0/24 dev eth2 proto kernel scope link src 172.29.1.73
192.168.173.0/24 dev eth0 proto kernel scope link src 192.168.173.2
root@host1:/etc/ppp/peers#
- You can see that there is ONLY a single host-route added in the routing table once the pptp-tunnel is UP
So on your windows-pptp-client, if the automatic route is getting added as shown above due to windows , then you have to do below steps everytime the tunnel is established on the windows-client-host:
step-1: delete the automatic route that is added
step-2: add below route manually
route add 10.0.0.0 mask 255.255.255.0 10.0.9.1
route add 10.40.1.0 mask 255.255.255.0 192.168.10.2
route add 10.50.1.0 mask 255.255.255.0 192.168.10.2
- the above will ensure that ONLY traffic to RV340-lan network 10.0.0.0/24 is routed via the pptp-tunnel connection
- and the other 2 routes ensure that traffic to 10.40.x.x/10.50,x,x are routed properly to 192.168.10.2 (the internal router)
hope this above info helps
cheers
