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

Not possible to set Gateway IP on IPv4 OpenVPN interface

Scheduled Pinned Locked Moved 2.1 Snapshot Feedback and Problems - RETIRED
14 Posts 5 Posters 25.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.
  • G
    ggzengel
    last edited by Feb 3, 2013, 2:07 AM

    And how making load balancing and traffic shaping without a gateway?

    1 Reply Last reply Reply Quote 0
    • J
      jimp Rebel Alliance Developer Netgate
      last edited by Feb 3, 2013, 2:15 AM

      Use the gateway as it is. It works fine without entering an IP. It's a dynamic type gateway so the IP is handled automatically behind the scenes. Check Status > Gateways and you'll see the IP of the remote VPN endpoint.

      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
      • G
        ggzengel
        last edited by Feb 3, 2013, 3:12 AM Feb 3, 2013, 3:04 AM

        Sometime it's too easy to understand.
        I thought it would be more complex and I have to give an IP to the interface.

        Perhaps it would be more transparent if there are an other option than none for IPV4 and IPV6 in this case.
        1. Because if i set it to none I will get a gateway what I not expect.
        2. I don't need an IPV6 gateway for this interface and make some confusion on dashboard.
        3. I will get an IPV6 gateway if I have disabled IPV6 globally.

        The gateway won't have an IP until you restart openvpn.

        1 Reply Last reply Reply Quote 0
        • J
          jimp Rebel Alliance Developer Netgate
          last edited by Feb 4, 2013, 1:35 PM

          That's always how OpenVPN gateways have worked when the interface is assigned. The gateways magically appeared once the interface was assigned.

          #2/#3 (the same issue) is something we can look into eventually but it's safe to just ignore it. It doesn't hurt anything.

          As for the gateway not showing up until you restart OpenVPN, again, that's how it's always worked. If you save/apply the Interface, you've always needed to restart the corresponding OpenVPN instance.

          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
          • J
            jimp Rebel Alliance Developer Netgate
            last edited by Feb 6, 2013, 12:22 AM

            I pushed a commit to skip the IPv6 gateways if you have IPv6 disabled, but the others are likely going to have to stay.

            The problem with skipping them if they don't have an IP is that in some cases OpenVPN may not have the IP if it's not connected (especially SSL/TLS in a server/multi-client setup), but we can't just take away the gateway in those cases as it may be needed and used once the VPN does connect. Not quite so easy to solve.

            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
            • G
              ggzengel
              last edited by Feb 6, 2013, 1:15 AM

              Thanks.

              1 Reply Last reply Reply Quote 0
              • S
                sebastiannielsen
                last edited by Feb 6, 2013, 9:12 PM

                A problem is that it seems to use the gateway configuration pushed from the OpenVPN server despite theres local gateway configured in the .ovpn file.
                This causes a odd error of setting the netmask (255.255.255.128) as gateway on one of the VPNs.
                It seems like the VPN provider have one server for all its customers, which gives a "generic" pushed configuration thats fits all dynamic customers, then gives each static customer its own .ovpn file which contains a customer-unique gateway & static IP.

                Thats why it MUST be possible to manually set IP and gateway on OpenVPN assigned interfaces.

                On 2.0.2 its possible to manually set gateways on OpenVPN interfaces, and it work wonderfully. Im surfing from behind that 2.0.2 pfsense box now, with manual gateways & IP on 2 OpenVPN tunnels, where one of the gateways are default gateway.
                On 2.1 its completely broken to manually set gateways on OpenVPN interfaces. Also another odd error is that its also uses the netmask pushed from OpenVPN server rather from the .ovpn file, so the interface gets its netmask set to /32 instead of /25.

                (had to downgrade from 2.1 to 2.0.2 due to the problem)

                As a customer, you are supposed to override the server-pushed configuration with your own customer-specific .ovpn file when you select static IP, rather than dynamic IP from the VPN provider.

                1 Reply Last reply Reply Quote 0
                • J
                  jimp Rebel Alliance Developer Netgate
                  last edited by Feb 6, 2013, 9:14 PM

                  Then use settings in the OpenVPN advanced options, not gateway entries.

                  If it worked that way before, it was purely by chance.

                  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
                    sebastiannielsen
                    last edited by Feb 6, 2013, 9:49 PM Feb 6, 2013, 9:41 PM

                    The problem is that PfSense prefers the pushed config in favor for the Advanced config set.

                    The 2 tunnels are configured with these advanced configs, obtained from 2 VPN tunnel providers .ovpn configs:
                    float 62.181.89.21;route-gateway 193.13.142.129;ifconfig 193.13.142.178 255.255.255.128;
                    float 46.59.86.2;route-gateway 46.59.86.129;ifconfig 46.59.86.163 255.255.255.128;

                    With no manual gateway config, OpenVPN restarted:

                    As you see, the PfSense behaves oddy and sets the gateway = the netmask specified in ifconfig in .ovpn

                    With manual gateway specified, OpenVPN restarted:

                    Note that the tunnels are UP in both of the scenarios.

                    This is on 2.0.2. As you see, the problem solves when manually specifying gateway.
                    Basically, you need to specify the gateway BOTH in advanced config AND manual gateway for it to work with certain VPN providers.

                    Thats why the "feature" of manually specifying gateways on with OpenVPN interfaces on 2.1 must stay. Some VPN providers require this to work.

                    1 Reply Last reply Reply Quote 0
                    • C
                      cmb
                      last edited by Mar 6, 2014, 7:00 PM

                      updating this thread in case anyone else runs across it (someone linked to it from elsewhere). The problem noted in the last post here is this:
                      https://redmine.pfsense.org/issues/3475

                      which is fixed in 2.1.1

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