Client Network Card Cannot get new IP

saytar

Hi….I have a peculiar problem. I have gotten everything pretty well set in Pfsense Box (ver 2.1.3). Have the WAN set to my Static IP that works, LAN is set at default 192.168.1.1, Have two interfaces bridged for home network working, and one for future DMZ possibly. Problem is I stayed plugged into the LAN interface throughout entire setup and being new at this type box made several changes to IP assignments on all the interfaces until I settled on what I have now.
Sooooo now I have gone and moved the Client interface to the Home Network Bridge to proceed with tweaking and guess what....Pfsense Box will not give the Client NIC a new address and the NIC defaults to the 169.xx.xx.xx settings. Network and sharing shows connected to A network, but with wrong IP, etc. At first I thought I had a bad NIC in Client computer, so replaced CAT 6 cable with new cable...same issue, so installed a dual NIC in client and tried to change from one Pfsense interface to another...works perfectly and receives a new IP, etc immediately. Ok still might be a bad NIC so pull out an Old router plugged "Bad" NIC into it.....bang gets a new IP, etc right away..working perfectly as intended. Ok so maybe its a software problem....well Windows had not been reloaded in 2 or 3 yrs so maybe hidden files somewhere with scrabbled settings......soo reinstalled Windows and reconfigured it. SAME problem only the IP did change to current settings, but still will not move to another Pfsense interface and get new settings...so out comes old Router, plug it in ,....Bingo gets new IP, etc no problem.

Now I am down to the fact that in spite of the fact that Pfsense Box is Working OK??? Nothing appears to be out of wack and Home network is working Just this ONE NIC is fubared. This leads me to think that with all the assignment changes that were made (box was rebooted several times during all this) that somewhere in the bowel's of the Unix files somewhere there is an IP assignment with the MAC of this One NIC locked in and will not give it a proper assignment with current Interface IP's.

I even have a PIA VPN setup working except on the Home Network Bridge I directed the Bridge with Firewall Setting to Use WAN instead of PIA VPN interface and so far everything on that Bridge Network seems to be working as intended. But since I reloaded Windows and received another IP the LAN interface (which was running on the VPN) has changed to running in the open and not through the VPN. I haven't been through that issue yet as the NIC issue is Right at the Moment the Biggie.

I suspect that one of the files (in Unix, not any of the WebConfig) may be duplicated somehow or that Pfsense is using the wrong conf file for this NIC or Interface.....Now I can plug another computer I have into the LAN interface and bingo no problems, it will go from LAN to Bridge, to DMZ interfaces and receive new IP and DNS info no problem.

Are there files that can be edited to remove the old confusing information or is a complete reburn of NanoBSD to CF card and re-setup required to get rid of this glitch??
Feel free to email me direct if you prefer, I have no issue with that.

P.S. Box is an older Wyse thin term, 550MHz, with 1gig of ram, and 4g CF Card, with one internal (LAN) Nic and a Quad port Gigabit RouterBoard Nic with one Port used as WAN (because it's a Gigabit port),2 other ports Bridged Network and one for Future DMZ Possibly.

WAN is Port 1 on Quad NIC, OPT1 and OPT2 are bridged, OPT3 is future DMZ, LAN is Internal NIC.

saytar

Still scratching my head here…................

divsys

Please note, this is just educated (not that much) guessing on my part, but it is how I would try and solve this ;)

My suggestion would be a simple test:

Backup your config.xml (always a good idea)
Create a new network using OPT3 and setup DHCP on it (eg 192.168.99.0/24)
Verify you can plug in a device and get an IP address from that NIC.
Swap the assignments for the bad NIC and OPT3 so the bad NIC now gives out addresses for the DMZ.
Attempt to connect a device and attempt to get an IP (best try a different MAC than used in 3 above, if possible)
Attempt to get an IP address from the "new" bridged NIC.

The results should be able to isolate a hardware failure from a misconfiguration.

saytar

