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

    Routing between LAN and WAN

    Scheduled Pinned Locked Moved Routing and Multi WAN
    4 Posts 3 Posters 732 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
      s0lucien
      last edited by

      I have the following setup :
      PFSense has internet (WAN) assigned by upstream DHCP (network not controlled by pfsense), and it acts as a gateway to a LAN running on 10.10.10.1/24 (static IP + pfSense DHCP server running on the LAN segment)
      pfSense is also acting as DNS forwarder for the LAN, and that works fine
      nslookups from VMs on the LAN work correctly, but ip-based traffic is not flowing through PFSense
      i'm now trying wireshark , and also shutting down all firewall rules to rule out a firewall issue
      basically what I want is whenever a ( for example google.com) request comes in from a VM running inside the LAN network (10.10.10.143 loads google.com)
      DNS resolves it to be 8.8.8.8
      pfsense sees that 8.8.8.8 is not on the 10.10.10.1/24 network , so it forwards it to 10.10.10.1 (itself)
      from there i want pfSense to use WAN (externally assigned by dhcp - 178.something.something.something/28)
      to perform the routing to 8.8.8.8
      and upon 8.8.8.8 response on 178.somethinh.something , pfsense should send it from the LAN GW 10.10.10.1 to 10.10.10.143
      so round trip completes
      does this make sense ?

      my reasoning is that it could be:

      1. a gateway configuration issue
      2. a bridging issue
      3. a firewall issue - pfSense by default maybe blocks 10.10.10.1 <-> 178...* traffic, so the fix would be to allow this kind of LAN <-> WAN traffic
        what do you guys think ? Feel like i'm quite close to understanding how to perform this request end-to-end
      S V 2 Replies Last reply Reply Quote 0
      • S
        SteveITS Galactic Empire @s0lucien
        last edited by

        @s0lucien I think you are looking for this?
        https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html

        Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
        When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
        Upvote 👍 helpful posts!

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

          @s0lucien said in Routing between LAN and WAN:

          pfsense sees that 8.8.8.8 is not on the 10.10.10.1/24 network , so it forwards it to 10.10.10.1 (itself)

          What do you think, is the benefit of this?
          pfSense redirects the traffic to its default gateway (or even to another one according to its routing table) by default. So that should work out of the box.

          pfsense should send it from the LAN GW 10.10.10.1 to 10.10.10.143

          Any traffic to the network devices is sent from the interface IP surely.
          Or do you mean, it should use the interface IP as source? That's not possible, pfSense does no NAT on respond packets. And if it was possible, that was a very bad idea at all, because some client software do not accept responses from a different IP than the origin destination IP the request was sent to.

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

            This was fixed by deleting all manually added GWs and using the one assigned by the upstream DHCP as default. the DNS-Redirect rule does not seem to have any effect (enabling/disabling it does not affect connectivity).
            Thank you guys for helping out ^_^

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