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

    Pfsense 2.0 route traffic between two different openvpn subnets

    Scheduled Pinned Locked Moved OpenVPN
    6 Posts 3 Posters 9.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.
    • G
      Ghilteras
      last edited by

      hello folks

      I succesfully setup 2 openvpn server with 2 different subnets:

      1. 10.100.0.0/16

      2. 10.200.0.0/16

      my goal is to make some common comes in the 1) server to be able to reach ips on the 10.200.0.0/16 but not vice versa, how do I achieve that?

      I tried setups NAT for forwarding and put push route 10.200.0.0/16 in the conf of the first server, my clients in the 2) subnet can reach the gateway of the 1) (10.200.0.1), but that's it, they cannot reach the single clients, what am i doing wrong?

      any help would be appreciated
      thanks
      cheers

      1 Reply Last reply Reply Quote 0
      • C
        cmb
        last edited by

        don't do NAT at all. Make sure both ends have routes, and restrict the traffic as desired via firewall rules on OpenVPN.

        1 Reply Last reply Reply Quote 0
        • G
          Ghilteras
          last edited by

          cmb, I created interface OPT1 and OPT2 with their gateway 10.100.0.1(OPT1) and 10.200.0.1(OPT2), then I created two routes: one towards net 10.100.0.0/16 through 10.100.0.1 and the other towards 10.200.0.1/16 through 10.200.0.1

          done that I can reach every ip from the pfsense machine, but I cannot reach subnet 2) from clients in subnet 1) i can only reach their gateway 10.200.0.1, not the peers, and if I try to ping a peer on 2) from a peer on 1) the packets that should go from OPT1 to OPT2 but they stop on the gate of OPT1, 10.100.0.1

          I managed to make it possible by disabling the nat outbound automatic rule generation and by creating a manual rule that says:

          interface OpenVPN -> source 10.100.0.0/16 -> destination 10.200.0.0/16 -> translation any

          but it's VERY unreliable, yesterday was pinging, this morning not, I have to restart the vpn each now and then to make it ping again.

          how do I achieve the routing without using NAT at all like you suggested?

          thanks
          cheers

          1 Reply Last reply Reply Quote 0
          • G
            Ghilteras
            last edited by

            I forgot to mention that in vpn server 1) (10.100.0.0/16 subnet) I have added the routes to reach its own subnet AND routes to reach the 2) (10.200.0.0/16) one so the push is:

            openvpn[43631]: ipcop/91.183.63.201:52653 SENT CONTROL [ipcop]: 'PUSH_REPLY,route 10.100.0.0 255.255.0.0,topology net30,ping 10,ping-restart 60,route 10.200.0.0 255.255.0.0,ifconfig 10.100.0.102 10.100.0.101' (status=1)

            that should be enough but still the peers that connect to this server cannot reach 10.200.0.0/16 network

            1 Reply Last reply Reply Quote 0
            • G
              Ghilteras
              last edited by

              in the end I put:

              route 10.200.0.0 255.255.0.0
              push "route 10.200.0.0 255.255.0.0"
              on 1) server

              and

              route 10.100.0.0 255.255.0.0
              on 2) server

              and it looks like it works, I can reach 10.200.0.0/16 subnet from 10.100.0.0/16 peers but the other way around also, which I would not. if I isolate the push command in a client override it seems that the other way around is restricted at that common name only

              is it the correct way to proceed?

              1 Reply Last reply Reply Quote 0
              • H
                heper
                last edited by

                use firewall rules to block or reject traffic in one or the other direction

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