Can be anything... you're best off wiresharking the WAN interface during a reboot to see whether its anything from the outside... Although, this reminds me of a cable-operator here whose cable-modems are responsible for answering incoming dhcp-requests using the config they get via tftp. If one resets the modem and requests an IP from it before it has synced and downloaded its config you get an IP in 192.168.100.0/24...
-Aarno On Sat, Apr 4, 2009 at 07:50, Karl Fife <[email protected]> wrote: > pfSense consistently has a 10.0.1.x address on the WAN interface after > reboot (DHCP client). > > pfSense WAN interface gets REAL public IP address only after explicit > release/renew event. > > > > This happens every time, > > > > To the users it manifests as 'it doesn't work' after a reboot without > administrator intervention. > > > > Does anyone have any idea what could be going on here? I configured > pfSense as a 10.2/16 not a 10./8 because I routinely create PPTP tunnels to > other networks 10.x /16 networks thinking that this configuration would > give me proper routing. Perhaps that is not incorrect, and perhaps I have > broken something by choosing 10.2 /16 instead of 10. /8. > > > > I originally assumed that someone in my ISP’s network had a rogue DHCP > server occasionally filling my WAN interface's DHCP requests. Evidence > against this theory is that pfSense only gets this 'bad' address on reboot, > and it seems to happen 100% of the time, and I can NEVER replicate the > problem with release/renew NOR can I get replicate the problem with a > modem-attached windows host even by trying hard (many times) to be issued a > bad address by aforementioned theoretical ROGUE DHCP server. > > > > A higher-up tech at my ISP mumbled some stuff about BSD DHCPD being known > to issue addresses to itself if dhcpd is not configured 100% properly. I > found this idea somewhat absurd because the 10.0.1.x address is not even in > my subnet, (10.2.x.x/16) neither do I see any noise about the DHCP > transaction in the System Log. ALTHOUGH dhcpd IS configured to allocate > leases between ..1.254 and ..1.1--so at least it's got the third octet right > if indeed there's something’s wrong related to /16 vs /8 on a 10. network > > > > By the way, this happens with 1.2-Release AND with 1.2.2 (embedded on > Soekris 5501) > > > > Anybody know what's going on? Any help or pointers are MUCH appreciated! > > > > Thank you! > > > > -Karl Fife > > > > > > > > > > -- Aarno Aukia ETH Zurich / Atrila GmbH +41764000464
