PfSense openVPN not assigning default gateway to clients



  • I recently configured an openVPN server on pfSense to connect to my internal network using tunnelblick. The connection is established, and the server assigns a correct ip address to the client, but there is no change in the default gateway of the client, so everything else on the local network is unreachable. Please let me know if any more information than what is in the config files below is necessary to discover the issue.

    openVPN config file:

    dev ovpns1
    verb 3
    dev-type tap
    dev-node /dev/tap1
    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 tcp-server
    cipher AES-128-CBC
    auth SHA1
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local 128.151.18.205
    tls-server
    server-bridge 192.168.42.36 255.255.224.0 192.168.40.10 192.168.40.49
    client-config-dir /var/etc/openvpn-csc
    tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'Server' 1 "
    lport 443
    management /var/etc/openvpn/server1.sock unix
    push "route 192.168.0.0 255.255.0.0"
    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.1024
    tls-auth /var/etc/openvpn/server1.tls-auth 0

    client config file:

    client
    dev tap
    proto tcp
    remote 128.151.18.205 443
    resolv-retry infinite
    nobind
    persist-key
    persist-tun
    ca ca.crt
    cert Mac.crt
    key Mac.key
    ns-cert-type server
    tls-auth ta.key 1
    cipher AES-128-CBC
    auth SHA1
    redirect-gateway def1



  • why TAP?
    https://community.openvpn.net/openvpn/wiki/BridgingAndRouting

    also, do you bridge your dhcp of your lan?



  • @heper:

    why TAP?
    https://community.openvpn.net/openvpn/wiki/BridgingAndRouting

    also, do you bridge your dhcp of your lan?

    I am using TAP because my network configuration would allow traffic to the rest of the network from connected clients, but there would be no way for the traffic to route back because of security configurations.

    I have a bridge set up on my network between the openVPN interface, and the LAN interface on the pfSense server.


  • Rebel Alliance Global Moderator

    "I have a bridge set up on my network between the openVPN interface, and the LAN interface on the pfSense server."

    Gawd what a cluster!!!

    You sure do not need tap to allow openvpn clients to connect to your lan network..  And what security concerns?  You give your openvpn clients a connection on your openvpn network say 10.0.8.0/24 This is common openvpn network, or 10.0.200/24 then setup your firewall rules how you want to allow/block traffic between these clients and your network behind pfsense.

    Routing back to them would be automatic if your normal lan clients are using pfsense as your gateway.  What security concerns would their be??  And how is putting them on your lan network directly not more of security issue?  If you put them on their own segment then you now easy to understand and maintain firewall (psense) between these segments that you can create what ever rules you want in.



  • I am using TAP because my network configuration would allow traffic to the rest of the network from connected clients, but there would be no way for the traffic to route back because of security configurations.

    To be honest… this statement doesn't make any sense.  Please re-phrase the issue you're trying to resolve by choosing a bridged solution over a routed one.  The ONLY reason to use TAP is to connect to an application that relies on broadcast traffic.  Routed is more efficient, routed scales better, etc, etc.

    I have a bridge set up on my network between the openVPN interface, and the LAN interface on the pfSense server.

    Do yourself a favor… remove the bridge and switch to routed.  You will save yourself dozens of hours beating your head against the wall on this.


  • Banned

    3 most common sources of pfSense troubles:

    • Squid and related proxy junk
    • bridging
    • PEBKAC

    ::) ::) ::)


  • Galactic Empire Netgate

    @doktornotor:

    3 most common sources of pfSense troubles:

    • Squid and related proxy junk
    • bridging
    • PEBKAC

    ::) ::) ::)

    /thread