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

    Site to site - no access to subnets behind client endpoint

    Scheduled Pinned Locked Moved OpenVPN
    3 Posts 2 Posters 832 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.
    • B
      bert64
      last edited by

      I am trying to setup a site to site openvpn link between a pfsense firewall and a linux host.

      I'm using 192.168.73.0/29 for the interlink, the pfsense firewall is acting as server and has 172.16.254.0/24 behind it while the linux host has 172.16.101.0/24 behind it.

      From the linux server i can reach hosts within 172.16.254.0/24, and hosts in this subnet can reach the tunnel ip of the linux host (192.168.93.2), but neither the pfsense firewall nor the host behind it can reach anything in 172.16.101.0/24.

      A route entry exists on the pfsense firewall, and tcpdump on the openvpn interface shows traffic going out, but a tcpdump running against the tun interface on the linux host shows no traffic reaching it…
      The rules on the pfsense are now set to allow everything on the openvpn interface but still to no avail, so i'm stumped... Any suggestions? I'm probably missing something stupidly obvious.

      1 Reply Last reply Reply Quote 0
      • A
        ahydle
        last edited by

        Have you tried rebooting your firewalls? I was about to post a question here because I assume there is some sort of timer that is messing with my vpn connections. I can usually ping through the tunnel interface but not the LAN at first. If I wait a while (several hours) or reboot things start working. I can see the correct route and the vpn connection is up but if I ping from the LAN interface (or a machine behind LAN) I can see the traffic going into the tunnel but dont see it arriving on the other side. I usually also see a message stating bad source address from client [x.x.x.x], packet dropped

        1 Reply Last reply Reply Quote 0
        • B
          bert64
          last edited by

          Tried a reboot, but no change…

          From the pfsense:

          tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
          listening on ovpns5, link-type NULL (BSD loopback), capture size 65535 bytes
          22:06:25.727660 IP 172.16.254.21 > 172.16.101.16: ICMP echo request, id 25565, seq 7, length 64
          22:06:26.727671 IP 172.16.254.21 > 172.16.101.16: ICMP echo request, id 25565, seq 8, length 64
          22:06:27.727676 IP 172.16.254.21 > 172.16.101.16: ICMP echo request, id 25565, seq 9, length 64
          22:06:28.727686 IP 172.16.254.21 > 172.16.101.16: ICMP echo request, id 25565, seq 10, length 64
          22:06:32.620809 IP 172.16.254.21 > 192.168.73.2: ICMP echo request, id 25566, seq 1, length 64
          22:06:32.920929 IP 192.168.73.2 > 172.16.254.21: ICMP echo reply, id 25566, seq 1, length 64
          22:06:33.621049 IP 172.16.254.21 > 192.168.73.2: ICMP echo request, id 25566, seq 2, length 64
          22:06:33.921304 IP 192.168.73.2 > 172.16.254.21: ICMP echo reply, id 25566, seq 2, length 64

          And from the remote end Linux host:
          tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
          listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
          17:36:32.798639 IP 172.16.254.21 > 192.168.73.2: ICMP echo request, id 25566, seq 1, length 64
          17:36:32.798655 IP 192.168.73.2 > 172.16.254.21: ICMP echo reply, id 25566, seq 1, length 64
          17:36:33.799001 IP 172.16.254.21 > 192.168.73.2: ICMP echo request, id 25566, seq 2, length 64
          17:36:33.799024 IP 192.168.73.2 > 172.16.254.21: ICMP echo reply, id 25566, seq 2, length 64

          It only sees the traffic to the tunnel ip, not any of the traffic destined for hosts beyond

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