Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - kug1977

Pages: [1]

18.7 Legacy Series / OpenVPN failed to start after reboot

« on: October 24, 2018, 06:48:06 am »

Hi,

due to the PPPoE reconnect issue, I have to restart the OPNsense (v18.7.5_1) on a daily base and I see, that OpenVPN failed to start in these procedure. This is a fresh installation. By the way, I'm able to connect to the OpenVPN Gateway, even if it shows, it's not up. So I guess these is a mismatch between GUI and real world.

These is, how it looks in bash:
root@fw:~ # ps aux | grep openvpn root 13532 0.0 0.2 1085792 6404 - Ss 06:38 0:00.17 /usr/local/sbin/openvpn --config /var/etc/openvpn/server1.conf

Oct 24 06:38:28 openvpn[13532]: Initialization Sequence Completed Oct 24 06:38:28 openvpn[13532]: IFCONFIG POOL: base=10.4.6.2 size=252, ipv6=0 Oct 24 06:38:28 openvpn[13532]: MULTI: multi_init called, r=256 v=256 Oct 24 06:38:28 openvpn[13532]: UDPv4 link remote: [AF_UNSPEC] Oct 24 06:38:28 openvpn[13532]: UDPv4 link local (bound): [AF_INET]89.247.XXX.XX0:1194 Oct 24 06:38:28 openvpn[13532]: Socket Buffers: R=[42080->42080] S=[57344->57344] Oct 24 06:38:28 openvpn[13532]: Could not determine IPv4/IPv6 protocol. Using AF_INET Oct 24 06:38:27 openvpn[13863]: Exiting due to fatal error Oct 24 06:38:27 openvpn[13863]: Cannot open TUN/TAP dev /dev/tun1: Device busy (errno=16) Oct 24 06:38:27 openvpn[13863]: TUN/TAP device ovpns1 exists previously, keep at program end Oct 24 06:38:27 openvpn[13863]: Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Oct 24 06:38:27 openvpn[13863]: Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Oct 24 06:38:27 openvpn[13863]: Diffie-Hellman initialized with 4096 bit key Oct 24 06:38:27 openvpn[13863]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Oct 24 06:38:27 openvpn[13863]: WARNING: using --duplicate-cn and --client-config-dir together is probably not what you want Oct 24 06:38:27 openvpn[13863]: MANAGEMENT: unix domain socket listening on /var/etc/openvpn/server1.sock Oct 24 06:38:27 openvpn[13532]: /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkup ovpns1 1500 1622 10.4.6.1 255.255.255.0 init Oct 24 06:38:27 openvpn[13532]: /sbin/route add -net 10.4.6.0 10.4.6.2 255.255.255.0 Oct 24 06:38:27 openvpn[13532]: /sbin/ifconfig ovpns1 10.4.6.1 10.4.6.2 mtu 1500 netmask 255.255.255.0 up Oct 24 06:38:27 openvpn[13532]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0 Oct 24 06:38:27 openvpn[13532]: TUN/TAP device /dev/tun1 opened Oct 24 06:38:27 openvpn[13532]: TUN/TAP device ovpns1 exists previously, keep at program end Oct 24 06:38:27 openvpn[13532]: Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Oct 24 06:38:27 openvpn[13532]: Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Oct 24 06:38:27 openvpn[13532]: Diffie-Hellman initialized with 4096 bit key Oct 24 06:38:27 openvpn[13532]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Oct 24 06:38:27 openvpn[13532]: WARNING: using --duplicate-cn and --client-config-dir together is probably not what you want Oct 24 06:38:27 openvpn[13532]: MANAGEMENT: unix domain socket listening on /var/etc/openvpn/server1.sock Oct 24 06:38:27 openvpn[12925]: library versions: LibreSSL 2.7.4, LZO 2.10 Oct 24 06:38:27 openvpn[12925]: OpenVPN 2.4.6 amd64-portbld-freebsd11.1 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Oct 15 2018 Oct 24 06:38:27 openvpn[13058]: library versions: LibreSSL 2.7.4, LZO 2.10 Oct 24 06:38:27 openvpn[13058]: OpenVPN 2.4.6 amd64-portbld-freebsd11.1 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Oct 15 2018

