We have an XG 310 that has two separate internet connections to the same ISP for redundancy and load balancing. Obviously, these two connections are set up on their own WAN ports on the XG, each with a different static IP (and each port has a different MAC address). The issue is that the second connection shows down, however, it will pass internet traffic that is forced out that port with the EXCEPTION of ping. For whatever reason, the XG cannot ping anything ping-able on the internet.... HOWEVER, clients on the LAN that are forced out that port can ping hosts on the internet. We also have a third internet connection to a different ISP for backup/failover that is working just fine. Does anyone have any input as to why the XG is acting this way?
Yep, I already thought of that. Yesterday I dropped in a dumb switch between the ISP ONT and our XG and ran one of the connections through it and got the same result. I think the only way I'm going to…
Can you perform the following command under the device console?Login with the admin credentials via putty with ssh protocol > press 4 for the device console:> system diagnostics utilities arp ping interface PortX X.X.X.Xe.g: system diagnostics utilities arp ping interface <port number> <gateway IP>See if you are able to receive a unicast reply from the ISP gateway? =========================================================================If a post solves your question please use the 'Verify Answer' button.
Thanks & Regards,
Vivek Jagad | Technical Account Manager 3 | Cyber Security EvolvedSophos Community | Product Documentation | Sophos Techvids | SMSIf a post solves your question please use the 'Verify Answer' button.
Using that command, I can get a unicast reply back from the ISP gateway.
Yes, it still shows down, but still passes internet traffic if forced out that port.
Alright, what is the gateway settings under the > Network > WAN link manager > IPv4 gateway > Port number/gateway > failover rules >> is ISP gateway mentioned or Global DNS like 188.8.131.52 ? if not try adding both under AND condition and then check whether the status changes...
This XG is still on v17.5, so I can't add a second failover qualifier, but if I change it from the ISP gateway to 184.108.40.206 or anything other ping-able IP on the internet, it still stays down. For whatever reason the XG just will not ping out that specific port.
May I know the v17.5 MR-release version [complete version info] ? Does it happen for this particular interface only? What if you configure the same ISP on another Interface, then what's the status ?++++++++++SF-OS 17.5 is retired 30-NOV-2021.More info can be found here: support.sophos.com/.../KB-000035279
It's V17.5.12. I set it up on a different port, I get the same results.
The version is outdated, so before you log a case, ensure you upgrade to the latest version v18.5 MR-3 And then get it checked with the support team by logging a case, if the issue still persists.
This XG was upgraded to V18 when it was fully released, but we had so many buggy issues with it that I had to wipe it out and re-load V17.5 back on to it. I'm going to be removing an XG210 from one of our other locations in the next week or so, so I might set it up and pop it in place after hours and see if I get the same results.
Thanks for taking the time to try and help me figure this issue out! I'll update this thread once I get to try the other XG out or if I figure it out before then.
I was able to get an un-used XG with V18.5.2 loaded on it. I set up the two WAN ports with their respective static IPs and just a few seconds after the second WAN came online, it got dropped. This feels like a spanning tree thing to me, but each of the WAN ports on the XG have a different MAC address, so I'm at a loss as to why it's behaving that way.
What if you configure an upstream unmanageable switch or ISP provided router then a private IP from that router to the fw, if that helps ?
Yep, I already thought of that. Yesterday I dropped in a dumb switch between the ISP ONT and our XG and ran one of the connections through it and got the same result. I think the only way I'm going to achieve the desired result is to drop that spare XG in between them and route the secondary connection through it.
Yep, should try that and check the following logs:1.) /log/dgd.log 2.) /log/networkd.logREF: https://docs.sophos.com/nsg/sophos-firewall/18.5/Help/en-us/webhelp/onlinehelp/AdministratorHelp/Logs/LogFileDetails/index.html#networkUnder the Network section ================