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

    Pfsense - OpenVPN - Pfsense - no traffic

    Scheduled Pinned Locked Moved OpenVPN
    15 Posts 3 Posters 5.1k 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.
    • K
      KJR
      last edited by

      Server1.conf is for remote access from home.

      Here are the conf from the VPN Tunnel.

      server2.conf:

      dev ovpns2
      dev-type tun
      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 AES-256-CBC
      up /usr/local/sbin/ovpn-linkup
      down /usr/local/sbin/ovpn-linkdown
      local xxx.xxx.11.2
      ifconfig 192.168.80.1 192.168.80.2
      lport 1195
      management /var/etc/openvpn/server2.sock unix
      push "route xxx.xxx.10.0 255.255.255.128"
      route xxx.xxx.10.128 255.255.255.128
      secret /var/etc/openvpn/server2.secret
      push route "xxx.xxx.10.0 255.255.255.248"
      push route "192.168.64.0 255.255.255.0"

      Client1.conf:

      dev ovpnc1
      dev-type tun
      dev-node /dev/tun1
      writepid /var/run/openvpn_client1.pid
      #user nobody
      #group nobody
      script-security 3
      daemon
      keepalive 10 60
      ping-timer-rem
      persist-tun
      persist-key
      proto udp
      cipher AES-256-CBC
      up /usr/local/sbin/ovpn-linkup
      down /usr/local/sbin/ovpn-linkdown
      local xxx.xxx.11.5
      lport 1195
      management /var/etc/openvpn/client1.sock unix
      remote xxx.xxx.11.2 1195
      ifconfig 192.168.80.2 192.168.80.1
      route xxx.xxx.10.0 255.255.255.128
      secret /var/etc/openvpn/client1.secret

      OpenVPN Rules are ANY/ANY allowed.

      1 Reply Last reply Reply Quote 0
      • M
        marvosa
        last edited by

        you can leave the local and remote statements masked as they are public, but you can unmask your push route and route statements… since they are reserved addresses.  We need to see them if we're going troubleshoot effectively.

        I see some possible issues, but need those ranges unmasked.

        Also, can you communicate with your DMZ from the LAN on server-side?

        1 Reply Last reply Reply Quote 0
        • P
          phil.davis
          last edited by 

          push "route xxx.xxx.10.0 255.255.255.128"