The service button stays red and any restart try fails with these logs:

Oct 24 06:45:57 openvpn[50915]: Exiting due to fatal error Oct 24 06:45:57 openvpn[50915]: Cannot open TUN/TAP dev /dev/tun1: Device busy (errno=16) Oct 24 06:45:57 openvpn[50915]: TUN/TAP device ovpns1 exists previously, keep at program end Oct 24 06:45:57 openvpn[50915]: Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Oct 24 06:45:57 openvpn[50915]: Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Oct 24 06:45:57 openvpn[50915]: Diffie-Hellman initialized with 4096 bit key Oct 24 06:45:57 openvpn[50915]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Oct 24 06:45:57 openvpn[50915]: WARNING: using --duplicate-cn and --client-config-dir together is probably not what you want Oct 24 06:45:57 openvpn[50915]: MANAGEMENT: unix domain socket listening on /var/etc/openvpn/server1.sock Oct 24 06:45:57 openvpn[50391]: library versions: LibreSSL 2.7.4, LZO 2.10 Oct 24 06:45:57 openvpn[50391]: OpenVPN 2.4.6 amd64-portbld-freebsd11.1 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Oct 15 2018

I see no difference in behaviour between OpenSSL and LibreSSL installs. Only way to get a match between GUI and bash, is killing the running OpenVPN process and start by hand.

Kind regards,
kug1977

18.1 Legacy Series / WAN re-negotiation fails on daily forced separation

« on: February 03, 2018, 04:32:43 pm »

Hi,

I've an APU1 board for OPNsense 18.1.1 and on port 0 works a Vigor 130 as VDSL modem. The Interface is configured as IPv4 / PPPoE and IPv6 / DHCPv6. I have enabled "Block private networks" and "Block bogon networks". Only username and password is set.

On a restart, the WAN come up and work probably. But it will not survive the daily forced separation and stay in interface overview than with status "up", but no network is working. It need a restart to work again. It stopped working after the upgrade to 17.7.11. 17.7.10 was working fine.

I can see in the logs at this time the following entries in /var/log/ppps.log. What is different between re-negotiation and restart is the entry Feb 3 15:35:31 fw2 ppp: caught fatal signal TERM.

Any idea, why the re-negotiation is failing?

Kind regards,
Kay-Uwe

17.7 Legacy Series / 17.7.11 and 17.7.12 doesn't reconnect on PPPoE IP renewal

« on: January 25, 2018, 10:37:46 am »

Hi,

since 17.7.11 I have the issue, that the daily IP renewal on the ADSL connection breaks online of OPNsense. The router will loose the IPv4 and IPv6 connection all 24h and it will get a new connection. I can see the connection goes online for 15sec and loose the connection again. An new IP get online after some seconds and the connection will be lost again. I can online break the cycle by restarting.

17.7.12 doesn't solve the issue. There is not so much installed next to default setup. I only have DynDNS package installed. Next to PPPoE I have a HE tunnel for IPv6. I see no error messages in the system log, that help me to understand the issue. It looks a bit like the issue we had some time ago with loosing PPPoE and going into a cycle.

Kind regards,
Kay-Uwe

17.1 Legacy Series / [SOLVED] IPsec is not routing traffic through the tunnel

« on: February 28, 2017, 05:02:40 pm »

Hi,

I've been trying to setup a IPsec tunnel and it was short working with OPNsense 17.1.1, but stopped again with OPNsense 17.1.2. The tunnel come up fine, but I can't put traffic through the tunnel (incl. PING). And now I'm at the end of my knowledge regarding IPsec and have to bother the forum members with my issue.

