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

    openvpn (site-to-site) routing issue

    Scheduled Pinned Locked Moved OpenVPN
    13 Posts 4 Posters 1.4k 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
      jazzl0ver
      last edited by jazzl0ver

      Hi,

      pfSense establishes openvpn connection to a remote site. there're static routes configured on pfsense to reach remote destinations. clients behind pfSense's LAN interface may reach those destinations w/o issues.
      when i try to, for example, ping remote IP, it's not working:

      # netstat -rn|grep 172.29
      172.29.0.0/16      10.8.1.2           UGS         lo0
      
      # netstat -rn|grep ovpnc1
      10.8.1.0/24        10.8.1.1           UGS      ovpnc1
      10.8.1.1           link#11            UH       ovpnc1
      fe80::204:76ff:fe24:34f0%ovpnc1   link#11                       UHS         lo0
      
      # ifconfig ovpnc1
      ovpnc1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
              options=80000<LINKSTATE>
              inet6 fe80::204:76ff:fe24:34f0%ovpnc1 prefixlen 64 scopeid 0xb
              inet 10.8.1.2 --> 10.8.1.1 netmask 0xffffff00
              nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
              groups: tun openvpn
              Opened by PID 23934
      
      # ping 172.29.2.176
      PING 172.29.2.176 (172.29.2.176): 56 data bytes
      36 bytes from localhost (127.0.0.1): Redirect Host(New addr: 10.8.1.2)
      Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
       4  5  00 0054 0a31   0 0000  40  01 0000 127.0.0.1  172.29.2.176
      
      36 bytes from localhost (127.0.0.1): Redirect Host(New addr: 10.8.1.2)
      Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
       4  5  00 0054 0a31   0 0000  3f  01 0000 127.0.0.1  172.29.2.176
      ...
      

      however, ping does work if i bind it to the openvpn interface:

      # ping -S 10.8.1.2 172.29.2.176
      PING 172.29.2.176 (172.29.2.176) from 10.8.1.2: 56 data bytes
      64 bytes from 172.29.2.176: icmp_seq=0 ttl=254 time=122.954 ms
      ^C
      --- 172.29.2.176 ping statistics ---
      1 packets transmitted, 1 packets received, 0.0% packet loss
      round-trip min/avg/max/stddev = 122.954/122.954/122.954/0.000 ms
      

      what am I missing? how to make it work?

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

        Post a network map so we can visualize what networks are being used at both ends.

        Also, the routing is done in the config...you shouldn't need any static routes, so you'll want to review what's entered in the IPv4 Remote network(s) section on both the client and server.

        Post the config.ovpn from both sides if you'd like another set of eyes to review them.

        J 1 Reply Last reply Reply Quote 0
        • bingo600B
          bingo600 @jazzl0ver
          last edited by bingo600

          @jazzl0ver
          Could be missing return routes in the remote end.

          You have "told" your local pfSense that 172.29.0.0/16 is behind/via 10.8.1.2.

          But you also have to tell your remote pfSense, how to route packets back to the local pfSense.

          That said:
          In your 1'st example :

          # ping 172.29.2.176
          PING 172.29.2.176 (172.29.2.176): 56 data bytes
          36 bytes from localhost (127.0.0.1): Redirect Host(New addr: 10.8.1.2)
          Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
           4  5  00 0054 0a31   0 0000  40  01 0000 127.0.0.1  172.29.2.176
          

          The packages are "sourced from" 127.0.0.1 , and that would never work for a remote ping. But i think that source ip is rewritten to the "Outging IF":

          Redirect Host(New addr: 10.8.1.2)
          

          But if that rewrite happens , then the 1'st ping , and the 2'nd should give same result. One is rewriting source for you, the other you specify i your self.

          The reason it works if you specify the 10.8.1.2 , is :
          The 10.8.1.x/24 network is already known at both ends , due to the OpenVPN tunnel being up.

          /Bingo

          If you find my answer useful - Please give the post a šŸ‘ - "thumbs up"

          pfSense+ 23.05.1 (ZFS)

          QOTOM-Q355G4 Quad Lan.
          CPUĀ  : Core i5 5250U, Ram : 8GB Kingston DDR3LV 1600
          LANĀ  : 4 x Intel 211, DiskĀ  : 240G SAMSUNG MZ7L3240HCHQ SSD

          J 1 Reply Last reply Reply Quote 0
          • J
            jazzl0ver @marvosa
            last edited by jazzl0ver

            @marvosa thank you for trying to help!

            Here is the network layout:
            1d33711c-aea0-4ee5-bcf0-2cd8af452838-image.png
            Relevant part of the openvpn server's config:

            # cat /etc/openvpn/server/server.conf
            dev tun
            proto udp
            lport 1194
            topology subnet
            server 10.8.1.0 255.255.255.0
            push "route 172.22.0.0 255.255.248.0"
            push "route 172.29.0.0 255.255.0.0"
            push "dhcp-option DNS 172.29.0.2"
            push "block-outside-dns"
            push "redirect-gateway def1"
            

            Relevant part of the openvpn client config (pfsense):

            # cat /var/etc/openvpn/client1.conf
            dev ovpnc1
            dev-type tun
            dev-node /dev/tun1
            local 172.26.1.1
            client
            lport 0
            remote vpn.remotehost.com 1194 udp4
            resolv-retry infinite
            route-nopull
            

            I had to use CARP VIP (172.26.1.1) as a local endpoint to be able to automatically switch between ISP channels if (when) one of them goes down and to handle pfsense failover.

            Let me know if you see anything.

            V 1 Reply Last reply Reply Quote 0
            • V
              viragomann @jazzl0ver
              last edited by

              @jazzl0ver
              You're running an access server on the remote site. So you have to set the route on the server for the specific client using iroute as descriped here: Lans behind OpenVPN

              Also not clear, why you're pushing some routes on the server and also pushing "redirect-gateway". If using the latter there is no need of pushing additional routes at all.

              J 1 Reply Last reply Reply Quote 0
              • J
                jazzl0ver @viragomann
                last edited by jazzl0ver

                @viragomann thanks for your reply!

                Yeah, there's no need to push the routes when redirect-gateway in use. I'll correct that, thanks

                I'm not sure why you think the mentioned link is my case.

                In my understanding pfsense should NAT outgoing ping packets into the ovpnc1's IP address (10.8.1.2) before sending them to the remote side. And it does seem to do that.

                But then it does not send NATed packets into ovpnc1 interface. I ran a sniffer on ovpnc1 interface and no packets were captured while pfsense was pinging 172.29.2.176.

                However, tcpdump started on pfsense's lo0 interface captured this:

                # tcpdump -nn -i lo0
                tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
                listening on lo0, link-type NULL (BSD loopback), capture size 262144 bytes
                17:17:16.620353 IP 127.0.0.1 > 172.29.2.176: ICMP echo request, id 31452, seq 0, length 64
                17:17:16.620430 IP 127.0.0.1 > 172.29.2.176: ICMP echo request, id 31452, seq 0, length 64
                17:17:16.620452 IP 127.0.0.1 > 127.0.0.1: ICMP redirect 172.29.2.176 to host 10.8.1.2, length 36
                17:17:16.620470 IP 127.0.0.1 > 172.29.2.176: ICMP echo request, id 31452, seq 0, length 64
                17:17:16.620486 IP 127.0.0.1 > 127.0.0.1: ICMP redirect 172.29.2.176 to host 10.8.1.2, length 36
                17:17:16.620525 IP 127.0.0.1 > 172.29.2.176: ICMP echo request, id 31452, seq 0, length 64
                ...
                
                V 1 Reply Last reply Reply Quote 0
                • J
                  jazzl0ver @bingo600
                  last edited by

                  @bingo600 I'm sorry I didn't get what you were trying to tell me :(

                  1 Reply Last reply Reply Quote 0
                  • V
                    viragomann @jazzl0ver
                    last edited by

                    @jazzl0ver said in openvpn (site-to-site) routing issue:

                    In my understanding pfsense should NAT outgoing ping packets into the ovpnc1's IP address (10.8.1.2) before sending them to the remote side.

                    Yeah, in this case, the proper routes to the remote site should be sufficient.
                    So the routes are set correctly on the client?

                    J 2 Replies Last reply Reply Quote 0
                    • J
                      jazzl0ver @viragomann
                      last edited by

                      @viragomann said in openvpn (site-to-site) routing issue:

                      So the routes are set correctly on the client?

                      Yep, just double checked it:

                      # netstat -rnW | grep 172.29
                      172.29.0.0/16      10.8.1.2           UGS        3760  16384        lo0
                      

                      Wondering why it the interface is lo0 here, but this is how pfsense set it after configuring thru web gui.

                      V 1 Reply Last reply Reply Quote 0
                      • J
                        jazzl0ver @viragomann
                        last edited by jazzl0ver

                        @viragomann well, that's interesting. I've disabled the static route in the gui and re-created it manually from cli:

                        # route add -net 172.29.0.0/16 10.8.1.1
                        add net 172.29.0.0: gateway 10.8.1.1
                        

                        And the issue has gone!

                        # ping -c 1 172.29.2.176
                        PING 172.29.2.176 (172.29.2.176): 56 data bytes
                        64 bytes from 172.29.2.176: icmp_seq=0 ttl=254 time=116.745 ms
                        
                        --- 172.29.2.176 ping statistics ---
                        1 packets transmitted, 1 packets received, 0.0% packet loss
                        round-trip min/avg/max/stddev = 116.745/116.745/116.745/0.000 ms
                        

                        Do you think it's a bug?

                        V 1 Reply Last reply Reply Quote 0
                        • V
                          viragomann @jazzl0ver
                          last edited by

                          @jazzl0ver
                          Also weird that the route shows the client IP as gateway. Should be the servers which is 10.8.1.1 as you stated.

                          1 Reply Last reply Reply Quote 0
                          • V
                            viragomann @jazzl0ver
                            last edited by

                            @jazzl0ver said in openvpn (site-to-site) routing issue:

                            Do you think it's a bug?

                            I think, you should not use static routes for remote networks across OpenVPN at all as suggested in the docs.

                            The proper way is to add the remote networks into the OpenVPN settings at "Remote network(s)" instead.
                            However, when the server is pushing the routes, there should be nothing necessary, just leave "Don't pull routes" unchecked.

                            J 1 Reply Last reply Reply Quote 0
                            • J
                              jazzl0ver @viragomann
                              last edited by

                              @viragomann I indeed missed that part of the docs. Thank you VERY much!!

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