2.2.5: stalled site-to-site connection due to rekeying (missing SAD entries)
-
Hi,
funny but i have no trouble with strongswan. I have 4 different ipsec tunnels up and running
1x ike v1 (2x pfsense)
1x ike v2 (2x pfsense)
1x ikev1 (pfsense /mikrotik)
1x ikev2 roadwarrier (android strongswan app)Maybe there are a missmatch in Phase 2 (Lifetime?) or the time of the ipsec endpoints are not the same.
With the mikrotik the setup was a little bit strange because of a working&matching setup.regards
max
-
Maybe there are a missmatch in Phase 2 (Lifetime?)
Checked n times, and just once more. They match perfectly.
or the time of the ipsec endpoints are not the same.
Nope, all set to UTC and synced by NTP, to the second.
Thanks
-
Do you have two phase2 entries only on one site ?
ccc.ccc.ccc.ccc/32 <–just a single host
(hope not s subset of bbb.bbb.bbb.bbb/24) -
Do you have two phase2 entries only on one site ?
Nope, the sites mirror each other.
ccc.ccc.ccc.ccc/32 <–just a single host
(hope not s subset of bbb.bbb.bbb.bbb/24)bbb.bbb.bbb.bbb/24 and ccc.ccc.ccc.ccc/32 (yes, a single host) are subnets of the actual site A LAN which is a /9 network. The subnets don't overlap.
Cheers
-
FYI, I found the following automatic outbound NAT mappings at site B:
Interface Source Source Port Destination Destination Port NAT Address NAT Port Static Port Description
WAN 127.0.0.0/8 * * 500 WAN address * YES Auto created rule for ISAKMP - localhost to WAN
WAN 127.0.0.0/8 * * * WAN address * NO Auto created rule - localhost to WAN
WAN yyy.yyy.yyy.yyy/24 * * 500 WAN address * YES Auto created rule for ISAKMP - LAN to WAN
WAN yyy.yyy.yyy.yyy/24 * * * WAN address * NO Auto created rule - LAN to WAN
WAN ###.###.###.###/24 * * 500 WAN address * YES Auto created rule for ISAKMP - OPT1 to WAN
WAN ###.###.###.###/24 * * * WAN address * NO Auto created rule - OPT1 to WAN(OPT1 is used for pfsync and XMLRPC Sync)
Neither do I know how they came about, nor why they appeared only at site B, nor why they would be needed at all - in short, I removed them. After that the tunnel was stable for about 24 hours, without any traffic being sent through it though! When I started to route traffic through it things went south again rather quickly. That tells me that a) those automatic NAT mappings aren't needed and b) they didn't cause the issue either. In fact, the tunnel seems to get unstable when you use it and "works" fine if left alone. Go figure. Anyhow, I also tried to remove the single-host phase 2 child to make things easier but to no avail…
I now moved on (in fact, back) to OpenVPN - for the time being :P
-
You can keep banging your head against the wall for a couple more weeks with the Weakswan thing, or switch to OpenVPN.
You can stop claiming issues fixed multiple releases and several months ago are actually still a problem any time now.
funny but i have no trouble with strongswan. I have 4 different ipsec tunnels up and running
Nor do at least 99.999% of others. strongswan had some issues in some cases in early 2.2.x versions, which is why doktornotor is still griping (though he hasn't used it in months so how would he know with anything current), but nearly all of those were fixed several months ago. At this point it's no more problematic than racoon was, the issues are largely the typical misconfigurations, or connectivity problems, or something else unrelated entirely to the keying daemon.
FYI, I found the following automatic outbound NAT mappings at site B:
If those y.y.y.y or #.#.#.# matched your public IP, you were NATing traffic initiated by the firewall itself, which will cause problems with IPsec.
-
@cmb:
[If those y.y.y.y or #.#.#.# matched your public IP
[/quote]
Of course not. Those are just the LAN and HA-sync networks (see above).But since you chimed in, can you shed some light on where these automatic rules came from at (just) one of the two sites?
-
It was switched to manual outbound NAT mode at some point, and those were the source networks that resided on non-Internet connections at that time.
-
Of course, that wasn't my question. I wanted to know how these specific automatic rules came about in the first place. What creates them and why?
-
Exactly what I said. When you switch to manual outbound NAT, the auto-added rules are added as manual entries.
-
I know how automatic rules turn into manual ones. My question is what created the automatic rules in the first place (IOW, what's their root cause?), in particular since they only appeared at one site, without a difference between the sites that could explain them (to me).