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

    OpenVPV site-to-site, only the first Remote Network is reachable from LAN

    Scheduled Pinned Locked Moved OpenVPN
    15 Posts 3 Posters 1.6k 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.
    • M
      mbaldini
      last edited by mbaldini

      I have pfSense latest version 2.4.4-RELEASE-p2 (amd64)

      LAN Interface: 192.168.1.2/24
      WAN Interface: 192.168.30.20/24 Gateway 192.168.30.1

      In the remote site I have two subnets, both are managed by the router on the remote site and that router is OpenVPN client too: 192.168.10.1/24, 192.168.90.1/24

      OpenVPN Tunnel network is 10.10.10.0/24

      I have configured an OpenVPN server, this are the networks parameters:

      -<openvpn-server>
  <vpnid>1</vpnid>
     -cut-
  <tunnel_network>10.10.10.0/24</tunnel_network>
  <remote_network>192.168.90.0/24, 192.168.10.0/24</remote_network>
  <local_network>192.168.1.0/24</local_network>
</openvpn-server>

      To make sure routes are correct, I use Client Specific Overrides:

      -<openvpn-csc>
  <server_list>1</server_list>
  -<common_name>
    <![CDATA[vpn-sanmartino]]>
  </common_name>
  -cut-
  <tunnel_network>10.10.10.2/24</tunnel_network>
  <local_network>192.168.1.0/24</local_network>
  <remote_network>192.168.90.0/24, 192.168.10.0/24</remote_network>
