2

I'd like to know the nitty gritty details of how VPN Remote Clients are given Private IP Addresses on a Remote Network when they connect to the StrongSWAN or OpenVPN VPN Server that's embedded in VyOS Routers, as well as how Virtual IP Address Pools fit in the process.

In the past, I just assumed that VPN Servers built into Routers established a virtual tunnel exit point as a point of entry for remote clients to connect to a remote network, and pointed the remote clients to DHCP Servers that existed on the Remote LAN, but then I started noticing that Several VPN Solutions mention something called Virtual IP Address Pools ("VIPAPs"), which made me question if there's more going on then I'd previously thought.

  • What exactly are "VIPAPs" why do they exist? What purpose do they serve?
  • Are "VIPAPs" separate from DHCP? (which also has a pool of reserved addresses)
  • Are "VIPAPs" dynamically generated based on the DHCP pool range?
  • If "VIPAPs" have statically set ranges, should they perfectly overlap DHCP range or should they be part of a reserved space outside of DHCP pool range?

Here's my Current Understanding:

I believe that in the past you used to have WAN -> Basic Firewall/Router and establish port forwarding of ports associated with VPN connections to a VPN server on the LAN. Such as a OpenVPN Server or StrongSWAN VPN Server. Now adays a mini OpenVPN Server exists on pfSense Firewalls, and a mini StrongSWAN VPN Server exists on VyOS Routers (and if you put these on the edge you don't need to forward ports.)

strongswan.org mentions something about a Virtual IP address pool. Let's pretend we have a 1 ethernet port computer acting as a StrongSWAN VPN Server. My understanding is that by default port forwarding (or DMZ) sort of remaps the WAN IP to the Laptop's private IP so it's accessible from the internet when behind a Firewall/NAT'd Router. And by default, the Server's Ethernet Port has a Private IP address 10.0.0.100, and a Virtual Network Adapter tunnel interface with an IP address in a 3rd subnet that's only used for routing through the virtual tunnel. Then whenever a remote client connects to the VPN Server, the VPN Server attaches a Virtual IP Address to it's Ethernet Port, which represents the client.

How it gets that Virtual IP Address for the client is the part that's confusing me.

Normally when I attach a new computer to my network, it gets an IP from DHCP's DORA process which occurs at layer 2. It gets DNS and subnet info from the O stage of DORA process. A VPN client would be coming into the network at layer 3, and not have a layer 2 presense on the remote network, and thus couldn't use DHCP which operates at layer 2.

Maybe when a client connects to a VPN Server, the VPN server makes a virtual network interface on the VPN Server to give the client a Layer 2 presence on the remote network, and the VPN Server initiates DHCP DORA process by proxy on behalf of the remote client, and then the DHCP server on the remote network assigns an IP address with DNS info to a virtual network interface that exists on the VPN Server and this virtual network interface represents the remote client? (Not saying it works like that, just saying I'm trying to visualize how it might work.)

But if it's that simple then why does something called Virtual IP Address Pool exist? Or am I getting my concepts mixed up and VIPAPs have nothing to do with remote DHCP resolution?

Improve this question
8
  • This url makes me think my understanding was right that it was that simple, and that "VIPAPs" are an alternative to DHCP. help.stonesoft.com/onlinehelp/StoneGate/SMC/5.4.5/SGAG/… T
    – neoakris
    Jan 8, 2018 at 1:25
  • This was one of the original URLs that confused me, the author mentions they have an OpenVPN Server running on a host configured with private DHCP pool 172.16.10.0/24 and OpenVPN pool of 172.16.11.0/24 networkengineering.stackexchange.com/questions/881/…
    – neoakris
    Jan 8, 2018 at 1:34
  • Unfortunately, questions about home networking, consumer-grade devices, and host/server configurations are all off-topic here. You could try to ask this question on Super User.
    – Ron Maupin ♦
    Jan 8, 2018 at 1:56
  • I'd argue that is protocol theory, making it on-topic
    – Ron Trunk
    Jan 8, 2018 at 2:09
  • 2
    DHCP is not a layer-3 protocol, and it is nominally off-topic here. "it uses ARP layer 2 broadcast to find a DHCP server who then hands out a Layer 3 IP address and DNS info." That is incorrect. IPv4 DHCP requests are broadcast, which is how they find a server, but there are DHCP relays. ARP and DHCP have nothing to do with each other, although both use broadcast for IPv4. IPv6 doesn't have broadcast, and it uses a standard multicast address for DHCP server discovery, nor does it have ARP.
    – Ron Maupin ♦
    Jan 8, 2018 at 9:31

2 Answers 2

Reset to default
4

DHCP requires a link layer which doesn't really exist for VPN clients. Usually, a routed VPN connection is used and the VIPAP pool is used instead of the non-existent DHCP pool.

With a bridged VPN connection, the VPN client uses an address in the same subnet as the VPN server. However, the bridge is not fully functional and DHCP doesn't work - the server uses proxy ARP to route the frames into the tunnel.

For a clean setup, DHCP and VIPAP shouldn't overlap. I suppose that already used IP addresses aren't re-used but I wouldn't depend on that. Additionally, you should always use routed VPN with a dedicated subnet unless bridging is absolutely necessary.

For the client, there is no difference between DHCP and VIPAP. At least the Windows OpenVPN TAP interface used to claim it's got a DHCP address.

Improve this answer
6
  • Ok so there are 2 types of VPN connections: Bridged VPN and Routed VPN. With Routed VPN the client enters at layer 3 (and thus has no layer 2 presence on the remote network), and thus need Proxy ARP and can't participate in DHCP's DORA Process as it operates at layer 2. So VIPAPs had to come into existence as an alternative to DHCP for this scenario. (DNS info is usually given to the client during the O stage of DORA DHCP process, do you manually set DNS server when creating a VIPAP pool? or is there another way the remote client gets DNS info about the remote network?)
    – neoakris
    Jan 9, 2018 at 4:45
  • The second from the bottom paragraph of my understanding in my question clarifies a way for a remote client to gain a Layer 2 presence on the remote network, any idea about if my theory to how Bridge VPNs work is accurate? If it is it'd mean that VIPAPs aren't needed for Bridged VPNs/they'd only apply to Routed VPNs. I'm guessing VIPAP and DHCP aren't designed to directly talk with each other so separate subnets as a best practice makes since.
    – neoakris
    Jan 9, 2018 at 4:47
  • Can you elaborate on what you mean by "However, the bridge is not fully functional and DHCP doesn't work" specifically the part about the bridge is not fully functional? (Are you just referring to the lack of ability to pass certain protocols through as if you were on the local network? Like how basic IPSEC tunnels can't forward multicast, VTI IPSEC tunnels can forward multicast but not legacy protocols like IPX/Apple Talk, but GRE tunnel inside IPSEC tunnel is a fully functional bridge in that it can forward all traffic including legacy protocols as if you were physically connected.)
    – neoakris
    Jan 9, 2018 at 4:52
  • OpenVPN in bridge mode does not implement a fully functional bridge. For instance, MAC addresses are not learned from the VPN link, the router just knows them. You can't put the VPN client in bridge mode (through additional software) and expect the two bridges to work. OpenVPN always works more like a router, its bridge mode only emulates a real bridge. VIPAP can be interpreted as part of that emulation.
    – Zac67 ♦
    Jan 9, 2018 at 12:09
  • Do you have a source for that claim? In my experiance using openvpn in bridge mode in conjuction with linux bridging to join two ethernet networks together works just fine.
    – Peter Green
    Jun 15, 2018 at 19:53
1

How are VPN Clients given IP addresses when they connect to VPN Routers such as VyOS? (How do Virtual IP Address Pools fit in?)

The answer is that it depends entirely on the VPN Technology being used:

  • Site-to-Site - GRE/IPSec/DMVPN/VTI Based VPN Technology:
    You can have a Local and Remote Router each with 2 physical Routed Ports.
    -(One Physical Port goes to the Internet Modem)
    -(One Physical Port points to the Core LAN Switch)
    -A virtualTunnel Interface is created on each router (one that supports multicast/routing protocols) VTI Diagram
    DHCP client 192.168.1.100 on Local LAN keeps their same IP, doesn't need any special software, configuration, or Virtual IP Address Pools, they just ping 192.168.2.100 on the Remote LAN. And their Local Router has a route to the remote LAN in it's routing table, so it forwards the traffic over the tunnel. (It does this in a way that bypasses NAT and the firewall effect of NAT.)
    (It works as if the Router's 2 WAN ports were connected by a single Ethernet Cable.)
    Pro: No configure needed by clients.
    Con: PC on Local LAN can only ping PC on remote LAN when they're connected to the Local Router, if they connect to a different network like the hotspot on their phone, they won't be able to ping the remote LAN. (because their phone's gateway doesn't have a route to that remote LAN.)



  • Remote-Access VPN OpenVPN/SSL/TLS Based VPN Technology:
    Client PC would install VPN client software which would install a virtual network adapter, which would be configured to form a connection with the remote OpenVPN Router. This virtual network adapter wouldn't get an IP address from the local DHCP server and it wouldn't get an IP address from the remote DHCP server either, instead, it'd get a Virtual IP Address(VIP) from a pool reserved for VPN clients, and this pool would need to be configured to give DNS information as well (as normally you'd get DNS info from the DHCP server).
    So what ends up happening is that the client PC has:
    -A physical interface with an IP address on their local LAN with their local DNS.
    -A Virtual interface with a VIP address that exists on the remote LAN that's configured with whatever DNS the remote pool was configured with.
    -The ability to ping local servers and remote servers by local private ip, remote private ip, local DNS resolution, and remote DNS resolution.
    Pro: This would work regardless of what network the client was connected to.
    Con: Need to install software and have a configuration on the client.
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.