ipsec: reqid left/right mismatch in route-based phase 1 #3443

jroehler23 · 2019-04-26T08:43:21Z

[X] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md

[X] I have searched the existing issues and I'm convinced that mine is new.

Describe the bug
IPSEC tunnel is not coming up in route-based configuration.
I have used the wiki: https://wiki.opnsense.org/manual/how-tos/ipsec-s2s-route.html
I think the problem is in mismatching reqids between the two sides.

Expected behavior
Tunnel should come up.

Relevant log files

Apr 25 10:52:55 | charon: 09[CFG] trap not found, unable to acquire reqid 0
Apr 25 10:52:55 | charon: 09[KNL] creating acquire job for policy XXX.XXX.XXX.XXX/32 === YYY.YYY.YYY.YYY/32 with reqid {0}
Apr 25 10:52:55 | charon: 09[KNL] received an SADB_ACQUIRE with policy id 52 but no matching policy found
Apr 25 10:52:43 | charon: 13[CFG] trap not found, unable to acquire reqid 0
Apr 25 10:52:43 | charon: 13[KNL] creating acquire job for policy XXX.XXX.XXX.XXX/32 === YYY.YYY.YYY.YYY/32 with reqid {0}
Apr 25 10:52:43 | charon: 13[KNL] received an SADB_ACQUIRE with policy id 52 but no matching policy found

Additional context
Add any other context about the problem here.

Environment
OPNsense 19.1.6-amd64
FreeBSD 11.2-RELEASE-p9-HBSD
OpenSSL 1.0.2r 26 Feb 2019

fichtner · 2019-04-26T10:59:05Z

Are both sides 19.1.6 and cleanly rebooted? Do IPsec configs differ on both sides? I mean in terms of phase 1 and 2 not configured on the other side...

jroehler23 · 2019-04-26T11:05:12Z

Both sides are 19.1.6. Policy based IPSec is working normal.

I did also a try to modify the working policy base configuration to avoid any typos.

fichtner · 2019-04-26T11:14:46Z

Well, the easiest way to confirm your theory is to compare reqid statements on both sides. Ifconfig will list all ipsec* devices which you can pair into left-right and see if there is a mismatch or not.

jroehler23 · 2019-04-26T11:23:57Z

Site Y:
ipsec2000: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1400
tunnel inet YYY --> XXX
inet6 fe80::20d:b9ff:fe43:1134%ipsec2000 prefixlen 64 scopeid 0xa
inet 10.0.204.2 --> 10.0.204.1 netmask 0xffffffff
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
reqid: 2000
groups: ipsec

Site X:
ipsec9000: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1400
tunnel inet XXX --> YYY
inet6 fe80::ae1f:6bff:fe69:f6ae%ipsec9000 prefixlen 64 scopeid 0x12
inet 10.0.204.1 --> 10.0.204.2 netmask 0xffffffff
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
reqid: 9000
groups: ipsec

fichtner · 2019-04-26T11:30:26Z

You should be able to work around this by editing /conf/config.xml changing all

<ikeid>2</ikeid>

on the left side to

<ikeid>9</ikeid>

of that ikeid is still free.

Can't offer a quick fix. @AdSchellevis will look at this next week, maybe reqid base needs to be able to be editable in phase 1.

Cheers,
Franco

AdSchellevis · 2019-04-27T09:49:30Z

reqid is used locally only, to verify your assumption, I've changed the ikeid on my test image on one side, so it now looks like:

site A

ipsec1000: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1400
	tunnel inet x.x.x.1 --> x.x.x.2
	inet6 fe80::21c:42ff:fe0b:7db0%ipsec1000 prefixlen 64 scopeid 0x7 
	inet 192.168.188.1 --> 192.168.188.2 netmask 0xffffffff 
	nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
	reqid: 1000
	groups: ipsec

site B

ipsec2000: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1400
	tunnel inet x.x.x.2 --> x.x.x.1
	inet6 fe80::21c:42ff:fe27:a918%ipsec2000 prefixlen 64 scopeid 0x8 
	inet 192.168.188.2 --> 192.168.188.1 netmask 0xffffffff 
	nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
	reqid: 2000
	groups: ipsec

You might have another configuration issue, I can't tell from the ticket.

vitense · 2019-05-29T11:25:19Z

