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

OpenVPN connection issue from Lan to remote OpenVPN client

Scheduled Pinned Locked Moved OpenVPN
4 Posts 3 Posters 477 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.
  • N
    notrox
    last edited by May 24, 2019, 8:28 PM

    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 May 26, 2019, 9:18 PM

      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 May 28, 2019, 12:32 PM

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

        1 Reply Last reply Reply Quote 0
        • D
          Derelict LAYER 8 Netgate
          last edited by May 31, 2019, 6:32 AM

          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
          4 out of 4
          • First post
            4/4
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
            This community forum collects and processes your personal information.
            consent.not_received