General OpenVPN / subnetting / Samba / FreeBSD 10.3

Hi All,

I’m setting up OpenVPN on FreeBSD 10.3 and ran into a problem which I can’t resolve despite following documentation and reading up on guides etc. Here’s what the setup and what happens:
  • Machine A –, gateway / router, DHCP provides addresses from the - range
  • Machine B (FreeBSD) –, BGE1
  • Machine B (FreeBSD) – 192.168.129/26, TUN0
  • Machine C –, HTTP
1. Clients connect to the external interface on Machine A.
2. Machine A relays the connection to Machine B which houses the OpenVPN server.
3. Machine B assigns an address of say Cool – everything works up until this point. The client can ping other clients within the VPN subnet, can ping the gateway, etc.
4. The client now attempts to access Machine C and fails miserably. Pinging anything within the network fails with the exception of the gateway and interfaces directly attached to Machine B.

The client tries to access the Samba share which is also located on Machine B – fails miserably too.

Now before I explain what I’ve done to date let me say what the rationale for this setup is: I want to be able to provide full, unrestricted access to all local services for remote clients. An ideal solution for me would be to use a bridge/TAP rather than routed/TUN setup – but I’ve got Android VPN clients connecting and TAP is not compatible with Android based on OpenVPN documentation. Given they’re mobile clients, TAP overheads are not ideal either – hence I’m stuck with TUN. Because of that, I also can’t reach the DHCP located on Machine A – this means that I need to assign addresses which could potentially clash with DHCP assigned addresses as DHCP will have no awareness of what’s been assigned to clients by Machine B. This is the reason for the */26 subnet. DHCP on Machine A has been restricted in terms of the pool of addresses it can provide from within the */24 network and Machine B provides them from outside of that range = no overlap.

What I’ve done / tested / configured:

1. Machine A has a static route to the VPN subnet via
2. Machine B is pushing to clients
3. Machine B has the route directive in the OpenVPN.conf.
4. I’ve tried using the iroute directive on clients – no change.
5. Machine B has IP forwarding configured (sysctl) and gateway enabled in rc.conf
6. There are no firewalls on any of these machines.
7. Samba on Machine B is serving both BGE1 and TUN interfaces. Still no access.

Am I missing something really obvious? Any extra comments re effectiveness of the setup would be most welcome.

Configs and variables below.

port 555
proto udp
dev tun
tls-version-min 1.2
remote-cert-eku "TLS Web Client Authentication"
cipher AES-256-CBC
auth SHA256
remote-cert-tls client
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/test.crt
key /usr/local/etc/openvpn/keys/test.key
dh /usr/local/etc/openvpn/keys/test.pem
tls-auth /usr/local/etc/openvpn/keys/test.key 0
topology subnet
ifconfig-pool-persist ipp.txt
push "route"
push "redirect-gateway autolocal"
push "dhcp-option DNS"
push "dhcp-option DNS"
keepalive 10 120
max-clients 10
status openvpn-status.log
verb 3
sndbuf 0
rcvbuf 0
mssfix 1300
Client config / x.ovpn:
dev tun
remote test 555
resolv-retry infinite
verb 3
remote-cert-tls server
tls-version-min 1.2
remote-cert-eku "TLS Web Server Authentication"
cipher AES-256-CBC
auth SHA256
key-direction 1
# sysctl net.inet.ip.forwarding
net.inet.ip.forwarding: 1
# ifconfig
        ether 1c:98:ec:0f:4d:75
        inet netmask 0xffffff00 broadcast
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        inet6 fe80::1e98:ecff:fe0f:4d74%tun0 prefixlen 64 scopeid 0x4
        inet --> netmask 0xffffffc0
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        Opened by PID 46362

Best regards,
Well, I've not read all your config very carefully but I see that your OpenVPN subnet is in the same network as (B) FreeBSD server's LAN interface (bge1). I know similar setups might work in linux or windows (those systems even allow a default gateway with IP outside the network), but this is strictly against the rules and does not work with FreeBSD.
In your case I'd add a completely different network for OpenVPN (ex. and arrange the corresponding routing in (A).
The VPNs are usually set up on the machine with direct access to the Internet, but I think this is not the problem in your case.
You're right in saying this is an odd addressing setup. I figured that since I've limited DHCP to issue addresses 'below' the OpenVPN network, it won't really matter from an address conflict perspective. Routing is required between those subnets of course but that should've been taken care of by OpenVPN and static routes on the gateway. I'll try changing the addresing scheme in a few days and will report back here whether it solved the problem.
As I mentioned above the main problem is that the OpenVPN subnet ( is PART OF the LAN subnet (inet netmask 0xffffff00). Routing decision is calculated by the IP and network mask. Machine A has direct LAN connection to /IP range from to and it will NOT forward anything inside this subnet to other machine. is an IP address from the same network. Any subnets routed or accessed by FreeBSD server (or just any router) should NOT overlap.
Changed the VPN subnet to / 24 and it does seem to work - you were right. Regarding what you wrote - I disagree, in theory it should have worked. The OpenVPN subnet was a part of the same class C network but I had a static route on the router, hence packets were being forwarded. Likewise on the server I stated which networks had to be routed. DHCP wasn't issuing IPs from the entire subnet so the OpenVPN part of the subnet would never be in conflict with another host. I had connectivity from the outside but for some reason internal routing wasn't working. In any case your solution still worked so even if in theory my setup should work it cleary doesn't so a best practice point for me going forward. :):beer:
I'm glad that you have a working solution now.
But note: you can use IPs from the same subnet only in bridge mode. The sub-subnet is not different than the main subnet for the router and should not be.