@itsol:

Hi all!

I have PfSense 2.14 setup fine behind a Cisco 3212 Cable Modem.  It's a real Modem. ;-)

When the Modem is rebooted, PfSense doesn't get the new WAN IP-Adress from the Provider (Unitymedia Germany) via DHCP.

If I reboot PfSense afterwards the WAN IP is renewed and everything is working again.

Same thing happens from time to time. (When the Provider resets the connection? I don't know.)

The IP is regulary renewed when the Leasetime expires. (Entries like "New IP detected" and then same IP given)

To me it looks like PfSense is not asking for a new IP through the Modem as long as the Lease is still valid.

Is there any way to make PfSense establish a new connection without rebooting?

Suggestions?

El Buco

Just saw, it's nearly the same question as here: https://forum.pfsense.org/index.php?topic=80477.0

Seems to be a feature, not a bug. ;-)

Olá Itsol.

Was searching for some solution to this poblema. Almost no one suffers from this evil DHCP WAN.

It was when I came across your doubts and the solution that was given. I had to disagree with the "Derelict" also. Ai continued my search and found this post: https://forum.pfsense.org/index.php?topic=57258.0

I have not read everything, went straight to the last page and read something talking ta communication rate of the network interface where the individual arrow interface to communicate to 100BaseT. Well, it cost not try, I changed my settings to "Full-Dublex 100BaseT." I did my tests and it worked oa _ || _: D

my system: "2.1.5-RELEASE (i386) built on Mon Aug 25 07:44:26 EDT 2014 " Interface: Realtek 10/100.

Well, there is a hint.
Good look.

If you're not using layer 3 functions of your switch, it's not a layer 3 switch.  If you are, then you need to do all sorts of things differently.  If you are not configuring virtual interfaces and assigning interface IP addresses in the switch, it's just layer 2.

what did you put for the domain on the host, what are you doing the query for - does you machine use search suffixes. Is the forwarder working for looking up say www.google.com.  Are you SURE you pointing to your forwarder.  Do you have pfsense using the forwarder via 127.0.0.1

How about you show us your host over rides, and then simple query.

C:>dig i5-w7.local.lan

; <<>> DiG 9.10-P2 <<>> i5-w7.local.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30484
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;i5-w7.local.lan.              IN      A

;; ANSWER SECTION:
i5-w7.local.lan.        86400  IN      A      192.168.1.100

;; Query time: 3 msec
;; SERVER: 192.168.1.253#53(192.168.1.253)
;; WHEN: Tue Oct 07 06:32:35 Central Daylight Time 2014
;; MSG SIZE  rcvd: 60

C:>dig -x 192.168.1.100

; <<>> DiG 9.10-P2 <<>> -x 192.168.1.100
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29216
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;100.1.168.192.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
100.1.168.192.in-addr.arpa. 86400 IN    PTR    i5-w7.local.lan.

;; Query time: 2 msec
;; SERVER: 192.168.1.253#53(192.168.1.253)
;; WHEN: Tue Oct 07 06:32:46 Central Daylight Time 2014
;; MSG SIZE  rcvd: 84

C:>

There is no underlying reason - DHCP can hand out an unspecified length list of DNS Server addresses.
System->General Setup supports 4, and will hand those out with DHCP if the forwarder is not enabled in pfSense.
You could conceivably use the "Additional BOOTP/DHCP Options" field to specify the details, but that would be really difficult to get the right 4-octet binary values in a list there, and in any case the wway the pfSense code is built it is also going to give out something itself that will mess up what you tried to specify.
The easiest would be to expand the GUI to accept 4 DNS servers, matching the number supported in System->General Setup - I wonder why that was never done in the first place?

How many places you going to post the same question??  Don't crosspost!!

https://forum.pfsense.org/index.php?topic=82359.0

Thanks!
I'll look into this.

maybe this will help?

https://forum.pfsense.org/index.php?topic=81747.msg446989#msg446989

According to unbound documentation, if no root hints file is provided, it will use some "reasonable defaults".  Not sure what those are, but they're enough to get it working, but not very clean or reliable.

