OpenVPN default gateway question
-
My pfsense is configured as multi-WAN. I have OpenVPN setup for OPT1 interface (using local x.x.x.x in custom options). This works as long as my WAN is online. The moment WAN is down, the openVPN on OPT1 drops the connection. I am suspecting it is due to the default gateway.
If WAN link is dead, is it possible to assign the default gateway to another interface ? In my case, the moment WAN goes down, I would like to use the default gateway 1 (the gateway of OPT1).
P.S: I tried switching the OpenVPN to TCP, as someone suggested that this is better for OPT 1… and that didn't work.
-
It's not possible to assign the default gateway to a different interface.
However it's possible to force the connection to the other gateway by creating a static route:
OPT1, dest: IP_of_server/32, gw: OPT1_gwBut then you force traffic always to the OPT1 gw.
An option is see: If you have the possibility of having multiple public IPs on the server:
Add multiple failover-servers to the openVPN config.
Have as primary the IP reachable via the WAN.
If the WAN fails it wont be able to reach the server and try the backup. The backup will be forced via a static route to the OPT1 and thus be able to connect.Not TCP is worse the UDP.
Google for "TCP over TCP" for the why this is bad. -
GruensFroeschli,
Thank you for the response! Appreciate it. Still no luck.
I do have public IPs for both the WANs. In the below openVPN config file, 92.121.2.163 is public IP for WAN. And 87.34.11.43 is public IP for WAN2 on OPT1. I am using them in failover mode.
Here is my config file:
dev tun
proto udp
remote 92.121.2.163 1194
remote 87.34.11.43 1194
ping 10
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
.
.
.Here is the log from the openVPN client:
Thu Aug 19 13:29:59 2010 OpenVPN 2.1.1 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Dec 11 2009
Thu Aug 19 13:29:59 2010 NOTE: OpenVPN 2.1 requires '–script-security 2' or higher to call user-defined scripts or executables
Thu Aug 19 13:29:59 2010 LZO compression initialized
Thu Aug 19 13:29:59 2010 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Aug 19 13:29:59 2010 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Aug 19 13:29:59 2010 Local Options hash (VER=V4): '41690919'
Thu Aug 19 13:29:59 2010 Expected Remote Options hash (VER=V4): '530fdded'
Thu Aug 19 13:29:59 2010 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu Aug 19 13:29:59 2010 UDPv4 link local: [undef]
Thu Aug 19 13:29:59 2010 UDPv4 link remote: 92.121.2.163:1194
Thu Aug 19 13:30:59 2010 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Aug 19 13:30:59 2010 TLS Error: TLS handshake failed
Thu Aug 19 13:30:59 2010 TCP/UDP: Closing socket
Thu Aug 19 13:30:59 2010 SIGUSR1[soft,tls-error] received, process restarting
Thu Aug 19 13:30:59 2010 Restart pause, 2 second(s)
Thu Aug 19 13:31:01 2010 NOTE: OpenVPN 2.1 requires '–script-security 2' or higher to call user-defined scripts or executables
Thu Aug 19 13:31:01 2010 Re-using SSL/TLS context
Thu Aug 19 13:31:01 2010 LZO compression initialized
Thu Aug 19 13:31:01 2010 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Aug 19 13:31:01 2010 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Aug 19 13:31:01 2010 Local Options hash (VER=V4): '41690919'
Thu Aug 19 13:31:01 2010 Expected Remote Options hash (VER=V4): '530fdded'
Thu Aug 19 13:31:01 2010 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu Aug 19 13:31:01 2010 UDPv4 link local: [undef]
Thu Aug 19 13:31:01 2010 UDPv4 link remote: 87.34.11.43:1194
Thu Aug 19 13:32:01 2010 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Aug 19 13:32:01 2010 TLS Error: TLS handshake failed
Thu Aug 19 13:32:01 2010 TCP/UDP: Closing socket
Thu Aug 19 13:32:01 2010 SIGUSR1[soft,tls-error] received, process restarting
Thu Aug 19 13:32:01 2010 Restart pause, 2 second(s)
Thu Aug 19 13:32:03 2010 NOTE: OpenVPN 2.1 requires '–script-security 2' or higher to call user-defined scripts or executables
Thu Aug 19 13:32:03 2010 Re-using SSL/TLS context
Thu Aug 19 13:32:03 2010 LZO compression initialized
Thu Aug 19 13:32:03 2010 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Aug 19 13:32:03 2010 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Aug 19 13:32:03 2010 Local Options hash (VER=V4): '41690919'
Thu Aug 19 13:32:03 2010 Expected Remote Options hash (VER=V4): '530fdded'
Thu Aug 19 13:32:03 2010 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu Aug 19 13:32:03 2010 UDPv4 link local: [undef]
Thu Aug 19 13:32:03 2010 UDPv4 link remote: 92.121.2.163:1194
Thu Aug 19 13:33:03 2010 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Aug 19 13:33:03 2010 TLS Error: TLS handshake failed
Thu Aug 19 13:33:03 2010 TCP/UDP: Closing socket
Thu Aug 19 13:33:03 2010 SIGUSR1[soft,tls-error] received, process restarting
Thu Aug 19 13:33:03 2010 Restart pause, 2 second(s)
Thu Aug 19 13:33:05 2010 NOTE: OpenVPN 2.1 requires '–script-security 2' or higher to call user-defined scripts or executables
Thu Aug 19 13:33:05 2010 Re-using SSL/TLS context
Thu Aug 19 13:33:05 2010 LZO compression initialized
Thu Aug 19 13:33:05 2010 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Aug 19 13:33:05 2010 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Aug 19 13:33:05 2010 Local Options hash (VER=V4): '41690919'
Thu Aug 19 13:33:05 2010 Expected Remote Options hash (VER=V4): '530fdded'
Thu Aug 19 13:33:05 2010 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu Aug 19 13:33:05 2010 UDPv4 link local: [undef]
Thu Aug 19 13:33:05 2010 UDPv4 link remote: 87.34.11.43:1194
Thu Aug 19 13:34:05 2010 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Aug 19 13:34:05 2010 TLS Error: TLS handshake failed
Thu Aug 19 13:34:05 2010 TCP/UDP: Closing socket
Thu Aug 19 13:34:05 2010 SIGUSR1[soft,tls-error] received, process restartingIt is still not connecting.
In your response, you said "The backup will be forced via a static route to the OPT1 and thus be able to connect." Should I make a setting somewhere for this to happen? Or are you saying this is automatically handled by pfSense?
If I plug in my WAN, they both work. I test this by removing the first IP in the above config file (I remove the line "remote 92.121.2.163 1194").
Thank you for your help!
-
No you need to add the static route manually.
Under "static route"alternatively you can add the static route to the openVPN config directly.
Add in the custom options field
route "IP_of_server 255.255.255.255 Gateway_of_OPT_interface"; -
GruensFroeschli,
Thanks for your help. This is driving me insane. I still can't connect through WAN2 when WAN is down.
Here is a screen of what it looks like. I tried with one or the other alternate setting, but no luck. Am I doing anything wrong?
Thank you for all your help. Anything else you think I am missing?
-
Maybe i didn't tell it clear.
You need two IPs on the server.Can you show the config on the client as well?
Why did you add the static route on the server?
It has to be on the client (since the client initiates the connection to the server).I'll write an examle config here.
OpenVPN-Server
[WAN1] [WAN2]
[192.168.1.2] [172.17.1.2]
| |
| |
| |
GW: 192.168.1.1 GW: 172.17.1.1
–-------------------------------
internetGW: 10.0.1.1 GW: 10.255.255.1
| |
| |
| |
[WAN1] [WAN2]
[10.0.1.2] [10.255.255.2]
OpenVPN-ClientI used private IP's but imagine they are public and directly on the internet.
On the server you dont have to configure anything special.
Just make sure it binds to both WANs.On the client: Add both IPs of the server in the config in a failover manner.
Look at the OpenVPN doc for how the custom options have to look.
http://www.imped.net/oss/misc/openvpn-2.0-howto-edit.html#loadbalance
We want failover from 192.168.1.2 to 172.17.1.2.
Per default connections on the client go to 10.0.1.1.
Now you add the static route: route "172.17.1.2 255.255.255.255 10.255.255.1" since we want to force all traffic going to the second WAN of the server to leave via the OPT-gateway.(Actually you dont need two WAN's on the server. Just a different IP to connect to.)
-
GruensFroeschli,
Thank you soooo very much for direction. I appreciate it.
I feel silly for adding it to the wrong spot. I made the recent changes you suggested but still no luck. I'm doing something really silly wrong here.
Client:
Server :
I verified that the above VPN server works. I verified it by plugging in both WAN and WAN2. And then connecting via OPT1/WAN2. It still works when WAN is plugged in.
And finally, here is the ipconfig /all after I connect through the OPT1 (WAN2) successfully when WAN is plugged in. (The vpn client doesnt connect to OPT1 when WAN is unplugged).
Thanks again for your help!
-
Can you send anything at all to the OPT1 interface when the WAN is down?
(Not only VPN traffic).The config looks good.
Only thing i would change, is to have a single server which binds to both WANs and not two servers. -
GruensFroeschli,
Thank you again for your input.
1. When WAN is down, other inbound traffic is passing safely through OPT1. My loadbalancer is also working when WAN is down. Only VPN is not getting established.
2. Like you suggested, I removed the 2nd VPN server. And, I removed the "local xxx.xxx.xxx.xxx" from the custom options field for the remaining server. Now, I cannot connect on OPT1 interface even when WAN is up. With two servers, I was able to connect through OPT1 when WAN was up.
I must be missing something minor. Any help is greatly appreciated.
Thank you
