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

    Strange connectivity problem with OpenVPN Site-to-Site configuration

    Scheduled Pinned Locked Moved OpenVPN
    6 Posts 2 Posters 1.1k 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
      juanespty
      last edited by

      Hi,

      I'm having a strange connectivity problem with an OpenVPN Site-to-Site configuration, that involves four sites (1 Server + 3 Clients). All are running the latest pfSense version.

      Configuration summary:

      OpenVPN Topology:

      • OpenVPN Server:
        • Server - Site A:
          • LAN = 10.30.51.0/24
          • pfSense Router = 10.30.51.1
          • Server mode: Remote Access (SSL/TLS)
      • OpenVPN Clients:
        • Client - Site B:
          • LAN = 10.30.52.0/24
          • pfSense Router = 10.30.52.1
        • Client - Site C:
          • LAN = 10.30.53.0/24
          • pfSense Router = 10.30.53.1
        • Client - Site D:
          • LAN = 10.30.50.0/24
          • pfSense Router = 10.30.50.1

      The client sites subnets are added to the Server router via the OpenVPN Server > Advanced Configuration > Custom Options section:

      route 10.30.50.0 255.255.255.0
route 10.30.52.0 255.255.255.0
route 10.30.53.0 255.255.255.0

      Routing information:

      Server:

      Destination	Gateway	Flags	Use	Mtu	Netif	Expire
default		WAN_IP		UGS	57501	1500	em1	
10.30.50.0/24	10.30.61.2	UGS	0	1500	ovpns1	
10.30.51.0/24	link#1	U	4475598	1500	em0	
10.30.51.1	link#1	UHS	0	16384	lo0	
10.30.52.0/24	10.30.61.2	UGS	0	1500	ovpns1	
10.30.53.0/24	10.30.61.2	UGS	0	1500	ovpns1	
10.30.61.0/24	10.30.61.2	UGS	1856	1500	ovpns1	
10.30.61.1	link#8	UHS	0	16384	lo0	
10.30.61.2	link#8	UH	936	1500	ovpns1	
10.30.61.3	10.30.61.2	UGHS	944	1500	ovpns1	
127.0.0.1	link#5	UH	156312	16384	lo0	
WAN_Subnet/23	link#2	U	6538	1500	em1	
WAN_IP		link#2	UHS	0	16384	lo0

      Client - Site A:

      Destination	Gateway	Flags	Use	Mtu	Netif	Expire
default		WAN_IP	UGS	147996	1500	em1	
10.30.51.0/24	10.30.61.1	UGS	264	1500	ovpnc1	
10.30.52.0/24	link#1	U	477802	1500	em0	
10.30.52.1	link#1	UHS	0	16384	lo0	
10.30.61.0/24	10.30.61.1	UGS	0	1500	ovpnc1	
10.30.61.1	link#8	UH	873	1500	ovpnc1	
10.30.61.3	link#8	UHS	0	16384	lo0	
127.0.0.1	link#4	UH	93	16384	lo0	
WAN_SUBNET/22	link#2	U	19434	1500	em1	
WAN_IP		link#2	UHS	0	16384	lo0

      Client - Site B:

      Destination	Gateway	Flags	Use	Mtu	Netif	Expire
default		WAN_IP	UGS	150150	1500	em1	
10.30.51.0/24	10.30.61.1	UGS	748	1500	ovpnc1	
10.30.52.0/24	link#1	U	495493	1500	em0	
10.30.52.1	link#1	UHS	0	16384	lo0	
10.30.61.0/24	10.30.61.1	UGS	0	1500	ovpnc1	
10.30.61.1	link#8	UH	2120	1500	ovpnc1	
10.30.61.3	link#8	UHS	0	16384	lo0	
127.0.0.1	link#4	UH	93	16384	lo0	
WAN_SUBNET/22	link#2	U	20056	1500	em1	
WAN_IP		link#2	UHS	0	16384	lo0

      Client - Site C:

      Destination	Gateway	Flags	Use	Mtu	Netif	Expire
default		WAN_IP	UGS	13038424	1500	em1	
10.30.50.0/24	link#1	U	210850993	1500	em0	
10.30.50.1	link#1	UHS	0	16384	lo0	
10.30.51.0/24	10.30.61.1	UGS	1140	1500	ovpnc1	
10.30.61.0/24	10.30.61.1	UGS	0	1500	ovpnc1	
10.30.61.1	link#7	UH	930	1500	ovpnc1	
10.30.61.10	link#7	UHS	0	16384	lo0	
127.0.0.1	link#4	UH	40607	16384	lo0	
WAN_Subnet/24	link#2	U	4672460	1500	em1	
WAN_IP		link#2	UHS	0	16384	lo0

      Firewall Rules:

      On all sites, both on the general OpenVPN and Specific OpenVPN rules section all IPv4 traffic is allowed. E.g.:

      States		Protocol	Source	Port	Destination	Port	Gateway	Queue	Schedule	Description	Actions		
