Ipcp Pro 250

0 views

Skip to first unread message

Kassim Sin

unread,

Aug 3, 2024, 11:51:24 AM8/3/24

to prosunkamu

After I've fixed the default routing in my home office, I've stumbled across another problem: the two ISPs I'm using for my primary and backup link have DNS servers that reply solely to the DNS requests sent from their own IP address range:

When the traffic is switched from the primary to the backup ISP, I therefore also need to switch the DNS servers. Fortunately, this is quite easy to do on a router; you just need to configure ppp ipcp dns request on the dialer interface and the router starts asking for the DNS server address as part of the IPCP negotiation.

The negotiation process can be debugged with the debug ppp negotiation command; it's a bit more complex than usual in my case since the access server has no secondary DNS (only the primary DNS is configured):

The access server receiving the call requires no special configuration; the first IP address configured with the ip name-server command is used as the primary DNS and the second one as the secondary. Alternatively, you can configure a different set of DNS servers to pass to the client with the ppp ipcp dns primary-DNS-address secondary-DNS-address interface configuration command.

Unfortunately, the integration with LAN clients is not as seamless as with DHCP; to make the whole solution work, you have to configure the router as a forwarding DNS server and make the LAN clients use the router as the default gateway and DNS server with the DHCP pool configuration:

After ppp's upgrade to version 2.5.0, I'm not able to establish VPN tunnels anymore.
Adding ipcp-accept-remote to /etc/ppp/options, tunnels are established, but remote networks are still unreachable.
Downgrading ppp to version 2.4.9 and removing the ipcp-accept-remote option allows openfortivpn to work again, but networkmanager-fortisslvpn depends on ppp 2.5.0 and has been recently moved to AUR.

As I wrote in my post, I already tried it.
The VPN tunnel goes up and the routing table is properly populated, but there is no communications with remote networks/hosts.
After downgrading ppp to version 2.4.9, openfortivpn's client works as expected, but networkmanager-fortisslvpn fails to build without ppp 2.5.0.

Anyone has any updates on this issue? I had the same problem when it happened.. I circumvented it by keeping the old ppp package version installed and ignored it for futured updates.
In the meantime I had to unfortunately completely reinstall my machine and how I'm kinda hoping this issue got sorted in the meantime

If you ever used IPCP for address allocation with PPP ("ip address negotiated" on client side and "peer default ip address" on server side) you may have noticed that the mask assigned to a client is always /32. It does not matter what mask a server uses on it's side of the connection, just PPP is designed to operate this way.

However, many have noticed two strange commands "ppp ipcp mask request" and "ppp ipcp mask X.X.X.X" under PPP interface configuration mode. If IPCP assigned address never uses a custom mask, what would the purpose of those commands be? The answer is simple - to configure on-demand address pools in a client. That is, a client may request a DHCP pool parameters from server using IPCP - for example request a subnet and a mask. The client may then further use this information and allocate IP addresses to it's subordinates. Here is a configuration to verify this feature. Consider that R1 connects to R3 over a point-to-point link:

However, the funniest part is that R1 serial interface IP address is actually not allocated from the local (on-demand) DHCP pool! Observing the debug output you can see that R1 uses the IP address sent from R3, not allocated from the local DHCP pool. Then again, the local pool DHCP still has the requested subnet:

This is what so funny about Cisco IOS - you can never be sure the feature works in a most logical way you may suppose it to work. You can play with this example further, for example changing IP address allocation on R3 to local DHCP Pools or a static IP - there is always something you can experiment with!