route xxx.xxx.10.128 255.255.255.128
secret /var/etc/openvpn/server2.secret
push route "xxx.xxx.10.0 255.255.255.248"
push route "192.168.64.0 255.255.255.0"

          The 2nd (middle) push route is certainly not needed - it is a subnet of the 1st (top) one.
          I think the correct syntax is:

          push "route 192.168.64.0 255.255.255.0"

          The 1st (top) one has the correct syntax, the others have the quote in the wrong place.
          Maybe it is as simple as that?
          Otherwise post firewall rules also.

          As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
          If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

          1 Reply Last reply Reply Quote 0
          • K
            KJR
            last edited by

            Ok, here is the modified server1.conf:

            dev ovpns2
            dev-type tun
            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 AES-256-CBC
            up /usr/local/sbin/ovpn-linkup
            down /usr/local/sbin/ovpn-linkdown
            local xxx.xxx.11.2
            ifconfig 192.168.80.1 192.168.80.2
            lport 1195
            management /var/etc/openvpn/server2.sock unix
            push "route 170.198.10.0 255.255.255.128"
            route 170.198.10.128 255.255.255.128
            secret /var/etc/openvpn/server2.secret
            push "route 192.168.64.0 255.255.255.0"

            Client1.conf:

            dev ovpnc1
            dev-type tun
            dev-node /dev/tun1
            writepid /var/run/openvpn_client1.pid
            #user nobody
            #group nobody
            script-security 3
            daemon
            keepalive 10 60
            ping-timer-rem
            persist-tun
            persist-key
            proto udp
            cipher AES-256-CBC
            up /usr/local/sbin/ovpn-linkup
            down /usr/local/sbin/ovpn-linkdown
            local xxx.xxx.11.5
            lport 1195
            management /var/etc/openvpn/client1.sock unix
            remote xxx.xxx.11.2 1195
            ifconfig 192.168.80.2 192.168.80.1
            route 170.198.10.0 255.255.255.128
            secret /var/etc/openvpn/client1.secret

            The only rule on the OpenVPN tab is to allow all traffic.

            I am able to communicate to the DMZ from the LAN on the server side without issue.  I cannot access from the client LAN side.

            Thanks again for all the help.

            1 Reply Last reply Reply Quote 0
            • M
              marvosa
              last edited by

              So, you're using public IP's on your LAN… Why?  It may or may not be the main issue, but that should be changed.  Check your firewall logs for blocks.

              After the correction with the quotation mark placement by phil.davis and both DMZ and OpenVPN have any/any rules on the firewall?  It should be working.... but your tunnel network and DMZ are private... while the LAN on both sides are using publicly addressable IP's.... that HAS to be causing confusion somewhere.

              1 Reply Last reply Reply Quote 0
              • K
                KJR
                last edited by

                Yeah…I walked into this mess with the public IPs being used, still not sure why they did that.

                I need to make a project to correct that first before I proceed.  After that I will revisit.  Thanks again for your help.

                1 Reply Last reply Reply Quote 0
                • K
                  KJR
                  last edited by

                  I made some changes and have a WIP to change the public addresses to 10.x.x.x on my lan.

                  When I try to traceroute to the DMZ 192.168.64.1 from the remote side it hits the firewall and routes it out the WAN interface instead of passing it across the VPN tunnel.

                  1 Reply Last reply Reply Quote 0
                  • M
                    marvosa
                    last edited by

                    Post new server1.conf and client1.conf and routing tables.

                    Also, what is the client-side using for an IP range?

                    1 Reply Last reply Reply Quote 0
                    • K
                      KJR
                      last edited by

                      server2.conf:

                      dev ovpns2
                      dev-type tun
                      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 AES-256-CBC
                      up /usr/local/sbin/ovpn-linkup
                      down /usr/local/sbin/ovpn-linkdown
                      local xxx.xxx.11.2
                      ifconfig 10.25.2.1 10.25.2.2
                      lport 1195
                      management /var/etc/openvpn/server2.sock unix
                      push "route 170.198.10.0 255.255.255.128"
                      route 10.25.1.0 255.255.255.0
                      secret /var/etc/openvpn/server2.secret

                      Client1.conf:

                      dev ovpnc1
                      dev-type tun
                      dev-node /dev/tun1
                      writepid /var/run/openvpn_client1.pid
                      #user nobody
                      #group nobody
                      script-security 3
                      daemon
                      keepalive 10 60
                      ping-timer-rem
                      persist-tun
                      persist-key
                      proto udp
                      cipher AES-256-CBC
                      up /usr/local/sbin/ovpn-linkup
                      down /usr/local/sbin/ovpn-linkdown
                      local xxx.xxx.11.5
                      lport 0
                      management /var/etc/openvpn/client1.sock unix
                      remote xxx.xxx.11.2 1195
                      ifconfig 10.25.2.2 10.25.2.1
                      route 170.198.10.0 255.255.255.128
                      secret /var/etc/openvpn/client1.secret

                      How do I export the routing tables?

                      My client side LAN is now: 10.25.1.0/24.

                      Thank you again for the help!

                      1 Reply Last reply Reply Quote 0
                      • M
                        marvosa
                        last edited by

                        You can either go to the shell and to a "netstat -r" or from the GUI it's Diagnostics -> Routes.

                        1 Reply Last reply Reply Quote 0
                        • K
                          KJR
                          last edited by

                          Well….I got it.

                          I started poking around the routing tables after the last msg.  I needed to put a static route to the DMZ using the openvpn IP as the gateway.  Once I did that and added the vendor static routes that exist on the primary firewall to the remote firewall it all worked.

                          Thanks marvosa for pushing me in the right direction.

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