@telmocalhaco: It´s a firewall problem on the pfsense , just add a floating rule on the WAN to allow all trafic and it start to working . hi i have the same scenario how did you make the floating rule I can’t seem to get it to work I have 2 wan a dsl and now I use d-link as a backup 4g wan I get an external ip address on the port but can’t route traffic and it show the gateway as offline please help I have a bad internet I have the latest pfsense

So I'm getting a repeat of this issue again. Nightmare. I've read up on some topics of people seeing similar issues regarding the states. Could anybody point me to the light regarding this issue? When I disconnect and reconnect via interfaces I get use of both gateways but not before long I get the same issue after a gateway maybe going down for a few minutes? :-[ Thanks

Had a colleague in China last year using my OpenVPN.  As a tourist on "public", hotels mostly, hot spots I'm sure it's not the same as for a "subscribed" service.  But even so it seemed connections were restarting quite a bit.  For a mobile device not being heavily/continuously used it was okay.  Can't imagine the poor user experience for heavy computer use though.  We weren't doing any thing to obfuscate though.

What might be the most concerning about this is whether or not there is a secure firewall rule set in place when this happens.

Ok I figured out why your image wasn't loaded - I was connected to one of my vps via vpn on my workstation, and that was having issues.  I notice when I couldn't get to my local stuff ;) Anyway.. So why and the hell would you have a dual wan router connect to pfsense lan with 2 different connections???  That is ZERO reason to do that… And why would you be using it as a router anyway??  That should just be used as an accesspoint.. You have a 50/20 internet connection there would be ZERO reason for such a setup.. Turn that router into just an AP connect it with 1 wire to pfsense lan and that should fix whatever issue your having..

delay.. without more info it is impossible to even guess what your talking about.  There is nothing in "nat" that would cause a hours delay..  Once this delay happens do they then work fine?  Its possible they had a different IP and you had to wait for their lease to expire then get a new IP on the new network since you removed their other nat.. As always a drawing of your network would be helpful in understanding your environment so we are all clear on how your setup.  You say you removed a nat, so I would assume your clients are now on a different network ip scheme..  Which is via dhcp?  So if you had an old lease, you would have to release and then get a new lease from the dhcp server on the new network your on. Or did you remove the nat and now your just routing to a downstream network vs natting to it?  These are details that need to be understood to try and help you.

Yep just tried emptying the cache directory and I was able to create the rule

Must be lot of fun with doing maths and waiting where it overflows… but - the circular log is not suitable for archiving purpose, at all. Use a remote syslog server, or at least install the syslog-ng package and log to normal logs, rotating them as needed.

Yes, reinstall is the only way to fix UFS. I've filed multitude of bugs about UFS and fsck. fsck is so broken that it needs multiple successive manual runs to even try to repair the filesystem, and then it gets all sort of things wrong, and segfaults, or spits out various confused nonsense, and eventually screws the filesystem to the point where you cannot boot any more. I got the below patch from one of the pfSense devs for debugging, and while it tries to run fsck much aggressively, as noted above, the only result in the end was complete FS destruction. Also, it would need updating for 2.3.2 or newer, apparently. diff --git a/src/etc/rc b/src/etc/rc index e82a5ba..970fa9c 100755 --- a/src/etc/rc +++ b/src/etc/rc @@ -54,7 +54,7 @@ fi if [ -e /root/force_fsck ]; then echo "Forcing filesystem(s) check..." - /sbin/fsck -y -F -t ufs + /sbin/fsck -y fi if [ "${PLATFORM}" != "cdrom" ]; then @@ -77,18 +77,37 @@ if [ "${PLATFORM}" != "cdrom" ]; then if [ ${FSCK_ACTION_NEEDED} = 1 ]; then echo "WARNING: Trying to recover filesystem from inconsistency..." - /sbin/fsck -yF + ntries=0 + fsck_rc=1 + until [ $ntries -ge 3 -o $fsck_rc -eq 0 ]; do + /sbin/fsck -y + fsck_rc=$? + ntries=$((ntries+1)) + echo "DEBUG: Run #${ntries} - rc = ${fsck_rc}" + sleep 1 + + # Sometimes first call returns 0 but filesystem is still broken + # Run fsck in preen mode again just to be sure + /sbin/fsck -p -F + fsck_rc=$? + echo "DEBUG: (-p) #${ntries} - rc = ${fsck_rc}" + sleep 1 + done + + if [ $fsck_rc -ne 0 ]; then + echo "Automatic filesystem recovery failed. Starting recovery shell!" + tcsh + reboot + fi fi /sbin/mount -a 2>/dev/null - mount_rc=$? - attempts=0 - while [ ${mount_rc} -ne 0 -a ${attempts} -lt 3 ]; do - /sbin/fsck -yF - /sbin/mount -a 2>/dev/null - mount_rc=$? - attempts=$((attempts+1)) - done + + if [ $? -ne 0 ]; then + echo "Filesystems could not be mounted. Starting recovery shell!" + tcsh + reboot + fi if [ "${PLATFORM}" = "nanobsd" ]; then # XXX This script does need all filesystems rw!!!!

@KOM: You were either using NAT reflection, or you had your internal DNS handing out LAN IPs (known as split DNS). thank you for your answer, i managed to get this fixed using a internal split brain DNS. much appreciate it your support.

Took PFSense out of the equation, and things did improve a bit. I've migrated from using the RG in router mode to pass-through with the WAN address MAC now being assigned the RG's IP via DHCP. So that much is working.  Throughput is still not where it ought to be.  So next step is to possibly replace my TPLink 24-port Gigabit switch with a Cisco 24-port to see if that helps. Though all of this created a new problem with my OpenVPN install no longer working, even after I changed its IP and created new certs for OpenVPN Connect.  Posted in the OpenVPN section on issues I've got there now…OpenVPN Connect will authenticate to the firewall, but then has access to nothing.

If you're pinging raw IP addresses then pfSense has nothing to do with problem unless (very unlikely though and you aren't providing enough information) there is an IP address conflict in your network and pfSense is somehow the cause of the conflict. If you're pinging DNS names then you need to look at the DNS forwarder/resolver logs on pfSense for signs of anything amiss.

Thanks,  doktornotor @johnpoz: Yes, normally you would do that at the switch however I have an unmanaged switch. I was planning to put a TAP switch but the fact that I have three NIC's already on the firewall box and pfsense has spanning capabilities, I was thinking of going that route.