(2.1) Overseeing something? "road warrior" with AD auth, no routes

msi

It's been a rather long time when I last configured OpenVPN on pfSense during a project on a previous workplace, maybe I'm just not remembering what I did the last time, I hope someon can point towards where I have to look for. :-\

After several try and errors I'm not getting to the point where I can get access to the remote network behind the pfSense (2.1 if that's of importance)
The potential client is using a Windows 64-bit machine, I tried both 32- and 64-bit 2.2 and 2.3-rc2 clients, the logs looked same.

The purpose is to get a VPN connection from a (second) uplink/WAN connection that allows me to access my switch management VLAN behind pfSense so I
don't have to hack my way to the switches via SSH-hopping across the firewall or doing some local port-forwarding to the Web-GUI of the switches.
(some of them don't like local port forwarding via pfSense that's why I though of OpenVPN)

My auth backend is an Active Directory, I'd like to not add extra user certs for auth (although I'd agree that this would be safer)
I already use the AD backend sueccessfully from the LAN side for admin access
My remote network management network is 10.0.0.0/24, my tunnel would be 10.20.0.0/24
I left the default pass all rule on the 'OpenVPN' interface, port 1194 is opened on this WAN uplink

Currently it pushes the remote network route to the client (says Windows' route PRINT), the gateway is registered 10
I then get 10.20.0.6 via 10.20.0.5 and I can ping 10.20.0.1, not 10.20.0.5 (normal?), but no device is ping-able in the remote network?
The routes added on the Windows side point to 10.20.0.5 as gateway to 10.0.0.0 - correct or already wrong?

Here is my client log if that helps.


Wed Dec 19 18:02:38 2012 OpenVPN 2.3_rc2 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Dec 17 2012
Wed Dec 19 18:02:43 2012 WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
Wed Dec 19 18:02:43 2012 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Wed Dec 19 18:02:43 2012 Control Channel Authentication: using 'wifigate-ng-udp-1194-tls.key' as a OpenVPN static key file
Wed Dec 19 18:02:43 2012 UDPv4 link local (bound): [undef]
Wed Dec 19 18:02:43 2012 UDPv4 link remote: [AF_INET]86.118.139.251:1194
Wed Dec 19 18:02:43 2012 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Dec 19 18:02:43 2012 WARNING: 'tun-ipv6' is present in remote config but missing in local config, remote='tun-ipv6'
Wed Dec 19 18:02:43 2012 [wifigate.gymnasium.koeniz] Peer Connection Initiated with [AF_INET]86.118.139.251:1194
Wed Dec 19 18:02:45 2012 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed Dec 19 18:02:45 2012 open_tun, tt->ipv6=0
Wed Dec 19 18:02:45 2012 TAP-WIN32 device [LAN-Verbindung 2] opened: \\.\Global\{060F1329-6461-4820-BB65-FE6655DC5B14}.tap
Wed Dec 19 18:02:45 2012 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.20.0.6/255.255.255.252 on interface {060F1329-6461-4820-BB65-FE6655DC5B14} [DHCP-serv: 10.20.0.5, lease-time: 31536000]
Wed Dec 19 18:02:45 2012 Successful ARP Flush on interface [19] {060F1329-6461-4820-BB65-FE6655DC5B14}
Wed Dec 19 18:02:50 2012 Initialization Sequence Completed

cmb

route sounds correct. I suspect from your description the VPN doesn't work for the same reason the port forwards won't work, the devices you're trying to access don't have a default gateway set appropriately. Alternatively they may have an ACL that only allows access from the local subnet.

jimp

That does sound like the kind of things we see where switches or related gear refuse to talk outside their own subnet.

I was on a conference call with a customer last week with them and their switch vendor and even though they had everything set correctly (gateway, subnet mask, etc) and the switch vendor said there were no such filters, it still refused to allow access to the switch GUI from outside its own subnet.

Add a little manual outbound NAT on that interface to make the traffic going to those devices appear to originate from its own subnet and it works fine.