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

    Routing issues between networks behind openvpn routers

    OpenVPN
    3
    13
    3.2k
    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
      mailman
      last edited by

      Hi all,

      I am a bit struggling with my VPN setup. It looks something like:

      LAN1: 10.0.0.0/24 ===> OVPN-GW <=== big bad internet ====> branch office router <=== LAN2: 10.0.11.0/24

      OpenVPN-Gateway is running OpenBSD 5.2 and OpenVPN 2.2.2.
      The branch office router is running pfsense 2.0.3-RELEASE (amd64)

      IP-range for the clients on the VPN is 10.0.1.0/24 (tun).

      My goal was to allow the users in LAN2 access to LAN1. OpenVPN configuration seems to be fine, as the connection is fine and pinging the OVPN-GW from the pfsense console is possible. The firewall on pfsense was temporary set to allow all traffic. Also on OpenBSD's pf  "pass in" && "pass out" were temporary activated for testing purpose, but I had no luck accessing LAN1 from LAN2.

      What also seemed a bit strange on this OpenVPN setup generally is that, pinging the server from the clients is successful, but not the other way round. Is this behavior correct? Ping from server to client fails.

      Has anybody some hints on this, or maybe can give me some clue on how to debug this issue? To me it seems a lot of a routing issue.

      Thank you!

      Best regards

      ========= routing table OVPN-GW =========

      Internet:
      Destination        Gateway            Flags  Refs      Use  Mtu  Prio Iface
      default            x.x.6.1            UGS        6  149158    -    8 em0 
      x.x.6.0/27        link#1            UC        1        0    -    4 em0 
      x.x.6.1            78:fe:3d:47:19:0f  UHLc      1        0    -    4 em0 
      x.x.6.24          127.0.0.1          UGHS      0        0 33196    8 lo0 
      10.0.0/24          link#2            UC        1        0    -    4 em1 
      10.0.0.2          08:00:27:45:c7:c1  UHLc      3  150838    -    4 em1 
      10.0.1/24          10.0.1.2          UGS        0    38419    -    8 tun0
      10.0.1.2          10.0.1.1          UH        1        0    -    4 tun0
      127/8              127.0.0.1          UGRS      0        0 33196    8 lo0 
      127.0.0.1          127.0.0.1          UH        2    31314 33196 L  4 lo0 
      224/4              127.0.0.1          URS        0        0 33196    8 lo0

      ========= routing table branch office router =========

      IPv4
      Destination Gateway Flags Refs Use Mtu Netif Expire
      default x.x.29.201 UGS 0 2060 1500 em1
      10.0.0.0/24 10.0.1.1 UGS 0 0 1500 ovpnc1
      10.0.1.0/24 10.0.1.9 UGS 0 977 1500 ovpnc1
      10.0.1.9 link#10 UH 0 0 1500 ovpnc1
      10.0.1.10 link#10 UHS 0 0 16384 lo0
      10.0.10.0/24 link#3 U 0 447 1500 em2
      10.0.10.11 link#3 UHS 0 0 16384 lo0
      10.0.11.0/24 link#1 U 0 2225 1500 em0
      10.0.11.11 link#1 UHS 0 0 16384 lo0
      x.x.29.200/29 link#2 U 0 987 1500 em1
      x.x.29.203 link#2 UHS 0 0 16384 lo0
      127.0.0.1 link#7 UH 0 13 16384 lo0

      ========= routing table computer in LAN2 =========

      IPv4-Routentabelle
      Aktive Routen:
          Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
                0.0.0.0          0.0.0.0      10.0.11.11      10.0.11.101    266
              10.0.11.0    255.255.255.0  Auf Verbindung      10.0.11.101    266
            10.0.11.101  255.255.255.255  Auf Verbindung      10.0.11.101    266
            10.0.11.255  255.255.255.255  Auf Verbindung      10.0.11.101    266
              127.0.0.0        255.0.0.0  Auf Verbindung        127.0.0.1    306
              127.0.0.1  255.255.255.255  Auf Verbindung        127.0.0.1    306
        127.255.255.255  255.255.255.255  Auf Verbindung        127.0.0.1    306
              224.0.0.0        240.0.0.0  Auf Verbindung        127.0.0.1    306
              224.0.0.0        240.0.0.0  Auf Verbindung      10.0.11.101    266
        255.255.255.255  255.255.255.255  Auf Verbindung        127.0.0.1    306
        255.255.255.255  255.255.255.255  Auf Verbindung      10.0.11.101    266

      ========= routing table computer in LAN1 =========

      Kernel IP routing table
      Destination    Gateway        Genmask        Flags  MSS Window  irtt Iface
      0.0.0.0        10.0.0.1        0.0.0.0        UG        0 0          0 eth0
      10.0.0.0        0.0.0.0        255.255.255.0  U        0 0          0 eth0
      127.0.0.0      0.0.0.0        255.0.0.0      U        0 0          0 lo
      169.254.0.0    0.0.0.0        255.255.0.0    U        0 0          0 eth0

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

        Which side is server and which side is the client?

        I do not see a route to 10.0.11.0/24 on the OVPN-GW side… that's likely your issue

        Post the config files from both sides (e.g. server1.conf and client1.conf)

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

          Hi,

          sorry I forgot some information. OVPN-GW is the server and pfsense the client.

          Adding the according route on the server fails with:

          route add -net 10.0.11.0/24 10.0.1.10

          route: writing to routing socket: Network is unreachable
          add net 10.0.11.0/24: gateway 10.0.1.10: Network is unreachable

          This will probably be caused by the server not being able reach the clients, as also "ping 10.0.1.10" times out. 10.0.1.10 is the client IP shown by pfsense. So I can assume this behavior is not supposed to be okay? Any ideas on this?

          Thank you!

          Best regards

          ====== server.conf ======

          proto udp
          port 444
          dev tun0
          ca /etc/openvpn/ca.crt
          cert /etc/openvpn/private/cert.cc.crt
          key /etc/openvpn/private/key.key
          dh /etc/openvpn/dh2048.pem

          server 10.0.1.0 255.255.255.0

          keepalive 10 120
          comp-lzo
          user openvpn
          group openvpn
          daemon openvpn
          persist-key
          persist-tun

          tls-auth /etc/openvpn/private/ta.key 0
          cipher AES-256-CBC

          push "route 10.0.0.0 255.255.255.0"
          push "dhcp-option DNS 10.0.0.2"
          client-to-client

          status /var/log/openvpn-status.log

          ====== client config ======

          client
          dev tun
          proto udp
          remote server 444
          resolv-retry infinite
          nobind
          persist-key
          persist-tun
          ca ca.crt
          cert client.crt
          key client.key
          tls-auth ta.key 1
          cipher AES-256-CBC
          comp-lzo
          verb 3

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

            Information I see (let me know if any of this is not correct:
            Tunnel Network - 10.0.1.0/24
            LAN1 - 10.0.0.0/24
            LAN2 - 10.0.11.0/24

            From the above info, it looks like the following is missing:

            SERVER
            –--------
            ifconfig 10.0.1.1 10.0.1.2
            route 10.0.11.0 255.255.255.0

            CLIENT

            ifconfig 10.0.1.2 10.0.1.1
            route 10.0.0.0 255.255.255.0

            Also that client config... are you sure you pulled that from a PFsense box?  Because if you enter the relevant info into the client section of OpenVPN... it should look similar to this:

            dev ovpnc2
            dev-type tun
            dev-node /dev/tun2
            writepid /var/run/openvpn_client2.pid
            #user nobody
            #group nobody
            script-security 3
            daemon
            keepalive 10 60
            ping-timer-rem
            persist-tun
            persist-key
            proto udp
            cipher AES-128-CBC
            up /usr/local/sbin/ovpn-linkup
            down /usr/local/sbin/ovpn-linkdown
            local WAN_IP_OF_LAN2
            tls-client
            client
            lport 0
            management /var/etc/openvpn/client2.sock unix
            remote WAN_IP_OF_LAN1 1194
            ifconfig 10.0.1.2 10.0.1.1
            route 10.0.0.0 255.255.255.0
            ca /var/etc/openvpn/client2.ca
            cert /var/etc/openvpn/client2.cert
            key /var/etc/openvpn/client2.key
            tls-auth /var/etc/openvpn/client2.tls-auth 1

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

              Hey,

              sorry for the delay. Didn't have any access to the system until now ….

              I tried adding the routes as you suggested, but had no luck :(

              And sorry for the wrong config-file; seem to have taken the wrong one ...

              dev ovpnc1
              dev-type tun
              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 AES-256-CBC
              up /usr/local/sbin/ovpn-linkup
              down /usr/local/sbin/ovpn-linkdown
              local x.x.29.203
              tls-client
              client
              lport 0
              management /var/etc/openvpn/client1.sock unix
              remote SERVER_DNS 444
              ca /var/etc/openvpn/client1.ca
              cert /var/etc/openvpn/client1.cert
              key /var/etc/openvpn/client1.key
              tls-auth /var/etc/openvpn/client1.tls-auth 1
              comp-lzo
              tls-auth /etc/tls.auth 1

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

                You are still missing info. After you've entered everything, your config should look identical to mine with the excepttion of the WAN IP's.

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

                  Marvosa - This is related but unrelated…

                  Ubuntu doesn't route to LANs the way it should automatically the way windows does when its a client to a pfsense TUN openvpn.

                  This little line you mentioned earlier totally fixed a looooonnnnnnggggggg standing issue of ubuntu to make it route to LANs.

                  In the client file on ubuntu, near bottom placed:
                  route 10.0.0.0 255.255.255.0  (substituted my LAN Subnet)

                  I haven't ever seen a good fix for this anywhere, but this is so simple.  Why didn't I do earlier (pfsense needs a facepalm icon) :-[

                  So, you are a genius.  Thank you much for the accidental unrelated help  :)

                  keywords added for web searches:

                  ubuntu linux mint pfsense openvpn can't access LAN TUN client

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

                    Just to clarify my first post, those missing lines need to be added to your config… not added via command line after connection.

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

                      Yeah sure, but as I told previously I still can't get any connection …

                      new pfsense config

                      dev ovpnc1
                      dev-type tun
                      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 AES-256-CBC
                      up /usr/local/sbin/ovpn-linkup
                      down /usr/local/sbin/ovpn-linkdown
                      local x.x.29.203
                      tls-client
                      client
                      lport 0
                      management /var/etc/openvpn/client1.sock unix
                      remote HOST 444
                      ca /var/etc/openvpn/client1.ca
                      cert /var/etc/openvpn/client1.cert
                      key /var/etc/openvpn/client1.key
                      tls-auth /var/etc/openvpn/client1.tls-auth 1
                      comp-lzo
                      tls-auth /etc/tls.auth 1
                      ifconfig 10.0.1.2 10.0.1.1
                      route 10.0.0.0 255.255.255.0

                      new server config:

                      proto udp
                      port 444
                      dev tun0

                      ifconfig 10.0.1.1 10.0.1.2
                      route 10.0.11.0 255.255.255.0

                      ca /etc/openvpn/ca.crt
                      cert /etc/openvpn/private/picard.goetzinger.cc.crt
                      key /etc/openvpn/private/picard.goetzinger.cc.key
                      dh /etc/openvpn/dh2048.pem

                      server 10.0.1.0 255.255.255.0

                      keepalive 10 120
                      comp-lzo

                      user openvpn
                      group openvpn
                      daemon openvpn

                      persist-key
                      persist-tun

                      tls-auth /etc/openvpn/private/ta.key 0
                      cipher AES-256-CBC

                      push "route 10.0.0.0 255.255.255.0"
                      push "dhcp-option DNS 10.0.0.2"
                      client-to-client

                      status /var/log/openvpn-status.log

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

                        Client-side looks right, although it looks like you added the lines manually to the advanced section instead of letting the system generate it ("should" work either way).

                        Is the tunnel established?  If so, probably looking at firewall rules.

                        Post the firewall rule from the OpenVPN tab on PFsense.

                        Posting routing tables from both firewalls might help as well.

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

                          Sure, tunnel status has been fine, since initial setup.

                          Firewall rules at OpenBSD are

                          pass in
                          pass out

                          Firewall rules at the pfsense are

                          Proto TCP
                          Source *
                          Port *
                          Destination *
                          Port *
                          Gateway *
                          Queue None

                          Routing table at pfsense:

                          IPv4
                          Destination Gateway Flags Refs Use Mtu Netif Expire
                          default   85.126.x.x UGS 0 4386 1500 em1
                          10.0.0.0/24 10.0.1.1 UGS 0 24 1500 ovpnc1
                          10.0.1.0/24 10.0.1.5 UGS 0 1699 1500 ovpnc1
                          10.0.1.5 link#10 UH 0 0 1500 ovpnc1
                          10.0.1.6 link#10 UHS 0 0 16384 lo0
                          10.0.10.0/24 link#3 U 0 0 1500 em2
                          10.0.10.11 link#3 UHS 0 0 16384 lo0
                          10.0.11.0/24 link#1 U 0 4693 1500 em0
                          10.0.11.11 link#1 UHS 0 0 16384 lo0
                          85.126.x.x/29 link#2 U 0 1709 1500 em1
                          85.126.x.x link#2 UHS 0 0 16384 lo0
                          127.0.0.1 link#7 UH 0 26 16384 lo0

                          Routing table at OpenBSD:

                          Destination        Gateway            Flags  Refs      Use  Mtu  Prio Iface
                          default            static.1.6.9.5.cli UGS      12  889109    -    8 em0 
                          static.0.6.9.5.cli link#1            UC        1        0    -    4 em0 
                          static.1.6.9.5.cli 78:fe:3d:47:19:0f  UHLc      2        0    -    4 em0 
                          picard            localhost          UGHS      0        0 33196    8 lo0 
                          10.0.0/24          link#2            UC        1        0    -    4 em1 
                          planck            08:00:27:45:c7:c1  UHLc      2  606332    -    4 em1 
                          10.0.1/24          10.0.1.2          UGS        0  285890    -    8 tun0
                          10.0.1.2          10.0.1.1          UH        2        0    -    4 tun0
                          10.0.11/24        10.0.1.2          UGS        0        0    -    8 tun0
                          85-126-x-x.work static.1.6.9.5.cli UGHD      2  888959    - L  56 em0 
                          loopback          localhost          UGRS      0        0 33196    8 lo0 
                          localhost          localhost          UH        7  145056 33196 L  4 lo0 
                          BASE-ADDRESS.MCAST localhost          URS        0        0 33196    8 lo0

                          Thank you!

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

                            Something's fishy… It looks like PFsense is trying to route 10.0.0.0/24 through 10.0.1.1 (which should be other end of the tunnel), but the system thinks the other end of the tunnel is 10.0.1.5.  Do you have any manual routes added?

                            I would start by removing any manually added routes, then:

                            Client side:

                            • remove the ifconfig and route lines from the advanced section and enter the appropriate information into the Tunnel Settings section of the GUI and let PFsense generate those lines

                            • Reboot PFsense

                            Server side:

                            • even know the server-side looks ok, I would place the ifconfig line underneath the server line

                            • place the route statement down by the push lines

                            • I'm also wondering on the server side if you need to change "dev tun0" to just "dev tun" (I believe you would only use that if you have multiple connections and want to bind each connection to a separate interface)

                            After that I would turn on logging of your firewall rules on the openvpn interface on both sides and verify that you're not getting blocks.

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

                              Okay, logging is turned on and everything is passed.

                              logs:

                              pass Oct 6 14:47:32 LAN 10.0.11.107 10.0.0.2 ICMP

                              the routes look way better now on the pfsense:

                              IPv4
                              Destination Gateway Flags Refs Use Mtu Netif Expire
                              default 85.126.29.201 UGS 0 38 1500 em1
                              10.0.0.0/24 10.0.1.5 UGS 0 36 1500 ovpnc1
                              10.0.1.0/24 10.0.1.5 UGS 0 0 1500 ovpnc1
                              10.0.1.5 link#10 UH 0 0 1500 ovpnc1
                              10.0.1.6 link#10 UHS 0 0 16384 lo0
                              10.0.10.0/24 link#3 U 0 0 1500 em2
                              10.0.10.11 link#3 UHS 0 0 16384 lo0
                              10.0.11.0/24 link#1 U 0 3994 1500 em0
                              10.0.11.11 link#1 UHS 0 0 16384 lo0
                              85.126.29.200/29 link#2 U 0 174 1500 em1
                              85.126.29.203 link#2 UHS 0 0 16384 lo0
                              127.0.0.1 link#7 UH 0 33 16384 lo0

                              but I still have no connection to 10.0.0.0/24; though pinging 10.0.1.6 works

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