General OpenVPN / subnetting / Samba / FreeBSD 10.3

Janusz

Janusz

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 – 192.168.1.1/24, gateway / router, DHCP provides addresses from the 192.168.1.5 - 192.168.1.64 range
  • Machine B (FreeBSD) – 192.168.1.2/24, BGE1
  • Machine B (FreeBSD) – 192.168.129/26, TUN0
  • Machine C – 192.168.1.5/24, 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 192.168.1.130/26. 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 192.168.1.0/24 network fails with the exception of the gateway and interfaces directly attached to Machine B.

5. 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 192.168.1.2/24
2. Machine B is pushing 192.168.1.0 255.255.255.0 to clients
3. Machine B has the route 192.168.1.0 255.255.255.0 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.

OpenVPN.conf:
Code: 
port 555
proto udp
dev tun
persist-tun
tls-version-min 1.2
tls-server
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
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
server 192.168.1.128 255.255.255.192
ifconfig-pool-persist ipp.txt
push "route 192.168.1.0 255.255.255.0"
push "redirect-gateway autolocal"
push "dhcp-option DNS 192.168.1.1"
push "dhcp-option DNS 192.168.1.2"
duplicate-cn
keepalive 10 120
max-clients 10
persist-key
status openvpn-status.log
verb 3
sndbuf 0
rcvbuf 0
mssfix 1300
Client config / x.ovpn:
Code: 
dev tun
persist-tun
auth-nocache
<connection>
remote test 555
</connection>
resolv-retry infinite
mute-replay-warnings
verb 3
client
remote-cert-tls server
tls-version-min 1.2
tls-client
remote-cert-eku "TLS Web Server Authentication"
cipher AES-256-CBC
auth SHA256
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
<ca>
...
</ca>
<cert>
...
</cert>
<key>
...
</key>
key-direction 1
<tls-auth>
...
</tls-auth>
# sysctl net.inet.ip.forwarding
Code: 
net.inet.ip.forwarding: 1
# ifconfig
Code: 
bge1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=c019b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE>
        ether 1c:98:ec:0f:4d:75
        inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        inet6 fe80::1e98:ecff:fe0f:4d74%tun0 prefixlen 64 scopeid 0x4
        inet 192.168.1.129 --> 192.168.1.130 netmask 0xffffffc0
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        Opened by PID 46362

Best regards,
Janusz
 
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. 192.168.2.0/24) 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 (192.168.1.128 255.255.255.192) is PART OF the LAN subnet (inet 192.168.1.2 netmask 0xffffff00). Routing decision is calculated by the IP and network mask. Machine A has direct LAN connection to 192.168.1.0/24 /IP range from 192.168.1.1 to 192.168.1.254/ and it will NOT forward anything inside this subnet to other machine. 192.168.1.129 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 192.168.10.0 / 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.
 
You must log in or register to reply here.
Back
Top