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

    Site-to-site

    Scheduled Pinned Locked Moved OpenVPN
    40 Posts 4 Posters 4.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.
    • J
      johnied
      last edited by

      OK, while I was pinging from server's LAN (pinging from VPN's interface works ok), I packet captured client's VPN interface (ICMP only) and indeed I captured packets. But when I captured LAN interface no packets were recieved.

      So in order to be clear:
      SERVER PING from VPN INTERFACE–-->CLIENT packet capture on VPN INTERFACE

      16:30:11.577687 IP 10.5.0.2 > 10.5.0.1: ICMP echo request, id 60760, seq 59656, length 8
      16:30:11.581641 IP 10.5.0.1 > 10.5.0.2: ICMP echo request, id 54791, seq 17796, length 8
      16:30:11.581667 IP 10.5.0.2 > 10.5.0.1: ICMP echo reply, id 54791, seq 17796, length 8
      16:30:11.633149 IP 10.5.0.1 > 10.5.0.2: ICMP echo reply, id 60760, seq 59656, length 8
      16:30:12.078581 IP 10.5.0.2 > 10.5.0.1: ICMP echo request, id 60760, seq 59657, length 8
      16:30:12.080301 IP 10.5.0.1 > 10.5.0.2: ICMP echo request, id 54791, seq 17797, length 8
      16:30:12.080326 IP 10.5.0.2 > 10.5.0.1: ICMP echo reply, id 54791, seq 17797, length 8
      16:30:12.250552 IP 10.5.0.1 > 10.5.0.2: ICMP echo reply, id 60760, seq 59657, length 8
      16:30:12.580604 IP 10.5.0.2 > 10.5.0.1: ICMP echo request, id 60760, seq 59658, length 8
      16:30:12.587870 IP 10.5.0.1 > 10.5.0.2: ICMP echo request, id 54791, seq 17798, length 8
      16:30:12.587892 IP 10.5.0.2 > 10.5.0.1: ICMP echo reply, id 54791, seq 17798, length 8

      It seems to reply but my ping fails (100% PACKET LOSS)

      SERVER PING from LAN INTERFACE  ---->CLIENT packet capture on VPN INTERFACE

      18:07:04.700947 IP 10.5.0.1 > 10.5.0.2: ICMP echo request, id 54791, seq 29354, length 8
      18:07:04.700969 IP 10.5.0.2 > 10.5.0.1: ICMP echo reply, id 54791, seq 29354, length 8
      18:07:04.820259 IP 10.5.0.2 > 10.5.0.1: ICMP echo request, id 60760, seq 9629, length 8
      18:07:04.875810 IP 10.5.0.1 > 10.5.0.2: ICMP echo reply, id 60760, seq 9629, length 8

      Exactly the same. It seems to reply but ping fails.

      SERVER PING from LAN INTERFACE ---->CLIENT packet capture on LAN INTERFACE
      Nothing gets captured.

      SERVER PING from VPN INTERFACE ---->CLIENT packet capture on LAN INTERFACE
      Nothing gets captured.

      I am posting the LAN Firewall Rules on Client.

      So if rules are allow all from any to any protocol on client's LAN, why can't I ping anything from the server's LAN to client's LAN.
      What am I doing wrong here?

      ![PING problem.png](/public/imported_attachments/1/PING problem.png)
      ![PING problem.png_thumb](/public/imported_attachments/1/PING problem.png_thumb)

      1 Reply Last reply Reply Quote 0
      • J
        johnied
        last edited by

        Of course I am not pinging VPN tunnel IPs but client's LAN IPs. This is not visible on the packet capture logs.

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

          I guess you have messed up your NAT.  ???
          To illuminate this, please post all your NAT rules (port forwarding, 1:1, outbound) from server an client.

          1 Reply Last reply Reply Quote 0
          • J
            johnied
            last edited by

            OK here are the attachments.
            Npt and 1:1 are black in both routers.

            NAT is in Hybrid mode.

            I am grateful for your time.
            Thank you,

            ![SERVER Port Fw and 1-1 and Outbound.png](/public/imported_attachments/1/SERVER Port Fw and 1-1 and Outbound.png)
            ![SERVER Port Fw and 1-1 and Outbound.png_thumb](/public/imported_attachments/1/SERVER Port Fw and 1-1 and Outbound.png_thumb)
            ![CLIENT Port Fw and 1-1.png](/public/imported_attachments/1/CLIENT Port Fw and 1-1.png)
            ![CLIENT Port Fw and 1-1.png_thumb](/public/imported_attachments/1/CLIENT Port Fw and 1-1.png_thumb)
            ![CLIENT Outbound.png](/public/imported_attachments/1/CLIENT Outbound.png)
            ![CLIENT Outbound.png_thumb](/public/imported_attachments/1/CLIENT Outbound.png_thumb)

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

              @johnied:

              SERVER PING from LAN INTERFACE  –-->CLIENT packet capture on VPN INTERFACE

              18:07:04.700947 IP 10.5.0.1 > 10.5.0.2: ICMP echo request, id 54791, seq 29354, length 8
              18:07:04.700969 IP 10.5.0.2 > 10.5.0.1: ICMP echo reply, id 54791, seq 29354, length 8
              18:07:04.820259 IP 10.5.0.2 > 10.5.0.1: ICMP echo request, id 60760, seq 9629, length 8
              18:07:04.875810 IP 10.5.0.1 > 10.5.0.2: ICMP echo reply, id 60760, seq 9629, length 8

              If the source address of ping is LAN there should be shown ICMP requests from coming from 192.168.1.1.
              I can find no reason in your NAT rules why the address should be translated.

              @johnied:

              SERVER PING from VPN INTERFACE–-->CLIENT packet capture on VPN INTERFACE

              16:30:11.577687 IP 10.5.0.2 > 10.5.0.1: ICMP echo request, id 60760, seq 59656, length 8
              16:30:11.581641 IP 10.5.0.1 > 10.5.0.2: ICMP echo request, id 54791, seq 17796, length 8
              16:30:11.581667 IP 10.5.0.2 > 10.5.0.1: ICMP echo reply, id 54791, seq 17796, length 8
              16:30:11.633149 IP 10.5.0.1 > 10.5.0.2: ICMP echo reply, id 60760, seq 59656, length 8
              It seems to reply but my ping fails (100% PACKET LOSS)

              This capture shown ping requests from the client to the server, not backwards.  ???

              I think all the pings shown here come from gateway monitoring (dpinger). To get a feasible outcome you should deactivate gateway monitoring on the vpn GWs in System > Routing > Gateways and rerun the test.

              1 Reply Last reply Reply Quote 0
              • J
                johnied
                last edited by

                OK, after disabling Gateway Monitoring(Checked the box Disable Gateway Monitoring), and disabling the reverse test connection(server as client, client as server, different tunnel network) here are the results:

                SERVER VPN INT to CLIENT VPN INT:
                Nothing gets captured.

                CLIENT VPN INT to SERVER VPN INT:
                20:16:08.987196 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 38425, seq 0, length 64
                20:16:08.987779 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 38425, seq 0, length 64
                20:16:10.045360 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 38425, seq 1, length 64
                20:16:10.045857 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 38425, seq 1, length 64

                CLIENT LAN INT to SERVER VPN INT:
                Nothing gets captured.

                CLIENT VPN INT to SERVER LAN INT:
                20:17:30.889581 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 156, seq 0, length 192
                20:17:30.889655 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 156, seq 0, length 192
                20:17:33.177124 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 46688, seq 0, length 64
                20:17:33.177610 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 46688, seq 0, length 64
                20:17:34.236385 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 46688, seq 1, length 64
                20:17:34.236938 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 46688, seq 1, length 64
                20:17:35.297149 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 46688, seq 2, length 64
                20:17:35.298138 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 46688, seq 2, length 64
                20:17:35.957371 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 156, seq 0, length 192
                20:17:35.957446 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 156, seq 0, length 192

                After that test I tried setting both outbound NATs to manual and deleting all the mappings. Then switched back to Hybrid NAT on both. Exactly the same results.

                Of course I have backed up both, before deleting outbound NAT rules.

                1 Reply Last reply Reply Quote 0
                • J
                  johnied
                  last edited by

                  I am attaching the NAT rules now.

                  ![SERVER NAT.png](/public/imported_attachments/1/SERVER NAT.png)
                  ![SERVER NAT.png_thumb](/public/imported_attachments/1/SERVER NAT.png_thumb)
                  ![CLIENT NAT.png](/public/imported_attachments/1/CLIENT NAT.png)
                  ![CLIENT NAT.png_thumb](/public/imported_attachments/1/CLIENT NAT.png_thumb)

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

                    It also matters where the captures are taken from, client or server, vpn or LAN?

                    @johnied:

                    CLIENT VPN INT to SERVER VPN INT:
                    20:16:08.987196 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 38425, seq 0, length 64
                    20:16:08.987779 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 38425, seq 0, length 64
                    20:16:10.045360 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 38425, seq 1, length 64
                    20:16:10.045857 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 38425, seq 1, length 64

                    This show pings from the clients vpn interface to a server sides LAN device.

                    @johnied:

                    CLIENT VPN INT to SERVER LAN INT:
                    20:17:30.889581 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 156, seq 0, length 192
                    20:17:30.889655 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 156, seq 0, length 192
                    20:17:33.177124 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 46688, seq 0, length 64
                    20:17:33.177610 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 46688, seq 0, length 64
                    20:17:34.236385 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 46688, seq 1, length 64
                    20:17:34.236938 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 46688, seq 1, length 64
                    20:17:35.297149 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 46688, seq 2, length 64
                    20:17:35.298138 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 46688, seq 2, length 64
                    20:17:35.957371 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 156, seq 0, length 192
                    20:17:35.957446 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 156, seq 0, length 192

                    Same here. Were you pinging 192.168.1.201?

                    1 Reply Last reply Reply Quote 0
                    • J
                      johnied
                      last edited by

                      Yes, both lans have a test machine always open and their ips end with 201.
                      So for client's lan this is 192.168.0.201.
                      For server's lan 192.168.1.201.

                      But I can't understand.
                      If NATs are back to default, gateways are normal, routes are normal, why can't I ping from the one LAN to the other and vice versa.

                      This is getting so frustrating.

                      I even tried to set a Client Specific Override, but no luck.
                      I actually doubt that this was right, because my client's VPN int ended up getting 10.5.0.0 as an IP.  :'(

                      I am also attaching the server routes just in case you see something odd.

                      My priority right now is to be able to see client's net from server's net.
                      And I too far from that.

                      Thanks again for your concern, I am really grateful.

                      ![Server Routes.png](/public/imported_attachments/1/Server Routes.png)
                      ![Server Routes.png_thumb](/public/imported_attachments/1/Server Routes.png_thumb)

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

                        That is the clients routing table, not the servers.

                        Unless you tell me where the packets taken from, there is no way to interpret the captures correctly.

                        1 Reply Last reply Reply Quote 0
                        • J
                          johnied
                          last edited by

                          Yes I am sorry the client's routes.

                          Unless you tell me where the packets taken from, there is no way to interpret the captures correctly.

                          What do you mean? I perform ICMP Diagnostics->Packet Capture on the one router,and Diagnostics->Ping on the other router from the interfaces I describe in the header of every capture.

                          What am I missing?

                          From Server router Ping fails from every interface. VPN and LAN.

                          From Client router Ping fails from LAN but succeeds from VPN interface.

                          Something that occured to me: Both VPN interfaces (server and client) are using LAN as interface. Does this pose any threat?

                          1 Reply Last reply Reply Quote 0
                          • J
                            johnied
                            last edited by

                            Also when I run both site-to-site VPN connections, where in the first:
                            A router is server, B router is client.
                            And in the second(which was created for testing):
                            A router is client, B router is server.

                            Both routers behave the same. I can ping from vpn interfaces to the others LAN, but not from their LAN interfaces to the other LAN.

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

                              @johnied:

                              What do you mean? I perform ICMP Diagnostics->Packet Capture on the one router,and Diagnostics->Ping on the other router from the interfaces I describe in the header of every capture.

                              On which interface have you taken the capture? VPN?

                              @johnied:

                              Something that occured to me: Both VPN interfaces (server and client) are using LAN as interface. Does this pose any threat?

                              ???
                              @johnied:

                              CLIENT VPN INT to SERVER VPN INT:
                              20:16:08.987196 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 38425, seq 0, length 64
                              20:16:08.987779 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 38425, seq 0, length 64
                              20:16:10.045360 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 38425, seq 1, length 64
                              20:16:10.045857 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 38425, seq 1, length 64

                              This shows the client vpn ip pinging to a servers LAN device.

                              The same as here:
                              @johnied:

                              CLIENT VPN INT to SERVER LAN INT:
                              20:17:30.889581 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 156, seq 0, length 192
                              20:17:30.889655 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 156, seq 0, length 192
                              20:17:33.177124 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 46688, seq 0, length 64
                              20:17:33.177610 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 46688, seq 0, length 64
                              20:17:34.236385 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 46688, seq 1, length 64
                              20:17:34.236938 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 46688, seq 1, length 64
                              20:17:35.297149 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 46688, seq 2, length 64
                              20:17:35.298138 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 46688, seq 2, length 64
                              20:17:35.957371 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 156, seq 0, length 192
                              20:17:35.957446 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 156, seq 0, length 192

                              Obviously taken on the servers LAN interface. I wonder why 192.168.1.2 is pinging the LAN at the same time.

                              1 Reply Last reply Reply Quote 0
                              • J
                                johnied
                                last edited by

                                Obviously taken on the servers LAN interface. I wonder why 192.168.1.2 is pinging the LAN at the same time.

                                192.168.1.2 is just a wifi Access Point which checks if it has access to the gateway. It's not important. I should not have posted it.

                                On which interface have you taken the capture? VPN?

                                Both VPN interfaces and LAN interfaces. I clarify it in the line before the capture logs every time.

                                This shows the client vpn ip pinging to a servers LAN device.

                                Yes, because I don't get any packets captured when I am pinging from the LAN interface.
                                I only capture packets, when I am pinging from the VPN interface.
                                And only from the client router.

                                From the Server I can't ping from LAN or VPN interface. Both fail.

                                1 Reply Last reply Reply Quote 0
                                • J
                                  johnied
                                  last edited by

                                  Ok, I think I am close to my goal.
                                  I dismissed the idea of Peer to Peer(SSL/TLS) and went on to create a Peer to Peer(Shared Key) connection.

                                  Now I can ping from the Client LAN to the Server lan flawlessly.

                                  What I cant't do is ping from the Server LAN to the client LAN.

                                  I packet captured the client lan interface when ping from server lan interface and although I see the packet requests, there is no reply.

                                  The client packet capture logs on the LAN interface read:

                                  01:07:48.438501 IP 192.168.1.1 > 192.168.0.201: ICMP echo request, id 9946, seq 0, length 64
                                  01:07:49.432827 IP 192.168.1.1 > 192.168.0.201: ICMP echo request, id 9946, seq 1, length 64
                                  01:07:50.434429 IP 192.168.1.1 > 192.168.0.201: ICMP echo request, id 9946, seq 2, length 64

                                  and I am attaching the server ping procedure that had the above as a result.

                                  This must be a NAT issue isn't that right?

                                  ![Server Ping.png](/public/imported_attachments/1/Server Ping.png)
                                  ![Server Ping.png_thumb](/public/imported_attachments/1/Server Ping.png_thumb)

                                  1 Reply Last reply Reply Quote 0
                                  • J
                                    johnied
                                    last edited by

                                    I can ping from Server LAN only the Client's LAN IP.
                                    I cannot ping any other device on the Network.

                                    Since Client's router is not the gateway of the whole network yes, I tried adding an Outbound NAT rule like the image attached.

                                    No luck however.

                                    If the client VPN is running on a Wan interface and not on a LAN, should the NAT rule use the WAN or the LAN interface?

                                    ![NAT rule client.png](/public/imported_attachments/1/NAT rule client.png)
                                    ![NAT rule client.png_thumb](/public/imported_attachments/1/NAT rule client.png_thumb)

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

                                      I dismissed the idea of Peer to Peer(SSL/TLS) and went on to create a Peer to Peer(Shared Key) connection.

                                      Now I can ping from the Client LAN to the Server lan flawlessly.

                                      This is because you had the tunnel network as a /24.

                                      When you have an SSL/TLS OpenVPN server with a larger than /30 (or is it /29?) tunnel network it will be treated as a point-to-multipoint server instead of point-to-point. You must add the remote network to the server configuration, which creates the kernel route (OpenVPN route directive) into OpenVPN. You must also create a client-specific override and add the network to the Remote Networks which creates a route internal to OpenVPN (OpenVPN iroute directive) so OpenVPN knows which endpoint to send the traffic to. You must do this even if there is only one available endpoint. If you do not want to have to do this, make the tunnel network a /30.

                                      The client packet capture logs on the LAN interface read:

                                      01:07:48.438501 IP 192.168.1.1 > 192.168.0.201: ICMP echo request, id 9946, seq 0, length 64
                                      01:07:49.432827 IP 192.168.1.1 > 192.168.0.201: ICMP echo request, id 9946, seq 1, length 64
                                      01:07:50.434429 IP 192.168.1.1 > 192.168.0.201: ICMP echo request, id 9946, seq 2, length 64

                                      If that can ping the other way that is almost always the local firewall/antivirus/etc on the target that is 192.168.0.201. pfSense can't do much but send the request (which it is doing) and wait for the reply (which never comes).

                                      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
                                      • J
                                        johnied
                                        last edited by

                                        If that can ping the other way that is almost always the local firewall/antivirus/etc on the target that is 192.168.0.201. pfSense can't do much but send the request (which it is doing) and wait for the reply (which never comes).

                                        Reply never comes when I ping from server's LAN interface.
                                        It replies normally when I ping from server's VPN interface.

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

                                          Great. So check the firewall/antivirus/etc on 192.168.0.201. It looks like it is blocking pings.

                                          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
                                          • J
                                            johnied
                                            last edited by

                                            I don't understand.

                                            192.168.0.201 is on the client's network.
                                            I checked and the firewall is off.
                                            So when I ping from the server's LAN interface it is not responding.
                                            When I ping from the server's VPN interface it responds normally.

                                            The client's router is not the main gateway of the client's network yet. I tried NATing the whole network but it does not work.

                                            NATing the network works only for the VPN server on the client's computer which is for remote administration only(not site-to-site).

                                            Should I add a static route to the specific PC(192.168.0.201) till I make the pfsense router the default gateway?

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