2 /2.80 MiB	IPv4 		*	*	*		*	*	*	none	 	Allow all

      Description of the problem:

      Some hosts in the Server LAN (Site A) cannot be contacted (ping or other protocols/ports), from Client Networks, but the strange thing is that this varies depending on which Client is trying to contact them.

      Example:

      Windows Servers on the Site A (OpenVPN Server) LAN:

      • 10.30.51.4
      • 10.30.51.10
      • 10.30.51.11
      • 10.30.51.12

      All of these hosts have 10.30.51.1 (pfSense router) as their gateway.
      They all have the same firewall settings which allow ping requests from any network.

      From Site B, I can ping all the hosts except 10.30.51.11 and 10.30.51.12.
      From Site C, I can ping all the hosts except 10.30.51.12.
      From Site D, I can ping all the hosts

      I tried capturing the packages to see up to which point they get, and it seems as if the pfSense router "refuses" to even try to communicate with these IPs.

      Example 1:

      I started a packet capture for the VPN interface on both sites (Site A = Server, and Site B = Client), and then pinged a host that does respond from the Diagnostics > Ping tool in the Client Site.

      For the host that does respond, the packets are picked up by both packet captures:

      Client packet capture:

      16:01:45.414505 IP 10.30.61.3 > 10.30.51.10: ICMP echo request, id 33330, seq 0, length 64
16:01:45.439284 IP 10.30.51.10 > 10.30.61.3: ICMP echo reply, id 33330, seq 0, length 64
16:01:46.416922 IP 10.30.61.3 > 10.30.51.10: ICMP echo request, id 33330, seq 1, length 64
16:01:46.444217 IP 10.30.51.10 > 10.30.61.3: ICMP echo reply, id 33330, seq 1, length 64
16:01:47.417097 IP 10.30.61.3 > 10.30.51.10: ICMP echo request, id 33330, seq 2, length 64
16:01:47.440953 IP 10.30.51.10 > 10.30.61.3: ICMP echo reply, id 33330, seq 2, length 64

      States section:

      Interface	Protocol	Source			Destination	State	Packets	Bytes
VPNX		icmp		10.30.61.3:56190 ->	10.30.51.10:56190	0:0	2/2	168 B / 168 B

      Server packet capture:

      16:01:45.429513 IP 10.30.61.3 > 10.30.51.10: ICMP echo request, id 33330, seq 0, length 64
16:01:45.430362 IP 10.30.51.10 > 10.30.61.3: ICMP echo reply, id 33330, seq 0, length 64
16:01:46.435699 IP 10.30.61.3 > 10.30.51.10: ICMP echo request, id 33330, seq 1, length 64
16:01:46.436353 IP 10.30.51.10 > 10.30.61.3: ICMP echo reply, id 33330, seq 1, length 64
16:01:47.434454 IP 10.30.61.3 > 10.30.51.10: ICMP echo request, id 33330, seq 2, length 64
16:01:47.435143 IP 10.30.51.10 > 10.30.61.3: ICMP echo reply, id 33330, seq 2, length 64

      States section:

      Interface	Protocol	Source			Destination	State	Packets	Bytes
VPNX		icmp		10.30.61.3:32191 -> 	10.30.51.10:32191	0:0	3/3	252 B / 252 B

      Example 2:

      I started a packet capture for the VPN interface on both sites (Site A = Server, and Site B = Client), and then pinged a host that doesn't respond (10.30.51.11) from the Diagnostics > Ping tool in the Client Site.

      The ping times out and no packages are captured in neither site. No states entries are created in neither site.

      Example 3:

      I started a packet capture for the VPN interface on both sites (Site A = Server, and Site B = Client), and then pinged a host that I know doesn't exist (10.30.51.189) in the Server site, from the Diagnostics > Ping tool in the Client Site.

      No packets are captured, but the state records are created in both sites:

      Client states section:

      Interface	Protocol	Source			Destination	State	Packets	Bytes
VPNX		icmp	10.30.61.3:64706 -> 10.30.51.189:64706	0:0	3 / 0	252 B / 0 B

      Server States section:

      Interface	Protocol	Source			Destination	State	Packets	Bytes
