Thanks, I've not noticed any errors so hopefully all is good :)

You might try increasing the available php process in System > Advanced > Admin Access. Set max processes to something higher, try 4 to start. However is something is hanging the available php processes this may only delay the errors. Steve

Get it in where?? Not sure why you think you need a WAN IP to resolve to something in your arp table for vpn clients to connect to you? I am thinking you still don't quite grasp what a PTR or reverse is... Your vpn.domain.tld resolves to IP.242 address.

modem reboot solved the problem thankyou very much for your help!! this is the traceroute from inside the firewall. 0_1540757854627_Traceroute from inside after modem reboot Document.txt

Steve, this resolved the issue. Thank you very much! [2.4.4-RELEASE][admin@netgate.tns4.net]/root: pkg install -f php72-pear-XML_RPC2 Updating pfSense-core repository catalogue... pfSense-core repository is up to date. Updating pfSense repository catalogue... pfSense repository is up to date. All repositories are up to date. The following 1 package(s) will be affected (of 0 checked): Installed packages to be REINSTALLED: php72-pear-XML_RPC2-1.1.3_1 [pfSense] Number of packages to be reinstalled: 1 57 KiB to be downloaded. Proceed with this action? [y/N]: y [1/1] Fetching php72-pear-XML_RPC2-1.1.3_1.txz: 100% 57 KiB 58.6kB/s 00:01 Checking integrity... done (0 conflicting) [1/1] Reinstalling php72-pear-XML_RPC2-1.1.3_1... [1/1] Extracting php72-pear-XML_RPC2-1.1.3_1: 100% uninstall ok: channel://pear.php.net/XML_RPC2-1.1.3 install ok: channel://pear.php.net/XML_RPC2-1.1.3 [2.4.4-RELEASE][admin@netgate.tns4.net]/root: sha256 /usr/local/share/pear/XML/RPC2/Client.php SHA256 (/usr/local/share/pear/XML/RPC2/Client.php) = b9b71829e2632b7a70361556050661d8174b3c262f05ec4fe40b97d11ca1fa4b [2.4.4-RELEASE][admin@netgate.tns4.net]/root:

You're welcome. Glad you have your pfSense up and running again. :-) -Rico

https://redmine.pfsense.org/issues/9066 Just pushed a fix. Should be simple to make the same change locally and see if it works for you.

Thank you. With all your support I could able to give internet to all the links. @johnpoz Yes I am in process of removing other networks apart from 172.28.0.0/16. Once they removed only one big network will remain. @stephenw10 I did as per your advise, I could able to give internet. @Derelict Thanks for giving me an idea, with which I could figure out the problem. Am attaching the backup (off course after taking precautions ) of my configuration. It may be useful for any one who has got the same issue, they can follow the same. Please let me know attaching backup is a violation, will remove for sure.0_1540451309619_config-pfSense.localdomain-20181020154833.xml

Did you choose the "recover config.xml" option in the installer? That's what it will do. https://www.netgate.com/docs/pfsense/backup/automatically-restore-during-install.html#recover-config-xml It wouldn't have done that by default, though, you'd have to have picked that option.

Thanks for this, I also found that I had to use glabel to label the new swap "swap0" so that it would auto mount at boot.

I had already done that. I found the issue, though. I had imported the configuration which programmed my WAN and LAN. When I configured WAN2 for dynamic, I then plugged it behind the same router that I had exported the config from. I didn't look very closely at it, but that left my LAN and WAN2 port on the same subnet. D'OH! Traffic still routed, I'm assuming because routes were defined according to interfaces. The underlying OS, though, seems to just see IPs on ports. Can't have LAN and WAN2 having the same subnet so traffic went nowhere.

filterdns which is used in the alias should auto update on its own every 5 minutes.. This is how it is started when you create an alias that needs it, ie a fqdn in a hosts alias. If your not seeing any IP in the table for your fqdn (that is some dyndns record) you sure that it resolves at all? When you go to diag, dns lookup and put in the fqdn of this dyndns does it resolve to the correct IP? So you have 5 different fqdn for this IP range 93.90.x.1-93.90.x.5? Or your saying that 1 fqdn should return all 5 IP? Can you PM me this FQDN your using for your dyndns and I can check to see what it resolves too.

I found a solution to install unnoficial packages without errors. [https://forum.netgate.com/topic/136730/aplicar-patch-para-usar-e2guardian-5-em-pfsense-2-4-4/3](link url)

@stephenw10 Thanks! That all makes sense. My SSD is en route from amazon.

Not I got it working, the reason for stopping seems to be the interface reassignment. thanks! console from the source maschine was serial, the new one has no serial, only HDMI. I guess that was the reason that I couldnt see ..

I have ZFS running on a number of systems and have not had any trouble with it. It's not the default install type in 2.4.4 and hence is less tested but I'm not aware of any problems with it. Steve

@stephenw10 Yes Steve, Zen uses IPv6. I'm running 2.4.4 here and have had no problems. The WAN ethernet is Intel i211 (igb driver). [2.4.4-RELEASE][admin@x]/root: ping6 -D -s 1452 -c 4 pfsense.org PING6(1500=40+8+1452 bytes) 2a02:x:x:x:x:x:x:x --> 2610:160:11:11::69 1460 bytes from 2610:160:11:11::69, icmp_seq=0 hlim=250 time=123.880 ms 1460 bytes from 2610:160:11:11::69, icmp_seq=1 hlim=250 time=123.528 ms 1460 bytes from 2610:160:11:11::69, icmp_seq=2 hlim=250 time=123.517 ms 1460 bytes from 2610:160:11:11::69, icmp_seq=3 hlim=250 time=132.205 ms --- pfsense.org ping6 statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 123.517/125.782/132.205/3.711 ms

Just wanted to say thanks for this. I did a couple pending updates and it totally screwed up PHP. This worked perfectly and saved me using datacenter resources to re-image (Netgate support's only solution). I am seriously rethinking my decision to use these for any more of my customers, as going through the forums it seems everyone is very accustom to re-imaging their firewalls. This should not be a normal occurrence! Anyway, I digress... Thanks again!