• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
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 850 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 Aug 16, 2016, 1:30 PM

    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 Aug 16, 2016, 2:57 PM

      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 Aug 16, 2016, 3:38 PM

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