OpenVPN on 2.3.2 "Exiting due to fatal error"
-
This all done postboot immediately.
Disable the OpenVPN server, keep the client:
route -rn
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 172.17.255.254 UGS vtnet0
10.11.12.0/24 link#3 U vtnet2
10.11.12.5 link#3 UHS lo0
10.172.0.1 link#9 UH ovpnc2
127.0.0.1 link#7 UH lo0
172.17.0.0/16 link#1 U vtnet0
172.17.0.1 fa:16:3e:b6:f4:b8 UHS vtnet0
172.17.0.16 link#1 UHS lo0
192.168.168.0/24 link#2 U vtnet1
192.168.168.5 link#2 UHS lo0Enable the OpenVPN server
route -rn
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 172.17.255.254 UGS vtnet0
10.11.12.0/24 link#3 U vtnet2
10.11.12.5 link#3 UHS lo0
10.172.0.1 link#9 UH ovpnc2
10.172.0.2 link#8 UH ovpns1
127.0.0.1 link#7 UH lo0
172.17.0.0/16 link#1 U vtnet0
172.17.0.1 fa:16:3e:b6:f4:b8 UHS vtnet0
172.17.0.16 link#1 UHS lo0
192.168.168.0/24 link#2 U vtnet1
192.168.168.5 link#2 UHS lo0Logs:
Sep 29 23:01:00 openvpn 22695 Exiting due to fatal error
Sep 29 23:01:00 openvpn 22695 FreeBSD ifconfig failed: external program exited with error status: 1
Sep 29 23:01:00 openvpn 22695 /sbin/ifconfig ovpns1 10.172.0.1 10.172.0.2 mtu 1500 netmask 255.255.255.0 up
Sep 29 23:01:00 openvpn 22695 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sep 29 23:01:00 openvpn 22695 TUN/TAP device /dev/tun1 opened
Sep 29 23:01:00 openvpn 22695 TUN/TAP device ovpns1 exists previously, keep at program endDisable the OpenVPN server AND delete the client
route -rn
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 172.17.255.254 UGS vtnet0
10.11.12.0/24 link#3 U vtnet2
10.11.12.5 link#3 UHS lo0
10.172.0.1 link#9 UH tun2
10.172.0.2 link#8 UH ovpns1
127.0.0.1 link#7 UH lo0
172.17.0.0/16 link#1 U vtnet0
172.17.0.1 fa:16:3e:b6:f4:b8 UHS vtnet0
172.17.0.16 link#1 UHS lo0
192.168.168.0/24 link#2 U vtnet1
192.168.168.5 link#2 UHS lo0and then ifconfig
ovpns1: flags=8010 <pointopoint,multicast>metric 0 mtu 1500
options=80000 <linkstate>nd6 options=21 <performnud,auto_linklocal>tun2: flags=8010 <pointopoint,multicast>metric 0 mtu 1500
options=80000 <linkstate>nd6 options=21 <performnud,auto_linklocal></performnud,auto_linklocal></linkstate></pointopoint,multicast></performnud,auto_linklocal></linkstate></pointopoint,multicast> -
@KOM:
I'm no expert by far, but I'm wondering if the following command is what's causing the error:
Sep 28 23:41:21 openvpn 78304 FreeBSD ifconfig failed: external program exited with error status: 1
Sep 28 23:41:21 openvpn 78304 /sbin/ifconfig ovpns1 10.172.0.1 10.172.0.2 mtu 1500 netmask 255.255.255.0 upI wonder if your problem is caused by a misconfiguration which can't be processed successfully by ifconfig. Can you run that command by itself without error?
Already tested previously, do not understand the result
/sbin/ifconfig ovpns1 10.172.0.1 10.172.0.2 mtu 1500 netmask 255.255.255.0 up
ifconfig: ioctl (SIOCAIFADDR): Address already in use -
Any idea what this post implies?
http://peter-mao.blogspot.fi/2015/09/freebsd-openvpn-bug.html
"Mon Sep 7 11:28:19 2015 /sbin/ifconfig tun0 172.23.238.249 172.23.238.250 mtu 1500 netmask 172.23.238.250 up
ifconfig: ioctl (SIOCAIFADDR): Address already in useMon Sep 7 11:25:45 2015 /sbin/ifconfig tun0 172.23.238.249 172.23.238.250 mtu 1500 netmask 172.23.238.250 up
ifconfig: ioctl (SIOCAIFADDR): File existssolution net.link.ether.inet.useloopback=0 "
-
it appears you are running an openvpn server & an openvpn client on the same subnet …. that is more then likely what the ifconfig error is about.
pick a different subnet for either of them
-
OK, you have got me there. Because this is how I have configured all my OpenVPNs always everywhere I thought this is the correct way to do it - to make sure the client connecting to the server is using the same subnet to be able to connect? This is not so?
-
My server has a "tunnel network" defined, my client has that field empty. So the server assigns the tunnel network automatically to the client connected? Is this not intended behavior?
-
clients receive their tunnel network when connecting to a server.
servers have a tunnel network defined in the config.in no circumstance should any interface have the same subnet and/or ip.
Because this is how I have configured all my OpenVPNs always everywhere I thought this is the correct way to do it - to make sure the client connecting to the server is using the same subnet to be able to connect? This is not so?
hmm? i'm unable to understand what you want todo.
clients connect to a server instance. there is no point in running both a client & server instance and connecting them to themselfs ????a tunnel network is a transit network. It honestly doesn't matter what subnet you use, as long as it doesn't conflict with others.
-
Summa summarum. The server component has a transit/tunnel network defined, the client configuration does not. However that translates into interface configurations, that I do not know. In no place have I defined the same network twice in any configuration.
-
Where does the client connect to?
-
Where does the client connect to?
I have defined one OpenVPN server and one Client. The client connects to the server.
-
Seems like this option makes it work. The serverprocess is able to start as well as the clientprocess.
net.link.ether.inet.useloopback=0
Does anyone know what that exactly does, and what the possible consequences might be? At the moment with that setting on, I can connect with my windowsclient to the OpenVPN server, but now I have problems with traffic.
WindowsPC out -> pfSense in -> pfSense out -> LAN Linux in -> LAN Linux out -> packet lost
I have monitored firewall logs and used tcpdump on pfsense as well as the Linux machine. to determine where tha packet gets lost.
-
-
Good for me. All of my firewalls are configured with "clients" which I wrongly assumed where "clients-that-connect-to-the-server" -client definitions. So it is not. Apparently the Client Export -tab is the only thing I need for my REAL clients, the Windows PC, to connect to the server.
In reality, all of my defined "Clients" have never connected anywhere it seems. But for the sake of our minds not blowing up, I have now deleted all client configurations from all of my firewalls.
Based on this mindblowing experience and knowledge, I will start over.
-
Right, so the connection still gets opened up. I removed the additional parameter from System -> Advanced. Still works. Of course deleted all "Clients". Still works. No traffic though. I verified that my ovpn-file for this firewall looks exactly like others that work - so I opted to download and install the latest version of the OpenVPN client for Windows. Tadaa. Now everything seem to work as expected. I suspect that part of debugging should be killing the openvpn.exe -process in windows every time, to make sure you don't have stuff interfering.
A learning experience.