Showing results for 
Search instead for 
Did you mean: 

Welcome to the Cisco Small Business Community

Have a question? Click on a topic board below to get started in the community.


Very bad trip in cisco land via RV340


i needed to change routers for about 20 custumers.

a classical, 2 wans, a routing table, and pptp server...

Pre-sales cisco : OK no problem the rv340 is the best for u...

i bought a rv340. After testing pptp, does not work or works with a mask of . very nice when your lan is /24 ...

goto post-sale support. i write all the setup of the rv340, one ingeneer, two ingeneer turning round about the problem since 4 days ( i'm not alone in this case ).


i believed cisco was the best and the ingeneers knows what a routing mask is...


I've tried Chineses routers and it's working perfectly.


Bye Bye Cisco ! 

VIP Expert

Not sure i was able to translate your comment, is this works only with mask ? not work ?


if only work with then it may be bug :


i am sure many of them works with RV series with /24 subnet.


here is guide and test :




***** Rate All Helpful Responses *****

How to Ask The Community for Help


If u want to make a simple try.

Rv340 lan -> /24

Pptp server -

Firewall disable, no routing table, nothing else.

On the pptp client (lan 192.168.10.x/24 ), I do not use the gateway for
remote network

I connect the client.

cmd-> ipconfig pptp

cmd-> route print

-> mask

this route is automaticly added when I connect the pptp client.

What's about when the client has for reason of intranet some addresses in
10.40.X.X or 10.50.X.X ?

They are routed to the pptp connection instead of the local network
192.168.10..x /24

If ure answer is to tell me to set the pptp server at
the client can not see the lan of the rv340.

I must add a route on the client route add -> that
is no acceptable !

That's my problem.

I 'll give u five stars if you tell me how to do with that router !!!!!!!




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 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 on your vlan1/lan interface of RV340, then you cannot configure your ip-pool as in the pptp-server config.

- Instead you have to configure the ip-pool as say for example

- or you could configure as 

- or you could configure as or

becos you are using on lan interface, the ip-pools:,, 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:








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,


Note: in case you want to know, the above ip-pool is allowed becos, the vlan1 ipaddr-subnet is (, whereas the pptp-ip-pool subnet would be 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
>>> mask
>>>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: Bcast: Mask:
inet6 addr: fe80::250:56ff:feb6:3a15/64 Scope:Link
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: Bcast: Mask:
inet6 addr: fe80::250:56ff:feb6:4d0/64 Scope:Link
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: Bcast: Mask:
inet6 addr: fe80::250:56ff:feb6:463b/64 Scope:Link
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: Mask:
inet6 addr: ::1/128 Scope:Host
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: P-t-P: Mask:
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 dev eth1 dev ppp0 proto kernel scope link src dev eth1 proto kernel scope link src dev eth1 scope link metric 1000 dev eth2 proto kernel scope link src dev eth0 proto kernel scope link src


- 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 mask

route add mask

route add mask 


- the above will ensure that ONLY traffic to RV340-lan network 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 (the internal router)


hope this above info helps