Prtg Sophos Xg



Prtg Sophos Xg

Having had mixed results with the Sophos XG, and having hardware that just can’t keep up with the latest updates for it, I’ve reverted back to the Sophos UTM9. This still plays nicely with my PIA VPN setup whereby a pfSense router is placed in front of a UTM interface to anonomise traffic however I do miss the highly granular way policy based routing could be done in the Sophos XG.

View Tunde Oladipo (CCNA, UBWA, MCSA, CCNSP, Sophos XG)’s profile on LinkedIn, the world’s largest professional community. Tunde has 3 jobs listed on their profile. See the complete profile on LinkedIn and discover Tunde’s connections and jobs at similar companies. Can you please tell me how to integrate PRTG in Sophos XG firewall. I tried almost any thing but the PRTG is not working with XG Firewall. SOPHOS-XG-MIB. These desktop firewall appliances (Sophos XG 106 and Sophos XG 106w) offer an excellent price-to-performance ratio making them ideal for small businesses or branch offices. These models come equipped with 4 GbE copper ports built-in and 1 shared SFP interface, e.g. For use with our optional DSL modem or an SFP Fiber transceiver to connect the. PRTG has a free tier and offers the most network sensors to monitor the XG. I’ve used Grafana and it presents a challenge because you’re limited on the MIB files.

For example, in the XG it is possible for each ACL rule to define a gateway and failover gateway as well as NAT’ing policies.

Prtg Sophos Xg

Within the UTM9 I’ve had to create ACL rules, NAT rules and Policy Routes separately – no big deal but it certainly needs more clicking around and isn’t as clear how the Policy Routes would handle an interface down situation – will it stall on the rule or move to the next valid rule for that traffic?

Prtg Sophos Utm

Sophos

Anyway – after setting everything up I was quickly able to get traffic flowing outbound through the pfSense gateway as well as out through the Virgin Media router direct depending on the traffic type. Likewise, getting my PRTG server published outbound was a doddle using Webserver protection. However, try as I might I was not able to update the UTM via the Up2Date process.

018:02:19-00:00:14 utm9 audld[12540]: no HA system or cluster node
2018:02:19-00:00:14 utm9 audld[12540]: Starting Up2Date Package Downloader
2018:02:19-00:00:24 utm9 audld[12540]: patch up2date possible
2018:02:19-00:00:27 utm9 audld[12540]: Could not connect to Server 79.125.21.244 (status=500 Can’t connect to 79.125.21.244:443 (Network is unreachable)).
2018:02:19-00:00:27 utm9 audld[12540]: Could not connect to Server 107.21.214.248 (status=500 Can’t connect to 107.21.214.248:443 (Network is unreachable)).
2018:02:19-00:00:27 utm9 audld[12540]: Could not connect to Server 54.214.16.252 (status=500 Can’t connect to 54.214.16.252:443 (Network is unreachable)).
2018:02:19-00:00:27 utm9 audld[12540]: Could not connect to Server 175.41.132.12 (status=500 Can’t connect to 175.41.132.12:443 (Network is unreachable)).
2018:02:19-00:00:27 utm9 audld[12540]: Could not connect to Authentication Server 79.125.21.244 (code=500 500 Can’t connect to 79.125.21.244:443 (Network is unreachable)).
2018:02:19-00:00:27 utm9 audld[12540]: Could not connect to Authentication Server 107.21.214.248 (code=500 500 Can’t connect to 107.21.214.248:443 (Network is unreachable)).
2018:02:19-00:00:27 utm9 audld[12540]: Could not connect to Authentication Server 54.214.16.252 (code=500 500 Can’t connect to 54.214.16.252:443 (Network is unreachable)).
2018:02:19-00:00:27 utm9 audld[12540]: Could not connect to Authentication Server 175.41.132.12 (code=500 500 Can’t connect to 175.41.132.12:443 (Network is unreachable)).
2018:02:19-00:00:27 utm9 audld[12540]: >
2018:02:19-00:00:27 utm9 audld[12540]: All 4 Authentication Servers failed
2018:02:19-00:00:27 utm9 audld[12540]:
2018:02:19-00:00:27 utm9 audld[12540]: 1. Modules::Logging::msg:46() /</sbin/audld.plx>Modules/Logging.pm
2018:02:19-00:00:27 utm9 audld[12540]: 2. Modules::Audld::Authentication::_handle_failure:235() /</sbin/audld.plx>Modules/Audld/Authentication.pm
2018:02:19-00:00:27 utm9 audld[12540]: 3. Modules::Audld::Authentication::start:66() /</sbin/audld.plx>Modules/Audld/Authentication.pm
2018:02:19-00:00:27 utm9 audld[12540]: 4. main::main:174() audld.pl
2018:02:19-00:00:27 utm9 audld[12540]: 5. main::top-level:40() audld.pl
2018:02:19-00:00:27 utm9 audld[12540]: |
2018:02:19-00:00:27 utm9 audld[12540]: id=”3703″ severity=”error” sys=”system” sub=”up2date” name=”Authentication failed, no valid answer from Authentication Servers”

Strangely I could connect fine to the addresses in the log such as https://175.41.132.12:443 I could ping them and resolve DNS records such as v8up2date3.astaro.com all from my PC behind the UTM. After messing for a couple of hours reviewing logs, forum posts and trying various changes including removing all policy routing and going straight out via a non-VPN’d route I finally found out the root cause… the UTM does not follow the rules of Policy Routes!

Prtg Sophos Xg

I’d set up routes to 192.168.0.1 (VMRouter) and 192.168.10.1 (pfSense) for administration of those routers, with HTTP(S) and ICMP to go via the VPN’d pfSense route.

So while I had no default gateway as such on the interfaces I had instead setup a catch all policy route which sent all traffic not hitting an above rule via the non-VPN’d gateway. Unfortunately the UTM doesn’t follow this and absolutely requires a tick box against “IPv4 default GW” in the interface.

Prtg sophos xg template

Prtg Sophos Utm Vpn

After ticking this the updates flowed in 🙂