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

    Why two binat lines for npt?

    Scheduled Pinned Locked Moved IPv6
    1 Posts 1 Posters 842 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.
    • H
      hcoin
      last edited by

      In experimenting with Npt, PFsense generates two binat rules.

      First:

      binat on <wan interface="">from <local v6="" prefix="">to any -> <global v6="" prefix="">Which, as far as I can tell from the docs, means "set up a 1-1 mapping so outbound from private  source gets the public prefix as source, and inbound from public with public prefix as dest gets the private prefix as dest before filtering and routing."  This is (I think) a stateless procedure.

      But then pf creates another rule:

      binat on <wan interface="">from any to <global prefix="">-> <private prefix="">Which I think means 'anything outbound with source in the global prefix gets source mapped to the private prefix (where exactly nobody can do anything with it..), and anything  inbound with dest using the private prefix gets forwarded to dest mapped to the global prefix'.  But as doing that makes little sense to me…  I must have some category error in understanding these things.

      What is the second binat rule meant to accomplish?  Could someone take me through:

      a:  Kernel app generates a packet with <private prefix="">outbound on npt interface, what does downstream router see as the prefix?  How do the two rules apply?

      b:  A packet comes in on <lan>with <private prefix="">policy routed to be outbound on npt interface, what down downstream router see as the prefix?  Which rules do that?

      c: What is the second rule supposed to enable?</private></lan></private></private></global></wan></global></local></wan>

      1 Reply Last reply Reply Quote 1
      • B bob2022 referenced this topic on
      • First post
        Last post
      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.