</openvpn-csc>

      When VPN is connected, if I try from local LAN to ping addresses in the remote site, I only have the correct reply from the addresses in the first remote subnet, the second subnet is incorrectly routed through the gateway and not the VPN.

      Routes seems ok to me:
      alt text

      traceroute to first remote address 192.168.90.1:
      alt text

      traceroute to second remote address 192.168.10.1, routing is totally wrong (pfsense routes through internet router gateway):
      alt text

      During various test I just made, I discovered that if I change the order of the addresses in Remote Networks, it always works only the first, so if in Remote Networks I put 192.168.10.0/24, 192.168.90.0/24 and restart OpenVPN, I can reach addresses in the 192.168.10.0/24 subnet but can't reach addresses in the second subnet:
      alt text

      Any idea on what is wrong? What can I do to make it works?

      Thanks

      1 Reply Last reply Reply Quote 0
      • RicoR
        Rico LAYER 8 Rebel Alliance
        last edited by Rico

        PKI/SSL?
        In the CSO you fill in nothing but the Common Name and IPv4 Remote Networks.
        Common Name is exactly your Client Cert Name.

        -Rico

        M 1 Reply Last reply Reply Quote 0
        • M
          mbaldini @Rico
          last edited by

          @rico
          It's certificate authentication, the part about the client authentication is working, the VPN tuunel is created, the routes are added, still pfSense route the packets to the remote sites only for the first subnet specified in remote networks. It's strange because the routes are there, but the routing is not working, those packets are directed to the WAN gateway and not to the VPN interface

          1 Reply Last reply Reply Quote 0
          • RicoR
            Rico LAYER 8 Rebel Alliance
            last edited by

            I know, I've read your post. :-)
            AFAIK your CSO is still incorrect....I'm not sure what happens when tunnel and local network is specified there, maybe it's the behavior you report.

            -Rico

            1 Reply Last reply Reply Quote 0
            • M
              mbaldini
              last edited by

              @rico
              You mean

              -<common_name>
    <![CDATA[vpn-client]]>
  </common_name>

              ?
              Sorry, I just wrote it bad, now it's correct.

              1 Reply Last reply Reply Quote 0
              • RicoR
                Rico LAYER 8 Rebel Alliance
                last edited by

                It‘s better to post screenshots of your OpenVPN and CSO configuration, not the conf files.

                -Rico

                1 Reply Last reply Reply Quote 0
                • M
                  mbaldini
                  last edited by

                  Screenshots as requested:

                  OPENVPN SERVER CONFIGURATION:

                  alt text

                  alt text

                  alt text

                  alt text

                  OPENVPN CLIENT SPECIFIC OVERRIDES:

                  alt text

                  alt text

                  alt text

                  TESTS IF REMOTE NETWORKS ARE WORKING:

                  Actually I have ping replies only from the first subnet in remote networks 192.168.10.0/24
                  I can't reach the second subnet 192.168.90.0/24

                  alt text

                  PfSense is doing some wrong thing in routing, as you can see from traceroute. Packets to the subnet 192.168.10.0/24 are correctly routed through the VPN tunnel, but packets to the subnet 192.168.90.0/24 are not routed through the VPN tunnel, both static routes are active as you can see from screenshot

                  alt text

                  Is this some nasty bug or am I missing something?

                  Thanks

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

                    What does the routing table look like on the client when it is connected?

                    ROUTE PRINT

                    The mode you are using is designed to be talking to another router.

                    The OpenVPN client for Windows is designed as a remote access client and is not necessarily designed to have routed subnets behind it.

                    You have two clients connected using the same CN. How is OpenVPN supposed to know where to route what?

                    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
                    • M
                      mbaldini
                      last edited by

                      In the remote site there is a Mikrotik router RB760 acting as OpenVPN client, behind that router there are various clients / devices in two phisically separated subnets (one port of the RB760 has IP in one subnet 192.168.90.1/24, another port has IP in the the other subnet 192.168.10.1/24). From the remote site everything is working, from clients / devices in both subnets, having Mikrotik router as gateway, I can reach every device in the LAN subnet 192.168.1.0/24 (other side of the VPN tunnel)

                      This is the network diagram of the infrastructure:
                      alt text

                      The problem is in the "LAN SEDE GARLAND" subnet, in this subnet every device has pfSense IP 192.168.1.2 as gateway, so the routing for the two subnets reachable via OpenVPN must be done by PfSense, in fact in the routing table of PfSense there are the correct routing entries:
                      alt text

                      As you can see, there are entries:
                      192.168.10.0/24 with gateway 10.10.10.2 (endpoint of the vpn)
                      192.168.90.0/24 with gateway 10.10.10.2 (same endpoint of the vpn)

                      In the clients there are no routing entries referred to subnets 192.168.90.0/24 and 192.168.10.0/24 because these must be handled by PfSense.
                      alt text

                      With the routing tables shown in client and PfSense, why is there this behaviour?
                      alt text

                      192.168.10.10 is correctly routed through VPN (2nd hop is 10.10.10.2, vpn endpoint)
                      192.168.90.98 is not routed through VPN, in fact it is routed through 192.168.30.1 (default gateway in PfSense)

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

                        Any policy routing on your LAN 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
                        • M
                          mbaldini
                          last edited by

                          I have two gateways in failover configuration, the VPN is active only in the default gateway, I don't need that to work in case of primary gateway down

                          alt text

                          alt text

                          alt text

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

                            You are probably policy routing that other VPN remote network out WAN. See where you are doing that and remove it.

                            If in doubt add a pass rule for protocol any source LAN net dest 192.168.90.0/24 with no gateway set at the top of the LAN 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 1
                            • M
                              mbaldini
                              last edited by

                              Thanks you very much.

                              Adding the rule in Firewall - Rules - LAN now it's working and packets are correctly routed for both subnets.
                              I checked all the firewall rules and there is no rule with 192.168.90.0/24 as source or destination, so I can't really understand why PfSense is routing that network through the WAN. Now it's working with the rule added, so it's ok for me.

                              Thanks

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

                                We would need to know the contents of all of those aliases to be able to be more sure. One of those rules is policy routing the traffic.

                                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
                                • M
                                  mbaldini
                                  last edited by mbaldini

                                  This is the alias list:

                                  alt text

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