The easiest way to see if it's something from the ISP's side is to boot up your pfSense with the WAN plugged into a switch _all by itself_, or boot up with a loopback adapter plugged into the WAN port. If it boots up and doesn't get an IP when it's set up like this, then it's something from the ISP.
Dimitri Rodis Integrita Systems LLC http://www.integritasystems.com From: Karl Fife [mailto:[email protected]] Sent: Friday, April 03, 2009 10:51 PM To: [email protected] Subject: [pfSense Support] pfSense gets RFC1918 address on WAN interface after reboot 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
smime.p7s
Description: S/MIME cryptographic signature