Exactly the same problem here, running 19.1.8 on both boxes, policy-based tunnels works fine, but route-based tunnels not come up. If the tunnel is established manually, traffic goes through the tunnel.

charon: 12[KNL] received an SADB_ACQUIRE
charon: 12[KNL] SADB_EXT_ADDRESS_SRC
charon: 12[KNL] SADB_EXT_ADDRESS_DST
charon: 12[KNL] SADB_X_EXT_POLICY
charon: 12[KNL] SADB_EXT_PROPOSAL
charon: 12[KNL] received an SADB_ACQUIRE with policy id 14 but no matching policy found
charon: 12[KNL] creating acquire job for policy x.x.x.x/32 === y.y.y.y/32 with reqid {0}
charon: 10[CFG] trap not found, unable to acquire reqid 0

AdSchellevis · 2019-05-29T11:39:56Z

@vitense have you tried the exact same settings as described in the docs (https://docs.opnsense.org/manual/how-tos/ipsec-s2s-route.html)? We tested it on multiple machines, as far as we know its configuration related (support tag on the issue), strongswan messages are sometimes hard to interpret.

vitense · 2019-05-29T12:31:42Z

I used the doc from github https://github.com/opnsense/docs/blob/master/source/manual/how-tos/ipsec-s2s-route.rst, it seems to be the same. I use certs for auth an other DH groups, and these settings in policy-based mode works...i'll check again with PSK.

vitense · 2019-05-29T12:46:16Z

it's exactly the same behavior: tunnel is not coming up automatically, the messages are also the the same.

AdSchellevis · 2019-05-29T12:49:23Z

You could post screenshots of the settings, maybe someone has an idea, I can't reproduce this on our end myself.

vitense · 2019-05-29T12:57:07Z

@AdSchellevis oh, i forgot to mention: if the tunnel is established manually, the traffic is routed through. Also if i set one peer to "start immidiate" the tunnel is also up after ipsec restarted. So I think, that it could not be just an config issue.

AdSchellevis · 2019-05-29T13:02:21Z

it might be an issue with "start on traffic" and vti, I haven't seen it on our end, but it might not be the best default for this setup anyway. If the device exist on OPNsense (ipsecXXX and have the right reqid assigned) it should work when there's an established connection.

vitense · 2019-05-29T13:18:25Z

Yes, it's not the best option. Just to be sure: one box has reqid=1000, the other reqid=20000, but you wrote this doesn't matter?

mimugmail · 2019-05-29T13:23:13Z

No, doesn't matter

AdSchellevis · 2019-05-29T13:23:41Z

@vitense ok, that's a bit weird. when set to default it should be treated as "start immediate" in these cases:

core/src/etc/inc/plugins.inc.d/ipsec.inc

Lines 1168 to 1170 in 6cd8297

    
           } elseif (!empty($config['ipsec']['auto_routes_disable'])) { 
        
               $conn_auto = 'start'; 
        
           } else {

can you check your ipsec.conf if "auto" is set to "start"? if so, can you post the configs using "start immidiate" and default? they should be equal, but maybe we overlooked something.

the reqid's shouldn't matter as this is just the local binding.

vitense · 2019-06-03T11:25:35Z

Hi, here are the configs (seems to be identical):
##start on traffic

This file is automatically generated. Do not edit

config setup
uniqueids = yes

conn con1
aggressive = no
fragmentation = yes
keyexchange = ikev2
mobike = yes
reauth = yes
rekey = yes
forceencaps = no
installpolicy = no

dpdaction = none
left = xx.xx.xx.xx
right = yy.yy.yy.yy

leftid = gw1
ikelifetime = 28800s
lifetime = 28800s
ike = aes256-sha512-modp2048!
leftauth = psk
rightauth = psk
rightid = gw2
reqid = 1000
rightsubnet = 0.0.0.0/0
leftsubnet = 0.0.0.0/0
esp = aes256-sha512-modp2048!
auto = route

include ipsec.opnsense.d/*.conf

default:

This file is automatically generated. Do not edit

config setup
uniqueids = yes

conn con1
aggressive = no
fragmentation = yes
keyexchange = ikev2
mobike = yes
reauth = yes
rekey = yes
forceencaps = no
installpolicy = no

dpdaction = none
left = xx.xx.xx.xx
right = yy.yy.yy.yy

leftid = gw1
ikelifetime = 28800s
lifetime = 28800s
ike = aes256-sha512-modp2048!
leftauth = psk
rightauth = psk
rightid = gw2
reqid = 1000
rightsubnet = 0.0.0.0/0
leftsubnet = 0.0.0.0/0
esp = aes256-sha512-modp2048!
auto = route

include ipsec.opnsense.d/*.conf

auto=start is set if "do not install automatically install routes" at IPSec Advances Settings".

AdSchellevis · 2019-06-03T11:37:35Z

yes, you need "do not install automatically install routes" for routed, seems like a configuration issue then.

See also https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN

First, the route installation by the IKE daemon must be disabled. To do this, set charon.install_routes=0 in strongswan.conf.

vitense · 2019-06-03T11:51:57Z

So a mixed mode IPSec config isn't possible? At the other box we also still use policy-based connections.

AdSchellevis · 2019-06-03T12:15:20Z

I'm not sure it can't work, but the strongswan docs suggests it's not intended.

vitense · 2019-06-03T12:19:05Z

i changed P1 from "default" to "start on traffic" and in ipsec.conf auto is set to "route". In strongswan.conf: install_routes = no

AdSchellevis · 2019-06-03T12:22:15Z

I'm not sure I'm following now, if you choose "start on traffic" the config sticks to "auto = route", that would be odd

core/src/etc/inc/plugins.inc.d/ipsec.inc

Lines 1164 to 1165 in 6cd8297

    
           if (!empty($ph1ent['auto'])) { 
        
               $conn_auto = $ph1ent['auto'];

vitense · 2019-06-03T12:30:23Z

every time i change something in P1 or P1 settings, auto is set to "route" in ipsec.conf.

AdSchellevis · 2019-06-03T12:34:06Z

sorry, my community support time is spend for now. With "start on traffic" I meant "Start immediate", which should just set "auto = start" for this tunnel.

vitense · 2019-06-03T12:36:52Z

if I set P1 to default -> auto = start
if I set P1 to start on traffic -> auto = route
if I set P1 to start immidiate -> auto = start

vitense · 2019-06-04T07:01:52Z

if auto is set to "start", the tunnel is established when IPSec/strongswan starts. But if the tunnel is disconnected manually or due timeout, it is not reconnected by traffic, still the same messages:

[KNL] received an SADB_ACQUIRE with policy id 2 but no matching policy found
[KNL] creating acquire job for policy xx.xx.xx.xx./32 === yy.yy.yy.yy/32 with reqid {0}
[CFG] trap not found, unable to acquire reqid 0

AdSchellevis · 2019-06-04T07:14:58Z

Try manual routes and "do not install automatically install routes", https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN really suggests your settings aren't supported.

vitense · 2019-06-04T07:55:41Z

automatically route installation was already disabled (please see my comment yesterday).
/usr/local/etc/strongswan.conf:
starter {
load_warning = no
}
charon {
threads = 16
ikesa_table_size = 32
ikesa_table_segments = 4
init_limit_half_open = 1000
ignore_acquire_ts = yes
syslog {
identifier = charon
daemon {
ike_name = yes
net = 4
}
}
install_routes = no
plugins {
}
}

AdSchellevis · 2019-06-04T08:11:42Z

I don't think I can help you, when in ipsec.conf auto = start and in strongswan.conf install_routes = no on all our setups it just works without issues. reqid 0 is also a bit odd, I don't think that's the actual configured ikeid.

vitense · 2019-06-04T10:16:46Z

thank you anyway

jroehler23 · 2019-06-18T15:33:23Z

The last hint was the solution! With "Do not install routes automatically" the tunnel is coming up and works!

mimugmail · 2019-07-15T09:36:46Z

Sidenote: I have a customer with a VPN problem, IKEv1, running 15 tunnels in sum, 1 of it has problems with exact error. But it's legacy policy routing, not routed ipsec:

Jul 15 11:31:22 FW1 charon: 14[KNL] received an SADB_ACQUIRE with policy id 4339 but no matching policy found
Jul 15 11:31:22 FW1 charon: 14[KNL] creating acquire job for policy X.X.X.X/32 === Y.Y.Y.Y/32 with reqid {0}
Jul 15 11:31:22 FW1 charon: 14[CFG] trap not found, unable to acquire reqid 0

EDIT: other side is Checkpoint

fichtner added incomplete Issue template missing info support Community support and removed incomplete Issue template missing info labels Apr 26, 2019

fichtner mentioned this issue Apr 26, 2019

Route-based IPSEC / if_ipsec #2332

Closed

fichtner changed the title ~~Route-based IPSEC not working in 19.1.6~~ ipsec: reqid left/right mismatch in route-based phase 1 Apr 26, 2019

fichtner assigned AdSchellevis Apr 26, 2019

fichtner added bug Production bug and removed support Community support labels Apr 26, 2019

fichtner added this to the 19.7 milestone Apr 26, 2019

AdSchellevis added support Community support and removed bug Production bug labels Apr 27, 2019

AdSchellevis removed their assignment Apr 27, 2019

fichtner removed this from the 19.7 milestone Apr 29, 2019

jroehler23 closed this as completed Jun 18, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ipsec: reqid left/right mismatch in route-based phase 1 #3443

ipsec: reqid left/right mismatch in route-based phase 1 #3443

jroehler23 commented Apr 26, 2019 •

edited

Loading

fichtner commented Apr 26, 2019

jroehler23 commented Apr 26, 2019

fichtner commented Apr 26, 2019

jroehler23 commented Apr 26, 2019 •

edited

Loading

fichtner commented Apr 26, 2019

AdSchellevis commented Apr 27, 2019

vitense commented May 29, 2019

AdSchellevis commented May 29, 2019

vitense commented May 29, 2019

vitense commented May 29, 2019

AdSchellevis commented May 29, 2019

vitense commented May 29, 2019

AdSchellevis commented May 29, 2019

vitense commented May 29, 2019

mimugmail commented May 29, 2019

AdSchellevis commented May 29, 2019

vitense commented Jun 3, 2019

AdSchellevis commented Jun 3, 2019

vitense commented Jun 3, 2019

AdSchellevis commented Jun 3, 2019

vitense commented Jun 3, 2019

AdSchellevis commented Jun 3, 2019

vitense commented Jun 3, 2019

AdSchellevis commented Jun 3, 2019

vitense commented Jun 3, 2019

vitense commented Jun 4, 2019

AdSchellevis commented Jun 4, 2019

vitense commented Jun 4, 2019

AdSchellevis commented Jun 4, 2019

vitense commented Jun 4, 2019

jroehler23 commented Jun 18, 2019

mimugmail commented Jul 15, 2019 •

edited

Loading

ipsec: reqid left/right mismatch in route-based phase 1 #3443

ipsec: reqid left/right mismatch in route-based phase 1 #3443

Comments

jroehler23 commented Apr 26, 2019 • edited Loading

fichtner commented Apr 26, 2019

jroehler23 commented Apr 26, 2019

fichtner commented Apr 26, 2019

jroehler23 commented Apr 26, 2019 • edited Loading

fichtner commented Apr 26, 2019

AdSchellevis commented Apr 27, 2019

vitense commented May 29, 2019

AdSchellevis commented May 29, 2019

vitense commented May 29, 2019

vitense commented May 29, 2019

AdSchellevis commented May 29, 2019

vitense commented May 29, 2019

AdSchellevis commented May 29, 2019

vitense commented May 29, 2019

mimugmail commented May 29, 2019

AdSchellevis commented May 29, 2019

vitense commented Jun 3, 2019

This file is automatically generated. Do not edit

include ipsec.opnsense.d/*.conf

This file is automatically generated. Do not edit

include ipsec.opnsense.d/*.conf

AdSchellevis commented Jun 3, 2019

vitense commented Jun 3, 2019

AdSchellevis commented Jun 3, 2019

vitense commented Jun 3, 2019

AdSchellevis commented Jun 3, 2019

vitense commented Jun 3, 2019

AdSchellevis commented Jun 3, 2019

vitense commented Jun 3, 2019

vitense commented Jun 4, 2019

AdSchellevis commented Jun 4, 2019

vitense commented Jun 4, 2019

AdSchellevis commented Jun 4, 2019

vitense commented Jun 4, 2019

jroehler23 commented Jun 18, 2019

mimugmail commented Jul 15, 2019 • edited Loading

jroehler23 commented Apr 26, 2019 •

edited

Loading

jroehler23 commented Apr 26, 2019 •

edited

Loading

mimugmail commented Jul 15, 2019 •

edited

Loading