RV082, Dual Wan, VPN + Protocol Bindings

[b.thibodeau]

Hi all,

I have this kind of setup and I can't figure out how this router thinks.

My setup uses Dual Wan in load balancing mode. I only need a single VPN tunnel. High availablity is my concern.

Site 1 has Fiber and Cable

Site 2 has Cable and FTTN

Every ISP supplies Static IPs

VPN works great in the event of an outage. I am still disappointed that it works in case a single primary WAN breaks, but is not operational if primary WAN on Site 1 shutdowns at the same time Site 2 secondary WAN stops. It's a really rare case but could happen.

Anyway, my problems lie where I need Protocol Binding to preserve secure WEB sessions (https, banking, supplier portal).

I have to bind, at least, port 443 to my primary WAN. This way, I can access websites and keep my session active.

Then, if I have to browse a HTTPS server on the other side of the VPN, Protocol Binding still tries to pass port 443 through WAN1. It does not even consider the VPN as a valid route first.

Problem (Maybe)   Can I reduce Hop Count for Site 2 to less than 35??     P.S. I replaced addresses as I do not feel they are revelant.

Destination IP Subnet Mask Default Gateway Hop Count Interface

WAN2 network addr 255.255.255.252 * 0 eth2 WAN1 network addr 255.255.255.248 * 0 eth1 Site 2 255.255.255.0 Site 1 Fiber Gateway 35 eth1 Site 1 255.255.255.0 * 0 eth0 default 0.0.0.0 Site 1 Fiber WAN1 15 eth1 default 0.0.0.0 Site 1 Cable WAN2 40 eth2 default 0.0.0.0 Site 1 Fiber WAN1 40 eth1

Thanks to all,

Bruno

[Tom Watts]

Hi Bruno, in the event of a WAN failure, the protocol bind rules should be failing over to the other WAN port. That is how the router is intended to work.

If your contention is that it is not happening a few steps to do first to receive proper support-

*Upgrade to the latest firmware

*Factory default the unit

*Create the base configuration

*Test

If this fails under the most fundamental circumstance then it would be a good time to call the small business support center and ask for an investigation.

-Tom
Please mark answered for helpful posts

[b.thibodeau]

Hi Tom,

Thanks for your insight.

Unfortunately this is not exactly the problem. Failover is OK. Problems lies with Protocol Binding + VPN

Binding a port to a specific WAN connection prevents it from ever going through the VPN tunnel.

i.e.: binding port 80 to wan1 prevents me from accessing a web server in my branch office, even if wan1+2 are operational on each side.

I recently got an answer from support.

Support:
After labbing up the scenario and discussing the case with our SMEs I have determine that there is not a workaround for your particular issue. Unfortunately, when you bind traffic to an interface it does just that. There isn’t a way to bind the traffic but also allow it to go through the VPN tunnel.

Bruno

[Tom Watts]

Hi Bruno, the binding and WAN port must be one in the same, this is correct. If you bind 443 to WAN 2 while the VPN is running on WAN 1, the precedence will remain at WAN 2 for the connection request.

-Tom
Please mark answered for helpful posts

[b.thibodeau]

I agree with you.

But what if I turn this around?

Let's use the same fact but change it a little bit.

--

The binding and WAN port must be one in the same, this is correct.

If you bind 443 to WAN 1 while the VPN is running on WAN 1, the precedence will remain at WAN 1 for the connection request.

--

This is what happens right now. Looking at routes, I thought by logic that would still let VPN route like an internal network, not external or WAN.

Site 2

255.255.255.0

Site 1 Fiber Gateway

35

eth1

Binding a port stops all traffic it may haul from ever reaching this route.

Imagine a single el cheapo router in a 192.168.0/24 subnet with a server at 192.168.0.2

Its like typing a valid web server ip (suppose 192.168.0.2) in your subnet and getting the same error as typing 192.168.254.2 (which is no even there in this scenario).

Looks like it reaches the limits of the router OS

[Tom Watts · Accepted solution]

I would conclude that is a bug and requires further investigation. I wouldn't call it a limitation if it were my decision (not that I matter so much in this regard)

-Tom
Please mark answered for helpful posts

[b.thibodeau]

Thanks again.

But support cant or wont do much more.