I’ve been working on a OpenVPN deployment that is working with asymmetric routing. I think it is working with a sub-optimal solution. First, let me show how it is deployed and what is bothering me.
So, lets check the path of a packet going from client A to client B.
|1||10.1.0.92||client site A|
|2||10.1.0.254||default gw site A|
|3||10.1.0.45||openvpn gw site A|
|4||172.16.1.1||wan openvpn site A|
|5||172.16.1.58||wan openvpn site B|
|6||10.1.8.254||default gateway site B|
|7||10.1.8.2||client site B|
But when the packet comes from client B to client A the path is a bit different.
|1||10.1.8.2||client site B|
|2||10.1.8.254||default gateway site B|
|3||172.16.1.2||wan openvpn site B|
|4||172.16.1.58||wan openvpn site A|
|5||10.1.0.45||openvpn gw site A|
|6||10.1.0.92||client site A|
Pay attention that the packet is not going through 10.1.0.254 (default gw site A). So the path is asymmetric.
As the packet does not go through 10.1.0.254 (default gw site A) in both ways, the firewall is unable to track the connection state and it starts to reject packets from that connection. Let’s take one example of client A trying to connect to client B.
client A -> client B – SYN packet
(this packet is forwarded by firewall in default gw site A)
client B -> client A – SYN/ACK packet
(this packet is delivered to client A without going through default gw site A)
client A -> client B – ACK packet
(this packet is reject by default gw site A)
As soon as the 10.1.0.254 (default gw site A) detects the next hop is in the same network as the sender, 10.1.0.92 (client site A), it should send an ICMP redirect instructing the client to send packets directly to 10.1.0.45 (openvpn gw site A). In this way you get the optimal path in both ways.
If your router is a linux box remember to enable it to send ICMP redirects by changing yours sysctl.conf
Unfortunately, routes created by ICMP redirects are short lived in Windows clients, and when this route gets expired a packet is sent to 10.1.0.254 in the middle of a TCP connection, witch wasn’t tracked, so it rejects the packet and the connection is dropped.
To get alternative #1 fixed you just need to make rules stateless in the firewall (aka don’t use switches -m state –state NEW in iptables). So when the ICMP redirect route gets expired the host will send the packet to it’s default gateway and will receive another ICMP redirect instead of an ICMP port unreachable.
If all your clients are working with DHCP and both client and servers supports RFC3442 it is a very good alternative. It will make clients always use the best route using the right gateway.
If you have a mixed network with DHCP clients and static clients this alternative can be a problem since you won’t get the all routes delivered to all hosts, also I had problems with some SIP phones that doesn’t support RFC3442.
Remember that you can still use both this alternative with alternatives #1 and #2 at same time.
If you decide that you would like to get the packets going through both gateways to get a symmetric routing you can use this alternative.
Check out LARTC how-to to get more info.
This last altervative involves using new network to get packets transferred between networks.
To achieve this you should create a new VLAN to connect the hosts:
- 10.1.0.254 (default gw site A)
- 10.1.0.45 (openvpn gw site A)
If you like to use just one NIC in 10.1.0.254 (default gw site A) you can make use of IEEE 802.1q, but your switch must support it.
If you have a spare NIC in 10.1.0.254 (default gw site A) you can just configure the new network using this NIC.
After you get the transfer network configured on 10.1.0.254 (default gw site A), you just need to route the packets addressed to VPN to go through this transfer network. Do the same on your VPN box to the packets addressed to your LAN.
Since they are in separated networks no ICMP redirect will occur.