Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 26 subscribers
  • Views 5031 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sophos XG sslvpn client to pfSense OpenVPN Server (max-routes)

mpeene

Hello,

We are in the process of investigating Sophos XG firewall to replace our pfSense firewalls. One of the critical things is that the remote Sophos XG appliances need to be able to connect to our virtual pfSense firewall in our datacenter (currently we have pfSense appliances onsite and main virtual pfSense in datacenter. All is connected with OpenVPN Site-2-Site).

I've managed to setup a virtual XG appliance and create the correct .apc file so that it can be imported into the Sophos XG firewall and it connects to the pfSense openVPN server. However, during the connection, more than 100 routes are pushed to the client. By default, openVPN only allows 100 routes for a VPN Connection, but we can manage that by adding the option max-routes 200 to override this. That's also what I see in the vpn log of XG firewall:

Tue Jan 15 15:08:17 2019 [16513] MANAGEMENT: Client disconnected
Tue Jan 15 15:08:17 2019 [16513] OpenVPN ROUTE: cannot add more than 100 routes -- please increase the max-routes option in the client configuration file
Tue Jan 15 15:08:17 2019 [16513] Exiting due to fatal error

Can someone tell me where I can add the option "max-routes 200" on the XG firewall? I can't find it in the UI but it will probably be possible somewhere in a config file, but I can't seem to find it.

P.S. I know it's best to keep the routes below 100, but for now that is not possible. Once all remote locations are converted from pfSense to Sophos, we can convert our datacenter and optimize the routing and vpn connections.

Thanks a lot.

Michiel.



This thread was automatically locked due to age.
Parents
  • 0

    Hi Michiel,

    I know this may not be the answer you are looking for but I would recommend using IPSEC over SSL as it is more efficient and has a much wider adoption/support visibility.

    At this time I cannot see a support validated method to do what you require as it does not seem to be an option as part of the Console options so may require development/GES involvement. Modification of the OpenVPN server configuration file is restricted and you cannot edit and save wherein even if you could make changes it would be an unsupported solution then.

    If you are fully licensed I would recommend opening a support case to see if it is possible (or at least provide visibility to Sophos) but out of countless installs, I have only used the SSL Site to Site system a few times as IPSEC is always a more viable alternative.

    Emile

  • 0 in reply to Emile Belcourt

    Emile,

    The situation is more complicated than it seems. IPSEC or any other VPN is not an option. For the time being we need to be able to use the Sophos without as little as possible changing the current main FW (pfSense) in the datacenter (being it's maintained by a 3rd party who is not really cooperating). Once all sites are merged, we can replace the datacenter pfSense with Sophos too and than use the best VPN solution available.

     

    I've been researching the logs further last night, and found out that the routes that are pushed over the openVPN seem to be pushed twice, so if I can find out why it's doing this, I could get my routes below 100! (It's probably doing this for our current pfSense firewalls too, but the solutions from the 3rd party = add max-routes 200. problem solved! It's like saying: the recycle bin is full: put another one next to it instead of emptying the bin...)

    Thanks for the quick reply though!

    Michiel.

  • +1 in reply to mpeene

    Hi Michiel,

    That is very frustrating they are not cooperating and obviously you can't change the datacenter FW until all the others are done, argh!

    Hmm, is it a hub and spoke configuration? Because if so you could get mega lazy and tell the 3rd party to change the SSL VPN route push to be just the Class A (10.0.0.0/8), Class B (172.16.0.0/12) and Class C (192.168.0.0/16) as routes rather than the multitude of your individual subnets. I presume all the ranges you are consuming fall within the A/B/C classes and the remote site boxes don't do any other routing than across SSL for corp subnets then 0.0.0.0/0 as default route to WAN? Hopefully that will be a simple change for the third party to do.

    You would then reduce your routes being deployed from the remote side to a very small number while maintaining proper routing capabilities.

    PFSense is easier to change as it is a pretty open box solution, performing any changes to the backend functionality of the XGs' subsystems is an absolute no-no, if you are even allowed to in the first place!

    Emile

Reply
  • +1 in reply to mpeene

    Hi Michiel,

    That is very frustrating they are not cooperating and obviously you can't change the datacenter FW until all the others are done, argh!

    Hmm, is it a hub and spoke configuration? Because if so you could get mega lazy and tell the 3rd party to change the SSL VPN route push to be just the Class A (10.0.0.0/8), Class B (172.16.0.0/12) and Class C (192.168.0.0/16) as routes rather than the multitude of your individual subnets. I presume all the ranges you are consuming fall within the A/B/C classes and the remote site boxes don't do any other routing than across SSL for corp subnets then 0.0.0.0/0 as default route to WAN? Hopefully that will be a simple change for the third party to do.

    You would then reduce your routes being deployed from the remote side to a very small number while maintaining proper routing capabilities.

    PFSense is easier to change as it is a pretty open box solution, performing any changes to the backend functionality of the XGs' subsystems is an absolute no-no, if you are even allowed to in the first place!

    Emile

Children
  • 0 in reply to Emile Belcourt

    Emile,

     

    i've found the solution. On the pfSense we use Client Overrides for each client connection to push the correct routes (all remote networks except the networks for this client)

    On the OpenVPN server config all remote networks are also already specified. It seems that a "client override" "merges" those 2 together (not looking at duplicates...) instead of "overriding" those settings. I've now set the client override option "Prevent this client from receiving any server-defined client settings." and now it's working.

    Michiel.

  • 0 in reply to mpeene

    Hi Michiel,

    That's fantastic, really good info and glad you now have it working :)

    Roll on switchovers then IPSEC! :P

    Emile