This is my setup for a site-to-site vpn with openvpn client with 2FA.
Install opkg packages:
opkg install expect tmux bind-tools
Files required:
- /jffs/openvpn/client.ovpn
- /jffs/openvpn/client-credentials.txt
- /jffs/openvpn/start-openvpn-client.sh
- /jffs/openvpn/firewall-up.sh
start-openvpn-client.sh starts the OpenVPN client with $OTP is an input parameter.
This startup script uses
expect (
#!/opt/bin/expect
) to automatically insert the 2FA-OTP string at the prompt
"CHALLENGE: Enter Authenticator Code"
after
openvpn command.
start-openvpn-client.sh
Rich (BB code):
#!/opt/bin/expect
set OTP [lindex $argv 0]
eval spawn /usr/sbin/openvpn --config /jffs/openvpn/client.ovpn --auth-user-pass /jffs/openvpn/client-credentials.txt
set prompt "CHALLENGE: Enter Authenticator Code"
interact -o -nobuffer -re $prompt return
send "$OTP\r"
interact
Run this command to start openvpn client with 2FA (OTP):
/jffs/openvpn/start-vpn.sh $OTP
<-- your 2FA OTP string
client.ovpn configures the challenge
prompt for the 2FA-OTP string.
The
prompt should match the prompt in start-openvpn-client.sh
Rich (BB code):
auth-user-pass
static-challenge "Enter Authenticator Code" 1
A new network interface (
tun0) is created when the openvpn connection is established.
Rich (BB code):
spawn /usr/sbin/openvpn --config /jffs/openvpn/client.ovpn --auth-user-pass /jffs/openvpn/client-credentials.txt
2022-07-10 11:00:28 OpenVPN 2.5.3 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Aug 6 2021
2022-07-10 11:00:28 library versions: OpenSSL 1.1.1k 25 Mar 2021, LZO 2.08
CHALLENGE: Enter Authenticator Code826154
...
2022-07-09 16:21:47 TUN/TAP device tun0 opened
2022-07-09 16:21:47 /usr/sbin/ip link set dev tun0 up mtu 1500
2022-07-09 16:21:47 /usr/sbin/ip link set dev tun0 up
2022-07-09 16:21:47 /usr/sbin/ip addr add dev tun0 172.16.0.1/22
2022-07-10 11:00:34 /usr/sbin/ip route add 172.16.0.1/20 metric 101 via 172.16.232.1
A word of caution.
I do NOT generally recommend using the firmware's user-defined chains for your own purposes. In this case, the OVPN chain. That can change. And in the case of 386.7, it just did!
The OVPN chain that used to be shared between the INPUT and FORWARD chains w/ 386.5_2 and below, is now two (2) separate chains in 386.7; OVPNCI in the INPUT chain, and OVPNCF in the FORWARD chain.
It's just more reliable to insert these kinds of rules at the top of INPUT and/or FORWARD chains than depend on those created and managed by the firmware.
Now as it happens, by default, ALL traffic, regardless of network interface, is allowed *outbound* from the default network (br0). The only exception is traffic explicitly denied w/ the NSFW chain (network services filter), but that only filters access to the WAN anyway, NOT the VPNs. And the replies are handled by the ESTABLISHED rule within the INPUT and FORWARD chains. IOW, afaict, such outbound rules are NOT necessary.
To allow (site-to-site) network traffic routes between local and remote networks over the new network interface (
tun0) created by openvpn client.
- Configure FORWARD chain to allow forwarding to tun0 interface
- Configure network address translation (NAT) to masquerade the source IP of packets sent to tun0 to router's IP
firewall-up.sh
Rich (BB code):
iptables -I OVPN -o tun0 -j ACCEPT
iptables -t nat -I POSTROUTING 1 -o tun0 -j MASQUERADE
Note:
- These 2 iptables rules allow local network to initiate connections to servers in the remote network.
- Remote network will not be able to initiate connections to servers in the local network.
The common definition of site-to-site does exactly what your Note section claims otherwise. It *allows* devices on the OpenVPN server side of the tunnel to initiate connections to devices behind the OpenVPN client.
IOW, the first statement is true, but NOT the second. NOT if we are being accurate in the common definition of a site-to-site VPN.
One of the reasons I bring this up is NOT just to be picky, but because it provides an opportunity to point out a security hole you haven't considered. It's still possible for any device on the server side of the tunnel to initiate a connection w/ the router itself on its assigned IP of the tunnel! It *is* site-to-site in that very narrow sense (but we don't typically use that terminology to avoid confusion). That's why the OpenVPN client of the GUI has the Inbound Firewall option, which is set by default to Block such access. And it does that by explicitly adding rules for that purpose.
Code:
iptables -I OVPNCI -i tun11 -j DROP # assumes 386.7 or later
iptables -I OVPNCF -i tun11 -j DROP # assumes 386.7 or later
Granted, when dealing w/ your *own* OpenVPN server, this is probably a lesser concern. But since most ppl are dealing w/ third-party OpenVPN servers (e.g., PIA, NordVPN), such trust can NOT be assumed, hence why that option exists.
Again, I brought it up because you specifically mentioned the fact that remote access was NOT possible from server to client. But it is in that one special case.