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

    Site-to-site tunnel up but devices from other site not reachable (route to WAN?)

    Scheduled Pinned Locked Moved OpenVPN
    6 Posts 2 Posters 2.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.
    • Z
      Zulucon
      last edited by

      I have set up a OpenVPN site-to-site tunnel following this guide exactly: https://doc.pfsense.org/index.php/OpenVPN_Site_To_Site

      Now the tunnel is marked as "up" but I cannot reach anything from the other subnets. To me it looks like there are no routes but obviously I have set "IPv4 Remote networks" on both sides to reflect the subnet of the remote site. As the guide has no other mentions I'd assume this is enough however, when I look in "Diagnostics / Routes" there are no routes to the remote site subnets. Should they show up here? The remote site pfSense tunnel IP does show up here and is pingable:

      10.8.10.2	link#7	UH	3	1500	ovpns1
      

      Gateways on clients in both subnets are correct. Here are some characteristics of the situation:

      Setup:

      pfSense A wan: 1.1.1.1 (example)
      pfSense B wan: 2.2.2.2 (example)

      A OpenVPN (server) tunnel IP: 10.8.10.1
      B OpenVPN (client) tunnel IP: 10.8.10.2
      Both OpenVPN tunnel network: 10.8.10.0/30

      A LAN Subnet (configured on B "IPv4 Remote networks"): 10.0.10.0/24
      B LAN Subnet (configured on A "IPv4 Remote networks"): 10.0.11.0/24

      A LAN IP: 10.0.10.250
      B LAN IP: 10.0.10.250

      Pings and traces:

      On A: ping 10.8.10.2    works!
      On B: ping 10.8.10.1    works!

      On A: ping 10.0.11.250  timeout
      On B: ping 10.0.10.250  timeout

      On some client in subnet A:

      traceroute to 10.0.11.250 (10.0.11.250), 30 hops max, 60 byte packets
       1  pfSenseA (10.0.10.250)  0.317 ms  0.287 ms  0.278 ms
       2  datacenter-gw-which-is-default-gw-of-pfSenseA (WAN-IP) 0.881 ms  0.886 ms  0.874 ms
       3  datacenter-some-core-router (WAN-IP) 0.838 ms  0.815 ms  0.809 ms
       4  datacenter-seemingly-exit-router (WAN-IP) 3.445 ms  3.429 ms  3.409 ms
       5  * * *
      [...]
      30  * * *
      

      I found more posts with similar problems but never with a real clue. In the traceroute obviously there is a routing problem from hop 1 to 2 but why? Shouldn't the traffic go through OpenVPN when the tunnel is up and "IPv4 Remote networks" are configured?

      Any help would be welcome!

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

        What tell the OpenVPN Logs?

        1 Reply Last reply Reply Quote 0
        • Z
          Zulucon
          last edited by

          Not sure for what I should look in it. I don't see anything related to the subnets. A and B logs look very similar only in B there are some parts with "No route to host (code=65)" which is cryptic to me. Therefore I'll just post B (complete openvpn log output after the latest restart):

          Feb 6 19:25:48	openvpn	6610	Initialization Sequence Completed
          Feb 6 19:25:48	openvpn	6610	WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
          Feb 6 19:25:48	openvpn	6610	Peer Connection Initiated with [AF_INET]1.1.1.1:51194
          Feb 6 19:25:41	openvpn	6610	write UDPv4: No route to host (code=65)
          Feb 6 19:25:40	openvpn	6610	write UDPv4: No route to host (code=65)
          Feb 6 19:25:40	openvpn	6610	write UDPv4: No route to host (code=65)
          Feb 6 19:25:40	openvpn	6610	UDPv4 link remote: [AF_INET]1.1.1.1:51194
          Feb 6 19:25:40	openvpn	6610	UDPv4 link local (bound): [AF_INET]2.2.2.2:0
          Feb 6 19:25:40	openvpn	6610	TCP/UDP: Preserving recently used remote address: [AF_INET]1.1.1.1:51194
          Feb 6 19:25:40	openvpn	6610	/usr/local/sbin/ovpn-linkup ovpnc1 1500 1572 10.8.10.2 10.8.10.1 init
          Feb 6 19:25:40	openvpn	6610	/sbin/ifconfig ovpnc1 10.8.10.2 10.8.10.1 mtu 1500 netmask 255.255.255.255 up
          Feb 6 19:25:40	openvpn	6610	do_ifconfig, tt->did_ifconfig_ipv6_setup=0
          Feb 6 19:25:40	openvpn	6610	ioctl(TUNSIFMODE): Device busy (errno=16)
          Feb 6 19:25:40	openvpn	6610	TUN/TAP device /dev/tun1 opened
          Feb 6 19:25:40	openvpn	6610	TUN/TAP device ovpnc1 exists previously, keep at program end
          Feb 6 19:25:40	openvpn	6610	GDG: problem writing to routing socket
          Feb 6 19:25:40	openvpn	6610	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
          Feb 6 19:25:40	openvpn	6408	library versions: OpenSSL 1.0.2m-freebsd 2 Nov 2017, LZO 2.10
          Feb 6 19:25:40	openvpn	6408	OpenVPN 2.4.4 amd64-portbld-freebsd11.1 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Nov 16 2017
          Feb 6 19:25:40	openvpn	6408	disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
          

          Edit: Maybe "GDG: problem writing to routing socket" can give some clue? It is also present in A…

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

            Are you using TAP devices in the OpenVPN settings?

            1 Reply Last reply Reply Quote 0
            • Z
              Zulucon
              last edited by

              no, I really followed the guide 1:1 (unless I made a mistake but I just rechecked and it is tun on both).

              1 Reply Last reply Reply Quote 0
              • Z
                Zulucon
                last edited by

                meh, after some further fun trail and error I found the problem. There was an old and disabled IPSec rule in conflicting subnet range. It looks like also it was disabled and definitely offline it still hindered OpenVPN to add its routes. After deleting it completely and another restart site-to-site works. And for further reference: yes, now also the routes to the remote OpenVPN subnets show up in "Diagnostics / Routes".

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