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

    OpenVPN connection issue from Lan to remote OpenVPN client

    OpenVPN
    3
    4
    442
    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.
    • N
      notrox
      last edited by

      I am working on trying to get communication between a computer on my lan to a remote connected client. The connection works from the client to the lan but not the other direction. My configuration is as follows:

      Tunnel network: 10.10.1.0/24

      Local network: 10.10.0.0/24

      Remote client ip: 10.10.1.2

      Local lan connected ip: 10.10.0.2

      Output of openvpn client side:

      Pinging 10.10.0.2 with 32 bytes of data:
      Reply from 10.10.0.2: bytes=32 time=17ms TTL=63
      Reply from 10.10.0.2: bytes=32 time=16ms TTL=63
      Reply from 10.10.0.2: bytes=32 time=10ms TTL=63
      Reply from 10.10.0.2: bytes=32 time=16ms TTL=63

      Ping statistics for 10.10.0.2:
      Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
      Approximate round trip times in milli-seconds:
      Minimum = 10ms, Maximum = 17ms, Average = 14ms

      Output from the 10.10.0.2 machine:

      ping 10.10.1.2
      PING 10.10.1.2 (10.10.1.2) 56(84) bytes of data.
      --- 10.10.1.2 ping statistics ---
      5 packets transmitted, 0 received, 100% packet loss, time 4073ms

      tcpdump output from pfsense openvpn server:

      tcpdump -envps 1500 -i ovpns1 host 10.10.0.2
      tcpdump: listening on ovpns1, link-type NULL (BSD loopback), capture size 1500 bytes
      15:17:27.929023 AF IPv4 (2), length 88: (tos 0x0, ttl 63, id 64772, offset 0, flags [DF], proto ICMP (1), length 84)
      10.10.0.2 > 10.10.1.2: ICMP echo request, id 32491, seq 1, length 64
      15:17:28.957394 AF IPv4 (2), length 88: (tos 0x0, ttl 63, id 65015, offset 0, flags [DF], proto ICMP (1), length 84)
      10.10.0.2 > 10.10.1.2: ICMP echo request, id 32491, seq 2, length 64
      15:17:29.981415 AF IPv4 (2), length 88: (tos 0x0, ttl 63, id 65016, offset 0, flags [DF], proto ICMP (1), length 84)
      10.10.0.2 > 10.10.1.2: ICMP echo request, id 32491, seq 3, length 64
      15:17:31.006337 AF IPv4 (2), length 88: (tos 0x0, ttl 63, id 65168, offset 0, flags [DF], proto ICMP (1), length 84)
      10.10.0.2 > 10.10.1.2: ICMP echo request, id 32491, seq 4, length 64

      ping output from pfsense openvpn server:

      ping 10.10.1.2
      PING 10.10.1.2 (10.10.1.2): 56 data bytes
      64 bytes from 10.10.1.2: icmp_seq=0 ttl=128 time=18.626 ms
      64 bytes from 10.10.1.2: icmp_seq=1 ttl=128 time=44.782 ms
      64 bytes from 10.10.1.2: icmp_seq=2 ttl=128 time=9.797 ms
      64 bytes from 10.10.1.2: icmp_seq=3 ttl=128 time=9.793 ms
      --- 10.10.1.2 ping statistics ---
      4 packets transmitted, 4 packets received, 0.0% packet loss
      round-trip min/avg/max/stddev = 9.793/20.749/44.782/14.336 ms

      tcpdump output from pfsense openvpn server:

      tcpdump -envps 1500 -i ovpns1 host 10.10.1.1
      tcpdump: listening on ovpns1, link-type NULL (BSD loopback), capture size 1500 bytes
      15:21:47.849708 AF IPv4 (2), length 88: (tos 0x0, ttl 64, id 50082, offset 0, flags [none], proto ICMP (1), length 84)
      10.10.1.1 > 10.10.1.2: ICMP echo request, id 12156, seq 0, length 64
      15:21:47.868286 AF IPv4 (2), length 88: (tos 0x0, ttl 128, id 26464, offset 0, flags [none], proto ICMP (1), length 84)
      10.10.1.2 > 10.10.1.1: ICMP echo reply, id 12156, seq 0, length 64
      15:21:48.881459 AF IPv4 (2), length 88: (tos 0x0, ttl 64, id 57915, offset 0, flags [none], proto ICMP (1), length 84)
      10.10.1.1 > 10.10.1.2: ICMP echo request, id 12156, seq 1, length 64
      15:21:48.926190 AF IPv4 (2), length 88: (tos 0x0, ttl 128, id 26465, offset 0, flags [none], proto ICMP (1), length 84)
      10.10.1.2 > 10.10.1.1: ICMP echo reply, id 12156, seq 1, length 64
      15:21:49.911773 AF IPv4 (2), length 88: (tos 0x0, ttl 64, id 46265, offset 0, flags [none], proto ICMP (1), length 84)
      10.10.1.1 > 10.10.1.2: ICMP echo request, id 12156, seq 2, length 64
      15:21:49.921527 AF IPv4 (2), length 88: (tos 0x0, ttl 128, id 26466, offset 0, flags [none], proto ICMP (1), length 84)
      10.10.1.2 > 10.10.1.1: ICMP echo reply, id 12156, seq 2, length 64
      15:21:50.945935 AF IPv4 (2), length 88: (tos 0x0, ttl 64, id 49390, offset 0, flags [none], proto ICMP (1), length 84)
      10.10.1.1 > 10.10.1.2: ICMP echo request, id 12156, seq 3, length 64
      15:21:50.955680 AF IPv4 (2), length 88: (tos 0x0, ttl 128, id 26467, offset 0, flags [none], proto ICMP (1), length 84)
      10.10.1.2 > 10.10.1.1: ICMP echo reply, id 12156, seq 3, length 64

      I am not sure what piece of the puzzle I am missing. I appreciate any advice someone might have.

      Thanks!

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

        Seem the client doesn't accept access from remote (unknown) networks. That's the default behavior of most system firewalls like Windows.
        You will have to open up the firewall to accept access from 10.10.0.0/24.

        1 Reply Last reply Reply Quote 1
        • N
          notrox
          last edited by

          You were totally right, a new firewall rule fixed this.

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

            Firewall (think windows firewall) on the client blocking the traffic?

            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
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.