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

    Policy based routing via alias (mostly working)

    Scheduled Pinned Locked Moved OpenVPN
    9 Posts 3 Posters 870 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.
    • S
      Soogs
      last edited by

      Hi all

      pretty new to pfSense but have been playing with it for a week now and gone from VM to baremetal.

      I've got OpenVPN connected to NordVPN as a client.

      Setup a VLAN for VPN clients. setup a killswitch floaring rule.

      These all work fine but I'm left with one issue which was working before I nuked and rebuilt:

      I've created an alias with static nodes which I want to route via OpenVPN and it is working - but not for all devices.

      alias group:

      • NAS (wired lan) - working
      • PC (wired vlan)- working
      • VM (wired vlan)- working
      • tablet (wireless)- working
      • pixel phone (wireless)- not working (random mac is off)
      • pc (wireless) - not working

      the alias is working as I lose access completely (to the non working devices) if I add the last 2 devices to the alias

      as stated these 2 devices which are now not working - were working in a previous install (same hw and 2.6.0ce)

      firewall rules and nat are all setup and working fine (the working tablet is in the same subnet/vlan as the two devices having issues)

      There are no IP conflicts.

      has anyone had this issue and overcome it? any advice on how to trouble shoot this?
      TIA

      M 2 Replies Last reply Reply Quote 0
      • M
        marvosa @Soogs
        last edited by marvosa

        @soogs Can we see your policy route rule, along with your alias and your outbound NAT rules? Also, since you mentioned it, lets see your floating rules.

        S 1 Reply Last reply Reply Quote 0
        • S
          Soogs @marvosa
          last edited by

          Hi @marvosa screenshots attached as requested - thanks for taking a look.
          I have sinse posting added/chaned clients in the alias - all working apart from the orignal two devices that refuse to work still.

          63e7b91a-c21a-4ecc-85d1-3441678ea246-image.png

          ^Alias's - second rule is missing IP's 192.168.40.10 and 192.168.40.30 (these are the devices which do not work when added to this rule. everything else listed in the rule routes fine).

          d63172b2-4740-4c45-aacb-c11a631a24f3-image.png

          ^NAT mappings:
          60.0 is vpn only and works fine
          40.0 is WiFi VLAN and will use the alias
          1.0 is LAN and will use the alias

          1ed78a72-fa67-4233-a510-1a287f241a94-image.png

          ^WiFi rules

          5f724399-56d6-4f89-b027-a5ea46fdf420-image.png

          c88532fe-bd3d-40c6-b151-31ea36a0fcee-image.png
          ^Tagged string

          d18f816f-5e90-47c9-a926-13a54bb04d83-image.png

          4c725fd6-99cd-45fc-9c74-61287ed8e1f7-image.png

          ^Floating rule Deny any tagged traffic to WAN

          fd08b161-105e-4598-8480-f9f169a615e7-image.png

          ^tagged string

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

            update: I've manually set static ip with DNS set to 1.1.1.1 and it works.
            my custom dns is 192.168.1.7 and 192.168.1.8 which both the pixel and pc happiliy use when they are not apart of the alias.... so confused....

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

              @soogs
              Yeah, a policy routing rule forces all matching traffic to the stated gateway. This includes DNS requests as well.
              Hence if the Alias_RFC1918_nets doesn't include your DNS servers the requests are forced out to the VPN gateway.
              And it doesn't look to me like as it does in order to be honest.

              That alias looks strange, as there were single IPs stated in it.
              Mine RFC1918 alias with network ranges inside (type Networks) looks pretty different:
              b55a4abe-9b6d-4b67-bff7-e8a64d3a846c-grafik.png

              There is basically no need to state individual networks inside this alias. Where you use it, it can securely match to the whole RFC 1918 range as well.

              S 1 Reply Last reply Reply Quote 1
              • M
                marvosa @Soogs
                last edited by

                @soogs ^^Agreed about the RFC1918_nets alias. I was going to look more into it, but @viragomann beat me to it. You'll need to change the type from "Host(s)" to "Network(s)" and choose the appropriate mask. Although, the rule is moot considering there's an any/any at the bottom anyway. I'd get rid of it.

                S 1 Reply Last reply Reply Quote 1
                • S
                  Soogs @viragomann
                  last edited by

                  @viragomann thank you so much!
                  this was bugging the life outta me and turns out i just needed to pay more attention.
                  just spent 10 mins of my clicking delete to fix this (wouldnt let me delete the alias as it was in use).

                  thanks again

                  1 Reply Last reply Reply Quote 0
                  • S
                    Soogs @marvosa
                    last edited by

                    @marvosa thank you for pointing this out --completely missed it.
                    If I get rid of this rule then I lose the ability to access local nodes / split tunnel

                    thanks again for you help

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

                      All sorted now, a couple of badly configured alias's were the issue and have now been rectified. all is working now as desired.

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