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

    Unable to connect to WAN when connecting from Client to OpenVPN server.

    Scheduled Pinned Locked Moved
    OpenVPN
    4
    28
    1.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.
    • I
      ianh @viragomann
      last edited by

      @viragomann

      results from ping test

      C:\Users\IanHarwood>ping 8.8.8.8

      Pinging 8.8.8.8 with 32 bytes of data:
      Request timed out.
      Request timed out.
      Request timed out.
      Request timed out.

      Ping statistics for 8.8.8.8:
      Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

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

        @ianh said in Unable to connect to WAN when connecting from Client to OpenVPN server.:

        This is the outbound rule for OpenVPN tunnel

        Dude, you need an outbound NAT rule for the source of the OpenVPN tunnel network on the WAN interface!
        I mentioned that already. Also that the outbound NAT on the VPN interface is useless in your case!

        Outbound NAT is to be set on interfaces where the traffic is going out!
        The vpn clients traffic is coming in on the OpenVPN interface and is going out on WAN. For getting responses back to the WAN IP, the source address in the outgoing packets has to be translated into the interface address. That is the job of the outbound NAT.

        I 1 Reply Last reply Reply Quote 0
        • I
          ianh @viragomann
          last edited by

          @viragomann

          I am sorry I misunderstood your previous comment, as this NAT rule seem to be vital for this working can you give me some guidance as to how this should be configured?

          You mention the following:

          For getting responses back to the WAN IP, the source address in the outgoing packets has to be translated into the interface address. That is the job of the outbound NAT.

          With this in mind I have configuered the NAT rule as follows:

          1de5c146-e09a-432f-93d0-6db786a5e9e0-image.png

          What should I put for the interface?

          86c84955-c09a-4489-b224-1956cc316455-image.png

          With this configuration still the traffic does not route and as far as I can tell the Routing table does not change on the client:

          IPv4 Route Table

          Active Routes:
          Network Destination Netmask Gateway Interface Metric
          0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.33 45
          0.0.0.0 128.0.0.0 10.3.200.1 10.3.200.2 281
          10.3.200.0 255.255.255.0 On-link 10.3.200.2 281
          10.3.200.2 255.255.255.255 On-link 10.3.200.2 281
          10.3.200.255 255.255.255.255 On-link 10.3.200.2 281
          95.154.192.200 255.255.255.255 192.168.0.1 192.168.0.33 301
          127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
          127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
          127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
          128.0.0.0 128.0.0.0 10.3.200.1 10.3.200.2 281
          192.168.0.0 255.255.255.0 On-link 192.168.0.33 301
          192.168.0.33 255.255.255.255 On-link 192.168.0.33 301
          192.168.0.255 255.255.255.255 On-link 192.168.0.33 301
          224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
          224.0.0.0 240.0.0.0 On-link 10.3.200.2 281
          224.0.0.0 240.0.0.0 On-link 192.168.0.33 301
          255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
          255.255.255.255 255.255.255.255 On-link 10.3.200.2 281
          255.255.255.255 255.255.255.255 On-link 192.168.0.33 301

          Persistent Routes:
          None

          Tnx.

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

            @ianh
            The NAT rule is okay now. Ensure that the Outbound NAT is working in hybrid or manual mode.

            If you have no love anyway, you have to do some troubleshooting. You the packet capture tool on pfSense to sniff the traffic on the respective interfaces.

            Select the WAN interface and ICMP protocol and enter 8.8.8.8 at host, then start the capture and try a ping on the client to 8.8.8.8. Stop it and check the result.
            If there is nothing switch to the OpenVPN interface and try again.
            Post the results, please.

            I 1 Reply Last reply Reply Quote 0
            • I
              ianh @viragomann
              last edited by

              @viragomann

              I have taken the packet capture and do not see anything in particular in wireshark other than:

              This is for the WAN inteface

              4 14.587045 10.3.200.2 8.8.8.8 ICMP 74 Echo (ping) request id=0x0001, seq=36/9216, ttl=127 (no response found!)

              Frame 4: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
              Encapsulation type: Ethernet (1)
              Arrival Time: Jan 6, 2021 14:19:46.475145000 GMT Standard Time
              [Time shift for this packet: 0.000000000 seconds]
              Epoch Time: 1609942786.475145000 seconds
              [Time delta from previous captured frame: 5.002190000 seconds]
              [Time delta from previous displayed frame: 5.002190000 seconds]
              [Time since reference or first frame: 14.587045000 seconds]
              Frame Number: 4
              Frame Length: 74 bytes (592 bits)
              Capture Length: 74 bytes (592 bits)
              [Frame is marked: False]
              [Frame is ignored: False]
              [Protocols in frame: eth:ethertype:ip:icmp:data]
              [Coloring Rule Name: ICMP]
              [Coloring Rule String: icmp || icmpv6]
              Ethernet II, Src: Xensourc_81:51:b7 (00:16:3e:81:51:b7), Dst: Cisco_d1:a3:e9 (00:62:ec:d1:a3:e9)
              Destination: Cisco_d1:a3:e9 (00:62:ec:d1:a3:e9)
              Source: Xensourc_81:51:b7 (00:16:3e:81:51:b7)
              Type: IPv4 (0x0800)
              Internet Protocol Version 4, Src: 10.3.200.2, Dst: 8.8.8.8
              0100 .... = Version: 4
              .... 0101 = Header Length: 20 bytes (5)
              Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
              Total Length: 60
              Identification: 0xb498 (46232)
              Flags: 0x00
              Fragment Offset: 0
              Time to Live: 127
              Protocol: ICMP (1)
              Header Checksum: 0xa513 [validation disabled]
              [Header checksum status: Unverified]
              Source Address: 10.3.200.2
              Destination Address: 8.8.8.8
              Internet Control Message Protocol
              Type: 8 (Echo (ping) request)
              Code: 0
              Checksum: 0x4d37 [correct]
              [Checksum Status: Good]
              Identifier (BE): 1 (0x0001)
              Identifier (LE): 256 (0x0100)
              Sequence Number (BE): 36 (0x0024)
              Sequence Number (LE): 9216 (0x2400)
              [No response seen]
              Data (32 bytes)

              This is for the OpenVPN interface

              1 0.000000 10.3.200.2 8.8.8.8 ICMP 64 Echo (ping) request id=0x0001, seq=39/9984, ttl=128 (no response found!)

              Frame 1: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)
              Encapsulation type: NULL/Loopback (15)
              Arrival Time: Jan 6, 2021 14:23:05.964157000 GMT Standard Time
              [Time shift for this packet: 0.000000000 seconds]
              Epoch Time: 1609942985.964157000 seconds
              [Time delta from previous captured frame: 0.000000000 seconds]
              [Time delta from previous displayed frame: 0.000000000 seconds]
              [Time since reference or first frame: 0.000000000 seconds]
              Frame Number: 1
              Frame Length: 64 bytes (512 bits)
              Capture Length: 64 bytes (512 bits)
              [Frame is marked: False]
              [Frame is ignored: False]
              [Protocols in frame: null:ip:icmp:data]
              [Coloring Rule Name: ICMP]
              [Coloring Rule String: icmp || icmpv6]
              Null/Loopback
              Internet Protocol Version 4, Src: 10.3.200.2, Dst: 8.8.8.8
              0100 .... = Version: 4
              .... 0101 = Header Length: 20 bytes (5)
              Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
              Total Length: 60
              Identification: 0x2852 (10322)
              Flags: 0x00
              Fragment Offset: 0
              Time to Live: 128
              Protocol: ICMP (1)
              Header Checksum: 0x305a [validation disabled]
              [Header checksum status: Unverified]
              Source Address: 10.3.200.2
              Destination Address: 8.8.8.8
              Internet Control Message Protocol
              Type: 8 (Echo (ping) request)
              Code: 0
              Checksum: 0x4d34 [correct]
              [Checksum Status: Good]
              Identifier (BE): 1 (0x0001)
              Identifier (LE): 256 (0x0100)
              Sequence Number (BE): 39 (0x0027)
              Sequence Number (LE): 9984 (0x2700)
              [No response seen]
              Data (32 bytes)

              Tnx.

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

                @ianh
                What is this??
                I was asking for the simple capture result with default options!

                I NogBadTheBadN 2 Replies Last reply Reply Quote 0
                • I
                  ianh @viragomann
                  last edited by

                  @viragomann it is the result with default options.

                  I tried to upload to the forum but it would not accept the .cap files.

                  So I opened in wireshark and copied the results here...

                  Not sure how else you want me to display this?

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

                    @viragomann looks like its being run under virtualization, check the MAC address.

                    Andy

                    1 x Netgate SG-4860 - 3 x Linksys LGS308P - 1 x Aruba InstantOn AP22

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

                      @ianh said in Unable to connect to WAN when connecting from Client to OpenVPN server.:

                      Not sure how else you want me to display this?

                      Simply copy and paste the result here. Enclose it in a code frame for readability.

                      I 1 Reply Last reply Reply Quote 0
                      • I
                        ianh @viragomann
                        last edited by

                        @viragomann Tnx for your help in trying to get this sorted. There was an additional layer to this problem which was as @NogBadTheBad stated the pfsense server is a VM.

                        Long story short once we had rolled out a new OPENvpn server and chosen Automated NAT rules the connection is working and as we wanted all traffic is being routed via the VPN tunnel :)

                        Unknown adapter OpenVPN TAP-Windows6:

                        Connection-specific DNS Suffix . : paacvpn
                        Description . . . . . . . . . . . : TAP-Windows Adapter V9
                        Physical Address. . . . . . . . . : 00-FF-A3-2E-4B-10
                        DHCP Enabled. . . . . . . . . . . : Yes
                        Autoconfiguration Enabled . . . . : Yes
                        Link-local IPv6 Address . . . . . : fe80::419:140e:1684:a44b%17(Preferred)
                        IPv4 Address. . . . . . . . . . . : 10.3.200.2(Preferred)
                        Subnet Mask . . . . . . . . . . . : 255.255.255.0
                        Lease Obtained. . . . . . . . . . : 15 January 2021 16:43:21
                        Lease Expires . . . . . . . . . . : 15 January 2022 16:43:21
                        Default Gateway . . . . . . . . . :
                        DHCP Server . . . . . . . . . . . : 10.3.200.254
                        DHCPv6 IAID . . . . . . . . . . . : 285278115
                        DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-27-52-C3-D6-1C-1A-DF-B0-ED-33
                        DNS Servers . . . . . . . . . . . : 8.8.8.8
                        8.8.4.4
                        1.1.1.1
                        NetBIOS over Tcpip. . . . . . . . : Enabled

                        C:\WINDOWS\system32>ping google.com

                        Pinging google.com [216.58.198.174] with 32 bytes of data:
                        Reply from 216.58.198.174: bytes=32 time=25ms TTL=117
                        Reply from 216.58.198.174: bytes=32 time=24ms TTL=117
                        Reply from 216.58.198.174: bytes=32 time=27ms TTL=117
                        Reply from 216.58.198.174: bytes=32 time=25ms TTL=117

                        Ping statistics for 216.58.198.174:
                        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
                        Approximate round trip times in milli-seconds:
                        Minimum = 24ms, Maximum = 27ms, Average = 25ms

                        C:\WINDOWS\system32>tracert google.com

                        Tracing route to google.com [216.58.198.174]
                        over a maximum of 30 hops:

                        1 25 ms 24 ms 26 ms 10.3.200.1
                        2 22 ms * 24 ms 95.154.192.1
                        3 25 ms 23 ms 26 ms 109.169.17.190
                        4 25 ms 24 ms 22 ms po201.net2.north.dc5.as20860.net [84.22.173.154]
                        5 26 ms 24 ms 23 ms be256.asr02.dc5.as20860.net [130.180.203.7]
                        6 40 ms 25 ms 22 ms be256.asr01.ld5.as20860.net [130.180.202.46]
                        7 26 ms 25 ms 24 ms 72.14.219.214
                        8 24 ms 24 ms 24 ms 108.170.246.129
                        9 38 ms 34 ms 23 ms 108.170.232.97
                        10 25 ms 23 ms 25 ms lhr25s10-in-f14.1e100.net [216.58.198.174]

                        Trace complete.

                        So thanks for your patience in trying to guide me to a solution.

                        All the best!

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post