VPNX		icmp	10.30.61.3:64706 -> 10.30.51.189:64706	0:0	3 / 0	252 B / 0 B

      The same behaviour is observed from other sites, but with different hosts.

      So from example #3, we can see that the client site B router tries to reach a non existing host in the server Site B.

      But in example 1, seems like it doesn't even try 🤔

      Any ideas on what could be going on or any additional information needed?

      Thanks!

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

        @juanespty said in Strange connectivity problem with OpenVPN Site-to-Site configuration:

        The client sites subnets are added to the Server router via the OpenVPN Server > Advanced Configuration > Custom Options section:
        route 10.30.50.0 255.255.255.0
        route 10.30.52.0 255.255.255.0
        route 10.30.53.0 255.255.255.0

        How should the server determine, which network is behind which client?

        You have to configure client specific overrides (CSO) for each. There you have to enter the respective clients LAN into the "IPv4 Remote Network/s" field.

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

          Hi @viragomann

          Yes, sorry I didn't clarify. There are already client overrides for each client site, and the specific network is assigned in the IPv4 Remote Network/s field.

          So the IPv4 Remote Network for each site is:

          • Site B: 10.30.52.0/24
          • Site C: 10.30.53.0/24
          • Site D: 10.30.50.0/24

          My understanding is that the routes have to be both at the OpenVPN Server > Advanced Configuration > Custom Options section and also on each client override.

          There's one thing that I don't quite understand.. The OpenVPN Server automatically assigns 10.30.61.2 as the gateway for the OpenVPN Interface. This can be seen on the routes for the OpenVPN Server router. However, this IP is also assigned to the first client that connects to the OpenVPN Server. I tested assigning static IP addresses to each client, to make sure that the 10.30.61.2 IP was no assigned to any client, using the following CSO commands, but it didn't make any difference in the problem I'm experiencing...

          • Client Site B: ifconfig-push 10.30.61.3 255.255.255.0
          • Client Site C: ifconfig-push 10.30.61.4 255.255.255.0
          • Client Site D: ifconfig-push 10.30.61.5 255.255.255.0

          Any other ideas? 😬

          Thanks

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

            Ok, I think I figured it out..

            For the 10.30.51.11 host that was not responding, I noticed that while poking a few days ago with the firewall rules, I had configured a floating firewall rule for this specific IP.. After I deleted this floating rule, this host started responding.. When checking the firewall rules, I didn't even bothered checking the floating rules, since I didn't even remember this rule.. Yes, I'm still banging my head against the wall for this 😒

            For the 10.30.51.12 host, this is a windows server that also acts as a router for another network (two nics and the Routing and Remote Access service running). When I disable the secondary network NIC, it starts pinging. So this is something specific with the Windows configuration, nothing to do with pfSense/OpenVPN..

            @juanespty said in Strange connectivity problem with OpenVPN Site-to-Site configuration:

            There's one thing that I don't quite understand.. The OpenVPN Server automatically assigns 10.30.61.2 as the gateway for the OpenVPN Interface. This can be seen on the routes for the OpenVPN Server router. However, this IP is also assigned to the first client that connects to the OpenVPN Server. I tested assigning static IP addresses to each client, to make sure that the 10.30.61.2 IP was no assigned to any client, using the following CSO commands, but it didn't make any difference in the problem I'm experiencing...

            I still have the question about the 10.30.61.2 gateway IP assigned to the OpenVPN Server interface, and also to the first client that connects.. I would appreciate some explanation for this behavior. I would expect this to be an IP conflict, but OpenVPN doesn't seem to be affected by this..

            Thanks!

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

              @juanespty said in Strange connectivity problem with OpenVPN Site-to-Site configuration:

              For the 10.30.51.12 host, this is a windows server that also acts as a router for another network (two nics and the Routing and Remote Access service running). When I disable the secondary network NIC, it starts pinging. So this is something specific with the Windows configuration, nothing to do with pfSense/OpenVPN..

              Possibly there is network or route overlapping on that interfaces with the remote 10.30.51.0/24.

              I still have the question about the 10.30.61.2 gateway IP assigned to the OpenVPN Server interface, and also to the first client that connects.. I would appreciate some explanation for this behavior. I would expect this to be an IP conflict, but OpenVPN doesn't seem to be affected by this..

              As far as I know this is needed by pfSense to route traffic to OpenVPN.

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

                @viragomann said in Strange connectivity problem with OpenVPN Site-to-Site configuration:

                Possibly there is network or route overlapping on that interfaces with the remote 10.30.51.0/24.

                This is correct. The 10.30.51.12, 10.30.52.12 and 10.30.53.12 hosts are Windows Servers acting as routers for local 192.168.6.0/24 networks. This overlapping is causing the connectivity problem on the VPN when the 192.168.6.0/24 NIC is enabled. I could make this secondary LAN unique in each site so that there is no overlapping, but for now this is Ok.

                @viragomann said in Strange connectivity problem with OpenVPN Site-to-Site configuration:

                As far as I know this is needed by pfSense to route traffic to OpenVPN.

                Ok..

                Well, everything is working fine so far.. Thanks! 😬

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