Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Pfsense as OpenVPN client, routing issue

    Scheduled Pinned Locked Moved OpenVPN
    3 Posts 2 Posters 1.1k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • J
      jakommo
      last edited by

      Hello,

      I try to connect our branch office to our main office using pfsense as a OpenVPN client on the branch office.

      Setup looks like this:

      Main Office:
      Net: 192.168.1.x
      Default GW: 192.168.1.244
      OpenVPN Server: 192.168.1.6 (Debian 7. PKI/TAP)
      Other Net: 10.1.1.x (routed via .244)

      Branch Office:
      Net: 192.168.2.x
      Ovpn Client IP: 192.168.1.194

      What I want to accomplish:
      The clients on the branch office should reach the Internet using the branch office's WAN and use the OpenVPN for connections to the main office's networks.

      What does work:
      OpenVPN connects successfully, I can ping from branch to 192.168.1.x and from main to 192.168.2.x. Branch clients also use there WAN for Internet access.

      What doesn't work:

      1. Clients from branch can't ping 10.1.1.x (because they/pfsense do not know about the route there).
      2. Branch clients can't access a webserver on 192.168.1.x Net. (Browser keeps loading forever).

      I think the problem is that connections over OVPN don't use 192.168.1.244 as their GW.

      Routing table on pfsense:

      Destination        Gateway            Flags    Refs      Use  Netif Expire
      default            XXX.XXX.XX.113     UGS         0       95    re0
      127.0.0.1          link#4             UH          0        0    lo0
      192.168.1.0/24     link#8             U           0       51 ovpnc1
      192.168.1.194      link#8             UHS         0        0    lo0
      192.168.2.0/24    link#2             U           0       46    re1
      192.168.2.254     link#2             UHS         0        0    lo0
      YYY.YYY.YYY.10     XXX.XXX.XX.113     UGHS        0       21    re0
      YYY.YYY.YYY.11     XXX.XXX.XX.113     UGHS        0        2    re0
      XXX.XXX.XX.112/29  link#1             U           0     2787    re0
      XXX.XXX.XX.117     link#1             UHS         0        0    lo0
      

      Routing table on 192.168.1.244

      Kernel IP routing table
      Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
      0.0.0.0         XXX.XXX.XX.113  0.0.0.0         UG        0 0          0 red0
      10.1.1.0        192.168.1.208   255.255.255.0   UG        0 0          0 green0
      192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 green0
      192.168.2.0    192.168.1.194   255.255.255.0   UG        0 0          0 green0
      XXX.XXX.XX.112  0.0.0.0         255.255.255.248 U         0 0          0 red0
      

      Both problems can be solved by adding the routes to pfsense manually via ssh:

      route del 192.168.1.0
      route add -net 192.168.1.0/24 192.168.1.244
      route add -net 10.1.1.0/24 192.168.1.244
      

      I could put these commands in a shell script an let it execute at boot time, but I'm looking for a "clean" solution.

      Is there a way to accomplish this in the webif?

      thanks,
      jakommo

      1 Reply Last reply Reply Quote 0
      • K
        kpa
        last edited by

        You shouldn't use addresses that overlap with either of the LAN nets on the tunnel interfaces. Select a non-overlapping subnet, for example 172.16.2.0/24 and use the first two addresses (.1 and .2) of it on the tunnel network. That way you can be sure there's never any confusion where a packet should be routed to.

        1 Reply Last reply Reply Quote 0
        • J
          jakommo
          last edited by

          Hi kpa,

          thanks for your fast response.
          The VPN is a TAP/bridged one, as fas as I understand there is no tunnel on this kind of vpn, or am I missing something?

          Thanks,
          Jakommo

          1 Reply Last reply Reply Quote 0
          • First post
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.