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

    Prevent OpenVPN from adding static routes?

    Scheduled Pinned Locked Moved OpenVPN
    11 Posts 3 Posters 5.7k 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.
    • jimpJ
      jimp Rebel Alliance Developer Netgate
      last edited by

      If you have OSPF setup right, you don't need to add any routes in OpenVPN.

      It works fine that way for me, I run that way between my house and another VPN site.

      Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

      Need help fast? Netgate Global Support!

      Do not Chat/PM for help!

      1 Reply Last reply Reply Quote 0
      • S
        stevewm
        last edited by

        I have been testing this setup with 2.0 with several VMs in VirtualBox.

        On the "main" pfSense box, I have 2 ISPs setup (no load balancing, just failover only), and then 2 OpenVPN tunnels setup.  On the "client" end I have a single ISP setup, with 2 OpenVPN tunnels setup as well.

        On both ends, each tunnel is configured as a interface and OSPF is setup with those interfaces on both ends.  Both ends are in Area 0, with different router IDs on each one.

        On the OpenVPN side of things…  If I fill the local/remote network fields in, the OpenVPN interfaces are brought up correctly, however OSPF then starts throwing out errors about not being able to write routes.  The only way I can get it to work correctly is to delete the static routes that appear immediately when the OpenVPN tunnels come up.  Within seconds OSPF then puts its own routes in and everything works like I want it to.  Traffic is re-routed the second OSPF declares the interface down, and goes back to primary within seconds of it coming back up.

        If I leave the local and remote network fields in the OpenVPN screen blank on either end, the tunnels will not come up at all, it seems a script that sets up the OpenVPN interfaces completely fails to run.  The tunnels never come up, and OSPF complains the OpenVPN interfaces are un-numbered.

        I have not tested this on 1.2.3.  Is this something that works correctly on it?  Also, what about OpenVPN and CARP?  I had planned to have another box for failover purposes...  Does OpenVPN cooperate with that at all?

        1 Reply Last reply Reply Quote 0
        • GruensFroeschliG
          GruensFroeschli
          last edited by

          @stevewm:

          If I leave the local and remote network fields in the OpenVPN screen blank on either end, the tunnels will not come up at all, it seems a script that sets up the OpenVPN interfaces completely fails to run.  The tunnels never come up, and OSPF complains the OpenVPN interfaces are un-numbered.

          Did you perhaps leave the tunnel-subnet field empty too?
          (Is that even possible?)
          What is in the log when OpenVPN doesn't come up like this?

          We do what we must, because we can.

          Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

          1 Reply Last reply Reply Quote 0
          • jimpJ
            jimp Rebel Alliance Developer Netgate
            last edited by

            There must be some other setting you have wrong. This will not work with the local/remote fields filled in, and it works perfectly for me with them empty.

            Make sure your tunnel subnet doesn't overlap any other existing subnets, double check subnet masks, etc…

            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

            1 Reply Last reply Reply Quote 0
            • S
              stevewm
              last edited by

              If the local/remote fields are not filled, the OpenVPN tunnel interfaces fail to come up at all.

              If the fields are populated on both ends, I see the following in the log when the OpenVPN tunnel connects.

              (Server)
              Apr 15 08:34:59 openvpn[11083]: /usr/local/sbin/ovpn-linkup ovpns1 1500 1558 192.168.100.1 192.168.100.2 init
              Apr 15 08:34:59 openvpn[11083]: /sbin/ifconfig ovpns1 192.168.100.1 192.168.100.2 mtu 1500 netmask 255.255.255.255 up

              (Client)
              Apr 15 08:44:03 openvpn[11760]: /usr/local/sbin/ovpn-linkup ovpnc1 1500 1558 192.168.100.2 192.168.100.1 init
              Apr 15 08:44:03 openvpn[11760]: /sbin/ifconfig ovpnc1 192.168.100.2 192.168.100.1 mtu 1500 netmask 255.255.255.255 up

              If the fields are not filled in, those commands are never executed, the OpenVPN interfaces remain unconfigured and OSPF won't start.

              If I execute the commands manually thereby configuring the interfaces, it works fine.

              And yes, the tunnel network fields are filled in.

              1 Reply Last reply Reply Quote 0
              • jimpJ
                jimp Rebel Alliance Developer Netgate
                last edited by

                And yet it works fine for me.

                You'll need to post screenshots of your entire OpenVPN config in the GUI (you can blank out the shared key field) and the contents of the config file from /var/etc/openvpn/ wouldn't hurt.

                Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                Need help fast? Netgate Global Support!

                Do not Chat/PM for help!

                1 Reply Last reply Reply Quote 0
                • S
                  stevewm
                  last edited by

                  Update:  I was running 2.0 RC1 from March 20th..  I installed the newest snapshot, now the tunnels come up properly without having to put the local/remote info in!  OSPF also takes off like it should and the routes are inserted.

                  My problem is now that traffic doesn't pass!

                  If you ping a host at one end from the other end, it does nothing.  Running a packet capture from PfSense on the receiving end I see the ping ending up on the OpenVPN interface, however its never sent forward to the client on the LAN.

                  Packet Cap from OpenVPN interface on receiving end:
                  12:24:03.784952 IP 192.168.100.6 > 192.168.100.5: ICMP echo request, id 46464, seq 46338, length 44
                  12:24:04.474968 IP 192.168.100.6 > 224.0.0.5: OSPFv2, Hello, length 48
                  12:24:04.795855 IP 192.168.100.6 > 192.168.100.5: ICMP echo request, id 46464, seq 46594, length 44

                  I have allow/any as firewall rules on all interfaces on both sides.

                  1 Reply Last reply Reply Quote 0
                  • jimpJ
                    jimp Rebel Alliance Developer Netgate
                    last edited by

                    Nothing in the firewall logs? Nothing in a packet capture on LAN?

                    Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                    Need help fast? Netgate Global Support!

                    Do not Chat/PM for help!

                    1 Reply Last reply Reply Quote 0
                    • S
                      stevewm
                      last edited by

                      I have it set to log all rules.. ping is not shown as being received.

                      Running a packet cap on the LAN does not show the pings.

                      1 Reply Last reply Reply Quote 0
                      • jimpJ
                        jimp Rebel Alliance Developer Netgate
                        last edited by

                        If they come in on the OpenVPN interface but don't leave LAN, then one of two things happened:

                        1. They were blocked by firewall rules somewhere
                        2. It went out a different interface that had a more specific route

                        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                        Need help fast? Netgate Global Support!

                        Do not Chat/PM for help!

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