PfSense - OpenVPN - [Resolved] Routing issue between Lan clients and openvpn.



  • Hi gents, I have a strange issue with my current setup.

    I have Pfsense configured as a VPN client connecting to an external VPS where other VPS also connect. This creates a "private" cloud where I can host a bunch of different services.

    Here is what I can figure out :

    1. The tunnel is up and any client in the 10.9.0.0/24 range can ping my Pfsense server on the OpenVPN interface (10.9.0.5).
    2. My pfsense server can ping any device in the 10.9.0.0/24 range.
    3. Any client in the 192.168.25.0/24 range are unable to access any device in the 10.9.0.0 range.
    4. Any client in the 192.168.25.0/24 range can ping the OpenVPN interface on the PFsense server 10.9.0.5 range.

    I've tried creating a static route from 10.9.0.0/24 GW 10.9.0.1 but that didn't seem to change anything.

    Here is the setup :

    firewall Rules :



  • Post the configs from both sides.

    We'll know more once you post the configs, but assuming both sides have an "any/any" firewall rule, it sounds like a routing issue.



  • Hi Marvosa,

    Here is as much info as I can provide! I appreciate any help on the matter.

    Running tcpdump on the tunnel interface on the VPS, I see zero traffic if I ping from a LAN host from my pfsense network. If I also run tcpdump on the openvpn interface on Pfsense, I see the ping echo request but no reply.

    Server Config

    #Management interface - For monitoring

    management 127.0.0.1 5556
    ;local a.b.c.d
    port 1195
    ;proto tcp
    proto udp

    topology subnet
    ;dev tap
    dev tun1
    ;dev-node MyTap

    ca hidden
    cert hidden
    key hidden  # This file should be kept secret

    dh hidden

    server 10.9.0.0 255.255.255.0
    ifconfig-pool-persist ipp-vps-tunnel.txt
    ;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100
    ;server-bridge

    push "route 10.8.0.0 255.255.255.0"
    ;push "route 192.168.20.0 255.255.255.0"

    ;client-config-dir ccd
    ;route 192.168.40.128 255.255.255.248

    ;client-config-dir ccd
    ;route 10.9.0.0 255.255.255.252

    ;learn-address ./script

    ;push "redirect-gateway def1 bypass-dhcp"

    #Static address for clients
    client-config-dir /etc/openvpn/static_clients/
    ;push "dhcp-option DNS 8.8.8.8"
    ;push "dhcp-option DNS 8.8.4.4"

    client-to-client

    ;duplicate-cn

    keepalive 10 120

    ;tls-auth ta.key 0 # This file is secret

    ;cipher BF-CBC        # Blowfish (default)
    ;cipher AES-128-CBC  # AES
    ;cipher DES-EDE3-CBC  # Triple-DES

    comp-lzo

    ;max-clients 100

    user nobody
    group nobody

    persist-key
    persist-tun

    status status-openvpn-vps-tunnel.log

    ;log        openvpn.log
    log-append  /etc/openvpn/logs/openvpn-vps-tunnel.log

    verb 3

    Silence repeating messages.  At most 20

    sequential messages of the same message

    category will be output to the log.

    ;mute 20

    Client config

    dev ovpnc1
    dev-type tun
    tun-ipv6
    dev-node /dev/tun1
    writepid /var/run/openvpn_client1.pid
    #user nobody
    #group nobody
    script-security 3
    daemon
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    proto udp
    cipher BF-CBC
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local hidden
    tls-client
    client
    lport 0
    management /var/etc/openvpn/client1.sock unix
    remote hidden.com 1195
    ifconfig 10.9.0.2 10.9.0.1
    route 10.9.0.0 255.255.255.0
    ca hidden
    cert hidden
    key hidden
    resolv-retry infinite
    comp-lzo


  • LAYER 8 Netgate

    Server config:

    push "route 10.8.0.0 255.255.255.0"
    ;push "route 192.168.20.0 255.255.255.0"

    I think you need to look at the local networks in the server config.  Something needs to:

    push "route 192.168.25.0 255.255.255.0"



  • If routing isn't a requirement, could I NAT from my local network (192.168.25.0) to the 10.9.0.x network using the ovpnc1 interface? I could use something like source=192.168.25.0/24  and destination=10.9.0.0/24 and NAT to ovpnc1 ?

    I mean, you are correct, the server itself has no knowledge of the 192.168.25.0 subnet(and doesn't really need to). That said, I never see any traffic leaving my pfsense network(I do see the packet on the ovpnc1 interface) and hitting the tun1 interface. It seems to vanish before leaving the pfsense server itself. If routing was the only issue, wouldn't I see packets exiting the ovpnc1 interface, hitting the tun1 VPS interface and only then failing to route back to the 192.168.25.0/24 network?


  • LAYER 8 Netgate

    OVPNC1 interface?  Nothing you're saying is matching the screen shots you're posting.

    Why on Earth would you want to NAT between 192.168 and 10.?

    What are your firewall rules on LAN?  Let's stick to a consistent set of interfaces and routes please.


  • Banned

    Flush all the stuff down the drain and see this: https://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_PKI_(SSL)

    Also, really easiest done on 2.2 since you can set up everything via the GUI, incl. the local/remote networks, with routes/iroutes set up completely behind the scenes, no need for messing with custom options.



  • @Derelict:

    OVPNC1 interface?  Nothing you're saying is matching the screen shots you're posting.

    Why on Earth would you want to NAT between 192.168 and 10.?

    What are your firewall rules on LAN?  Let's stick to a consistent set of interfaces and routes please.

    This is the interface created when the tunnel is up :

    Unfortunately, the VPS server is running Centos. Anyway, I'll try working on this a bit more.



  • Anyway, this is resolved. I needed "route 192.168.25.0 255.255.255.0 10.9.0.2 (ip address of the ovpn interface where the subnet is located".

    What really threw me off is that tcpdump didn't show any traffic but logging into the management interface and using "log on" + "verb 7" showed packets being received and de-crypted.



  • Anyway, this is resolved. I needed "route 192.168.25.0 255.255.255.0 10.9.0.2 (ip address of the ovpn interface where the subnet is located"

    Yes, the routing issue was fairly evident once you posted the configs.


Log in to reply