I have an OpenVPN client on a Windows 7, that connects to an OpenVPN server with tap.
The tunnel establishes correctly.
AFAIK, tap means that my virtual adapter is 'virtually' connected to the remote LAN, gets a remote LAN ip and participate in the LAN broadcast domani and so on.
When the tunnel is established, my virtual adapter gets the correct IP.
But I cannot ping the other hosts in the remote network.
It might be a problem on the sererver side, but before checking there i've noticed something strange on the client side, in the way Windows handles the virtual interface.
Let's begin.
When the tunnel is up, the virtual interface is up too. In my routing table i can see my phisical network 192.168.2.0, infact my local IP is 192.168.2.134.
Then I can see the remote network 172.16.1.0, directly attached to my interface 172.16.1.40. So far so good.
(i've removed loopback entries)

          0.0.0.0          0.0.0.0      192.168.2.1    192.168.2.134     25
       172.16.1.0    255.255.255.0         On-link       172.16.1.40    276
      172.16.1.40  255.255.255.255         On-link       172.16.1.40    276
     172.16.1.255  255.255.255.255         On-link       172.16.1.40    276
      192.168.2.0    255.255.255.0         On-link     192.168.2.134    281
    192.168.2.134  255.255.255.255         On-link     192.168.2.134    281
    192.168.2.255  255.255.255.255         On-link     192.168.2.134    281
        224.0.0.0        240.0.0.0         On-link       172.16.1.40    276
        224.0.0.0        240.0.0.0         On-link     192.168.2.134    281
  255.255.255.255  255.255.255.255         On-link       172.16.1.40    276
  255.255.255.255  255.255.255.255         On-link     192.168.2.134    281

Thus, clients on the remote network shouldn't be reached via gateway, but through direct routing via the virtual interface provided by openvpn.
But
when i trace the route to an host on the remote network (that my PC should see as local) my client routes it on the gateway, and obviously, get lost.

C:\Users\agostinox>tracert 172.16.1.17
  1     1 ms     1 ms     1 ms  192.168.2.1
  2    14 ms    96 ms   101 ms  192.168.1.1
  3     *        *        *     Richiesta scaduta.
  4    24 ms    12 ms    12 ms  172.17.129.137
  5     *        *        *     Richiesta scaduta.

And here it seems that the system routes packages straight to the gateway as it didn't see the directly attached network adapter.
Why does this happen?

Edit 1 – details on my OpenVPN client config

C:\Users\agostinox>openvpn --version
OpenVPN 2.3.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Mar 19 2015
library versions: OpenSSL 1.0.1m 19 Mar 2015, LZO 2.08

And my client config:

remote xxx.xxx.xxx.xxx
cipher AES-128-CBC
port 1194
proto tcp-client
dev tap
ifconfig 172.16.1.40 255.255.255.0
dev-node "Connessione alla rete locale (LAN) 3"
secret a_file_containing_my_preshared_key.key
ping 10
comp-lzo
verb 4
mute 10

Edit 2, details on my server configuration

Here is the "backup" of my (pfsense) server configuration.
As you can see the configuration is at the minimum possible.

<openvpn>
  <openvpn-server>
  <vpnid>2</vpnid> 
  <mode>p2p_shared_key</mode> 
  <protocol>TCP</protocol> 
  <dev_mode>tap</dev_mode> 
  <ipaddr /> 
  <interface>wan</interface> 
  <local_port>1194</local_port> 
  <description><![CDATA[ test tap OpenVPN server]]> 
  </description>
  <custom_options /> 
  <shared_key>... my shared key, omitted ...</shared_key> 
  <crypto>AES-128-CBC</crypto> 
  <engine>none</engine> 
  <tunnel_network /> 
  <tunnel_networkv6 /> 
  <remote_network /> 
  <remote_networkv6 /> 
  <gwredir /> 
  <local_network /> 
  <local_networkv6 /> 
  <maxclients /> 
  <compression>yes</compression> 
  <passtos /> 
  <client2client /> 
  <dynamic_ip /> 
  <pool_enable>yes</pool_enable> 
  <topology_subnet /> 
  <serverbridge_dhcp /> 
  <serverbridge_interface /> 
  <serverbridge_dhcp_start /> 
  <serverbridge_dhcp_end /> 
  <netbios_enable /> 
  <netbios_ntype>0</netbios_ntype> 
  <netbios_scope /> 
  </openvpn-server>
</openvpn>

Edit 3, output of ipconfig /all

When the tunnel is up, this is the output of

ipconfig /all

Scheda Ethernet TAP-Interface:

   Suffisso DNS specifico per connessione:
   Descrizione . . . . . . . . . . . . . : TAP-Windows Adapter V9
   Indirizzo fisico. . . . . . . . . . . : 00-FF-7B-FB-32-C0
   DHCP abilitato. . . . . . . . . . . . : Sì
   Configurazione automatica abilitata   : Sì
   Indirizzo IPv6 locale rispetto al collegamento . : fe80::3838:3c0c:c3c6:fcca%35(Preferenziale)
   Indirizzo IPv4. . . . . . . . . . . . : 172.16.1.40(Preferenziale)
   Subnet mask . . . . . . . . . . . . . : 255.255.255.0
   Lease ottenuto. . . . . . . . . . . . : giovedì 16 aprile 2015 09:57:32
   Scadenza lease . . . . . . . . . . .  : venerdì 15 aprile 2016 09:57:32
   Gateway predefinito . . . . . . . . . : fe80::20c:29ff:fe92:2272%35
   Server DHCP . . . . . . . . . . . . . : 172.16.1.0
   IAID DHCPv6 . . . . . . . . . . . : 1107361659
   DUID Client DHCPv6. . . . . . . . : 00-01-00-01-14-AE-89-EA-F0-4D-A2-63-11-97
   Server DNS . . . . . . . . . . . . .  : fec0:0:0:ffff::1%1
                                           fec0:0:0:ffff::2%1
                                           fec0:0:0:ffff::3%1
   NetBIOS su TCP/IP . . . . . . . . . . : Attivato