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

OpenVPN traffic from behind Server to one of two remote endpoints doesn't route

Scheduled Pinned Locked Moved OpenVPN
1 Posts 1 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.
  • O
    overand
    last edited by Dec 15, 2010, 12:49 AM

    All firewall/gateway systems are using pfSense 1.2.3-RELEASE.

    OpenVPN server at "home office" - 172.16.0.0/24 (In a CARP setup, incidentally, but running on master)

    OpenVPN client at "remote office 1" - 10.2.105.0/24

    OpenVPN client at "remote office 2" - 172.31.2.0/24 (also in a CARP setup, running on master)

    Setup is PKI, all tunnels establish properly.  OpenVPN server itself can ping / connect to everything as-expected, but clients at "home office" behind the pfSense box can't communicate with clients at "remote office 2"

    Routes appear to be built correctly.  Each "client-specific configuration" is set as I believe is correct - 'remotesite1' ID on server with "iroute 10.2.105.0 255.255.255.0" and "remotesite2" with "iroute 172.31.2.0 255.255.255.0"

    Routes, visible with netstat -rn - direct attached devices and unrelated routes / interfaces removed.

    Home Office (server)

    Internet:
    Destination        Gateway            Flags    Refs      Use  Netif Expire
    default            X.X.X.1        UGS        0    66465  fxp0
    10.2.105.0/24      10.222.58.2        UGS        0    10554  tun0
    10.222.58.0/24    10.222.58.2        UGS        0        0  tun0
    10.222.58.2        10.222.58.1        UH          3        0  tun0
    127.0.0.1          127.0.0.1          UH          0        0    lo0
    172.16.0.0/24      link#9            UC          0        0  vlan1
    172.31.2.0/24      10.222.58.2        UGS        0        0  tun0

    Remote 1

    Internet:
    Destination        Gateway            Flags    Refs      Use  Netif Expire
    default            y.y.y.193      UGS        0 321579527  vlan0
    10.2.105.0/24      link#4            UC          0        0  fxp3
    10.2.105.1        10.2.105.1        UH          0        0  carp1
    10.222.58.1/32    10.222.58.9        UGS        0        0  tun0
    10.222.58.9        10.222.58.10      UH          2        0  tun0
    127.0.0.1          127.0.0.1          UH          0        0    lo0
    172.16.0.0/24      10.222.58.9        UGS        0    9976  tun0

    Remote 2

    Internet:
    Destination        Gateway            Flags    Refs      Use  Netif Expire
    default            z.z.z.49      UGS        0    56180    em1
    10.222.58.1/32    10.222.58.5        UGS        0        0  tun0
    10.222.58.5        10.222.58.6        UH          2        0  tun0
    127.0.0.1          127.0.0.1          UH          0        0    lo0
    172.16.0.0/24      10.222.58.5        UGS        0        0  tun0
    172.31.2.0/24      link#1            UC          0        0    em0

    –--

    Behavior when  pinging from workstations to remote-2 sites from behind the home-office is to get NATed out rather than routed.

    i.e. if I traceroute -n, I get my first hop as my WAN-side (public IP) Gateway.

    I do have 'auto-generated VPN rules' disabled on the server, but the tun0 firewall rules are 'allow all out' - i even set it to 'allow all' to test.

    I can provide openVPN configs if it's helpful, but I've compared remote 1 and remote 2- the config files are identical.

    Server is dual-WAN, though I have 'local wan2 ip' in my custom options on the server.

    1 Reply Last reply Reply Quote 0
    1 out of 1
    • First post
      1/1
      Last post
    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
      This community forum collects and processes your personal information.
      consent.not_received