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

Three node site to site VPN works, user VPN connects but can't access anything

Scheduled Pinned Locked Moved OpenVPN
7 Posts 2 Posters 1.5k 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
    brucet622
    last edited by Nov 19, 2014, 11:38 PM

    …first post so go easy...

    I have three firewalls at three sites setup using site to site VPN.  One node has a static IP address and the others connect to it.  That all works great.  Everyone can access everyone.

    I have setup the Open VPN for a couple of clients, they connect just fine.  However, they can't access anything.  We have tried all sorts of different rules without success.  Thought I would ask for guidance.  What should we do to allow VPN users access to everything?  (Yes, we are a development site so it is important, at least for now, that everyone be able to access everything.)

    Also note that a prior test setup was able to access the local network using Open VPN before we reconfigured to set up the site-to-site stuff.

    Any pointers?  Can post any other info as needed.

    Thanks!

    Bruce

    1 Reply Last reply Reply Quote 0
    • D
      Derelict LAYER 8 Netgate
      last edited by Nov 20, 2014, 2:08 AM

      @brucet622:

      …first post so go easy...

      I have three firewalls at three sites setup using site to site VPN.  One node has a static IP address and the others connect to it.  That all works great.  Everyone can access everyone.

      Are these all OpenVPN?

      I have setup the Open VPN for a couple of clients, they connect just fine.  However, they can't access anything.  We have tried all sorts of different rules without success.  Thought I would ask for guidance.

      Yeah.  Adding rules when you don't really know what you need is generally not going to work.

      Here's the deal:  pfSense needs a route for everything it is supposed to be forwarding to the OpenVPN process.  OpenVPN itself needs an iroute to know which tunnel to send the traffic through once pfSense routes it to OpenVPN.

      When pfSense receives traffic from OpenVPN, it needs to be passed by rules on either the OpenVPN tab or the assigned OpenVPN interface.  We don't know what you have configured.

      There are a couple different ways to accomplish this in the config so it might be better if we have a drawing to work from.

      What should we do to allow VPN users access to everything?  (Yes, we are a development site so it is important, at least for now, that everyone be able to access everything.)

      Also note that a prior test setup was able to access the local network using Open VPN before we reconfigured to set up the site-to-site stuff.

      Any pointers?  Can post any other info as needed.

      Thanks!

      Bruce

      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
      • B
        brucet622
        last edited by Nov 20, 2014, 8:14 PM

        Thanks.  I'll put together the diagram and post as soon as I can.

        Bruce

        1 Reply Last reply Reply Quote 0
        • B
          brucet622
          last edited by Nov 24, 2014, 1:40 AM

          Here is the server1.conf file of the main office firewall.

          dev ovpns1
          dev-type tun
          tun-ipv6
          dev-node /dev/tun1
          writepid /var/run/openvpn_server1.pid
          #user nobody
          #group nobody
          script-security 3
          daemon
          keepalive 10 60
          ping-timer-rem
          persist-tun
          persist-key
          proto udp
          cipher CAMELLIA-256-CBC
          up /usr/local/sbin/ovpn-linkup
          down /usr/local/sbin/ovpn-linkdown
          local 10.1.10.60
          tls-server
          server 172.16.9.0 255.255.255.0
          client-config-dir /var/etc/openvpn-csc
          ifconfig 172.16.9.1 172.16.9.2
          tls-verify /var/etc/openvpn/server1.tls-verify.php
          lport 1194
          management /var/etc/openvpn/server1.sock unix
          max-clients 10
          push "route 172.16.1.0 255.255.255.0"
          push "route 172.16.2.0 255.255.255.0"
          route 192.168.2.0 255.255.255.0
          route 172.16.4.0 255.255.255.0
          ca /var/etc/openvpn/server1.ca
          cert /var/etc/openvpn/server1.cert
          key /var/etc/openvpn/server1.key
          dh /etc/dh-parameters.4096
          crl-verify /var/etc/openvpn/server1.crl-verify
          tls-auth /var/etc/openvpn/server1.tls-auth 0
          comp-lzo
          route 192.168.2.0 255.255.255.0

          route 172.16.4.0 255.255.255.0

          push "route 172.16.1.0 255.255.255.0"

          push "route 172.16.2.0 255.255.255.0"

          push "route 172.16.8.0 255.255.255.0"

          I've attached the network diagram (I think).  Note that all the firewalls are pfsense-based.

          Thanks for your help!

          Bruce

          NetworkDiagram.jpg
          NetworkDiagram.jpg_thumb

          1 Reply Last reply Reply Quote 0
          • D
            Derelict LAYER 8 Netgate
            last edited by Nov 24, 2014, 1:53 AM

            What are your firewall rules on the OpenVPN tab (or the OpenVPN assigned interface) on the main office pfSense?

            There should also be a server2.conf file for the remote access server.  What's in that?

            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
            • B
              brucet622
              last edited by Nov 25, 2014, 10:49 PM

              Thanks for all your help!  Here is the additional info:

              OpenVPN firewall is wide open currently:

              ID:(blank) proto:IPV4* source:* port:* dest:* port:* gw:* queue:none sched:(blank)

              /var/etc/openvpn/server2.conf:

              dev ovpns2
              dev-type tun
              tun-ipv6
              dev-node /dev/tun2
              writepid /var/run/openvpn_server2.pid
              #user nobody
              #group nobody
              script-security 3
              daemon
              keepalive 10 60
              ping-timer-rem
              persist-tun
              persist-key
              proto udp
              cipher CAMELLIA-256-CBC
              up /usr/local/sbin/ovpn-linkup
              down /usr/local/sbin/ovpn-linkdown
              client-connect /usr/local/sbin/openvpn.attributes.sh
              client-disconnect /usr/local/sbin/openvpn.attributes.sh
              local 10.1.10.60
              tls-server
              server 172.16.8.0 255.255.255.0
              client-config-dir /var/etc/openvpn-csc
              username-as-common-name
              auth-user-pass-verify /var/etc/openvpn/server2.php via-env
              tls-verify /var/etc/openvpn/server2.tls-verify.php
              lport 11940
              management /var/etc/openvpn/server2.sock unix
              max-clients 10
              push "route 172.16.1.0 255.255.255.0"
              push "route 172.16.2.0 255.255.255.0"
              push "route 172.16.4.0 255.255.255.0"
              push "route 192.168.2.0 255.255.255.0"
              client-to-client
              ca /var/etc/openvpn/server2.ca
              cert /var/etc/openvpn/server2.cert
              key /var/etc/openvpn/server2.key
              dh /etc/dh-parameters.4096
              crl-verify /var/etc/openvpn/server2.crl-verify
              tls-auth /var/etc/openvpn/server2.tls-auth 0
              comp-lzo
              persist-remote-ip
              float
              route 192.168.2.0 255.255.255.0

              route 172.16.4.0 255.255.255.0

              push "route 172.16.1.0 255.255.255.0"

              push "route 172.16.2.0 255.255.255.0"

              push "route 172.16.4.0 255.255.255.0"

              push "route 172.16.9.0 255.255.255.0"

              1 Reply Last reply Reply Quote 0
              • D
                Derelict LAYER 8 Netgate
                last edited by Nov 25, 2014, 11:44 PM

                It looks to me like server1.conf is your site-to-site and server2.conf is your remote access.

                It also looks like your diagram should have 172.16.9.0/24 as your remote access network.  Is that true?

                If all that is the case, you have routes from pfSense for:

                route 192.168.2.0 255.255.255.0
                route 172.16.4.0 255.255.255.0

                …in both configs.  Those routes should only be in your site-to-site.

                If you want your remote access clients to access all LANs at all sites, you need to push them routes for everything, meaning 172.16.1.0/24, 172.16.2.0/24, 172.16.4.0/24, 192.168.2.0/24.

                And you need to push routes to all foreign networks to each site.  For instance, Satellite office 2 needs to be pushed routes for the following:

                172.16.1.0/24
                172.16.2.0/24
                172.16.4.0/24
                172.16.9.0/24

                (Note you could just push a route to 172.16.0.0/16 instead.  Or even /20 in that particular case.)

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