OpenVPN client - Routing from LAN?

  • Hi all,

    For some reason I can't find the right search terms to locate what to do here, but I bet it's been answered before. I have a remote OpenVPN server running, and I would like PFSense to connect to said OpenVPN server and route any traffic from the local LAN ( destined for through the VPN.

    The VPN connects great and I can ping hosts from PFSense. However, I can't ping hosts from any machine on the local LAN.

    I've tried:

    • Setting "IPv4 Remote network(s)" in the OpenVPN client settings to
    • Adding route to the "Custom options" in the client settings
    • Creating firewall rules in LAN for the two networks
    • Creating firewall rules in OpenVPN for the two networks

    I must be doing something just flat out wrong, and hoping someone here can help.

    Once I've got the VPN client working, what are the next steps to route LAN traffic to a specific subnet through it?


  • If it helps, the following is in the status for OpenVPN:

    Local address:
    Virtual address:

    The virtual address is being provided by the OpenVPN server, and I can ping that from my LAN clients.

  • LAYER 8 Moderator

    With that virtual address I'd guess the other site is configured for a RAS/Client style network as in a tunnel settings normally you only have 2 IPs (.1 and .2) on either end of the tunnel. But perhaps I'm wrong and you have as your tunnel network? What you seem to achieve is a Site2Site VPN that has to be configured in another setup. That's what those different server settings of OVPN are all about. A client-style VPN server doesn't need information about the networks "behind" the dialed in client so has no clue about them and won't send packets that way. That's why you need a tunnel style site2site setup where you define (on both ends) what local and remote network you want to connect. Otherwise those hosts aren't accessible.

    If that's a tunnel network setup, check that you correctly configure the local and remote networks on both side. Also check under Diagnostics/Routes if those routes are there. Then check your firewall filter rules on both ends if you permit incoming traffic via OpenVPN interface so you won't get blocked. :)

    But for better guesses/help we'd need screens from the config of both ends as well as the rules.

  • Ok.. my post is getting flagged as spam, so I'm going to try to break it up and figure out what's causing it:

    Thanks for the help! The server side is an OpenVPN docker container. It's not configured to be a tunnel per-se, just a server, but I have used it as such when I was using DD-WRT instead of PFSense. DD-WRT basically handled all the firewall rules for me, so I'm guessing it's something to do with me messing that up. Your routing comment got me a bit closer bit still no luck. I've switched up the address space since starting, so here's how everything looks now (but with the same results):

    Relevant parts of server config:

    proto udp
    port 1194
    dev tun0

    Routes on server (172.18 is the Docker address space, running on a machine in 192.168.6.x):

    # route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface         UG    0      0        0 eth0     U     0      0        0 eth0   UG    0      0        0 tun0   UG    0      0        0 tun0 UH    0      0        0 tun0

    Ping from OpenVPN server to PFsense client:

    # ping
    PING ( 56 data bytes
    64 bytes from seq=0 ttl=64 time=40.523 ms
    64 bytes from seq=1 ttl=64 time=42.446 ms
    --- ping statistics ---
    2 packets transmitted, 2 packets received, 0% packet loss
    round-trip min/avg/max = 40.523/41.484/42.446 ms

    Ping from PFSense to network behind OpenVPN server:

    : ping
    PING ( 56 data bytes
    64 bytes from icmp_seq=0 ttl=62 time=42.249 ms
    64 bytes from icmp_seq=1 ttl=62 time=40.428 ms
    64 bytes from icmp_seq=2 ttl=62 time=99.519 ms
    --- ping statistics ---
    3 packets transmitted, 3 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 40.428/60.732/99.519/27.437 ms

    Ping from machine on LAN behind PFSense to network behind OpenVPN server:

    $ ping
    PING ( 56(84) bytes of data.
    --- ping statistics ---
    2 packets transmitted, 0 received, 100% packet loss, time 1009ms

  • And now it thinks I'm a new user even though I've been around for years and years so I have to wait 120s ;)

    Turns out it was pasting XML causing the spam error.

    PFSense OpenVPN client config (minus security/host info):

    PFSense routes:

    Interface assignments (I've tried this since the first post):


    As you can see the firewall setup is pretty permissive as I try to figure this out.

  • LAYER 8 Moderator

    @Fmstrat said in OpenVPN client - Routing from LAN?:

    Ping from PFSense to network behind OpenVPN server:

    That works, because your VPN Server has - as per your routing table - the VPN transfer network available and as pfSense always pings from the network interface that is nearest to the destination - in that case it's the ovpn interface itself - that gets answered correctly. But your Docker OVPN is missing the route back to the 192.168.10/11.0 network as I don't see that in your routing table at all. Without that, not traffic will flow back to pfSense through the tunnel.

    As pfSense itself is acting as a client rather then a real site2site connection it's on you:

    Do you want a site2site VPN? Then I'd change the docker container OVPN instance and either add another OVPN server for that or switch the available one to site2site config with shared key. That's the easiest setup available.

    If you only want to have clients on the Docker site available to access FROM your pfSense/LAN and you don't care if anything on that side wants to access your pfSense LAN - then you can simply add a Outbound NAT rule on the OVPN interface to NAT anything from your LAN network range (source) to your target destination network gets NATted to the OVPN interface address.

    I don't know exactly what where the 192.168.6.x or 192.168.254.x networks are, you didn't mention them in your original post so it's quite hard ATM to guess what is what :) But just as an example:


    That would NAT your local LAN only when leaving through your OVPN interface to a certain destination IP Range and NAT it to your OVPN GW Address that should be accessible to your target server so it can route back your packets to you. That's no solution if you want equal access from Site A <-> Site B though!

  • Got it!

    NAT was the key, vs modifying rules manually. I have now deleted the extra interface and all firewall rules and all is good. The .10 network no longer exists, I changed up the scheme (mentioned that above but probably wasn't clear). Thanks!

Log in to reply