Navigation

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

    RFC 2136 behind transfer net

    DHCP and DNS
    2
    5
    2182
    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.
    • JeGr
      JeGr LAYER 8 Moderator last edited by

      Hi all,

      I'm wondering about dyndns on pfSense. I have an issue with RFC2136 vs DynDNS providers. If I'm using dyn.com or other providers, pfSense is checking against an online URL and handing over her "external" address. As I am bound to run the pfSense installation behind an already NATting front router (and no that can't be disabled :( ), I am using a small 192.168… transfer net between the gateway and the pfSense. Besides that, the dyn.com IP is always checking OK and handled well. Now I wanted to use RFC 2136, as I'm running my own nameserver for that domain and setup worked fine. But the address handed over to my BIND-NS is the external 192.168.168.2 address from the transfer net, not the external address like dyn.com.

      So: can that behaviour be switched or can I somehow "manipulate" the pfSense to use the same checking method as for the "normal" dyndns setup?
      That would be real great as I will perhaps get another uplink line (DSL fallback) with PPPoE where the normal behavior is no problem at all (as the WAN IF will have the original address and no transfer net).

      Greets
      Grey

      1 Reply Last reply Reply Quote 0
      • jimp
        jimp Rebel Alliance Developer Netgate last edited by

        That is probably a deficiency in our RFC2136 code. We don't have a lot of people using that currently so it may not have ever been requested that it work that way. Feel free to open up a feature request ticket at http://redmine.pfsesne.org/

        1 Reply Last reply Reply Quote 0
        • JeGr
          JeGr LAYER 8 Moderator last edited by

          Hey jimp,

          I added issue #2727 (https://redmine.pfsense.org/issues/2727) for this topic, hopefully to be included into a future 2.1BETA build. I hope it's clear, what I am trying to describe but I think a switch for the behavior (take <if>address vs. do external checking of IP over <if>) would be nice. As the checking code seems to be already in place (as it is used for the other dyndns services), that hopefully isn't that much of a hassle.

          Meanwhile do you have any idea, how to perhaps manually do this (perhaps using a custom cron and doing a hand-made nsupdate)?
          As I currently are in need of this I'd be willing to test any idea :) I'm currently workaround'ing by using a dyn.com address, but as my cable provider doesn't change IP that often (perhaps once or twice in three months), dyn.com is expiring every once in a while by not being updated and as I'm running my own DNS anyway, it's pointless on buying a paid account from them, if I could do the same thing via dDNS Updates myself :)

          Greets
          Grey</if></if>

          1 Reply Last reply Reply Quote 0
          • jimp
            jimp Rebel Alliance Developer Netgate last edited by

            Really not sure, sorry. I've worked on the regular dyndns code but not the RFC side of things (aside from simple bug fixes).

            1 Reply Last reply Reply Quote 0
            • JeGr
              JeGr LAYER 8 Moderator last edited by

              If you worked with the other dyndns code, is it somehow possible to trigger the detection of the external WAN address and write that to a file? That whould help, as it could be written to the nsupdate file.

              1 Reply Last reply Reply Quote 0
              • First post
                Last post

              Products

              • Platform Overview
              • TNSR
              • pfSense Plus
              • Appliances

              Services

              • Training
              • Professional Services

              Support

              • Subscription Plans
              • Contact Support
              • Product Lifecycle
              • Documentation

              News

              • Media Coverage
              • Press
              • Events

              Resources

              • Blog
              • FAQ
              • Find a Partner
              • Resource Library
              • Security Information

              Company

              • About Us
              • Careers
              • Partners
              • Contact Us
              • Legal
              Our Mission

              We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

              Subscribe to our Newsletter

              Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

              © 2021 Rubicon Communications, LLC | Privacy Policy