Thanks jimp. I went back to the General System Settings and re-selected the correct timezone location, saved then rebooted and all seems good.

Thanks for the fast answer. It's a shell script I wrote so the only requirement for the method is that I can do it via command line.

I installed pfSense-pkg-arpwatch and tried successfully via: echo "test" | sendmail recipient@email.com

The only downside is that the sender is "Arpwatch Notification" but since that's only cosmetic I will stick to this approach.
Thank you

Edit:
As it turns out there's a mail.php that I can utilize, without the need to install arpwatch package and without the cosmetic flaws. echo "test" | mail.php -s"subject" recipient@email.com

Ok, now that we found the cause you need to make sure your rules on the WIFI net are right. If you don't intend to route the devices on that network through your VPN connection, but want them to talk to devices on another local network you will need an additional rule. That rule needs to be placed above the default rule, with the source of your WIFI net, the destination will be your local network(s) and it's gateway needs to be "default". That is because currently all connections coming from your WIFI net will be routed out of your WAN gateway.

For more in-depth details you better read up on policy routing.

Thank you, that makes sense, I am enlightened!
Appreciate the reply.

Thanks for notifying us of this! I just confirmed that this happens even when using the local database as authorization. If you haven't already, could you open up a ticket on redmine so it can be tracked and documented? https://redmine.pfsense.org/projects/pfsense/issues

Thank you.

@khorton said in No WAN IP on startup, until lease is manually renewed:

Now I need to figure out how to renew a lease from a script.

Take a look at /etc/rc.d/dhclient.

You'd specify restart and the interface to get a dhcp address.

@johnpoz
Yeah John also per previous I did say the time was reporting ok. At the time that I was experiencing the PHP issue.

I did mention NTP clock sync issue showing in my NTP log but the GUI was reporting time correctly.

Subsequently a couple days after I experienced a crash with IDS/IPS going down stopping and restarting and few other systems going off line and restarting.

And that after is when the GUI started reporting incorrect time for several time zones which I have fixed but will check again tonight. The main issue to me now is not the PHP error but the Clock sync issue

So if you recommend I backup and then a fresh download of 2.44 again I will do that

Thanks again for all the advice!

I do hate those HP racks when network kit needs to go in them, not much space for cable runs down the sides 😉

Not great to work in but £50 from ebay so can't complain!

@jimp said in Default gateway, subnets and, gateway groups.:

o setup rules to bypass policy routing for local traffic

Thanks jim!
you nailed it!

The latest one is generally the most stable but they are still snapshots. We don't test them all individually before they go up, so there could be problems there.

@rgc said in pfsense 2.4.4 NTP PHP Error Bug (possible work around):

Sorry for bothering you all. Yea I guess I am an idiot

No, not at all. It was an honest mistake that just so happened to be quite funny (at least to me). You might have been thinking of python, which can be used for scripting system services. We all live & learn. I've lost count of the times I've been corrected here after giving my best advice, usually by john or jim 😃

@jimp okay i am on latest snapshot, that is probably why its not looping anymore.

Appologies on the delay getting back to you on this, been a bit busy with things.

So I've done a lot more digging and it seems that traffic is going out, back into the pfsense box but doesn't seem to get back to my VM and I'm honestly out of my depth trying to work out why.

So relevant info is below, 10.0.10.254 is the external gateway and does DHCP, so my VM 10.0.10.121 gets it's IP from our office router ok but pings and normal internet traffic fails. It would appear that the WAN interface is getting the ping reply but it's not going across to the statics or the bridge interface and I cant work out why

pfTop: Up State 1-17/17, View: default, Order: bytes PR DIR SRC DEST STATE AGE EXP PKTS BYTES icmp Out 10.0.10.121:32235 10.0.10.254:32235 0:0 00:07:06 00:00:09 1643 46004 icmp Out 10.0.10.121:55748 10.0.10.254:55748 0:0 00:07:03 00:00:09 1640 45920

Packet Capture WAN:
11:40:12.494284 IP 10.0.10.121 > 10.0.10.254: ICMP echo request, id 32235, seq 1242, length 8
11:40:12.494450 IP 10.0.10.121 > 10.0.10.254: ICMP echo request, id 55748, seq 1238, length 8
11:40:12.509484 IP 10.0.10.254 > 10.0.10.121: ICMP echo reply, id 32235, seq 1242, length 8
11:40:12.510505 IP 10.0.10.254 > 10.0.10.121: ICMP echo reply, id 55748, seq 1238, length 8
11:40:13.651769 ARP, Request who-has 10.0.10.254 tell 10.0.10.124, length 46

Packet Capture Bridge:
11:48:49.284145 ARP, Request who-has 10.0.10.254 tell 10.0.10.124, length 46
11:48:50.307864 ARP, Request who-has 10.0.10.254 tell 10.0.10.124, length 46
11:48:51.331496 ARP, Request who-has 10.0.10.254 tell 10.0.10.124, length 46

Packet Capture Statics:
11:50:30.660879 ARP, Request who-has 10.0.10.254 tell 10.0.10.124, length 46
11:50:31.688384 ARP, Request who-has 10.0.10.254 tell 10.0.10.124, length 46
11:50:32.709554 ARP, Request who-has 10.0.10.254 tell 10.0.10.124, length 46
11:50:33.733321 ARP, Request who-has 10.0.10.254 tell 10.0.10.124, length 46
11:50:34.757094 ARP, Request who-has 10.0.10.254 tell 10.0.10.124, length 46

VM tcp dump for icmp:
0_1538651044673_tcpdump icmp.png

I am i right in thinking that incoming flow from WAN to the Statics is what's failing? Are there other diagnostic steps I can take to work this out?

I'll keep trying this afternoon to see if i can get anywhere.

Thanks

@jimp

Thanks. Its fine now.

Yeah I would suggest you post in your native language section, or for sure draw this up.. The only thing you should be plugging into from your ISP is wan interface of pfsense. If your running it through a switch then the proper vlans need to be setup.

The default block rule should take care of that. Just allow only the traffic you want everything else will be blocked.

Yes, it's better to use the narrowest allow rules you can to void ever accidentally allowing access to something you didn't want to.

Steve

Should be simple to fix that now that we can easily disable it. I added https://redmine.pfsense.org/issues/9001 to track it.

Rebooted a few times and now the error is gone but it's gotten really slow to almost not workable anymore, the router still works, however the webpages are have gotten really slow to the point where they don't load anymore.

All known XSS issues have been fixed. If you have found what you believe to be a new or otherwise uncorrected XSS, please follow the procedure at https://www.pfsense.org/security/ and report it privately.