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

    Pfsense 2.2.6 mangling staticmap entries

    Scheduled Pinned Locked Moved Problems Installing or Upgrading pfSense Software
    5 Posts 2 Posters 1.3k 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.
    • A
      apmuthu
      last edited by

      The original stanza for a <staticmap>entry which worked was:

      
      ..
      	 <dhcpd><lan><enable><range><from>192.168.10.30</from>
      				<to>192.168.10.59</to></range> 
      			 <staticmap><mac>92:ff:aa:dd:36:dd</mac>
      				<ipaddr>192.168.10.15</ipaddr>
      				<hostname>MyDesktop</hostname></staticmap> 
      			 <failover_peerip><dhcpleaseinlocaltime><defaultleasetime><maxleasetime><netmask><gateway><domain><domainsearchlist><ddnsdomain><ddnsdomainprimary><ddnsdomainkeyname><ddnsdomainkey><mac_allow><mac_deny><tftp><ldap><nextserver><filename><filename32><filename64><rootpath></rootpath></filename64></filename32></filename></nextserver></ldap></tftp></mac_deny></mac_allow></ddnsdomainkey></ddnsdomainkeyname></ddnsdomainprimary></ddnsdomain></domainsearchlist></domain></gateway></netmask></maxleasetime></defaultleasetime></dhcpleaseinlocaltime></failover_peerip></enable></lan></dhcpd> 
      ..
      
      

      When creating a new <staticmap>or editing an existing one, pfSense v2.2.6 mangles it making it useless (when using it for port forwarding) by moving most entries between the ending tags</staticmap> and into the <staticmap>stanza like:

      
      	 <dhcpd><lan><enable><range><from>192.168.10.30</from>
      				<to>192.168.10.59</to></range> 
      			 <staticmap><mac>92:ff:aa:dd:36:dd</mac>
      				<ipaddr>192.168.10.15</ipaddr>
      				<hostname>MyDesktop</hostname>
      
      				<filename></filename>
      				<rootpath></rootpath>
      				 <defaultleasetime><maxleasetime><gateway><domain><domainsearchlist><ddnsdomain><ddnsdomainprimary><ddnsdomainkeyname><ddnsdomainkey><tftp><ldap></ldap></tftp></ddnsdomainkey></ddnsdomainkeyname></ddnsdomainprimary></ddnsdomain></domainsearchlist></domain></gateway></maxleasetime></defaultleasetime></staticmap></enable></lan></dhcpd> 
      
      

      Even the original <netbootfile>entry is missing now!</netbootfile></staticmap></staticmap>

      1 Reply Last reply Reply Quote 0
      • C
        cmb
        last edited by

        It's not moving anything. The original static mapping was either added manually to the config, or was from a several year old version. Those tags all apply to that static mapping. The netbootfile tag no longer exists by that name and hasn't been used in about 7 years, 2.0.x versions, which is why it gets unset upon edit.

        The values outside the static mapping getting unset isn't functionally problematic either from the looks of it (certainly wouldn't hurt port forwarding in any way), it's unsetting values that are at their defaults. But it shouldn't do that. Check your config history, Diag>Backup/restore, Config History tab, and use the diff there. What change unset those values, which page was that on?

        I pasted that exact original config snippet in, edited that static mapping, and it adds the additional lines to the static mapping as it should and leaves everything outside the static mapping alone. services_dhcp_edit.php doesn't touch anything outside static mappings.

        1 Reply Last reply Reply Quote 0
        • A
          apmuthu
          last edited by

          The problem appears solved.

          A fresh edit and save of the staticmap entry resulted in this snippet from the config file:

          
          	 <staticroutes><dhcpd><lan><enable><range><from>192.168.10.30</from>
          				<to>192.168.10.59</to></range> 
          			 <staticmap><mac>92:ff:aa:dd:36:dd</mac>
          				<cid>MyDesktop</cid>
          				<ipaddr>192.168.10.15</ipaddr>
          				<hostname>MyDesktop</hostname>
          
          				<filename></filename>
          				<rootpath></rootpath>
          				 <defaultleasetime><maxleasetime><gateway><domain><domainsearchlist><ddnsdomain><ddnsdomainprimary><ddnsdomainkeyname><ddnsdomainkey><tftp><ldap></ldap></tftp></ddnsdomainkey></ddnsdomainkeyname></ddnsdomainprimary></ddnsdomain></domainsearchlist></domain></gateway></maxleasetime></defaultleasetime></staticmap> 
          			 <failover_peerip><dhcpleaseinlocaltime><defaultleasetime><maxleasetime><netmask><gateway><domain><domainsearchlist><ddnsdomain><ddnsdomainprimary><ddnsdomainkeyname><ddnsdomainkey><mac_allow><mac_deny><tftp><ldap><nextserver><filename><filename32><filename64><rootpath></rootpath></filename64></filename32></filename></nextserver></ldap></tftp></mac_deny></mac_allow></ddnsdomainkey></ddnsdomainkeyname></ddnsdomainprimary></ddnsdomain></domainsearchlist></domain></gateway></netmask></maxleasetime></defaultleasetime></dhcpleaseinlocaltime></failover_peerip></enable></lan></dhcpd></staticroutes> 
          

          This is used in a VNC Port Forwarding entry for entry from the wan.

          Even within the LAN, we could not enter the MyDesktop PC earlier.

          But now we can.

          1 Reply Last reply Reply Quote 0
          • C
            cmb
            last edited by

            @apmuthu:

            A fresh edit and save of the staticmap entry resulted in this snippet from the config file:

            Which is exactly what should be there.

            The port forward has nothing to do with the static mapping. The static mapping affects DHCP, strictly what IP (and related options) the client receives. Removing those additional tags, which are all at defaults and hence do nothing, doesn't impact the client. If the client's getting the correct IP from DHCP, that's the extent of static mappings involvement.

            Is the machine getting the IP defined in the mapping when it doesn't work?

            1 Reply Last reply Reply Quote 0
            • A
              apmuthu
              last edited by

              Thanks @cmb.
              All works correctly as it should.
              It would be better to purge all blank entries from the config file to make it readable.
              There can be a checkbox in the save config form to choose to save blank entries or not.
              Safe defaults on being blank and being assumed blank when the config file is parsed would be in order.

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