I have a problem with OpenVPN. I have two IPFire servers with OpenVPN, and they are connected via a net-to-net setup, with one acting as the server and the other as the client. We’ve already configured the server and transferred the file to the client. The tunnel interface appears, and on the server’s “Connection status and control” it shows “reconnecting,” while on the client it says “connected,” but if you refresh the page, it disconnects.
Did you follow the documentation?
Regards
1 Like
Hallo @lucia
Welcome to the IPFire community.
I have had a net2net system running without any issues for a couple of years now on my vm testbed and I set this up with the documentation.
One error that is often made is that the openvpn subnet that is specified is the same as or overlaps with another subnet used elsewhere in the IPFire system. That will cause problems as the software won’t know where to send the data to.
If all subnets are not overlapping then to get help it would be good to show screenshots of your server and client connections.
3 Likes
Good morning Adolf, thank you for your response. Today we reconfigured everything from scratch following the net-to-net guide available on the website. Each of the firewalls is on a different network with a different router, and they communicate through the internet.
We have a question about whether the networks we’ve set up are correct. These are the network configurations we’ve established on both the client and the server sides:
Client:
Green: 192.168.30.x
Red: 192.168.10.100
GW: 192.168.10.1
Server:
Green: 192.168.20.x
Red: 192.168.10.101
GW: 192.168.10.1
The OpenVPN subnet we’ve used is 192.168.2.0.
I’m sending you what the structure looks like on one side; the other side is the same.
Client:
Red: 192.168.10.100
GW: 192.168.10.1
Server:
Red: 192.168.10.101
GW: 192.168.10.1
Are you sure?
1 Like
Good morning, the gateways are the same because the routers are identical, but they are two separate routers. I’m trying to make the connection between each firewall go through the internet.
I am presuming that the red IP’s and the Gateway IP’s are provided to IPFire at each end by the respective router via dhcp.
A difference your network has, compared to mine, is that you have IPFire and another router, meaning that both ends of your net2net connection are double NAT’d.
Have you put into each router a port forward rule for the port number you are using for net2net connection.
Have you made sure to not use the same port number for the net2net connection as is used for the rw connection (default 1194) or is the rw connection disabled at both ends?
2 Likes
Can you show the routing table on IPFire server and on IPFire client?
1 Like
The openvpn troubleshooting section of the documentation is also worth checking through to see how to review the logs and the typical issues that can be found.
https://www.ipfire.org/docs/configuration/services/openvpn/troubles
2 Likes
Good morning, thank you for your response. Here I’m sending some screenshots in case they can help to resolve the issue.
I’ve tried changing the MTU to 1400 and even 1500, but it doesn’t make any difference.
On the routers, we have configured DMZ and a route for port “1195”, which is the port we use in the Net-to-Net configuration.
Could you copy and paste the logs as text. As screenshots, those are very hard to follow and read with my mobile.
1 Like
Logs - Client
Apr 11 10:47:18 ipfire-B clienten2n[7098]: [UNDEF] Inactivity timeout (–ping-restart), restarting
Apr 11 10:47:18 ipfire-B clienten2n[7098]: SIGUSR1[soft,ping-restart] received, process restarting
Apr 11 10:47:18 ipfire-B clienten2n[7098]: Restart pause, 300 second(s)
Apr 11 10:47:37 ipfire-B clienten2n[7098]: MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1195
Apr 11 10:47:37 ipfire-B clienten2n[7098]: MANAGEMENT: CMD ‘state’
Apr 11 10:47:37 ipfire-B clienten2n[7098]: MANAGEMENT: Client disconnected
Apr 11 10:48:57 ipfire-B clienten2n[7098]: MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1195
Apr 11 10:48:57 ipfire-B clienten2n[7098]: MANAGEMENT: CMD ‘state’
Apr 11 10:48:58 ipfire-B clienten2n[7098]: MANAGEMENT: Client disconnected
Apr 11 10:49:01 ipfire-B clienten2n[7098]: MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1195
Apr 11 10:49:01 ipfire-B clienten2n[7098]: MANAGEMENT: CMD ‘state’
Apr 11 10:49:01 ipfire-B clienten2n[7098]: MANAGEMENT: Client disconnected
Apr 11 10:49:04 ipfire-B clienten2n[7098]: MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1195
Apr 11 10:49:04 ipfire-B clienten2n[7098]: MANAGEMENT: CMD ‘state’
Apr 11 10:49:04 ipfire-B clienten2n[7098]: MANAGEMENT: Client disconnected
Apr 11 10:49:20 ipfire-B clienten2n[7098]: /sbin/ip route del 192.168.20.0/24
Apr 11 10:49:20 ipfire-B clienten2n[7098]: ERROR: Linux route delete command failed: external program exited with error status: 2
Apr 11 10:49:20 ipfire-B clienten2n[7098]: Closing TUN/TAP interface
Apr 11 10:49:20 ipfire-B clienten2n[7098]: /sbin/ip addr del dev tun1 local 10.150.150.2 peer 10.150.150.1
Apr 11 10:49:20 ipfire-B clienten2n[7098]: Linux ip addr del failed: external program exited with error status: 2
Apr 11 10:49:20 ipfire-B clienten2n[7098]: SIGTERM[hard,init_instance] received, process exiting
Apr 11 10:49:20 ipfire-B clienten2n[14548]: Cipher negotiation is disabled since neither P2MP client nor server mode is enabled
Apr 11 10:49:20 ipfire-B clienten2n[14548]: WARNING: Using --management on a TCP port WITHOUT passwords is STRONGLY discouraged and considered insecure
Apr 11 10:49:20 ipfire-B clienten2n[14548]: WARNING: file ‘/var/ipfire/ovpn/certs/cliente.p12’ is group or others accessible
Apr 11 10:49:20 ipfire-B clienten2n[14548]: OpenVPN 2.5.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Feb 20 2025
Apr 11 10:49:20 ipfire-B clienten2n[14548]: library versions: OpenSSL 3.4.1 11 Feb 2025, LZO 2.10
Apr 11 10:49:20 ipfire-B clienten2n[14549]: MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:1195
Apr 11 10:49:20 ipfire-B clienten2n[14549]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Apr 11 10:49:20 ipfire-B clienten2n[14549]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1300)
Apr 11 10:49:20 ipfire-B clienten2n[14549]: ROUTE_GATEWAY 192.168.10.1/255.255.255.0 IFACE=red0 HWADDR=70:10:6f:b1:db:a5
Apr 11 10:49:20 ipfire-B clienten2n[14549]: TUN/TAP device tun1 opened
Apr 11 10:49:20 ipfire-B clienten2n[14549]: /sbin/ip link set dev tun1 up mtu 1300
Apr 11 10:49:20 ipfire-B clienten2n[14549]: /sbin/ip link set dev tun1 up
Apr 11 10:49:20 ipfire-B clienten2n[14549]: /sbin/ip addr add dev tun1 local 10.150.150.2 peer 10.150.150.1
Apr 11 10:49:20 ipfire-B clienten2n[14549]: /etc/init.d/static-routes start tun1 1300 1405 10.150.150.2 10.150.150.1 init
Apr 11 10:49:20 ipfire-B clienten2n[14549]: /sbin/ip route add 192.168.20.0/24 via 10.150.150.1
Apr 11 10:49:20 ipfire-B clienten2n[14549]: TCP/UDP: Preserving recently used remote address: [AF_INET]62.87.74.133:1195
Apr 11 10:49:20 ipfire-B clienten2n[14549]: Socket Buffers: R=[212992->212992] S=[212992->212992]
Apr 11 10:49:20 ipfire-B clienten2n[14549]: UDPv4 link local (bound): [AF_INET]192.168.10.100:1195
Apr 11 10:49:20 ipfire-B clienten2n[14549]: UDPv4 link remote: [AF_INET]62.87.74.133:1195
Apr 11 10:49:21 ipfire-B clienten2n[14549]: GID set to nobody
Apr 11 10:49:21 ipfire-B clienten2n[14549]: UID set to nobody
Apr 11 10:49:21 ipfire-B clienten2n[14549]: MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1195
Apr 11 10:49:21 ipfire-B clienten2n[14549]: MANAGEMENT: CMD ‘state’
Apr 11 10:49:21 ipfire-B clienten2n[14549]: MANAGEMENT: Client disconnected
Apr 11 10:49:35 ipfire-B clienten2n[14549]: event_wait : Interrupted system call (code=4)
Apr 11 10:49:35 ipfire-B clienten2n[14549]: /sbin/ip route del 192.168.20.0/24
Apr 11 10:49:35 ipfire-B clienten2n[14549]: ERROR: Linux route delete command failed: external program exited with error status: 2
Apr 11 10:49:35 ipfire-B clienten2n[14549]: Closing TUN/TAP interface
Apr 11 10:49:35 ipfire-B clienten2n[14549]: /sbin/ip addr del dev tun1 local 10.150.150.2 peer 10.150.150.1
Apr 11 10:49:35 ipfire-B clienten2n[14549]: Linux ip addr del failed: external program exited with error status: 2
Apr 11 10:49:35 ipfire-B clienten2n[14549]: SIGTERM[hard,] received, process exiting
Apr 11 10:49:35 ipfire-B clienten2n[14651]: Cipher negotiation is disabled since neither P2MP client nor server mode is enabled
Apr 11 10:49:35 ipfire-B clienten2n[14651]: WARNING: Using --management on a TCP port WITHOUT passwords is STRONGLY discouraged and considered insecure
Apr 11 10:49:35 ipfire-B clienten2n[14651]: WARNING: file ‘/var/ipfire/ovpn/certs/cliente.p12’ is group or others accessible
Apr 11 10:49:35 ipfire-B clienten2n[14651]: OpenVPN 2.5.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Feb 20 2025
Apr 11 10:49:35 ipfire-B clienten2n[14651]: library versions: OpenSSL 3.4.1 11 Feb 2025, LZO 2.10
Apr 11 10:49:35 ipfire-B clienten2n[14652]: MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:1195
Apr 11 10:49:35 ipfire-B clienten2n[14652]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Apr 11 10:49:35 ipfire-B clienten2n[14652]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1300)
Apr 11 10:49:35 ipfire-B clienten2n[14652]: ROUTE_GATEWAY 192.168.10.1/255.255.255.0 IFACE=red0 HWADDR=70:10:6f:b1:db:a5
Apr 11 10:49:35 ipfire-B clienten2n[14652]: TUN/TAP device tun1 opened
Apr 11 10:49:35 ipfire-B clienten2n[14652]: /sbin/ip link set dev tun1 up mtu 1300
Apr 11 10:49:35 ipfire-B clienten2n[14652]: /sbin/ip link set dev tun1 up
Apr 11 10:49:35 ipfire-B clienten2n[14652]: /sbin/ip addr add dev tun1 local 10.150.150.2 peer 10.150.150.1
Apr 11 10:49:35 ipfire-B clienten2n[14652]: /etc/init.d/static-routes start tun1 1300 1405 10.150.150.2 10.150.150.1 init
Apr 11 10:49:35 ipfire-B clienten2n[14652]: /sbin/ip route add 192.168.20.0/24 via 10.150.150.1
Apr 11 10:49:35 ipfire-B clienten2n[14652]: TCP/UDP: Preserving recently used remote address: [AF_INET]62.87.74.133:1195
Apr 11 10:49:35 ipfire-B clienten2n[14652]: Socket Buffers: R=[212992->212992] S=[212992->212992]
Apr 11 10:49:35 ipfire-B clienten2n[14652]: UDPv4 link local (bound): [AF_INET]192.168.10.100:1195
Apr 11 10:49:35 ipfire-B clienten2n[14652]: UDPv4 link remote: [AF_INET]62.87.74.133:1195
Apr 11 10:49:35 ipfire-B clienten2n[14652]: GID set to nobody
Apr 11 10:49:35 ipfire-B clienten2n[14652]: UID set to nobody
Apr 11 10:49:35 ipfire-B clienten2n[14652]: MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1195
Apr 11 10:49:35 ipfire-B clienten2n[14652]: MANAGEMENT: CMD ‘state’
Apr 11 10:49:35 ipfire-B clienten2n[14652]: MANAGEMENT: Client disconnected
Logs - Server
Apr 11 10:44:41 firewall-A Prueban2n[6174]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Apr 11 10:44:41 firewall-A Prueban2n[6174]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Apr 11 10:44:41 firewall-A Prueban2n[6174]: Preserving previous TUN/TAP instance: tun1
Apr 11 10:44:41 firewall-A Prueban2n[6174]: TCP/UDP: Preserving recently used remote address: [AF_INET]31.4.236.118:1195
Apr 11 10:44:41 firewall-A Prueban2n[6174]: Socket Buffers: R=[212992->212992] S=[212992->212992]
Apr 11 10:44:41 firewall-A Prueban2n[6174]: UDPv4 link local (bound): [AF_INET]192.168.30.101:1195
Apr 11 10:44:41 firewall-A Prueban2n[6174]: UDPv4 link remote: [AF_INET]31.4.236.118:1195
Apr 11 10:45:41 firewall-A Prueban2n[6174]: [UNDEF] Inactivity timeout (–ping-restart), restarting
Apr 11 10:45:41 firewall-A Prueban2n[6174]: SIGUSR1[soft,ping-restart] received, process restarting
Apr 11 10:45:41 firewall-A Prueban2n[6174]: Restart pause, 5 second(s)
Apr 11 10:45:46 firewall-A Prueban2n[6174]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Apr 11 10:45:46 firewall-A Prueban2n[6174]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Apr 11 10:45:46 firewall-A Prueban2n[6174]: Preserving previous TUN/TAP instance: tun1
Apr 11 10:45:46 firewall-A Prueban2n[6174]: TCP/UDP: Preserving recently used remote address: [AF_INET]31.4.236.118:1195
Apr 11 10:45:46 firewall-A Prueban2n[6174]: Socket Buffers: R=[212992->212992] S=[212992->212992]
Apr 11 10:45:46 firewall-A Prueban2n[6174]: UDPv4 link local (bound): [AF_INET]192.168.30.101:1195
Apr 11 10:45:46 firewall-A Prueban2n[6174]: UDPv4 link remote: [AF_INET]31.4.236.118:1195
So the wui screens look generally okay, except you should make the mtu as 1500 for both server and client. That is the default for udp, which you are using and what i have on my testbed system. I didn’t change those settings from default on my system.
Both sets of logs also show messages saying that mtu should be 1500.
The connection at both ends are seeing the other but timeouts are ocurring.
I am not an expert but i would think that the mtu for both ends needs to be the same.
I changed the MTU as you suggested. On the OpenVPN pages, it still shows as connected, but it doesn’t actually connect, and nothing appears in the Connection Statistics. Also, the logs still show the same messages. When I refresh the page, it shows as connected for a second and then disconnects.
Apr 11 11:41:55 ipfire-B clienten2n[17963]: MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1195
Apr 11 11:41:55 ipfire-B clienten2n[17963]: MANAGEMENT: CMD ‘state’
Apr 11 11:41:55 ipfire-B clienten2n[17963]: MANAGEMENT: Client disconnected
Apr 11 11:42:20 ipfire-B clienten2n[17963]: [UNDEF] Inactivity timeout (–ping-restart), restarting
Apr 11 11:42:20 ipfire-B clienten2n[17963]: SIGUSR1[soft,ping-restart] received, process restarting
Apr 11 11:42:20 ipfire-B clienten2n[17963]: Restart pause, 5 second(s)
Apr 11 11:42:25 ipfire-B clienten2n[17963]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Apr 11 11:42:25 ipfire-B clienten2n[17963]: Preserving previous TUN/TAP instance: tun1
Apr 11 11:42:25 ipfire-B clienten2n[17963]: TCP/UDP: Preserving recently used remote address: [AF_INET]62.87.74.133:1195
Apr 11 11:42:25 ipfire-B clienten2n[17963]: Socket Buffers: R=[212992->212992] S=[212992->212992]
Apr 11 11:42:25 ipfire-B clienten2n[17963]: UDPv4 link local (bound): [AF_INET]192.168.10.100:1195
Apr 11 11:42:25 ipfire-B clienten2n[17963]: UDPv4 link remote: [AF_INET]62.87.74.133:1195
Apr 11 11:42:48 ipfire-B clienten2n[17963]: MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1195
Apr 11 11:42:48 ipfire-B clienten2n[17963]: MANAGEMENT: CMD ‘state’
Apr 11 11:42:49 ipfire-B clienten2n[17963]: MANAGEMENT: Client disconnected
Apr 11 11:43:25 ipfire-B clienten2n[17963]: [UNDEF] Inactivity timeout (–ping-restart), restarting
Apr 11 11:43:25 ipfire-B clienten2n[17963]: SIGUSR1[soft,ping-restart] received, process restarting
Apr 11 11:43:25 ipfire-B clienten2n[17963]: Restart pause, 5 second(s)
Apr 11 11:43:30 ipfire-B clienten2n[17963]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Apr 11 11:43:30 ipfire-B clienten2n[17963]: Preserving previous TUN/TAP instance: tun1
Apr 11 11:43:30 ipfire-B clienten2n[17963]: TCP/UDP: Preserving recently used remote address: [AF_INET]62.87.74.133:1195
Apr 11 11:43:30 ipfire-B clienten2n[17963]: Socket Buffers: R=[212992->212992] S=[212992->212992]
Apr 11 11:43:30 ipfire-B clienten2n[17963]: UDPv4 link local (bound): [AF_INET]192.168.10.100:1195
Apr 11 11:43:30 ipfire-B clienten2n[17963]: UDPv4 link remote: [AF_INET]62.87.74.133:1195
Apr 11 11:44:30 ipfire-B clienten2n[17963]: [UNDEF] Inactivity timeout (–ping-restart), restarting
Apr 11 11:44:30 ipfire-B clienten2n[17963]: SIGUSR1[soft,ping-restart] received, process restarting
Apr 11 11:44:30 ipfire-B clienten2n[17963]: Restart pause, 5 second(s)
Reboot the PC
1 Like
Looking at your client and server logs the connection is definitely failing to be made. If it was successful you would have the message
Initialization Sequence Completed
Also before that message is shown, would be the cipher authentication messages and there are none of those in the logs.
The fact that the connection setup fails very early in the sequence of things make me feel there is some issue with the port forward setup on your other routers.
If it was my system, my first check would be to open the port forwarding on the other two routers to be fully open and then test again.
I just tried pinging my IPFire public IP and it worked without any problem.
I just tried pinging the IP you have shown for the server and the client and got 100% packet loss with no response.
If you edited the public IP’s in your logs then test out doing a ping to the public IP of one IPFire from the other IPFire. If you cannot get any packets received it suggests that there is an error of some sort in your port forward.
You mention that you have set up a route for port 1195. Can you confirm that the route goes to the correct IP for the red interface of that IPFire?
Sometimes the so called DMZ mode in routers does not do a very good job of port forwarding, as it is not really port forwarding but just saying that a specified IP gets everything passed to it without any checks but then you need to ensure you have selected the correct IP for it to forward to.
Can you put those other routers into bridged mode, so they don’t interfere with the traffic at all?
When I had a period where I had to initially have the router from my ISP between my IPFire and the internet connection, I did not have to set any DMZ mode, I just set the port forward for a specific IP and port/protocol.
2 Likes
Good morning, thank you for your response. We have contacted our ISP, and they are blocking the incoming traffic. We have decided to use two switches connected to each other.
Our IPs are:
FW-Client
- Green: 192.168.30.10
- Red: 192.168.10.100
- GW: 192.168.10.1 - switch
FW-Server
- Green: 192.168.20.60
- Red: 192.168.10.101
- GW: 192.168.10.2 - switch