0

Background

I have this configuration:

Internet <--> router <--> laptop

My laptop has openvpn installed. Listening on port 9999. The router has port forwarding from port 9999 to my laptop.

My laptop is getting the IP address 192.168.1.2 from my router. Static IP.

I created a client certificate for testing. Add an external computer and he was able to connect my internal network, using the VPN tunnel.

My external VPN user getting the IP address 10.0.0.2.

The Question

I want to create a situation that the external client will get IP address from the router's network (for example: 192.168.1.3), instead of from the openvpn's network (10.0.0.2). So this user will looks like any other users on my router internal network.

Is this possible?

1 Answer 1

1

Technically possible, but not really recommended – in most cases you should instead just get inter-subnet routing working correctly.

There are two ways, and which one to use depends on why you want the clients to look "like any other user", as having an IP address is just part of what makes a device be within the same subnet – do you need the ability to send/receive broadcasts? do you need the ability to send/receive non-IP packets?

Bridging

In this method, VPN clients "directly" connect to the same Ethernet broadcast domain – they can get an address through DHCP, they can send broadcasts, they can even send non-IP packets. The VPN server acts like a switch.

  1. Switch the OpenVPN service to bridge mode:

    dev tap
    server-bridge
    

    All clients must use dev tap too.

  2. Create the actual bridge at OS level. On Linux this can be done using ip link and bridge commands, although older tutorials which talk about brctl are still valid as well.

    The manual (temporary) setup would look like this:

    ip link add br0 type bridge
    ip link set br0 up
    ip link set tap0 master br0
    ip link set eth0 master br0
    
    ip -4 addr flush dev eth0
    ip -4 addr add 192.168.1.2/24 dev br0
    ip -4 route add default via 192.168.1.1 dev br0
    

    Note that both the VPN 'tap' interface and the physical Ethernet interface are put in the bridge.

    Doing this "permanently" depends on how your existing network is configured – e.g. on Debian you would add the bridge in /etc/network/interfaces, on Ubuntu you would use netplan, etc.

Bridging with OpenVPN is well documented elsewhere:

Proxy ARP

In this method, the VPN clients only get addresses from the same range, but they are still separate at layer-2 (with the VPN server still acting as a router between the two).

The advantage is that this works with Android/iOS clients, which cannot use the Ethernet 'tap' mode due to OS limitations. (The absence of broadcasts saves their battery life, too – a LAN sometimes has a surprising amount of junk packets being sent around.)

  1. Configure the VPN service to have a smaller prefix (e.g. a /27) that's within the LAN range.

    dev tun
    topology subnet
    server 192.168.1.192 255.255.255.224
    

    You should end with something like this on the VPN server, with the address ranges intentionally overlapping:

    eth0 = 192.168.1.2/24
    tun0 = 192.168.1.193/27
    
  2. Either enable the proxy-ARP feature that Linux kernel has built-in, or install the 'parpd' daemon which does the same thing on its own. (Personally I find parpd easier to understand and configure.)

    For example, this will cause Linux to answer all ARP queries that arrive through eth0 and ask for an address that belongs to some other interface:

    sysctl net.ipv4.conf.eth0.proxy_arp=1
    

    parpd, meanwhile, is configured like this:

    interface eth0
        proxy 192.168.1.192/27
    

Now your LAN's other devices think that VPN clients are in the same subnet, based on their address. When they try to make an ARP query, the VPN server will answer on the client's behalf.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .