Navigation

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

    Changing LAN IP to 169.254.1.1

    Installation and Upgrades
    5
    14
    11432
    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.
    • P
      peekmessage last edited by

      Trying to change the LAN IP address to 169.254.1.1 with DHCP range of 169.254.1.100-169.254.1.200.  Everything works with the default 192.168.1.1 address, but as soon as I change it to the 169.254.1.1 address, I'm not able to connect to anything outside the LAN.

      Any ideas on how to fix this would be appreciated.

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

        Errrr… 169.254.0.0/16 is link-local? You shouldn't use that.

        1 Reply Last reply Reply Quote 0
        • Cry Havok
          Cry Havok last edited by

          As SeventhSon said - don't do that.

          Stick with the RFC-1918 IP ranges, using anything else will cause you problems unless you own the IP range in question (and know what you're doing).

          1 Reply Last reply Reply Quote 0
          • P
            peekmessage last edited by

            Sigh, this is the only way I can use company VPN and have access to internal network at the same time also.

            Thanks for the replies.

            1 Reply Last reply Reply Quote 0
            • P
              peekmessage last edited by

              So I just verified, and according to IT this is the only way I can VPN and have access to internal network.  Is there anyway I can get this to work on pfSense?

              1 Reply Last reply Reply Quote 0
              • Cry Havok
                Cry Havok last edited by

                Are you sure? They're using all of 192.168.x.y/16, 172.16.x.y/16 to 172.31.x.y/16 and 10.x.y.z/8? There's more to the RFC-1918 ranges than just 192.168.x.y/16 after all.

                The whole point of the 169.254.0.0/16 range is that there is no DHCP allocation.

                1 Reply Last reply Reply Quote 0
                • P
                  peekmessage last edited by

                  I doubt if they are using all of it, unfortunately this is how they have it setup. I used to have this setup with my old not so smart router and worked fine. In 192.168.x.x everything works fine, including the VPN, except am not able to access any thing on the LAN while logged in. I just really don't want to go back to the old setup, the hardware is a lot slower.

                  There is no way to convince pfSense to go along with the 169.254.x.x setup?

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

                    So if you change your LAN to 10.something (or anything they don't use), it should be fine!

                    1 Reply Last reply Reply Quote 0
                    • P
                      peekmessage last edited by

                      Switching to 10.x.x.x would get things working fine in the house (same as 192.168.x.x), allows VPN to work fine also.  But once I log into the VPN which uses 169.254.x.x I am not able to connect to anything else inside the house.

                      If I switch the router to 169.254.1.1 this would be resolved (as it was with the netgear router), except I haven't been able to get pfSense to work in this configuration.  I know this is not ideal, but I can't change the way the VPN is configured, so I have to play along with their rules.  >:(

                      Does anyone know what is preventing 169.254 subnet from working?

                      Thanks

                      1 Reply Last reply Reply Quote 0
                      • Cry Havok
                        Cry Havok last edited by

                        Your work is using 169.254.x.x for the VPN - sheesh! The VPN is presumably a bridge then?

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

                          http://en.wikipedia.org/wiki/Link-local_address
                          A link-local address is an Internet Protocol address that is intended only for communications within the segment of a local network (a link) or a point-to-point connection that a host is connected to. Link-local addresses allow addressing hosts without using a globally-routable address prefix that must be obtained from a local or regional Internet registry. Routers do not forward packets with link-local addresses.

                          So if your old router forwarded packet from that 169.254.0.0/16, it did so in error. You shouldn't forward link-local adresses, because they are for use on a single network segment only.

                          Anyway, it's probably blocked because it's (rightfully) in the bogons table:
                          /etc/bogons

                          You could disable bogon checking for the interface or remove the entry "169.254.0.0/16" in there.

                          Edit: Sheesh indeed

                          1 Reply Last reply Reply Quote 0
                          • P
                            peekmessage last edited by

                            Thanks for all the information.  I ended up using a second network card for my home network.  So far it's working, and I can keep the home network on 192.168.x.x, and leave them to deal with their network :)

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

                              Whoever had the bright idea to use link-local addressing for anything should be fired (and fired at).

                              1 Reply Last reply Reply Quote 0
                              • X
                                XIII last edited by

                                @jimp:

                                Whoever had the bright idea to use link-local addressing for anything should be fired (and fired at).

                                +1 with the possibility of torture…as its torture.

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

                                Products

                                • Platform Overview
                                • TNSR
                                • pfSense
                                • 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