Sophos Central Endpoint and SEC: Computers fail/hang on boot after the Microsoft Windows April 9, 2019 update. Please follow knowledge base article 133945
Learn about the Benefits of Multi-Factor Authentication (MFA). Turn your MFA on now!
Outage on MySophos and Partner Portal. You may contact Sophos Support through Phone.
We'd love to hear about it! Click here to go to the product suggestion community
I've got a customer with a dedicated server at OVH, running ESXi.They wish that a XG protect there virtual servers and managing the traffic.
But this simple setup, a XG and myself failed to accomplish this.I need to set a host-IP on an interface e.g. 18.104.22.168/32 and use a route to the servers primary IPs gateway e.g. 22.214.171.124/24
This is the official OVH documentation:docs.ovh.com/.../
EDIT:Tested with a vUTM and works fine out of the box.....the configuration look like this (and this is everything to configure on the UTM!)
please check the driver version you are using. Make sure that the XG interface is pointing at the virtual NIC used for the WAN interface.
Also you don't need to use routing if your setup is correct, a firewall rule will work.
In reply to rfcat_vk:
could you tell me the steps I need to go through?Sure that a FW-rule helps? Are you running a XG at OVH?
In reply to Mr.Roboto:
The problem is the following:
I can not do the same setup as in UTM.
To make this work I have to set the zone to something else then WAN and do a interface-route:
This is now my solution / workaround and the complete steps:
1. Go to your OVH control panel: Dedicated -> "IP" and select the dedicated server you want to donate a XG2. Select the IP-Network and choose a IP. Click "Add virtual MAC" and enter a name you remember "CustomerXYZ vSFOS"3. Copy the created vMAC and paste it into the vNIC for WAN of you virtual machine (set the mode to manual, VM must be powered off!)4. Start the XG and connect to it - in my case I need a jump desk (fedora live-disc) because the XG is the first VM on this ESXi.5. Create a new zone "WAN_OVH" and select only Admin HTTPS (we make it safe later)6. Configure the WAN interface in zone "WAN_OVH" and enter the IP you selected at OVH and a /32 mask7. Create a interface route "0.0.0.0/0 -> Port B" (or which port your WAN is connected to)8. Change the default FW-rule: replace the destination zone with "WAN_OVH"9. Enter a DNS and test INternet Access from your Jump-Desk and access to the Admin GUI via the public IPFINISH
I hope there are no side-effects with this?
EDIT:Of course there are massive side-effects, because this bad design causes the XG to resolve every communication with a ARP lookup.Also this is not a allowed configuration at OVH.
The configured interface-route is not a allowed solution at OVH.
So again, how to configure this in a XG:
After some testing I found out how it works until the next reboot, quit easy but this is very poor by Sophos:
Using the advanced shell and type:route add IP-OF-YOUR-HOST.252 dev PortBroute add default gw IP-OF-YOUR-HOST.252
But after the next reboot I've to config this again,no way via the guy to accomplish this.
Back again and with some discussion with OVH tech's, interface routes are accepted now at OVH and with this a XG works without any magic, at the other site the XG has to query ARP for each IP - with a result of a biiiiig ARP table all pointing to the gateways MAC. But still now, it works great :=).
I've been stuck with this issue (gateway outside of the failover IP range at OVH) for 2 years now, and while it's worked with the "fake" gateway workaround on v16, I could never upgrade to v17 as a result.
Could you let me know what configuration you had to put in place to make what you mentioned start working (with the interface routes that OVH apparently allows now)?
Many thanks in advance!
In reply to Jory Lane:
Hi,because of the peer-to-peer or the linked MAC address, on the physical switchport of your server, these Failover-IPs are not in the same network as the physical servers IP.So the problem is simple to solve on any linux distri, but if there is any "intelligence" which tries to check the user input - it will fail, of course. Because this is no normal route.To overcome these "intelligence" you could set up an interface route and now, instead of typing the gateways IP, we just drop the packet out of our WAN port. This is not the fine english way, because now every IP must be discovered by ARP. This again generates a big ARP-Table, with maaaaaany IPs and every entry with the pointing to the gateways MAC-address. This behave, what I found in documentation, is not wanted by OVH - because of the many ARP requests. But now (a month ago) a technician at OVH told me that I can to exactly this! It allowed and if there is a problem they get in touch with me.In short:The OVH specific routing entry can't setup with XG, UTM and every other competitor can do this - poor XG. Simply set a interface route with 0.0.0.0 0.0.0.0 P2 or whatever your WAN port is. Remember that the WAN IP on the interface of the XG need a /32 mask!If you need further help.....I'am there :)
Not sure I'm clear on where you're referring to by "Interface Route". Here is my existing config:
• XG virtual 16.05 as a VM on a HyperV host• OVH Failover IP Block: 99.99.99.X/24• OVH Gateway IP (from the server's original IP block): 126.96.36.199• Port B is our WAN, with 8x Alias IP's applied to it (the OVH Failover IP block we purchase), example 99.99.99.X/24• Port B's Gateway is set to 188.8.131.52 (this is a FAKE IP to satisfy XG needing to see a gateway within the same subnet).Under Routing-->Static Routing• Entry created for Dest. IP 184.108.40.206/24, Gateway left blank, Interface set to Port B• Entry created for Dest. IP 0.0.0.0/0, Gateway 220.127.116.11, No Interface selected
This config works find under XG 16. As soon as I update it to (any) v17 version, this stops working.
Simply delete the first entry and modify the 2nd entry like this: 0.0.0.0 0.0.0.0 Port B (interface route, because it does not point to any IP, instead to an interface)
I will try that, though I’m still unclear on how it will be able to route traffic to the internet without being aware of the “real” gateway IP ending in .254. With your suggested config, the .254 gateway IP does not exist anywhere in the XG’s configuration.
As I suspected, after upgrading to 17.5 and deleting the second route, setting the first to an Interface route, no change, still cannot route traffic.
Let me know if I've missed anything here, desperate to get this working. Thank you.
Mhhh....did you configure the FO-IP at the WAN-Port?
Please note that the WAN-Port CANNOT exist in the zone WAN because here you need a gateway. Configure a new zone, like WAN_OVH.
I see, no I hadn’t defined a separate zone previously.
Would you mind sharing (redacted of course) what all of your interfaces and routes look like? I want to make sure I have this right before attempting the 17.5 upgrade again. Thanks.
Sure, I will upload it tomorrow.
So, 10 minutes where hopefully the phone is quiet.
First on the ESXi, you need to set the security options of the vSwitch0, where the WAN is linked to, to this (but this is OVH default I mean):
(the port groups on this vSwitch will inherit that in default)
Then at the OVH management create a vMAC for the Failover-IP you wish to use at the SFOS.Add the generated vMAC to the corresponding interface of the VM in the ESXi (set to manual, bla bla)
After install the SFOS, I configure it via a jump-desktop.The routing mode is "this firewall" (the XG).
Then in the Web-GUI, configure a new zone like WAN_OVH.
Then go to the Interfaces and select PortB or what you want to connect to the internet and select the zone WAN_OVH, enter the IP-address (Failover IP, corresponding with the vMAC you configured in the ESXi) and select a subnetmask of /32.
Then go to Routing and add a new route:
The last step is to create a firewall rule, if you want to allow traffic to flow between whatever.Thats it.