We'd love to hear about it! Click here to go to the product suggestion community
Hey guys - have you tested your failover actually fails over and passes Web Traffic?
I have an XG450 17.5.5 MR5 - two PPPoE connections into the XG Direct. One is used a Primary WAN and one as Backup WAN.
WAN LinK manager configured correctly and to fire up the Backup if the Primary drops. Tested this by unplugging the primary WAN port - after a short time my RED reconnects to the Backup WAN fine.
All User based FW rules are set to MASQ as a NAT and have both WAN connections set as Primary and Secondary.
Now when I failover no web traffic passes - no matter what I try with Gateway Specific NAT or adding 0.0.0.0 to go via the Backup Port etc - I cannot pass web traffic.
Have you actually checked yours does pass traffic? I am thinking Bug as its not a routing issue and I can see the secondary connection has indeed kicked in and is passing traffic to RED.
In reply to Shrikant Patil1:
do you configure booth external IP's within RED-Config?
In reply to dirkkotte:
So after many weeks, several levels of engineers and many updates, logins, tests, trial failovers, logs and repeat I am none the wiser.
Sophos Support have gone dark and now don't respond to email. Seems they are unable to work out why my XG won't fail over.
So Enterprise solution with home user support?
In reply to M8ey:
Can you share your Case ID with us?
In reply to LuCar Toni:
Hi M8ey Sorry for the inconvenience caused! I would check the details for the provided service request number and ask them to contact you further at earliest.
Can we please have an update on this issue as it is effecting our client firewalls as well...ready to jump on the watchguard boat
In reply to Sean DiLella:
My last contact was Support asking me to try the failover again since going to MR-8
I Haven't had a chance to try as yet but as the issue was there since 17.5 and nothing in the release notes about it for MR-8 I don't hold much hope
So I have an update from Sophos Support :-)
The issue is due to missing entry of Interface Port7 into tblhost of postgres database. This resulted into opcode update_host getting failed which results into opcode dyniface_dbhandler and finally dyniface:systemevent_handler getting failed. Thus the created interface Port7_ppp does not get the zone type assigned and the traffic through it gets dropped. Development has given workaround to see if it fixes the issue We need to insert some value in database and disconnect Port7 from UI and re-connect. Then need to run same test again to confirm if it works.
*** Port 7 is my Backup / Failover Port
So the next step is to apply the fix and retest which will confirm this.
Some odd issue.
Did you used some kind of backup / restore or API import / export or other techniques with this appliance?
I mean, that sounds unlikely to happen.
I did have an XG230 and restored the backup onto an XG450 as per normal upgrade.
Would suggest to tell Support this information. There went something wrong.
LuCar ToniWould suggest to tell Support this information.
Yes they have been well aware since it happened - been nearly a year now.
Tonight Support ran a command to insert the zone and public IP back into the DB which fixed it.
Then we disconnected and reconnected Port 7 WAN from GUI - last of all killed the primary WAN and the XG failed over fine and reconnected etc.
The issue above is the cause - now we just need to work out why, and if the fix applied will stick over Firmware updates. Loading MR9 now and will test tomorrow.
I hope this helps the others with the same issue
I would recommend to remove the psql command.
Basically this would not help at all, messing in the Database of the XG firewall could led to actually interrupts and failures in the firewall setup. It is highly dangerous to do so and not supported to do it without Sophos Support.
You would not helping anybody instead killing productive firewalls with such commands.
LuCar ToniYou would not helping anybody instead killing productive firewalls
Just posting what Support did on my XG :-)
As always its best anyone with this issue goes via Support to work out if the issue is the same
Yeah, but this was a approved modification done by Support.
just picture the scenario, somebody has a similar issue, sees this command, simply type in this command and breaks his XG Firewall completely and has to reimage everything. Its missing his context etc. Its up to you, to have this command here, but if somebody breaks his firewall, its because they saw this command and tried it.