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

    PFsense FQDN curl issue.

    Scheduled Pinned Locked Moved General pfSense Questions
    5 Posts 2 Posters 287 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.
    • J
      jamesthetechie
      last edited by

      Hello, i have newly set up a PFsense ha cluster, im coming from a unifi setup and im running into some issues.

      i have 2 wan ip's, ill call them .148 and .149. on .148 i have it assigned to vlan15 which i have 2 VM's on that vlan. the .149 has one VM.

      the 2 vms on host 15 run 2 different docker hosts, each docker host is behind traefik.
      vm 1 runs traefik, a website, a git instance and a nextcloud instance.
      vm 2 runs an appwrite instance. (web based database)

      vlan 16 runs some video games (no traefik), so i want to keep them separate.

      i also have a VM on vlan 15 that doesnt have traefik that i use for testing and that wont talk to either.

      The issue im running into is when i try to curl any FQDN (eg. test1.server.com) that assigned to a server behind the pfsense box, it resolves to the correct WAN IP, but it doesnt pass any of the traffic. when i curl the IP its perfectly fine over http, but my cert for https need the fqdn to reply.

      ive tried a mix of nat reflection and that hasnt panned out, the only way ive been able to get it to respond over the FQDN is by setting up host override, but that still only works for http and not https since traefik has that cert for the FQDN, this also means i have to remove the firewall rule preventing intervlan communication.

      What would be the best way to get this functionality working? apologies if got something wrong, im quite new to PFsense and it has been quite the learning curve.

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        How exactly are you assigning the public IP to the VMs? It sounds like you might just be forwarding traffic to it?

        Where are you running the CURL test from? Does it behave differently from a different VLAN or from an external host?

        J 1 Reply Last reply Reply Quote 0
        • J
          jamesthetechie @stephenw10
          last edited by

          @stephenw10
          the public IP's are port forwarded to the VM IP's.

          i can run the curl test from the test1 vm or test2 vm and try to get either and it fails.

          all Vlans behave the same way, externally they work fine and i can curl as expected and hit the webpages properly.

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            Ok so I assume the FQDN resolves to the external IP for each of the internal test VMs? And you have NAT reflection enabled so requests to it are sent back to the internal IP traefik is listening on?

            Do you have 'Enable automatic outbound NAT for Reflection' set? Without that you will get asymmetry when testing from local subnets.

            What error do you see when trying https?

            J 1 Reply Last reply Reply Quote 0
            • J
              jamesthetechie @stephenw10
              last edited by

              @stephenw10
              Thanks for looking at this and helping me out, when i restarted the states, and toggled some firewall rules after testing with packet capture, it just randomly started working.

              ive rebooted a couple times and changed things around and it seems to be good for now, not sure what caused the issue however, but i think i should be good now.

              Thank you again for the help.

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