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

    Firewall Rule for gateway online ONLY

    Scheduled Pinned Locked Moved OpenVPN
    16 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.
    • V
      viragomann @Bambos
      last edited by

      @bambos
      That doesn't say really much.

      Post a screenshot of System > Routing > Gateways, please.

      B 1 Reply Last reply Reply Quote 0
      • B
        Bambos @viragomann
        last edited by

        @viragomann yes..

        013ba010-8cac-4a6c-b243-51355c30da2c-image.png

        V 1 Reply Last reply Reply Quote 0
        • V
          viragomann @Bambos
          last edited by

          @bambos
          That's a small section, not the whole screen and that does not match to the gateway you've monitoring issues.

          B 1 Reply Last reply Reply Quote 0
          • B
            Bambos @viragomann
            last edited by

            @viragomann why not ?? .1 is the server, .2 is the client.

            this is the whole section

            e6c4a3ae-494d-4764-819b-3c92624f7d94-image.png

            V 1 Reply Last reply Reply Quote 0
            • V
              viragomann @Bambos
              last edited by

              @bambos
              So there is no gateway with the name "SUNTECHNICS_VPN_VPNV" in this list as shown in the monitoring screen above.

              So I'm quite wondering, where you got this screen from. Is it from the other site of the VPN?

              B 1 Reply Last reply Reply Quote 0
              • B
                Bambos @viragomann
                last edited by Bambos

                @viragomann i think you confused a little. The red gateway was on the VPN client side, not having the correct firewall rule on the server interface ! please see post 1 again.

                As i said , i have an allow all on the client side (vpn interface) and control only on the server side (vpn interface).

                V 1 Reply Last reply Reply Quote 0
                • V
                  viragomann @Bambos
                  last edited by

                  @bambos
                  Okay, I've reproduced this in my network. You're right. The ping doesn't work if the source is the implicit network variable for what ever reason.
                  But it works, when I state the tunnel network in numbers.

                  Yes, seems as a bug, which shouldn't behave like that.

                  B 1 Reply Last reply Reply Quote 1
                  • B
                    Bambos @viragomann
                    last edited by

                    @viragomann thanks a lot Sir, i'm glad we figured this out. How we can put that on official bugs so netgate could resolve ?

                    V 1 Reply Last reply Reply Quote 0
                    • V
                      viragomann @Bambos
                      last edited by

                      @bambos
                      You may find a link in the forum, I think.
                      But did you get this on a current release? I reproduced it on 2.4.5, so I don't know if it still persists.

                      Additional info:
                      Checked out /tmp/rules.debug and found that the net is replaced with the clients IP with /32 mask.
                      So obviously the net doesn't work properly with OpenVPN interfaces on the client, the tunnel network is not taken over in the variable even if it is stated in the settings.

                      B 1 Reply Last reply Reply Quote 1
                      • B
                        Bambos @viragomann
                        last edited by

                        @viragomann client is 2.4.5 and server is 2.5.1.

                        V 1 Reply Last reply Reply Quote 0
                        • V
                          viragomann @Bambos
                          last edited by

                          @bambos
                          So we don't know if it still persists in recent versions at all.
                          I kicked my only one 2.6 installation due to dynamic DNS issues.

                          I would prescind from reporting a bug in this case.

                          B 1 Reply Last reply Reply Quote 0
                          • B
                            Bambos @viragomann
                            last edited by Bambos

                            @viragomann Hello Sir !!!

                            I have tested this again with both client and server to 2.6 latest version.
                            Same problem appears.

                            0392bda0-4005-4715-9a6e-0483d0e95ca8-image.png

                            First rule is not letting the client ping, so gateway is red.
                            second rule let the client gateway ping (and going green)

                            172.18.47.2 it is a part of the LAN47_MXGREEN net, so to my understanding is the same firewall rule !!

                            as a prove i have it first, and 0B traffic there. Is this a bug now ?

                            V 1 Reply Last reply Reply Quote 0
                            • V
                              viragomann @Bambos
                              last edited by

                              @bambos
                              Yes, I agree that it behaves in an other way than expected. Obviously the 'interface net' alias doesn't work with OpenVPN interfaces.

                              If you check Status > Interfaces the site to site OpenVPNs interfaces have a 255.255.255.255 mask. So it only includes the interface IP. And the same is adopted in the rule.
                              Don't know, what's the reason for this behavior.

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