Thanks divsys (you seen to pop up quite frequently…we appreciate the attention). Just read your post. Been doing something similar, but I finally went in and set a new MAC address in the Windows Client NIC configuration (the one not working right..all the Pfsense Nics working fine) and incremented the last number by +1. Client NIC Now works and gets a new IP almost immediately from any other interface now.............soooooooo now it appears that something is ...well I'm not sure misconfigured (at least I don't think I am the misconfigurer). Since I did quite a bit of changing IP's, Interface Names (Using Alisas's quite a bit now) before deciding on current naming and IP configuration, I think that a config file is still retaining the old IP, and/or interface name and has the original MAC tied to that and thus is giving out that same old WRONG DHCP to the Client NIC.
I do know that in digging through the Win Registry I found several reference's to the NIC and the old 192.168.2.2/24 Interface Port. That is one reason I re-loaded Windows (that and the original install was over 4 yrs old, lots of "Stuff" accumulated) with a Clean re-install.

Sooooo I'm thinking its the problem lies in one of the default config or DHCP config files, or DNS config files that will need some minor surgery to exorcise the demon IP's and MAC's !!!...either that or reburn 2.1.3 on the CF card and start from scratch......shame to do that as otherwise not having any problems much (other than the one's I cause bumbling through).

Got any idea's? Like which files might be involved and how to SAFELY re-do them?

Thanks for the info and reply!

divsys

Just thought of a real acid test - spoof the bad MAC address on a different PC and see if that PC then refuses to get an IP, should define the problem as pfsense or the original PC.

If you're still convinced it's in your pfsense, you could try looking through the config.xml you took in step 1 (see I told you it was good idea). Look for the offending MAC and/or IP address.

The other thing I've done is to clear all the package info from a "working" version of my config.xml and then reload and add back packages as necessary. That way you can eliminate any possible package interaction from a relatively clean install.

saytar

Found part (maybe all of the no IP) problem…...........somehow a Gremlin tapped Insert my MAC on OPT1 (part of the now Bridge Network) and put in the NIC MAC as the Interface NIC.
But in Going thru the config.xml file I have found several references to the OLD IP of OPT1 (192.168.50.1/24). Not being an XML editting type guy (I do much better with a soldiering iron and soldier on delicate boards) I am all thumbs on the proper Formatting and Required layout of Pfsense Box XML file.

So hopefully someone can enlighten me and/or point me to several good links on editting XML files (in Particular PFsense XML files) or a good way to make some temp settings and force the box to completely re-write it itself without nuking the mostly working settings.

Will look at the XML file more tomorrow.......could even print it as a PDF file .............ok getting late and the gears are grinding tonite.

Thanks again.

divsys

The easiest way to edit the XML file is with a text editor that is XML "sensitive".

Notepad++ is a good free version that handles XML (and lots of other syntax ) quite well.

Just remember XML "brackets" sections and items like:

<interface>…...details......
......more......</interface>

Keep the bracketing matched and all will be well. (except for the exceptions where a single type entry is valid by itself :P )

Glad you're on track to fixing it up.

Gertjan

If you're use the ssh access, remember this command:
viconfig

It's the vi editor, so fasten your seatbelt, but you will have direct edit access to the config.xml with one command.

saytar

Definitely going to look into a good xml editor. Been going thru the XML file and the WebConfg settings. Most of the problems were caused by…...................drum roll................crash of cymbals.................................ME, and my bumble fingers. Apparently I supposed that clicking on Show Mac in Interface setup would more or less hard code the interface and prevent some glitch from throwing a bum pitch. Weeellll further investigation reveled that the MAC that was Hard Coded to the interface was the Offending Client NIC MAC. All is now fixed on that at least..................(crossed fingers and toes).

Now on the XML issue.......after several examinations of the XML code and a closer look at the WebConfg interface......the reference's to the OLD interface IP's were just that.............reference's. When something is first configured on the Interface the IP of the "administrator" is logged, as are changes and if the IP of the "administrator" changes so do the change's IP.

Went back over the Confg.xml file today and it began to make some sense (A Scary thought for a Code Virgin), after a reboot of the Box to see if the Original Mac on the Client computer was or was not still a problem (Its not anymore, working as it should be). That is when I noticed the pattern....don't say that it was clear what was going on, but a pattern AND explain's the random OLD IP's

So thanks Divsys and everybody........sometimes it helps to bounce an issue off somewhere but your own self. Well it's off to do some more configuring and see what new mess I can get into!!!

Stay Tuned!!

viconfig.........hmmmmmmmmmmmmm wonder what kind of trouble I can turn that into??????? Time to Backup the config.xml file again Divsys!!

Gertjan

Ok, forget about viconfig. Your setup might not survive it.
A good XML is what you need.

Btw: I read about bugs, but I never found Gremlins in my firewall …. You're sure ? ;)