Hello everyone!
In the past I have established successfully OpenVPN Net-To-Net connections using IPFire devices on the server and client side (pretty straightforward).
Now I am wondering if this is also possible with IPFire as the OpenVPN server and a Teltonika RUTX11 as the client.
Has anyone already successfully implemented such a scenario? If not with a Teltonika router, maybe with another OpenWRT based system on the client side?
Thanks in advance!
Hello again!
So I went ahead and started testing.
- My IPFire acting as OpenVPN Server: IPFire 2.29 (x86_64) - Core-Update 185 (hosted in a German data center)
- My Teltonika RUT X11 acting as OpenVPN Client: RUTX_R_00.07.07.1 (connected to the Internet via Starlink)
First I tried out a roadwarrier scenario.
I imported the files from the ipfire openvpn client package into a new Teltonika RUTX11 openpn entry:
Nice to see that the connection works right away:
On the RUTX11 (client) the following log is created:
Fri Jun 7 07:57:01 2024 daemon.warn openvpn(SN1609TR)[19516]: DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
Fri Jun 7 07:57:01 2024 daemon.notice openvpn(SN1609TR)[19516]: OpenVPN 2.5.3 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Fri Jun 7 07:57:01 2024 daemon.notice openvpn(SN1609TR)[19516]: library versions: OpenSSL 3.0.12 24 Oct 2023, LZO 2.10
Fri Jun 7 07:57:01 2024 daemon.warn openvpn(SN1609TR)[19516]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Fri Jun 7 07:57:01 2024 daemon.notice openvpn(SN1609TR)[19516]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Fri Jun 7 07:57:01 2024 daemon.notice openvpn(SN1609TR)[19516]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Fri Jun 7 07:57:01 2024 daemon.notice openvpn(SN1609TR)[19516]: TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xx.xx.xx:1194
Fri Jun 7 07:57:01 2024 daemon.notice openvpn(SN1609TR)[19516]: Socket Buffers: R=[180224->180224] S=[180224->180224]
Fri Jun 7 07:57:01 2024 daemon.notice openvpn(SN1609TR)[19516]: UDP link local: (not bound)
Fri Jun 7 07:57:01 2024 daemon.notice openvpn(SN1609TR)[19516]: UDP link remote: [AF_INET]xx.xx.xx.xx:1194
Fri Jun 7 07:57:01 2024 daemon.notice openvpn(SN1609TR)[19516]: TLS: Initial packet from [AF_INET]xx.xx.xx.xx:1194, sid=922ce524 016b26e9
Fri Jun 7 07:57:01 2024 daemon.notice openvpn(SN1609TR)[19516]: VERIFY OK: depth=1, xxx
Fri Jun 7 07:57:01 2024 daemon.notice openvpn(SN1609TR)[19516]: VERIFY KU OK
Fri Jun 7 07:57:01 2024 daemon.notice openvpn(SN1609TR)[19516]: Validating certificate extended key usage
Fri Jun 7 07:57:01 2024 daemon.notice openvpn(SN1609TR)[19516]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Fri Jun 7 07:57:01 2024 daemon.notice openvpn(SN1609TR)[19516]: VERIFY EKU OK
Fri Jun 7 07:57:01 2024 daemon.notice openvpn(SN1609TR)[19516]: VERIFY X509NAME OK: xxx
Fri Jun 7 07:57:01 2024 daemon.notice openvpn(SN1609TR)[19516]: VERIFY OK: xxx
Fri Jun 7 07:57:01 2024 daemon.notice openvpn(SN1609TR)[19516]: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
Fri Jun 7 07:57:01 2024 daemon.notice openvpn(SN1609TR)[19516]: [serverip.de] Peer Connection Initiated with [AF_INET]xx.xx.xx.xx:1194
Fri Jun 7 07:57:02 2024 daemon.notice openvpn(SN1609TR)[19516]: SENT CONTROL [serverip.de]: 'PUSH_REQUEST' (status=1)
Fri Jun 7 07:57:02 2024 daemon.notice openvpn(SN1609TR)[19516]: PUSH: Received control message: 'PUSH_REPLY,route 192.168.14.0 255.255.255.0,route 10.247.126.0 255.255.255.0,topology net30,ping 10,ping-restart 60,route 192.168.11.0 255.255.255.0,ifconfig 10.247.126.26 10.247.126.25,peer-id 1,cipher AES-256-CBC'
Fri Jun 7 07:57:02 2024 daemon.notice openvpn(SN1609TR)[19516]: OPTIONS IMPORT: timers and/or timeouts modified
Fri Jun 7 07:57:02 2024 daemon.notice openvpn(SN1609TR)[19516]: OPTIONS IMPORT: --ifconfig/up options modified
Fri Jun 7 07:57:02 2024 daemon.notice openvpn(SN1609TR)[19516]: OPTIONS IMPORT: route options modified
Fri Jun 7 07:57:02 2024 daemon.notice openvpn(SN1609TR)[19516]: OPTIONS IMPORT: peer-id set
Fri Jun 7 07:57:02 2024 daemon.notice openvpn(SN1609TR)[19516]: OPTIONS IMPORT: adjusting link_mtu to 1524
Fri Jun 7 07:57:02 2024 daemon.notice openvpn(SN1609TR)[19516]: OPTIONS IMPORT: data channel crypto options modified
Fri Jun 7 07:57:02 2024 daemon.notice openvpn(SN1609TR)[19516]: Outgoing Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Fri Jun 7 07:57:02 2024 daemon.notice openvpn(SN1609TR)[19516]: Outgoing Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Fri Jun 7 07:57:02 2024 daemon.notice openvpn(SN1609TR)[19516]: Incoming Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Fri Jun 7 07:57:02 2024 daemon.notice openvpn(SN1609TR)[19516]: Incoming Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Fri Jun 7 07:57:02 2024 daemon.notice openvpn(SN1609TR)[19516]: net_route_v4_best_gw query: dst 0.0.0.0
Fri Jun 7 07:57:02 2024 daemon.notice openvpn(SN1609TR)[19516]: net_route_v4_best_gw result: via 100.64.0.1 dev eth1
Fri Jun 7 07:57:02 2024 daemon.notice openvpn(SN1609TR)[19516]: TUN/TAP device tun_c_SN1609TR opened
Fri Jun 7 07:57:02 2024 daemon.notice openvpn(SN1609TR)[19516]: net_iface_mtu_set: mtu 1400 for tun_c_SN1609TR
Fri Jun 7 07:57:02 2024 daemon.notice openvpn(SN1609TR)[19516]: net_iface_up: set tun_c_SN1609TR up
Fri Jun 7 07:57:02 2024 daemon.notice openvpn(SN1609TR)[19516]: net_addr_ptp_v4_add: 10.247.126.26 peer 10.247.126.25 dev tun_c_SN1609TR
Fri Jun 7 07:57:02 2024 daemon.notice openvpn(SN1609TR)[19516]: /etc/openvpn/updown.sh tun_c_SN1609TR 1400 1524 10.247.126.26 10.247.126.25 init
Fri Jun 7 07:57:02 2024 daemon.notice openvpn(SN1609TR)[19516]: net_route_v4_add: 192.168.14.0/24 via 10.247.126.25 dev [NULL] table 0 metric -1
Fri Jun 7 07:57:02 2024 daemon.notice openvpn(SN1609TR)[19516]: net_route_v4_add: 10.247.126.0/24 via 10.247.126.25 dev [NULL] table 0 metric -1
Fri Jun 7 07:57:02 2024 daemon.notice openvpn(SN1609TR)[19516]: net_route_v4_add: 192.168.11.0/24 via 10.247.126.25 dev [NULL] table 0 metric -1
Fri Jun 7 07:57:02 2024 daemon.notice openvpn(SN1609TR)[19516]: Initialization Sequence Completed
and I can reach the server side network 192.168.11.0/24 from the client side network 192.168.50.0/24.
Second, I tried the net-to-net scenario.
In order to create an ovpn file that the RUTX11 can work with, I followed the tips in https://gist.github.com/terrillmoore/dfccff9ef8bffacdb9eb39264f6b341f.
Furthermore, I had to comment out three lines as they lead to error messages:
# user nobody
# group nobody
# daemon Starlink50SN1609n2n
The resulting ovpn file is then:
# IPFire n2n Open VPN Client Config by ummeegge und m.a.d
#
# User Security
# user nobody
# group nobody
persist-tun
persist-key
script-security 2
# IP/DNS for remote Server Gateway
remote serverip.de
float
# IP adresses of the VPN Subnet
ifconfig 10.11.50.2 10.11.50.1
# Server Gateway Network
route 192.168.11.0 255.255.255.0
# tun Device
dev tun
#Logfile for statistics
# Port and Protokoll
port 1199
proto udp4
# Paketsize
tun-mtu 1500
fragment 1300
mssfix
remote-cert-tls server
# Auth. Client
tls-client
# Cipher
cipher AES-256-CBC
# HMAC algorithm
auth SHA512
# Debug Level
verb 3
# Tunnel check
keepalive 10 60
# Start as daemon
# daemon Starlink50SN1609n2n
writepid /var/run/Starlink50SN1609n2n.pid
# Activate Management Interface and Port
# remsub 192.168.50.0/255.255.255.0
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>
When I use this, I get promising log entries on the RUTX11:
Fri Jun 7 08:05:17 2024 daemon.warn openvpn(vsn2novp)[24004]: Cipher negotiation is disabled since neither P2MP client nor server mode is enabled
Fri Jun 7 08:05:17 2024 daemon.notice openvpn(vsn2novp)[24004]: OpenVPN 2.5.3 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Fri Jun 7 08:05:17 2024 daemon.notice openvpn(vsn2novp)[24004]: library versions: OpenSSL 3.0.12 24 Oct 2023, LZO 2.10
Fri Jun 7 08:05:17 2024 daemon.warn openvpn(vsn2novp)[24004]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Fri Jun 7 08:05:17 2024 daemon.notice openvpn(vsn2novp)[24004]: net_route_v4_best_gw query: dst 0.0.0.0
Fri Jun 7 08:05:17 2024 daemon.notice openvpn(vsn2novp)[24004]: net_route_v4_best_gw result: via 100.64.0.1 dev eth1
Fri Jun 7 08:05:17 2024 daemon.notice openvpn(vsn2novp)[24004]: TUN/TAP device tun_c_vsn2novp opened
Fri Jun 7 08:05:17 2024 daemon.notice openvpn(vsn2novp)[24004]: net_iface_mtu_set: mtu 1500 for tun_c_vsn2novp
Fri Jun 7 08:05:17 2024 daemon.notice openvpn(vsn2novp)[24004]: net_iface_up: set tun_c_vsn2novp up
Fri Jun 7 08:05:17 2024 daemon.notice openvpn(vsn2novp)[24004]: net_addr_ptp_v4_add: 10.11.50.2 peer 10.11.50.1 dev tun_c_vsn2novp
Fri Jun 7 08:05:17 2024 daemon.notice openvpn(vsn2novp)[24004]: /etc/openvpn/updown.sh tun_c_vsn2novp 1500 1605 10.11.50.2 10.11.50.1 init
Fri Jun 7 08:05:17 2024 daemon.notice openvpn(vsn2novp)[24004]: net_route_v4_add: 192.168.11.0/24 via 10.11.50.1 dev [NULL] table 0 metric -1
Fri Jun 7 08:05:17 2024 daemon.notice openvpn(vsn2novp)[24004]: TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xx.xx.xx:1199
Fri Jun 7 08:05:17 2024 daemon.notice openvpn(vsn2novp)[24004]: Socket Buffers: R=[180224->180224] S=[180224->180224]
Fri Jun 7 08:05:17 2024 daemon.notice openvpn(vsn2novp)[24004]: UDPv4 link local (bound): [AF_INET][undef]:1199
Fri Jun 7 08:05:17 2024 daemon.notice openvpn(vsn2novp)[24004]: UDPv4 link remote: [AF_INET]xx.xx.xx.xx:1199
Fri Jun 7 08:05:17 2024 daemon.notice openvpn(vsn2novp)[24004]: TLS: Initial packet from [AF_INET]xx.xx.xx.xx:1199, sid=d7e021e9 c4ba568f
Fri Jun 7 08:05:17 2024 daemon.notice openvpn(vsn2novp)[24004]: VERIFY OK: depth=1, ... , emailAddress=...
Fri Jun 7 08:05:17 2024 daemon.notice openvpn(vsn2novp)[24004]: VERIFY KU OK
Fri Jun 7 08:05:17 2024 daemon.notice openvpn(vsn2novp)[24004]: Validating certificate extended key usage
Fri Jun 7 08:05:17 2024 daemon.notice openvpn(vsn2novp)[24004]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Fri Jun 7 08:05:17 2024 daemon.notice openvpn(vsn2novp)[24004]: VERIFY EKU OK
Fri Jun 7 08:05:17 2024 daemon.notice openvpn(vsn2novp)[24004]: VERIFY OK: depth=0, C=DE, ST=NRW, O=Esser Org, OU=Esser Dept, CN=serverip.de
Fri Jun 7 08:05:18 2024 daemon.notice openvpn(vsn2novp)[24004]: Outgoing Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Fri Jun 7 08:05:18 2024 daemon.notice openvpn(vsn2novp)[24004]: Outgoing Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Fri Jun 7 08:05:18 2024 daemon.notice openvpn(vsn2novp)[24004]: Incoming Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Fri Jun 7 08:05:18 2024 daemon.notice openvpn(vsn2novp)[24004]: Incoming Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Fri Jun 7 08:05:18 2024 daemon.notice openvpn(vsn2novp)[24004]: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
Fri Jun 7 08:05:18 2024 daemon.notice openvpn(vsn2novp)[24004]: [serverip.de] Peer Connection Initiated with [AF_INET]xx.xx.xx.xx:1199
Fri Jun 7 08:05:19 2024 daemon.warn openvpn(vsn2novp)[24004]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri Jun 7 08:05:19 2024 daemon.notice openvpn(vsn2novp)[24004]: Initialization Sequence Completed
and the GUI shows:
Nevertheless, I am unable to reach any client from the one network to the other and vica versa.
From my perspective, the routing table on the RUTX11 looks good:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 100.64.0.1 0.0.0.0 UG 1 0 0 eth1
default * 0.0.0.0 U 3 0 0 qmimux0
10.11.50.1 * 255.255.255.255 UH 0 0 0 tun_c_vsn2novp
xx.xx.xx.xx * 255.255.255.255 UH 1 0 0 eth1
100.64.0.0 * 255.192.0.0 U 1 0 0 eth1
xx.xx.xx.xx * 255.255.255.255 UH 3 0 0 qmimux0
192.168.11.0 10.11.50.1 255.255.255.0 UG 0 0 0 tun_c_vsn2novp
192.168.50.0 * 255.255.255.0 U 1 0 0 br-lan
192.168.100.1 * 255.255.255.255 UH 1 0 0 eth1
Does anyone have a tip for me what to try to solve this?
For example, do the RUTX11 firewall settings need to be changed? - Currently, they look as follows:
Do I need to make any additional changes to the ipfire settings? - When I did ipfire net-to-net setups previously, it always worked out of the box (with ipfire on both sides server and client) …
Thanks in advance!
So after a lot of experimenting I can confirm that also in my case the ipfire side seems to block the traffic by its OVPNBLOCK rule, as already mentioned by “terrillmore”, see link in my previous post above.
Thus by executing
iptables -F OVPNBLOCK
on the ipfire side, I can successfully ping from the Teltonika RUTX11 network 192.168.50.0/24 to 192.168.11.1 and from 192.168.11.1 to 192.168.50.0/24 through the OpenVPN net-to-net tunnel.
Now of course I am wondering what the security implications are of removing the OVPNBLOCK rules for my setup?
I am not 100% sure but I suspect that this means that by default the two networks at each end of the n2n are blocked by default to all users on those two subnets.
This then allows you to define who should have permissions via firewall rules to access the networks across the n2n tunnel, and also if the access is for the whole of the subnet or specific machines/protocols or even only specific directions.
I think without the OVPNBLOCK by default then any user on the network at one end of the n2n tunnel could access any machine in the subnet at the other end, without restriction, which might be too open an approach.
So I beieve by removing that OVPNBLOCK then you can now access from the Teltonika 192.168.50.0/24 subnet to the IPFire 192.168.11.0/24 subnet but so can every other user on that Teltonika subnet. You might not want that.
My conclusion above may not be correct.
According to this documentation page the default is to have the subnets at both ends of a VPN tunnel open and then you create a rule to block it and then additional rules to open it for the appropriate user.
https://www.ipfire.org/docs/configuration/firewall/rules/filtering-vpn
Based on this then I don’t understand what the OVPNBLOCK rule is for.
Dear Adolf, thanks for your replies! … 
I will publish more testing results later, probably today.
In the meantime, I have created a graphical overview of my complete setup, hopefully that makes it easier to get a good understanding:
1 Like
Happy to mention that the setup started to work fully, clients on networks 192.168.50.0/24, 192.168.14.0/24 and “roadwarriers” on 10.247.126.0/24 can now all reach each other, which was the intention.
Short summary of the important findings:
1 As already mentioned above,
iptables -F OVPNBLOCK
needs to be executed on 192.168.11.1 to disable the OVPNBLOCK rule. I have not found a better solution for this issue so far.
2 In addition to the routes to the respective subnets, I also had to push routes to the OpenVPN tunnel networks.
2a For the Teltonika Router ovpn client file (see above for the initial version), that meant using the following route instructions:
route 192.168.11.0 255.255.255.0
route 192.168.14.0 255.255.255.0
route 10.247.126.0 255.255.255.0
route 10.11.14.0 255.255.255.0
2b For the roadwarriers configuration, on 192.168.11.1 I am pushing the following routes in OpenVPN - Advanced Server Options:
192.168.14.0/255.255.255.0
192.168.50.0/255.255.255.0
10.11.50.0/255.255.255.0
10.11.14.0/255.255.255.0
2c On 192.168.14.1, I am using the following Static Routes:
I would be happy if the real ipfire experts (I am unfortunately not … ) could tell me, if there is a better / more elegant / more secure way to make my setup work avoiding the points mentioned above.
