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
    28 Posts 4 Posters 1.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.
    • V
      viragomann @ianh
      last edited by

      @ianh
      Is the outbound NAT rule for the OpenVPN tunnel network still in place?

      Does the client connect without issues? Something in the log on client or server?

      Show the clients routing table.

      Try to ping 8.8.8.8 from the client.

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

        @viragomann

        This is the outbound rule for OpenVPN tunnel

        2f49f316-9e29-40a8-a9c1-e5d4e4e71797-image.png

        This is the log from the client the connection shows no errors and this is the routing table:

        2021-01-06 12:07:41 OpenVPN 2.5.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 28 2020
        2021-01-06 12:07:41 Windows version 10.0 (Windows 10 or greater) 64bit
        2021-01-06 12:07:41 library versions: OpenSSL 1.1.1h 22 Sep 2020, LZO 2.10
        Enter Management Password:
        2021-01-06 12:07:48 TCP/UDP: Preserving recently used remote address: [AF_INET]95.154.192.200:1194
        2021-01-06 12:07:48 UDPv4 link local (bound): [AF_INET][undef]:1194
        2021-01-06 12:07:48 UDPv4 link remote: [AF_INET]95.154.192.200:1194
        2021-01-06 12:07:48 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
        2021-01-06 12:07:49 [mercury.paac-it.com] Peer Connection Initiated with [AF_INET]95.154.192.200:1194
        2021-01-06 12:07:50 open_tun
        2021-01-06 12:07:50 tap-windows6 device [OpenVPN TAP-Windows6] opened
        2021-01-06 12:07:50 Set TAP-Windows TUN subnet mode network/local/netmask = 10.3.200.0/10.3.200.2/255.255.255.0 [SUCCEEDED]
        2021-01-06 12:07:50 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.3.200.2/255.255.255.0 on interface {A2C4D3E6-3922-4706-8943-83589ECC4E95} [DHCP-serv: 10.3.200.254, lease-time: 31536000]
        2021-01-06 12:07:50 Successful ARP Flush on interface [17] {A2C4D3E6-3922-4706-8943-83589ECC4E95}
        2021-01-06 12:07:50 IPv4 MTU set to 1500 on interface 17 using service
        2021-01-06 12:07:55 Initialization Sequence Completed

        C:\Users\IanHarwood>route print

        Interface List
        7...1c 1a df b0 ed 33 ......Surface Ethernet Adapter
        5...........................Wintun Userspace Tunnel
        17...00 ff a2 c4 d3 e6 ......TAP-Windows Adapter V9
        19...04 33 c2 10 6e 91 ......Microsoft Wi-Fi Direct Virtual Adapter
        9...06 33 c2 10 6e 90 ......Microsoft Wi-Fi Direct Virtual Adapter #2
        10...04 33 c2 10 6e 90 ......Intel(R) Wi-Fi 6 AX201 160MHz
        1...........................Software Loopback Interface 1

        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

        IPv6 Route Table

        Active Routes:
        If Metric Network Destination Gateway
        1 331 ::1/128 On-link
        17 281 fe80::/64 On-link
        10 301 fe80::/64 On-link
        17 281 fe80::b05d:3a66:e901:c2f0/128
        On-link
        10 301 fe80::bd3d:8014:35bb:a3c2/128
        On-link
        1 331 ff00::/8 On-link
        17 281 ff00::/8 On-link
        10 301 ff00::/8 On-link

        Persistent Routes:
        None

        C:\Users\IanHarwood>tracert 8.8.8.8

        Tracing route to dns.google [8.8.8.8]
        over a maximum of 30 hops:

        1 24 ms 21 ms 24 ms 10.3.200.1
        2 * * * Request timed out.
        3 * * * Request timed out.
        4 * * * Request timed out.
        5 * * * Request timed out.
        6 * * * Request timed out.
        7 ^C
        C:\Users\IanHarwood>

        There are many errors in the pfsense but it seems that these are generic errors and not related to my issue - based on previous searches in google etc...

        There were error(s) loading the rules: /tmp/rules.debug:143: unknown protocol udp4 - The line in question reads [143]: pass in quick on $WAN reply-to ( vtnet0 95.154.192.1 ) inet proto udp4 from any to 95.154.192.200 tracker 1608329661 keep state label "USER_RULE: OpenVPN Remote Technical Staff wizard"

        V 1 Reply Last reply Reply Quote 0
        • 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
                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.