Using XG on OVH dedicated server - General Routing issues

Hi,

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.

Ian

Hi Ian,

could you tell me the steps I need to go through?
Sure that a FW-rule helps? Are you running a XG at OVH?

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:

EDIT:

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 XG
2. 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 mask
7. 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 IP
FINISH

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 PortB
route 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!

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): 167.114.0.254

• 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 99.99.99.254 (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 167.114.0.0/24, Gateway left blank, Interface set to Port B
• Entry created for Dest. IP 0.0.0.0/0, Gateway 167.114.0.254, No Interface selected

This config works find under XG 16. As soon as I update it to (any) v17 version, this stops working. 

Ideas?

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.