Adding route/rules to allow access to VPN client



  • Hello,

    I have a number of embedded devices running the OpenVPN client and a small piece of software.  These clients also serve up a webpage with status information.  I have a VK-T40E that has been configured to run the OpenVPN server.

    I have everything setup successfully, and the clients are calling hope and authenticating.

    I would like to get to the web page that is on each device from the local LAN that the VK-T40E is on.

    I am using the VK-T40E as my router, and have set my gateway to it's LAN ip.  My LAN is 192.168.80.0/24 and my OpenVPN network is 192.168.45.0/24.

    I would like to be able to get to the 192.168.45.0 network from the 192.168.80.0 network.  Could someone perhaps shed some light as to how I should go about this?  Here is my entry for the LAN:

    http://i.imgur.com/DJSWpHh.png

    And for OpenVPN:

    http://i.imgur.com/pu7TZcu.png

    I'm at a bit of a loss here, so any assistance on where to start looking would be great.

    Thanks!



  • If the clients are connected the web pages should be accessible with the given rules. Aren't they?
    What's the particular problem?

    It would be a good idea to give predefined IPs to the clients, so you can reach each client with a definite IP.



  • I'm curious why you blocked out the source on your LAN rule.  Assuming your LAN rule has "LAN net" as the source it's redundant.  The default "LAN net"/any rule should allow access to your tunnel network.

    e.g. my tunnel network is 10.0.90.0/24 and when I connect to the VPN from work, I can access all LAN resources… conversely, when I go home I can also access my work PC in the 10.0.90.0/24 network from my LAN.

    You've stated what you want, but unless I missed it, you haven't stated whether what you want is working or not.  Have you even tried it?

    Check the dashboard for the Virtual IP's from your connected clients, they should have an IP in the 192.168.45.0/24 range and you should be able to ping them and connect to any open port.

    All this is assuming the server is configured properly, the routing is in place and there is no firewall on the remote devices blocking connections.

    If you cannot ping your devices, post a network map and post your openvpn config (server1.conf).



  • Here is my server config:

    
    dev ovpns1
    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-128-CBC
    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 216.136.37.237
    tls-server
    server 192.168.45.0 255.255.255.0
    client-config-dir /var/etc/openvpn-csc
    username-as-common-name
    auth-user-pass-verify /var/etc/openvpn/server1.php via-env
    tls-verify /var/etc/openvpn/server1.tls-verify.php
    lport 1194
    management /var/etc/openvpn/server1.sock unix
    max-clients 100
    push "route 192.168.80.0 255.255.255.0"
    push "dhcp-option DOMAIN <redacted>.vpn"
    client-to-client
    duplicate-cn
    ca /var/etc/openvpn/server1.ca
    cert /var/etc/openvpn/server1.cert
    key /var/etc/openvpn/server1.key
    dh /etc/dh-parameters.1024
    tls-auth /var/etc/openvpn/server1.tls-auth 0
    comp-lzo
    topology subnet</redacted> 
    

    Here is my client config:

    
    dev tun
    persist-tun
    persist-key
    cipher AES-128-CBC
    auth SHA1
    tls-client
    client
    resolv-retry infinite
    remote <redacted><redacted>udp
    lport 0
    verify-x509-name "<redacted>" name
    auth-user-pass <redacted>.pass
    pkcs12 <redacted>.p12
    tls-auth <redacted>.key 1
    ns-cert-type server
    comp-lzo
    keepalive 10 30</redacted></redacted></redacted></redacted></redacted></redacted> 
    

    Clients call in fine, and i can ping them from the Diagnostics: Execute command page.  I can even get the http response using telnet when ssh'd into the pfsense box.  What I can not do is ping the clients from my LAN network.

    WAN: a.b.c.d
    LAN: 192.168.80.0/24
    OpenVPN: 192.168.45.0/24

    I would like to get to the 45.x clients from the 80.x network.  I believe this is a route issue, and not an OpenVPN issue.  Any additional insight is greatly appreciated.

    Thanks,

    -TD



  • The rules at LAN interface have to allow access from LAN host to the VPN client. Since you don't show us the hole rule set, we cannot gauge.

    The next point is the route. If the pfSenses LAN IP is set as default gateway on the LAN machines the VPN clients should be reachable, otherwise you have to set the route.
    If you are unsure show us the routing table of the LAN machine an tell us the pfSenses LAN IP.



  • Thank you very much for sticking with me here.

    I have WAN, DEMO and OPENVPNINTERFACE for my three interfaces.

    DEMO has an IP of 192.168.30.254, with DHCP for 192.168.30.10->192.168.30.250

    I have set the rules for DEMO to the following:

    http://i.imgur.com/y5oaZZh.png

    I have set the rules for OPENVPNINTERFACE to the following:

    http://i.imgur.com/iNtDUNs.png

    The rules for OpenVPN:

    http://i.imgur.com/qchppnD.png

    I have turned on logging on, and can see that my laptop, 192.168.30.26, is being allowed to 192.168.45.2 (vpn client).

    http://i.imgur.com/1sd3unp.png

    I have confirmed that the service (ssh in this case) is running on the client.  I am not thinking that this may be a openvpn client configuration issue?? That maybe it isn't allowing connections via the tun0 adapter?

    Thanks,

    -TD



  • What's the OPENVPNINTERFACE? Have you assigned an interface to the OpenVPN server? That's not necessary for your needs.
    You will need that for routing issues only.



  • It appears that this was an issue with the clients being on the same network as the DEMO lan (the clients have more than one network adapter).  After I moved them to a different network, everything worked as expected.

    Thanks for assisting.  This is resolved.


Log in to reply