IP Routing Conflict: PC IP remains in original network

[jsrpp]

I set up a PPTP VPN server using Asus RT-N12+ (stock firmware) in location A, and use Asus AC68U (stock firmware) in location B to connect to the RT-N12+ VPN.

The VPN works as expected when connected directly say via a mobile phone or desktop. But when connected via the AC68U VPN Client, it shows "IP Routing Conflict" and the IP remains in the original network of location B:

System log on the Client (Ac68u):

May 2 23:23:59 pptp[16560]: pppd 2.4.7 started by admin, uid 0
May 2 23:24:00 pptp[16560]: Connect: ppp5 <--> pptp (218.xxx.xxx.xxx)
May 2 23:24:00 pptp[16560]: CHAP authentication succeeded
May 2 23:24:01 pptp[16560]: local IP address 192.168.10.2
May 2 23:24:01 pptp[16560]: remote IP address 192.168.1.1
May 2 23:24:01 pptp[16560]: primary DNS address 192.168.1.1
May 2 23:24:01 pptp[16560]: secondary DNS address 192.168.1.1
May 2 23:24:01 rc_service: service 16569:notify_rc start_vpnclient1
May 2 23:25:01 rc_service: service 16603:notify_rc start_vpnclient1

System log on the Server side (RT-N12+):

May 2 23:24:31 pptp[18773]: pppd 2.4.7 started by admin, uid 0
May 2 23:24:31 pptp[18773]: Connect: ppp10 <--> pptp (27.xxx.xxx.xx)
May 2 23:24:32 pptp[18773]: Cannot determine ethernet address for proxy ARP
May 2 23:24:32 pptp[18773]: local IP address 192.168.1.1
May 2 23:24:32 pptp[18773]: remote IP address 192.168.10.2

I wonder what's the cause of such IP conflict? Why the asus router were not able to assign internal IP orderly and properly? Are there too many devices connected in the client side's network?

 

[ColinTaylor]

What is the LAN IP address range on each of the routers? Are they both 192.168.1.0/24? If so that won't work, they need to be different.

 

[jsrpp]

What is the LAN IP address range on each of the routers? Are they both 192.168.1.0/24? If so that won't work, they need to be different.

So instead of segmenting my LAN IP pool, can I just use 192.168.0.1/24 for the Server router?

 

[ColinTaylor]

So instead of segmenting my LAN IP pool, can I just use 192.168.0.1/24 for the Server router?

I think so (it's been a long time since I've used PPTP ).

 

[eibgrad]

So instead of segmenting my LAN IP pool, can I just use 192.168.0.1/24 for the Server router?

You don't *have* to use the same IP network for your PPTP clients as the local IP network, but it's most commonly done that way because it offers several advantages. But to understand those advantages, we have to describe how PPTP actual works.

The reason you can use the same IP network for the PPTP client as the remote network is because each PPTP client is configured w/ its own network interface (ppp0, ppp1, etc.), and as a single-host network (e.g., 192.168.1.100/32). Some ppl mistakenly believe this is a bridged configuration because the networks are the same. But that's NOT the case. When the PPTP client gets connected, a new network interface is created based on the name ppp# (e.g., ppp10).

So each PPTP client is routed from its respective network interface to the local network interface (bro). And the router makes that possible by configuring an arp-proxy for that IP host within its own arp table. IOW, the router configures itself so that all arp request to the PPTP client are routed initially to itself, then forwarded to the PPTP client's network interface (ppp10, using my example).

The primary benefit here is that PPTP gives the *illusion* of being bridged without actually being bridged. So say you use your laptop both at home and remotely. Anyone who communicates w/ your laptop on a regular basis while at home, can *still* communicate w/ your remote laptop (provided you also configure the site-to-site routing) once it gets connected, and without any changes. IOW, the rest of the local IP network doesn't need to know if your laptop is local or remote and thereby use different IP references (or hostnames for that matter, if you're using DNSMasq for those purposes). It provides a certain level of seamlessness that using a different IP network for the PPTP clients doesn't. This is particularly advantageous when it comes to Android and other mobile devices that don't otherwise support actual bridged tunnels!

That's also why the PPTP server usually offers Broadcast Relay Mode, which can proxy network discovery between the PPTP client and the rest of the network, thereby furthering the *illusion* of being bridged to the remote network.

In the early days of the internet, this is one the things that made PPTP so popular. But eventually it fell out of favor due to security issues. And then other options came along like OpenVPN, but worked a bit differently (which I explain below).

One gotcha though. None of this is going to work if by chance your IP range on the PPTP server overlaps w/ the range of your DHCP server. DNSMasq's DHCP server will NOT respect any IPs assigned by other processes that happen to fall within its DHCP range! Same is true for manually/statically configured TCP/IP clients. And should that happen, then it's just a race between the two devices as to which client responds first (more likely the local device).

In short, never allow the DHCP server's range and PPTP client range to overlap. You're asking for problems.

Just to complete the picture, OpenVPN took a completely different approach for routed (tun) tunnels and configured all OpenVPN clients to use the *same* network interface (e.g., tun21), and gave that network its own unique IP network. And if you want a bridged configuration, you need to create a *real* bridge using a bridged (tap) tunnel.

So yeah, you can use a different IP network, but just realize you lose something in the process. Whether that's significant to you is obviously up to you to decide.