I always forget to just sniff the traffic.. \sigh

Everything was in order - Option 3 as well as the others were what I expected them to do.

The issue, as it turns out, has to do with having multiple NICs in Linux. In short, you can't always just unplug the cables and expect things to be happy. You have to ifdown and ifup the interfaces for the DHCP info to be set properly (or reboot) when you have multiple NICs. Embarrassingly, this isn't the first time I've run into this either.

I reinstalled pfsense without havp and get now the error 'This page can't be displayed' wich is i think basically the same error as that i get with HAVP installed.
I have a modemrouter in front of pfsense, maybe the problem lays there. In the securitylog of that modemrouter are a lot of SYN Flood to host and TCP FIN Scan from the ip of the pfsense firewall. Is that maybe the problem?

WAN1 is a public range, I have a /28 addressable subnet. One of the IPs is statically assigned to the pfSense, one is the modem/router itself (default gateway) and a couple of the remaining ones are assigned to devices sitting "outside" the firewall - these are the ones I tested DNS lookups from whenever I get timeouts from pfSense itself.

WAN2 is slightly different, I get an RFC1918 address, but have a 1:1 NAT set so I can configure port forwarding etc on the pfSense directly. No other devices between that modem/router and the pfSense WAN port.

However, as I mentioned above, I disabled WAN2 altogether last time I saw the issue, and it was still happening after that, all the while DNS queries outside the pfSense were fine.

I'll try your suggestion of running a packet capture on pfSense next time this happens, and will report back…

Thanks.
-Alex

Ah yes, that protection on switches has fooled even seasoned network veterans!

For completeness' sake, the 2nd rule should be:
Allow Proto IPv4 UDP SRC: 2ndLAN subnet DST: ANY (or an alias of 2ndLAN subnet and 255.255.255.255), ports 67,68 - allow DHCP
Since the initial request is a discover packet sent to 255.255.255.255.

Set logging on for the dhcp rule, look for hits in the firewall log

You can also try tcpdump if you don't mind getting your hands dirty.
Enable ssh, and connect to pfSense
Note down the interface that corresponds to 2nd LAN (looks like em1)
Drop to the shell and run:
tcpdump -i em1 -s 0 -n -v udp port 67 or udp port 68
You should see DHCP packets from the client.

Thanks, i solved the problem.
No DNS Forwarder problem o firewall rules mistake. It was an Access point TL-WA901ND V3 bug. I connected WIFI interfase and AP both to the same switch, then connect the client to the wired lan, all worked fine with the original configuration. So i discovered that the problem was an Access point bug.

Googled some issues with this AP and DNS and found this

"I got the DNS issue fixed only if I run the AP as DHCP Client. With a static IP (and yes still without default Gateway) any DNS request replies with the static IP address of the AP."

So i changed  the fixed IP on the AP to a Dynamic IP and all worked fine on the wireless clients.

so what are your lan rules set too? while you list pfsense as your gateway - what is the dns server hand out to the clients.  If you say it resolves yahoo to its public IP.  You still have to allow it out.  Now the default lan rules should be any any and let your end 8.1 box to talk to the internet.

But if you have edited these rules, or have setup a different interface its rules would be blank and you would have to create rules to allow the client out.

Other possible issue is devices your trying to ping just do not answer ping and would explain timeout - if browsing is not working, this could be a proxy setup on your client that you can not get too, etc.

Are you using squid on pfsense (proxy) this is another thing that is setup that could cause you problems if not correct.

who is unable to resolve your internals?  pfsense or clients - if you tell your clients to use opendns for example - how would opendns know about your internal something.somedomain.com ?

You should have pfsense set to ask itself - the dns forwarder at 127.0.0.1 and google and opendns if you want it to resolve local names.

You didn't give any info that would let anyone help you..  What outside server you were using has nothing to do with anything..  Without the actual domain you were talking about your post is just gibberish that you were using opendns, or level3 or your isp, etc.

Need to know what domain you are talking about, and what was their old name servers vs their new ones, etc.

I ended up putting the cable modem on a separate vswitch.