OpenVPN Multi WAN

[DynamicIS]

Due to having issues with bonded DSL / OpenVPN and RDP traffic, Im attempting to come up with another approach in case I cannot resolve the issue which has been ongoing for quite a while!

Can I install another NIC in the Untangle box connected to a separate DSL line, designate it as a WAN interface (WAN2) and force OpenVPN to connect over that WAN2 connection whilst all other internet bound traffic goes out over the existing bonded dsl WAN connection (WAN1)?

Thanks

Paul..

[jcoffin]

You can but not easily. You will need to edit each client VPN config and remove the WAN1 information from the .ovpn file.

[DynamicIS]

Its only going to be used for a site-to-site VPN between 2 Untangle boxes..

Both "server" and "client" sites are behind bonded dsl connections at the moment with an Untangle 10.1 box and whilst the OpenVPN connection works for pings and traceroutes etc, it has RDP and SMB issues which we cant seem to resolve. We have isolated the issue to the bonded dsl connection itself as it works fine when a line is dropped from the bonded dsl and used as a single adsl instead.

So Im thinking that we could use the bonded DSL on WAN1 for "internet" traffic and use a single ADSL on WAN2 at each site with OpenVPN on WAN2 for site-to-site traffic.. Any problems in this approach?

Paul..

[jcoffin]

No problems with your scenario. I've had better performance with IPsec site-to-site than OpenVPN in live sites. There should be no difference but across the Internet there is a measurable difference with transfers.

[DynamicIS]

Thanks..

Ive now configured WAN2 on the "server" end connected to a single ADSL line. The remote test Untangle I have is connecting fine and all seems to be working OK for 2 way traffic.

By default, does it send all traffic over WAN1 unless its OpenVPN traffic? What happens if WAN1 goes down - will it route outbound traffic to WAN2 in that instance? Are there any other circumstances it will send over WAN2?

Paul..

[jcoffin]

By default, does it send all traffic over WAN1 unless its OpenVPN traffic? What happens if WAN1 goes down - will it route outbound traffic to WAN2 in that instance? Are there any other circumstances it will send over WAN2?

OpenVPN can only use one WAN at a time. It does do a round-robin on the WANs on each disconnect. Example, OpenVPN disconnects since WAN 1 is down, OpenVPN will try to reconnect on the next WAN.

[dmorris]

Thanks..

Ive now configured WAN2 on the "server" end connected to a single ADSL line. The remote test Untangle I have is connecting fine and all seems to be working OK for 2 way traffic.

By default, does it send all traffic over WAN1 unless its OpenVPN traffic? What happens if WAN1 goes down - will it route outbound traffic to WAN2 in that instance? Are there any other circumstances it will send over WAN2?

Paul..

The client chooses which WAN to connect to - the server will answer via the same WAN the client connected on.
The client chooses based on your configuration of Public Address. If the Public Address fails it will then try the IPs of the WANs manually as configured in the conf file.

[DynamicIS]

Thanks again.

I manually edited the client conf file to remove any references to anything other than the single IP address of WAN2 so that the client will only connect over this connection.

I should be been more precise in my questions..

Firstly - As the server now has 2 WAN ports, will it route general internet traffic over WAN2 in normal circumstances? What happens if WAN1 goes down - will it route outbound traffic to WAN2 in that instance? Are there any other circumstances it will send over WAN2?

Secondly, when I reconfigure the client with 2 WANs, how can I force untangle to route the OpenVPN connection over WAN2?

Paul..

[DynamicIS]

In the end, OpenVPN over Sheredband just didnt work. Rather than start complicating matters I have bought the IPSec VPN modules for both ends of the connection and configured it and can now connect fine.

Thanks

Paul..

[dmor]

@DynamicIS - I wonder if your OpenVPN over bonded DSL issue was due to the MTU of the DSL connection being smaller than 1500. I have seen this before with DSL connections and had to modify my client's server to keep its MTU within the boundaries of what the DSL connection permitted.