[SOLVED] Another lame OpenVPN client <-> LAN no access thread



  • Hello,

    I'm setting up a VPN network between a pfSense and some Windows OpenVPN clients.
    The VPN client connects, pings the LAN IP but can't access LAN devices.
    LAN devices can ping the virtual IP of the OpenVPN client though.
    I have searched like every option that came into my mind, I cannot solve this.

    Could someone have a look and tell me if I am becomming stupid ?

    Network schematics

    
    [Windows computer]---------[pfSense1, bridged WAN]----(internet)----[pfSense2, bridged WAN]----------[LAN2 COMPUTERS]
    
    with:
    
    Windows computer IP: 10.210.100.55
    Windows computer virtual tun IP: 10.13.37.1
    pfSense1 LAN IP: 10.210.100.254
    pfSense1 LAN Subnet: 10.210.100.0/24
    pfSense2 LAN2 IP: 172.16.1.1
    pfSense2 LAN2 Subnet: 172.16.0.0/24
    LAN2 computers have pfSense2 as their gateway
    
    

    pfSense1 just happens to be there and is not involved with the VPN link.

    on pfSense2: /var/etc/openvpn/server1.conf content:

    
    dev ovpns1
    verb 1
    dev-type tun
    tun-ipv6
    dev-node /dev/tun1
    writepid /var/run/openvpn_server1.pid
    #user nobody
    #group nobody
    script-security 3
    daemon
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    proto udp
    cipher AES-256-CBC
    auth SHA1
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    client-connect /usr/local/sbin/openvpn.attributes.sh
    client-disconnect /usr/local/sbin/openvpn.attributes.sh
    local 192.168.1.253
    tls-server
    server 10.13.37.0 255.255.255.0
    client-config-dir /var/etc/openvpn-csc/server1
    client-cert-not-required
    username-as-common-name
    auth-user-pass-verify "/usr/local/sbin/ovpn_auth_verify user 'Local Database' false server1" via-env
    tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'remote.somelan.local' 1"
    lport 48885
    management /var/etc/openvpn/server1.sock unix
    max-clients 2
    push "route 172.16.0.0 255.255.0.0"
    push "dhcp-option DOMAIN somelan.local"
    push "dhcp-option DNS 172.16.1.1"
    push "register-dns"
    push "dhcp-option NTP 172.16.1.1"
    push "redirect-gateway def1"
    ca /var/etc/openvpn/server1.ca 
    cert /var/etc/openvpn/server1.cert 
    key /var/etc/openvpn/server1.key 
    dh /etc/dh-parameters.2048
    tls-auth /var/etc/openvpn/server1.tls-auth 0
    comp-lzo adaptive
    persist-remote-ip
    float
    topology subnet
    
    

    Windows OpenVPN client config file:

    
    dev tun
    persist-tun
    persist-key
    cipher AES-256-CBC
    auth SHA1
    tls-client
    client
    resolv-retry infinite
    remote pfsense2.wan.ip 48885 udp
    lport 0
    auth-user-pass
    ca etablissement-wifi-udp-48885-ca.crt
    tls-auth etablissement-wifi-udp-48885-tls.key 1
    ns-cert-type server
    comp-lzo adaptive
    
    

    Windows routing table once connected (using route print)

    
    IPv4 Table de routage
    ===========================================================================
    Itinéraires actifs :
    Destination réseau    Masque réseau  Adr. passerelle   Adr. interface Métrique
              0.0.0.0          0.0.0.0   10.210.100.254    10.210.100.55     10
              0.0.0.0        128.0.0.0       10.13.37.1       10.13.37.2     20
           10.13.37.0    255.255.255.0         On-link        10.13.37.2    276
           10.13.37.2  255.255.255.255         On-link        10.13.37.2    276
         10.13.37.255  255.255.255.255         On-link        10.13.37.2    276
         10.210.100.0    255.255.255.0         On-link     10.210.100.55    266
        10.210.100.55  255.255.255.255         On-link     10.210.100.55    266
       10.210.100.255  255.255.255.255         On-link     10.210.100.55    266
            127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
            127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
      127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
            128.0.0.0        128.0.0.0       10.13.37.1       10.13.37.2     20
           172.16.0.0      255.255.0.0       10.13.37.1       10.13.37.2     20
     [pfSense2WANIP]  255.255.255.255   10.210.100.254    10.210.100.55     10
            224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
            224.0.0.0        240.0.0.0         On-link     10.210.100.55    266
            224.0.0.0        240.0.0.0         On-link        10.13.37.2    276
      255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      255.255.255.255  255.255.255.255         On-link     10.210.100.55    266
      255.255.255.255  255.255.255.255         On-link        10.13.37.2    276
    
    

    Of course, I do launch OpenVPN gui with admin privileges.

    OpenVPN interface firewall rule

    
    IPv4   *    *    *    *   *   none
    
    

    LAN interface firewall rule (where LB1 is a gateway group of which WAN1 is primary tier.)

    
    IPv4    LAN net    *    *    *    LB1   qACK/qOthersHigh
    
    

    And yes, I already tried changing LB1 to WAN1.
    I created the OpenVPN configs manually without the wizard. Anything I forgot like a static route back to the 10.13.37.0/24 network or an outgoing NAT rule ?

    Any errors please ?


  • Rebel Alliance Global Moderator

    And what about the firewall running on the clients your trying to access?  Out of the box windows for example blocks access from devices that are not on its same local network.  Your vpn clients would not be on the same local network as your boxes..

    This is like 1st thing to look into when you can not access stuff..



  • Yep, I had AV / windows firewall disabled for my tests, didn't mention it because I kinda lost my mind on this today.

    I've noticed some VERY strange behavior when using tracert under windows (sorry for the french console output):

    
    C:\Windows\system32>tracert 172.16.1.1
    
    Détermination de l'itinéraire vers somelan.local [172.16.1.1]
    avec un maximum de 30 sauts :
    
      1    74 ms    76 ms    70 ms  somelan.local [172.16.1.1]
    
    Itinéraire déterminé.
    
    C:\Windows\system32>tracert 172.16.1.9
    
    Détermination de l'itinéraire vers 172.16.1.9 avec un maximum de 30 sauts.
    
      1    83 ms    89 ms    70 ms  192.168.1.1
      2   125 ms     *      142 ms  reverse-dns-of-my-pfsense2-wan [XX.XX.XX.XX]
      3     *        *        *     Délai d'attente de la demande dépassé.
      4     *        *        *     Délai d'attente de la demande dépassé.
      5     *        *     ^C
    C:\Windows\system32>
    
    

    I don't have any 192.168.1.0/24 net anywhere.
    Double checked with ipconfig and route print on the windows machine.
    Routing magic ?


  • Rebel Alliance Global Moderator

    1    83 ms    89 ms    70 ms  192.168.1.1

    Clearly you do! ;)



  • That looks suspiciously like a WAN gateway IP you'd get when your behind another DSL router.
    Are you sure your DSL is actually "bridged"?
    What's the first two octets of your WAN IP?


  • Rebel Alliance Global Moderator

    Why would you ever see pfsense wan IP in this trace either..  That would never show up with rfc1918 address as hop before that..  And if had a tunnel going, for sure never ever see your wan IP in the trace.



  • Indeed, yesterday I've tried to connect to another of my pfSense boxes that is behind a router with 192.168.1.0/24 network and forgot to switch back.

    So far so good, tracert seems better when connecting to the pfSense I described above (which is bridged to a WAN modem).

    
    C:\Windows\system32>tracert 172.16.1.1
    
    Détermination de l'itinéraire vers partdieu-wifi.dghotels.local [172.16.1.1]
    avec un maximum de 30 sauts :
    
      1    85 ms    71 ms    66 ms  partdieu-wifi.dghotels.local [172.16.1.1]
    
    Itinéraire déterminé.
    
    C:\Windows\system32>tracert 172.16.1.3
    
    Détermination de l'itinéraire vers 172.16.1.3 avec un maximum de 30 sauts.
    
      1    47 ms    48 ms    48 ms  10.13.37.1
      2     *        *        *     Délai d'attente de la demande dépassé.
      3     *        *        *     Délai d'attente de la demande dépassé.
      4     *        *        *     Délai d'attente de la demande dépassé.
      5     *        *        *     Délai d'attente de la demande dépassé.
      6     *        *        *     Délai d'attente de la demande dépassé.
      7     *     ^C
    
    

    Routing table still seems to have the right 172.16.0.0/16 network

    
    IPv4 Table de routage
    ===========================================================================
    Itinéraires actifs :
    Destination réseau    Masque réseau  Adr. passerelle   Adr. interface Métrique
              0.0.0.0          0.0.0.0   10.210.100.254    10.210.100.47     10
              0.0.0.0        128.0.0.0       10.13.37.1       10.13.37.2     20
           10.13.37.0    255.255.255.0         On-link        10.13.37.2    276
           10.13.37.2  255.255.255.255         On-link        10.13.37.2    276
         10.13.37.255  255.255.255.255         On-link        10.13.37.2    276
         10.210.100.0    255.255.255.0         On-link     10.210.100.47    266
        10.210.100.47  255.255.255.255         On-link     10.210.100.47    266
       10.210.100.255  255.255.255.255         On-link     10.210.100.47    266
        [public ip pfSense2]  255.255.255.255   10.210.100.254    10.210.100.47     10
            127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
            127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
      127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
            128.0.0.0        128.0.0.0       10.13.37.1       10.13.37.2     20
           172.16.0.0      255.255.0.0       10.13.37.1       10.13.37.2     20
            224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
            224.0.0.0        240.0.0.0         On-link     10.210.100.47    266
            224.0.0.0        240.0.0.0         On-link        10.13.37.2    276
      255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      255.255.255.255  255.255.255.255         On-link     10.210.100.47    266
      255.255.255.255  255.255.255.255         On-link        10.13.37.2    276
    ===========================================================================
    
    

    I've enabled "Log packets that are handled by this rule" on the OpenVPN interface in pfSense, and the packets seem to reach the LAN.

    
    (Pass) Jun 22 14:25:00	ovpns1	  10.13.37.2	  172.16.1.3	ICMP
    
    

    So it seems that my windows client can reach the LAN, but doesn't get a reponse.


  • Rebel Alliance Global Moderator

    yeah you need to check the lan box your trying to ping and see where its sending the response if it is, is it possible your windows machine has a different gateway then the pfsense box your vpn tunnel is coming in on.

    Easy enough to sniff on the lan box to see if its actually seeing the ping and what it does about it.



  • Okay, well… sometimes a good sleeping night should be considered before posting.

    Most of the devices I need to remotely access aren't computers but switches and WAPs.
    Some of the switches (which I had the luck to pick) don't have gateways setup.
    And on top of this, the remote computer I was playing with has been shutdown while I was using it as "working reference" !!! (going crazy).
    So actually everything worked perfectly with my initial setup, just no luck with the devices I was pinging.

    In the end, as my setup is supposed to be more a tech VPN to remotely access network equipment, I ended up trading the tun for a tap setup, so I get a nice bridge and can access devices that don't have gateways setup.

    Thanks for the help.



  • The proper solution is to use outbound NAT (on the interface where the said devices are connected to) to access devices that don't have a gateway option.



  • Is there an advantage of using a outgoing NAT vs TAP bridge ?


  • Rebel Alliance Global Moderator

    why sort of crap device does not have option for a gateway?? They must be the cheapest of the cheapest devices designed for home use only..  Any device work 2 cents that has the option for ip management would have option for gateway..



  • Well, in my use case (not road warrior but remote access to switches etc), it's just brilliant to get broadcast etc.


  • Rebel Alliance Global Moderator

    huh??  Accessing switches and broadcast have to do with each other how??



  • Being in the same local lan is a lot easier for my tasks, which don't require any road warrior worker setup  8)