OPNsense Forum
Archive => 17.7 Legacy Series => Topic started by: wos on December 04, 2017, 10:05:29 am
-
Hi!
coming in origin from monowall years ago, meanwhile i used pfsense also for some years at home and at some of my customers. I've heard about opnsense and want to give it a try. My first experience was positive. Installation on my old APU was flawless, things seam to work out of the box.
On the second day i decided to setup the IPSec Tunnels to my comapny as well. One P1 and 4 P2. Its almost the same settings and look and feel like pfsense (as its a fork) and so I felt immediately at home. The tunnel was configured in a few moments and I was pleased about it.
Next Day ... no tunnel anymore. Logs are full of errors. Stopping IPSec an starting again brings the tunnel up. When the first P2 rekey happens ... it's all over ... and never comes back. My Cicso ASA on the other side states in syslog, that there is a P2 Error.
opnsense showing in P2 logs, NO_PROPOSAL_CHOOSEN which is the same meaning. P1 always is coming up. P2 initial also, but ... not when rekeying. Why should there now a P2 error, when P2 is coming initial up? Seems strange to me.
Does anybody maybe got an idea?
-
Probably when ASA initiates the tunnel it works but not vice versa. Can you verify to set in P1 respond only and check if ASA can build the tunnel, and also try set start immediate to recheck. Quite sure it only works in one direction.
-
Just checked the settings in my asa. The connection-type is already "answer-only" (not "bidirectional" and not "originate-only"). So it should be already configured as like you would suggest.b At the moment i cant take a look remotely to my opnsense. But I'm 99,99% sure, that opnsense is configured to "immediately". For 100% I've to look this evening.
-
Hm, ASA to respond only and OPN to start immediate should be the most compatible .. can't imagine why this wont work.
-
Ok, i can confirm now, that P1 is set to "immediately". This morning I disabled and enabled IPSec so the tunnel comes up. Meanwhile a rekeying was in progress ... and the tunnel was broken afterwards. And I think here's the problem (found in opnsense ipsec logs):
Dec 5 15:18:48 charon: 14[CFG] configured proposals: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_1536/NO_EXT_SEQ
Dec 5 15:18:48 charon: 14[CFG] received proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_MD5_96/NO_EXT_SEQ, ESP:AES_CBC_192/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_192/HMAC_MD5_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_MD5_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_MD5_96/NO_EXT_SEQ, ESP:DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:DES_CBC/HMAC_MD5_96/NO_EXT_SEQ
The received proposals and configured proposals are not matching ... when rekeying. But the proposals must be proper, why was the tunnel up bevore. Especially the MODP_1536, i think it's about the PerfectForwardSecrecy seems to be the problem.
With pfsense I had over years the same proposals.
Now i reconfigured opnsense and my asa in the company to make no pfs in P2. I think, this will solve the issue as a workaround ... i can give a feedback tomorrow.
But, on the other hand, if its working then ... something is going wrong with the proposals which should be fixed in the future. Let us see ...
-
Would it be possible to set the old values on the ASA to reproduce the problem?
Then on the OPN via CLI open /usr/local/etc/ipsec.conf and go to your connection. For phase2 remove the "!" at the end, save and on the CLI /usr/local/etc/rc.d/ipsec onestop and /usr/local/etc/rc.d/ipsec onestart.
I have an open issue and if to works for you I can input this one:
https://github.com/opnsense/core/issues/1852
-
Of course, I'll give it a try tomorrow. First I'll have a look if my workaround is solving the issue and if my thougts are going into the right direction.
-
Turning PFS off in QuickMode, didn't chang anything, the issue persists. I've now set the old values PFS1536 on both sides and removed the "!" from every con001-00x in vi, as suggested:
# This file is automatically generated. Do not edit
config setup
uniqueids = yes
charondebug=""
conn con1-000
aggressive = no
fragmentation = yes
keyexchange = ikev1
reauth = yes
rekey = yes
forceencaps = no
installpolicy = yes
type = tunnel
dpdaction = clear
dpddelay = 10s
dpdtimeout = 60s
left = 123.123.123.123
right = ipsec.bla.bla
leftid = 123.123.123.123
ikelifetime = 86400s
lifetime = 3600s
ike = aes128-sha1-modp1024!
leftauth = psk
rightauth = psk
rightid = 234.234.234.234
rightsubnet = 10.0.0.0/24
leftsubnet = 192.168.111.0/24
esp = aes128-sha1-modp1536!
auto = start
... and on the CLI /usr/local/etc/rc.d/ipsec onestop and /usr/local/etc/rc.d/ipsec onestart.
Unfortunaly there is noting with ipsec in ...
root@wall:~ # cd /usr/local/etc/rc.d
root@wall:/usr/local/etc/rc.d # ls -la
total 156
drwxr-xr-x 2 root wheel 1024 Nov 30 21:29 .
drwxr-xr-x 29 root wheel 5632 Nov 30 21:54 ..
-rwxr-xr-x 1 root wheel 1720 Nov 21 06:54 acme_http_challenge
-r-xr-xr-x 1 root wheel 443 Oct 3 20:27 apinger
-rwxr-xr-x 1 root wheel 5571 Nov 21 06:56 captiveportal
-r-xr-xr-x 1 root wheel 682 Oct 3 22:11 choparp
-rwxr-xr-x 1 root wheel 1579 Nov 21 06:56 configd
-r-xr-xr-x 1 root wheel 1181 Oct 3 22:59 dhcp6c
-r-xr-xr-x 1 root wheel 881 Oct 3 22:59 dhcp6relay
-r-xr-xr-x 1 root wheel 1005 Oct 3 22:59 dhcp6s
-r-xr-xr-x 1 root wheel 2747 Oct 3 21:40 dnsmasq
-r-xr-xr-x 1 root wheel 404 Oct 3 23:46 expiretable
-r-xr-xr-x 1 root wheel 729 Oct 3 22:27 flowd
-rwxr-xr-x 1 root wheel 1145 Nov 21 06:56 flowd_aggregate
-r-xr-xr-x 1 root wheel 12216 Oct 3 23:11 isc-dhcpd
lrwxr-xr-x 1 root wheel 9 Nov 30 19:55 isc-dhcpd6 -> isc-dhcpd
-r-xr-xr-x 1 root wheel 1828 Oct 3 23:10 isc-dhcrelay
lrwxr-xr-x 1 root wheel 12 Nov 30 19:55 isc-dhcrelay6 -> isc-dhcrelay
-r-xr-xr-x 1 root wheel 509 Oct 3 23:46 kpropd
-r-xr-xr-x 1 root wheel 3330 Oct 4 00:49 lighttpd
-r-xr-xr-x 1 root wheel 838 Oct 3 23:16 mpd5
-r-xr-xr-x 1 root wheel 12193 Nov 21 01:08 named
-rwxr-xr-x 1 root wheel 4767 Nov 21 06:56 netflow
-r-xr-xr-x 1 root wheel 4694 Nov 21 02:38 openssh
-r-xr-xr-x 1 root wheel 4341 Oct 3 23:57 openvpn
-r-xr-xr-x 1 root wheel 1228 Nov 21 00:36 php-fpm
-r-xr-xr-x 1 root wheel 444 Oct 3 23:28 radvd
-r-xr-xr-x 1 root wheel 1936 Oct 3 23:30 samplicator
-r-xr-xr-x 1 root wheel 3875 Oct 4 01:02 squid
-r-xr-xr-x 1 root wheel 576 Oct 4 00:05 strongswan
-r-xr-xr-x 1 root wheel 2048 Nov 21 02:51 suricata
-r-xr-xr-x 1 root wheel 1235 Nov 21 01:14 unbound
root@wall:/usr/local/etc/rc.d #
root@wall:/usr/local/etc/rc.d # find / -name ipsec
/etc/rc.d/ipsec
/usr/local/libexec/ipsec
/usr/local/opnsense/scripts/ipsec
/usr/local/etc/inc/plugins.inc.d/ipsec
/usr/local/lib/ipsec
/usr/local/sbin/ipsec
/var/db/etcupdate/current/etc/rc.d/ipsec
root@wall:/usr/local/etc/rc.d #
But there is a dir /etc/rc.d/ ... maybe that one? There is also a file called ipsec which looks like this:
#!/bin/sh
#
# $FreeBSD$
#
# PROVIDE: ipsec
# REQUIRE: FILESYSTEMS
# BEFORE: DAEMON mountcritremote
# KEYWORD: nojail
. /etc/rc.subr
name="ipsec"
desc="Internet Protocol Security protocol"
rcvar="ipsec_enable"
start_precmd="ipsec_prestart"
start_cmd="ipsec_start"
stop_precmd="test -f $ipsec_file"
stop_cmd="ipsec_stop"
reload_cmd="ipsec_reload"
extra_commands="reload"
ipsec_program="/sbin/setkey"
# ipsec_file is set by rc.conf
ipsec_prestart()
{
if [ ! -f "$ipsec_file" ]; then
warn "$ipsec_file not readable; ipsec start aborted."
stop_boot
return 1
fi
return 0
}
ipsec_start()
{
echo "Installing ipsec manual keys/policies."
${ipsec_program} -f $ipsec_file
}
ipsec_stop()
{
echo "Clearing ipsec manual keys/policies."
# Still not 100% sure if we would like to do this.
# It is very questionable to do this during shutdown session
# since it can hang any of the remaining IPv4/v6 sessions.
#
${ipsec_program} -F
${ipsec_program} -FP
}
ipsec_reload()
{
echo "Reloading ipsec manual keys/policies."
${ipsec_program} -f "$ipsec_file"
}
load_rc_config $name
run_rc_command "$1"
Now, I'm a little bit confused, what to do now. I guessed something like ipsec start ... some thing happens but nothing changes.
So I rebooted opnsense and enabled ipsec via gui. But ... then my deleted "!" from config was back again.
-
You're right. It's ipsec stop and ipsec start.
Just remove the "!" and test again please
-
Ok, the rekeying after 1 hour seems to be working now (newest entry on top):
Dec 6 10:53:47 charon: 02[IKE] CHILD_SA con1-001{7} established with SPIs cf7c0bfd_i 0effb429_o and TS 192.168.111.0/24 === 10.20.0.0/16
Dec 6 10:53:47 charon: 02[IKE] CHILD_SA con1-001{7} established with SPIs cf7c0bfd_i 0effb429_o and TS 192.168.111.0/24 === 10.20.0.0/16
Dec 6 10:53:47 charon: 02[ENC] parsed QUICK_MODE response 2181303872 [ HASH SA No KE ID ID ]
Dec 6 10:53:47 charon: 02[NET] received packet: from 234.234.234.234[500] to 123.123.123.123[500] (364 bytes)
Dec 6 10:53:47 charon: 02[NET] sending packet: from 123.123.123.123[500] to 234.234.234.234[500] (380 bytes)
Dec 6 10:53:47 charon: 02[ENC] generating QUICK_MODE request 2181303872 [ HASH SA No KE ID ID ]
Dec 6 10:53:47 charon: 10[KNL] creating rekey job for CHILD_SA ESP/0x12b549df/234.234.234.234
What I regognized, was, that the tunnel was up, but I wasn't able to send traffic through. But ... ok ... maybe this is not possible if I just type ipsec start to bring the tunnel up. After ipsec stop and enabling in the gui, packets are passing through.
In summary, this seems to solve the issue, if config changes in the gui also don't put that "!" in. I hope so ... also that then ... traffic will passing by.
I've also saw 2 tings in my asa syslog:
06.12.2017 10:08:01 Local:234.234.234.234:500 Remote:123.123.123.123:500 Username:Unknown IKEv2 Received request to establish an IPsec tunnel; local traffic selector = Address Range: 10.20.1.20-10.20.1.20 Protocol: 0 Port Range: 0-65535; remote traffic selector = Address Range: 192.168.111.49-192.168.111.49 Protocol: 0 Port Range: 0-65535"
06.12.2017 10:10:00 wall local 3 Warning "%ASA-4-750003: Local:234.234.234.234:500 Remote:123.123.123.123:500 Username:123.123.123.123 IKEv2 Negotiation aborted due to ERROR: Received no proposal chosen notify"
The P1 is configured to IKE V1. I don't understand why there is obviously an attempt ... something with IKE V2? Or should i open better a new thread for that question?
-
Its definitely working now, without the "!". Permanent without any issue, of course, unless I would make any changes in the ipsec gui.
-
Hi wos,
Thank you for the feedback. We're discussing what to do and will come up with a GUI-based solution in the next weeks so you don't have to make these modifications all the time.
Cheers,
Franco