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

    Can't enter valid static IP for new interface

    Scheduled Pinned Locked Moved
    2.1 Snapshot Feedback and Problems - RETIRED
    4
    5
    2.0k
    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.
    • C
      clarknova
      last edited by

      I apologize in advance, because some of the following details are vague due to me reporting this problem after the fact and not having a clear idea of how to reproduce it. I realize that if I'm the only one experiencing this issue then this thread isn't likely to go anywhere, so I'm hoping that some other poor soul's search will land him here so that we can get a clearer picture of what the problem is/was.

      2.1-BETA1 (amd64)
      built on Wed May 1 12:20:46 EDT 2013
      FreeBSD 8.3-RELEASE-p8

      I have a multiplicity of vlan interfaces and it's been working fine. A few weeks ago I added a new vlan to an interface that was already parent to many vlans. I then attempted to activate and assign a static IP address of 192.168.86.254/24 to the new interface, but after hitting the Save (Apply?) button, I received an error to the effect that the address or subnet was already in use on another interface. After the page refreshed itself, the text in the static IP assignment box had changed to 192.168.1.254.

      After attempting this a couple of times with the same result, I tried rebooting pfsense, knowing that at times in the past a reboot has been necessary to 'cement' changes to interfaces. Even after a reboot however, the same thing happened.

      I also attempted downloading and modifying the interfaces-config.xml file. I confirmed through search that '192.168.86' did not occur anywhere in the file, then made the change and uploaded the file. I don't recall if I saw errors at this point, but the interface address again reverted to 192.168.1.254/24 in the GUI. I don't recall if I rebooted before, after, or before and after attempting this direct edit of the config file.

      At this point I decided to just accept the fact that my new interface would be 192.168.1.254/24, and I enabled the dhcp server and set a corresponding range for the pool on the interface (the dhcp server was already enabled on other interfaces).

      For a few weeks this configuration worked fine (although not a single client connected to the new interface, so by 'fine', I mean it in the sense of the whole system without actually testing the new network).

      Today however, pfsense stopped responding on all network interfaces for reasons that I am unable to diagnose remotely. I power-cycled the firewall and it came back up fine. Within a short time however, I noticed that dhcp leases weren't being handed out on any interface. I found in the system log "bad range, address 192.168.1.100 not in subnet 192.168.86.0 netmask 255.255.255.0". The new interface had reverted to an address of 192.168.86.254/24, but the dhcp server still had the now-incompatible pool of addresses in the 192.168.1.0/24 subnet, and the dhcp server was failing to hand out leases on all interfaces, presumably because it had failed to start due to this error.

      I fixed the address range on my new subnet (back to the now-active 192.168.86.0/24 subnet) and after applying changes, dhcp appears to be working normally on all interfaces where it is enabled.

      So my questions are:

      1. Why was I seeing the bogus error when attempting to assign a valid, unused address and subnet, even after reboots?
      2. Why did the interface revert at some point to the address that it hadpreviously rejected? The only reasonable explanation I can think of is that the config file had retained my manual edits despite the GUI reverting to a different range. At some point, pfsense re-read the config file and this time didn't have a problem with it, and applied it.

      Anybody seen anything similar? I apologize if this is a known issue. Because I don't remember the exact error I saw, I wasn't able to formulate search terms specific enough to my situation to produce any meaningful results.

      edit: I should add, that the only config changes I have made since then were some minor modifications to some existing firewall rules, and a manual re-ordering of my interfaces in the interfaces-config.xml file. I downloaded that file and made the ordering changes yesterday, then uploaded the file again yesterday. Having just looked at the file copy that I edited locally, I see that the assigned address for my new interface is 192.168.86.0/24, so obviously that edit which I made a few weeks ago survived in the xml file, and then was activated today, probably when the firewall booted after having been power cycled due to the lock-up.

      In retrospect, had I rebooted pfsense immediately after manually editing the config file the first time, it seems like the change may have taken effect at that time. That still doesn't answer the question of why the change was rejected when attempting to make it in the GUI, even after reboots. It also doesn't answer the question of why pfsense locked on me today, but obviously there's not much forensic evidence now on which to base a hypothesis on this point.

      db

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

        We'd need to see the entire config to say anything for sure.

        If it detected an overlap, it was probably due to an improper subnet mask on another interface, not the new IP you were entering.

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

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

          This continues to baffle me. If I PM'ed my config would somebody look at it?

          Here's some new info that only confuses me more. I logged into this pfsense today (via the internet/WAN) and OPT13 is still up with the assigned IP address of 192.168.86.254. However when I try to connect to hosts on the LAN subnet (192.168.85.0/24), these hosts do not respond. I run 'ifconfig em0_vlan85' and discover that the LAN interface has an IP of xx.xx.225.253, which is an IP address that is assigned by pfsense (dhcp reservation) to a host on another subnet. Except now pfsense is assigning that address to its own LAN interface??

          So I attempt to browse (still from the internet/WAN) to the web server on host xx.xx.225.253 and the attempt times out. A concurrent tcpdump on em0_vlan240 (the interface that the web server is attached to) show no packet to the web server.

          Pfsense's GUI shows that the assigned IP address of em0_vlan85 is 192.168.85.254/24, but the shell disagrees. Now I disable OPT13 from the GUI, and 'ifconfig em0_vlan85' in the shell now shows the correct IP address of 192.168.85.254/24. When I try to re-enable OPT13 with the iP address of 192.168.86.254/24, pfsense again complains that the address or network is in use.

          Next I try to enable OPT13 with and IP address of 192.168.87.254/24. This time I am able to save and apply, but the Status:Interfaces page and the console both show that the interface is down. I hope that a reboot will bring it up, but I'm not confident to make any assumption at this point.

          db

          1 Reply Last reply Reply Quote 0
          • P
            phil.davis
            last edited by

            I have no idea about the web server thing, but as JimP says earlier, there is probably a subnet mask wrong somewhere else in the config. PM me the config if you like and I can try and spot what it is.

            As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
            If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

            1 Reply Last reply Reply Quote 0
            • M
              mikeisfly
              last edited by

              I have seen some weird things to like when making a VLAN and assigning that VLAN to an interface you have to look at the assignments carefully. Pfsense will sometimes rearrange your previously last VLAN and assign it to a different interface. I always double check before clicking apply now. This just happened to me yesterday and I'm running 2.1RC0 i368 built on Thu May 23 19:52:31 EDT 2013. I hope this makes sense, let me give an example:

              I have a parent interface of lets say em0 and on em0 I will make the following VLANs:

              10 - core
              20 - admin
              30 - research

              Now if I make another VLAN 40 and want to assign that to em0 I click the (+) symbol to make the assignment but the Pfsense will move VLAN 30 to a different interface or VLAN. So I always double check before I click apply to make sure things haven't changed.

              This might be what is happening to you which could explain why Pfsense is reporting the IP range conflict. I think this problem is repeatable.

              Hope this helps.

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