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

    Traffic through another wan, 2WAN 1LAN 1VLAN

    Scheduled Pinned Locked Moved NAT
    30 Posts 2 Posters 5.8k Views 2 Watching
    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 Offline
      GDSF @viragomann
      last edited by GDSF

      @viragomann

      00845a5d-2057-4bdc-bd4d-b584489d8f76-image.png

      seems to have worked

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

        @gdsf
        No, not this way. You have to state the VIP at source.
        Your WAN IP is a private one as shown above.

        G 1 Reply Last reply Reply Quote 0
        • G Offline
          GDSF @viragomann
          last edited by

          @viragomann

          b74a0b73-006c-493a-976e-4bc575646d8d-image.png

          It went wrong, do you know what could cause it?

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

            @gdsf
            I got the idea, that the ping tool is not an appropriate way to test this. The ping requests might go out to the default gateway.

            You have to ping from a VLAN10 device. The policy routing rule should direct it out to WAN2 and it should get the VIP as source.
            So sniff the traffic with packet capture while pinging to investigate if all these work.

            G 1 Reply Last reply Reply Quote 0
            • G Offline
              GDSF @viragomann
              last edited by

              @viragomann that's the problem, if I could make VLAN10 travel over WAN2 it would already solve the problem

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

                @gdsf
                The policy routing rule forces all traffic, which the rule is applied to the WAN2 gateway. There is no way around this.
                The screenshot ot the rule above shows, that it treated already some traffic. But maybe not all from VLAN10.

                If you suspect that the rule is circumvented by some packets for whatever reason, check if there are other rules with higher priority applied to VLAN10 traffic. Consider that floating rules and rules on interface group are probed before ones on the interface tab. So check if you have any.

                G 2 Replies Last reply Reply Quote 0
                • G Offline
                  GDSF @viragomann
                  last edited by

                  @viragomann I just have an interface group configured in routing for failover, otherwise my firewall rules are any for all

                  1 Reply Last reply Reply Quote 0
                  • G Offline
                    GDSF @viragomann
                    last edited by

                    @viragomann SQUID Proxy intervene in this matter?

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

                      @gdsf
                      Yes. See here: Troubleshooting Multi-WAN

                      I've read somewhere that there is an option to do the policy routing within squid, but I don't use it, so cannot help here.

                      G 1 Reply Last reply Reply Quote 0
                      • G Offline
                        GDSF @viragomann
                        last edited by

                        @viragomann Bruh, I disabled squid and the firewall rules worked normally.

                        Thank you very much friend you helped me. have a great day !

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