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

    OpenVPN does not route traffic to remote IPSec branch offices.

    Scheduled Pinned Locked Moved Routing and Multi WAN
    5 Posts 2 Posters 1.2k 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.
    • R Offline
      rodylopez
      last edited by

      Hello,
      I have a pfSense 2.2.1 installed in the HQ hosting the OpenVPN for remote users. I also have two branch offices on pfSene (same version) connecting to the same HQ pfSense box using IPsec.
      HQ subnet - 192.168.10.0/21
      Branch1 - 192.168.21.0/24
      Branch2 - 192.168.23.0/24
      OpenVPN - 172.16.1.0/24
      On the HQ pfSense box I have set for the OpenVPN server under IPv4 Local Network/s the three 192.168.10.0/21,192.168.21.0/24,192.168.23.0/24 so this way the route for the 3 subnets is pushed out to the OpenVPN clients which I know change the routing table as I have confirmed this. So the 3 subnets are routed to the OpenVPN server in the HQ.
      On the branch offices I have two phase2 one on the IPsec, one with the HQ LAN subnet (as remote subnet) 192.168.10.0/21 and the other with 172.16.1.0/24 (as remote subnet). So traffic back from branch offices should reach the HQ pfSense box.
      OpenVPN clients can reach any machine at the HQ with no problems but they cannot reach any o the branch offices thought the IPsec. I do not want the configure site to site OpenVPN as the IPsec has been working reliable between the HQ and the two branch offices for years.
      What can I do to set properly routing between the OpenVPN clients and the remote offices.
      Thanks.

      1 Reply Last reply Reply Quote 0
      • DerelictD Offline
        Derelict LAYER 8 Netgate
        last edited by

        What about all the necessary OpenVPN and IPSec firewall rules?

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • R Offline
          rodylopez
          last edited by

          I allow all traffic between the OpenVPN and the two IPSec on both directions while I am trying to get this working.
          Thanks.

          1 Reply Last reply Reply Quote 0
          • DerelictD Offline
            Derelict LAYER 8 Netgate
            last edited by

            Then I guess you have to post screenshots to get more eyes on things because if you had done all that it would be working.

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • R Offline
              rodylopez
              last edited by

              I don't think this is a firewall issues, it is a routing issue. When I run a trace route from an OpenVPN client trying to reach one of the branch offices this is what I get:

              C:>tracert 192.168.23.1

              Tracing route to 192.168.23.1 over a maximum of 30 hops

              1    15 ms    14 ms    12 ms  172.16.1.1
                2    11 ms    10 ms    10 ms  domainname.com [206.201.5.180]
                3    *    saddleback-rs-mv4 [64.58.128.9]  reports: Destination net unreachable

              Trace complete.

              So the HQ box is sending the packets to the default route instead of sending them through the proper IPSec to the branch office. Looks like it's not aware of the IPSec it's running on the same box.

              Thanks.

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