I've the following setup
Site A: DSL with the name gw1.dyndns.net (the DynDSN is working and result in the right DNS name)
Site B: DSL with the name gw2.dyndns.net (the DynDSN is working and result in the right DNS name)
phase1: IKEv2, Main Mode, NAT Enabled, MOBIKE disabled
phase2: will connect o lot of VLANs that are created on both sites. For test purposes I cut it down to ONE child SA.
I've been setting sysctl on both gateways the same way:
net.inet.ipsec.def_policy: 1
net.inet.ipsec.esp_trans_deflev: 1
net.inet.ipsec.esp_net_deflev: 1
net.inet.ipsec.ah_trans_deflev: 1
net.inet.ipsec.ah_net_deflev: 1
net.inet.ipsec.ah_cleartos: 1
net.inet.ipsec.ah_offsetmask: 0
net.inet.ipsec.dfbit: 0
net.inet.ipsec.ecn: 0
net.inet.ipsec.debug: 0
net.inet.ipsec.ipsecstats: Format:I Length:128 Dump:0x00000000000000000000000000000000...
net.inet.ipsec.crypto_support: 50331648
net.inet.ipsec.filtertunnel: 1

This is how apices status looks on gw2.dyndns.net
Status of IKE charon daemon (strongSwan 5.5.1, FreeBSD 11.0-RELEASE-p7, amd64):
uptime: 3 minutes, since Feb 28 18:00:02 2017
worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, scheduled: 4
loaded plugins: charon aes des blowfish rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf xcbc cmac hmac gcm attr kernel-pfkey kernel-pfroute resolve socket-default stroke vici updown eap-identity eap-md5 eap-mschapv2 eap-radius eap-tls eap-ttls eap-peap xauth-generic whitelist addrblock
Listening IP addresses:
10.0.2.129
87.180.85.216
Connections:
con1: 87.180.85.216...gw1.dyndns.net IKEv2, dpddelay=10s
con1: local: [87.180.85.216] uses pre-shared key authentication
con1: remote: [178.24.49.155] uses pre-shared key authentication
con1: child: 10.0.2.128/25 === 10.0.2.0/25 TUNNEL, dpdaction=clear
Security Associations (1 up, 0 connecting):
con1[1]: ESTABLISHED 3 minutes ago, 87.180.85.216[87.180.85.216]...178.24.49.155[178.24.49.155]
con1[1]: IKEv2 SPIs: 50508ca22749bb8b_i* 4089c57de2e38c5a_r, pre-shared key reauthentication in 3 hours
con1[1]: IKE proposal: BLOWFISH_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_4096
con1{1}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c92fbb12_i c655083e_o
con1{1}: AES_GCM_16_128, 0 bytes_i (0 pkts, 183s ago), 0 bytes_o, rekeying in 44 minutes
con1{1}: 10.0.2.128/25 === 10.0.2.0/25

root@gw2:~ # ipsec up con1
establishing CHILD_SA con1
generating CREATE_CHILD_SA request 45 [ N(ESP_TFC_PAD_N) SA No KE TSi TSr ]
sending packet: from 87.180.85.216[500] to 178.24.49.155[500] (464 bytes)
received packet: from 178.24.49.155[500] to 87.180.85.216[500] (464 bytes)
parsed CREATE_CHILD_SA response 45 [ N(ESP_TFC_PAD_N) SA No KE TSi TSr ]
received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
CHILD_SA con1{2} established with SPIs c0e90bb1_i ce7ab7b5_o and TS 10.0.2.128/25 === 10.0.2.0/25
connection 'con1' established successfully

On both sides the FW IPsec section allows all traffic to pass. I've setup a outgoing rule to prevent local packets leaving on WAN (https://www.infotechwerx.com/blog/Prevent-Any-Traffic-VPN-Hosts-Egressing-WAN), which triggers on PING from gw2 to gw1 (10.0.2.1) :
ping: sendto: Operation not permitted
I see also no traffic passing into our out of the tunnel in the VPN>IPsec>Status Overview on both sides. But I've been seeing the packages blogged in the FW logs by this rule. (Disabling the rule make IPsec not working.)

Can someone help to create a tunnel in my network, please? Or at least give me some more steps to troubleshoot?

King regards,
Kay-Uwe

17.1 Legacy Series / [SOLVED] Setup IPsec Tunnel with RSA Certificates

« on: February 28, 2017, 02:46:02 pm »

Hi,

I'm on opnsense 17.1.2 and I've been trying to setup a IPsec tunnel Phase1 with a RSA certificate. This failed with "The field Certificate Authority is required." I can understand the message, but I didn't see where to select the CA.

King regards,
Kay-Uwe

Pages: [1]