Re: [strongSwan] had to manually up a connection
I can't remember what was the option but I know I used it to avoid multiple updown running in parallel for the same peer. Try changing make_before_break to avoid overlapping child_sa, or adjust the time of idle child_sa to expire faster. On Mon, Mar 9, 2020 at 11:43 PM Victor Sudakov wrote: > Victor Sudakov wrote: > > Felipe Polanco wrote: > > > > Does this not cause excessive SAs piling up? I've seen a similar > > > > problem with Strongswan on my side and a MikroTik on the remote side: > > > > too many excessive SAs in "ipsec status" output and in MikroTik's > > > > management console. > > > > > > > > My theory was that each trapped packet causes a new SA to be > > > > attempted/generated until some limit is hit or some resource is > > > > exhausted. > > > Haven't seen that issue. > > > > > > But you should use reuse_ike SA and reuse_child SA, that avoids > duplicates > > > SA for phase one and phase two. > > > > > > > What's their equivalent in the old (ipsec.conf) syntax? I could not find > > them in ipsec.conf(5) > > There is charon.reuse_ikesa (default already "yes") in > strongswan.conf(5) but no "reuse_child" even there. > > -- > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > 2:5005/49@fidonet http://vas.tomsk.ru/ >
Re: [strongSwan] had to manually up a connection
Victor Sudakov wrote: > Felipe Polanco wrote: > > > Does this not cause excessive SAs piling up? I've seen a similar > > > problem with Strongswan on my side and a MikroTik on the remote side: > > > too many excessive SAs in "ipsec status" output and in MikroTik's > > > management console. > > > > > > My theory was that each trapped packet causes a new SA to be > > > attempted/generated until some limit is hit or some resource is > > > exhausted. > > Haven't seen that issue. > > > > But you should use reuse_ike SA and reuse_child SA, that avoids duplicates > > SA for phase one and phase two. > > > > What's their equivalent in the old (ipsec.conf) syntax? I could not find > them in ipsec.conf(5) There is charon.reuse_ikesa (default already "yes") in strongswan.conf(5) but no "reuse_child" even there. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
Re: [strongSwan] had to manually up a connection
Haven't seen that issue. But you should use reuse_ike SA and reuse_child SA, that avoids duplicates SA for phase one and phase two. On Mon, Mar 9, 2020, 10:49 PM Victor Sudakov wrote: > Felipe Polanco wrote: > > I always use auto=route or start_action=trap and just keep a ping > > running in the background for critical UDP traffic. > > > > I know it's a poor's man solution but guarantees the connection is always > > up. > > Does this not cause excessive SAs piling up? I've seen a similar > problem with Strongswan on my side and a MikroTik on the remote side: > too many excessive SAs in "ipsec status" output and in MikroTik's > management console. > > My theory was that each trapped packet causes a new SA to be > attempted/generated until some limit is hit or some resource is > exhausted. > > > -- > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > 2:5005/49@fidonet http://vas.tomsk.ru/ >
Re: [strongSwan] had to manually up a connection
Felipe Polanco wrote: > I always use auto=route or start_action=trap and just keep a ping > running in the background for critical UDP traffic. > > I know it's a poor's man solution but guarantees the connection is always > up. Does this not cause excessive SAs piling up? I've seen a similar problem with Strongswan on my side and a MikroTik on the remote side: too many excessive SAs in "ipsec status" output and in MikroTik's management console. My theory was that each trapped packet causes a new SA to be attempted/generated until some limit is hit or some resource is exhausted. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: [strongSwan] had to manually up a connection
I always use auto=route or start_action=trap and just keep a ping running in the background for critical UDP traffic. I know it's a poor's man solution but guarantees the connection is always up. On Mon, Mar 9, 2020 at 10:59 AM Victor Sudakov wrote: > Victor Sudakov wrote: > > Tobias Brunner wrote: > > > > > > > I see that the first packet in matching > > > > traffic is always lost: in a ping session, packet with seq=1 never > makes > > > > it to the other side, only from seq=2 onwards. > > > > > > > > Why does this happen? > > > > > > It's a known property of the Linux kernel. Packets, in particular the > > > triggering one, are not cached and lost until the IPsec SAs are > established. > > > > > > > and is there a way to avoid it? > > > > > > Not that I'm aware. > > > > Maybe using "auto=start" would be better in this scenario? When the > > host wants to send an SNMP trap, the IPSec connection will have already > > been established. No need for triggering. > > I'm almost ready to take my words back. > > I've experimented in my lab and it turned out that if you configure your > Strongswan connections for anything other than "auto=route", you risk > for some packets to be sent unencrypted until the SA is established. > > If you value the data in your SNMP datagrams (e.g. the community > string), you may expose it. > > Proof: http://admin.sibptus.ru/~vas/1.txt > > traffic is sent unencrypted until 21:28:40.577854 when > Strongswan@192.168.246.10 is finally up. > > At 21:28:58.538009 the host 192.168.246.10 is shut down and traffic from > 192.168.246.1 is again being sent unencrypted. > > -- > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > 2:5005/49@fidonet http://vas.tomsk.ru/ >
Re: [strongSwan] had to manually up a connection
Victor Sudakov wrote: > Tobias Brunner wrote: > > > > > I see that the first packet in matching > > > traffic is always lost: in a ping session, packet with seq=1 never makes > > > it to the other side, only from seq=2 onwards. > > > > > > Why does this happen? > > > > It's a known property of the Linux kernel. Packets, in particular the > > triggering one, are not cached and lost until the IPsec SAs are established. > > > > > and is there a way to avoid it? > > > > Not that I'm aware. > > Maybe using "auto=start" would be better in this scenario? When the > host wants to send an SNMP trap, the IPSec connection will have already > been established. No need for triggering. I'm almost ready to take my words back. I've experimented in my lab and it turned out that if you configure your Strongswan connections for anything other than "auto=route", you risk for some packets to be sent unencrypted until the SA is established. If you value the data in your SNMP datagrams (e.g. the community string), you may expose it. Proof: http://admin.sibptus.ru/~vas/1.txt traffic is sent unencrypted until 21:28:40.577854 when Strongswan@192.168.246.10 is finally up. At 21:28:58.538009 the host 192.168.246.10 is shut down and traffic from 192.168.246.1 is again being sent unencrypted. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
Re: [strongSwan] had to manually up a connection
Tobias Brunner wrote: > > > I see that the first packet in matching > > traffic is always lost: in a ping session, packet with seq=1 never makes > > it to the other side, only from seq=2 onwards. > > > > Why does this happen? > > It's a known property of the Linux kernel. Packets, in particular the > triggering one, are not cached and lost until the IPsec SAs are established. > > > and is there a way to avoid it? > > Not that I'm aware. Maybe using "auto=start" would be better in this scenario? When the host wants to send an SNMP trap, the IPSec connection will have already been established. No need for triggering. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
Re: [strongSwan] had to manually up a connection
On 06.03.20 15:58, Tobias Brunner wrote: > Hi Felipe, > >> I see that the first packet in matching >> traffic is always lost: in a ping session, packet with seq=1 never makes >> it to the other side, only from seq=2 onwards. >> >> Why does this happen? > It's a known property of the Linux kernel. Packets, in particular the > triggering one, are not cached and lost until the IPsec SAs are established. > >> and is there a way to avoid it? > Not that I'm aware. > >> I'm thinking about >> SNMP traps over IPSec that are not retransmitted since they use UDP. > Neither UDP, IP, nor IPsec guarantee delivery of any sent packets, you > always have to reckon with packet loss. > > Regards, > Tobias Use SNMPv3 informs. The SNMP manager sends a confirmation having received it. Mit freundlichen Grüßen, -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein signature.asc Description: OpenPGP digital signature
Re: [strongSwan] had to manually up a connection
Hi Felipe, > I see that the first packet in matching > traffic is always lost: in a ping session, packet with seq=1 never makes > it to the other side, only from seq=2 onwards. > > Why does this happen? It's a known property of the Linux kernel. Packets, in particular the triggering one, are not cached and lost until the IPsec SAs are established. > and is there a way to avoid it? Not that I'm aware. > I'm thinking about > SNMP traps over IPSec that are not retransmitted since they use UDP. Neither UDP, IP, nor IPsec guarantee delivery of any sent packets, you always have to reckon with packet loss. Regards, Tobias
Re: [strongSwan] had to manually up a connection
Hi, I have a related question with that. with auto=route and action=trap I see that the first packet in matching traffic is always lost: in a ping session, packet with seq=1 never makes it to the other side, only from seq=2 onwards. Why does this happen? and is there a way to avoid it? I'm thinking about SNMP traps over IPSec that are not retransmitted since they use UDP. Thanks, On Fri, Mar 6, 2020 at 6:47 AM Tobias Brunner wrote: > Hi Victor, > > > That could be the case, thanks for the hint. Strongswan could have made 3 > > attempts after detecing a dead peer and given up, is that what you > > imply? > > Yes. > > > What's the timeout between keyingtries? > > No timeout between them, regular retransmission timeouts apply for each > attempt. > > > And why is > > `keyingtries=%forever` not the default? > > Who knows, legacy reasons maybe (on the other hand, the default is 1 now > with swanctl.conf). > > > Is there no need for `keyingtries=%forever` in the `auto=route` mode? > > Further traffic will trigger another acquire (it might even cause > duplicate SAs if a retry occurs while traffic triggers another acquire > from the kernel). > > Regards, > Tobias >
Re: [strongSwan] had to manually up a connection
Tobias Brunner wrote: > > > That could be the case, thanks for the hint. Strongswan could have made 3 > > attempts after detecing a dead peer and given up, is that what you > > imply? > > Yes. > > > What's the timeout between keyingtries? > > No timeout between them, regular retransmission timeouts apply for each > attempt. > > > And why is > > `keyingtries=%forever` not the default? > > Who knows, legacy reasons maybe (on the other hand, the default is 1 now > with swanctl.conf). > > > Is there no need for `keyingtries=%forever` in the `auto=route` mode? > > Further traffic will trigger another acquire (it might even cause > duplicate SAs if a retry occurs while traffic triggers another acquire > from the kernel). Thank you very much Tobias, I've learned a lot from this conversation. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
Re: [strongSwan] had to manually up a connection
Hi Victor, > That could be the case, thanks for the hint. Strongswan could have made 3 > attempts after detecing a dead peer and given up, is that what you > imply? Yes. > What's the timeout between keyingtries? No timeout between them, regular retransmission timeouts apply for each attempt. > And why is > `keyingtries=%forever` not the default? Who knows, legacy reasons maybe (on the other hand, the default is 1 now with swanctl.conf). > Is there no need for `keyingtries=%forever` in the `auto=route` mode? Further traffic will trigger another acquire (it might even cause duplicate SAs if a retry occurs while traffic triggers another acquire from the kernel). Regards, Tobias
Re: [strongSwan] had to manually up a connection
Tobias Brunner wrote: > > > I'd like to understand why. > > Then read the log. What's definitely missing from your config is > `keyingtries=%forever`. That could be the case, thanks for the hint. Strongswan could have made 3 attempts after detecing a dead peer and given up, is that what you imply? What's the timeout between keyingtries? And why is `keyingtries=%forever` not the default? > And there could have been a fatal error, after > which no further attempts will be made at all. Also, using `auto=route` > (with `dpdaction=clear`) would also recreate the SA if matching traffic > occurs. Is there no need for `keyingtries=%forever` in the `auto=route` mode? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
Re: [strongSwan] had to manually up a connection
Hi Victor, > I'd like to understand why. Then read the log. What's definitely missing from your config is `keyingtries=%forever`. And there could have been a fatal error, after which no further attempts will be made at all. Also, using `auto=route` (with `dpdaction=clear`) would also recreate the SA if matching traffic occurs. Regards, Tobias
Re: [strongSwan] had to manually up a connection
Alex K wrote: > > > > > According to ipsec.conf(5) "auto=start loads a connection and brings it > > up immediately." What is the expected behavior of auto=start on > > connection *loss* (e.g. peer death is detected by DPD)? > > > My understanding is that dpdaction=restart should automatically restart the > connection upon dead peer detection and restore it back again when the peer > becomes available. Mine too, but this apparently did not happen in my case. I'd like to understand why. My config once again: conn home auto=start authby=secret dpddelay=10s dpdaction=restart esp=aes256-sha1-modp2048 ike=aes256-sha1-modp2048 ikelifetime=1h lifetime=10m keyexchange=ikev2 type=transport left=10.10.10.5 right=y.y.y.y leftprotoport=47 rightprotoport=47 -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: [strongSwan] had to manually up a connection
On Fri, Mar 6, 2020, 04:45 Victor Sudakov wrote: > Hello Noel, > > According to ipsec.conf(5) "auto=start loads a connection and brings it > up immediately." What is the expected behavior of auto=start on > connection *loss* (e.g. peer death is detected by DPD)? > My understanding is that dpdaction=restart should automatically restart the connection upon dead peer detection and restore it back again when the peer becomes available. > > I want Strongswan to reestablish this connection immediately after the > right side becomes alive again, not when there are packets for it. > > > Noel Kuntze wrote: > > Hello Victor, > > > > You configured it to start, not to try to reinitiate. Use auto=route > > for the latter. It will try to reestablish when there's packets for it > > then though, not immediately. > > > > > Kind regards > > > > Noel > > > > Am 05.03.20 um 12:03 schrieb Victor Sudakov: > > > Dear Colleagues, > > > > > > There was a power outage, the Mikrotik router at home was powered off > > > for several hours. Then it was powered on again but there was no IPSec > > > SA from work (Strongswan) to home (Mikrotik). > > > > > > I had to run "ipsec up home" at work to make things work again. Why did > > > the SA not start automatically when the Mikrotik became available > again? > > > > > > This is the relevant Strongswan config (yes the Strongswan at work is > > > behind NAT). > > > > > > conn home > > > auto=start > > > authby=secret > > > dpddelay=10s > > > dpdaction=restart > > > esp=aes256-sha1-modp2048 > > > ike=aes256-sha1-modp2048 > > > ikelifetime=1h > > > lifetime=10m > > > keyexchange=ikev2 > > > type=transport > > > left=10.10.10.5 > > > right=y.y.y.y > > > leftprotoport=47 > > > rightprotoport=47 > > > > > > > > > > > > > > > > > > > -- > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > 2:5005/49@fidonet http://vas.tomsk.ru/ >
Re: [strongSwan] had to manually up a connection
Hello Noel, According to ipsec.conf(5) "auto=start loads a connection and brings it up immediately." What is the expected behavior of auto=start on connection *loss* (e.g. peer death is detected by DPD)? I want Strongswan to reestablish this connection immediately after the right side becomes alive again, not when there are packets for it. Noel Kuntze wrote: > Hello Victor, > > You configured it to start, not to try to reinitiate. Use auto=route > for the latter. It will try to reestablish when there's packets for it > then though, not immediately. > > Kind regards > > Noel > > Am 05.03.20 um 12:03 schrieb Victor Sudakov: > > Dear Colleagues, > > > > There was a power outage, the Mikrotik router at home was powered off > > for several hours. Then it was powered on again but there was no IPSec > > SA from work (Strongswan) to home (Mikrotik). > > > > I had to run "ipsec up home" at work to make things work again. Why did > > the SA not start automatically when the Mikrotik became available again? > > > > This is the relevant Strongswan config (yes the Strongswan at work is > > behind NAT). > > > > conn home > > auto=start > > authby=secret > > dpddelay=10s > > dpdaction=restart > > esp=aes256-sha1-modp2048 > > ike=aes256-sha1-modp2048 > > ikelifetime=1h > > lifetime=10m > > keyexchange=ikev2 > > type=transport > > left=10.10.10.5 > > right=y.y.y.y > > leftprotoport=47 > > rightprotoport=47 > > > > > > > > > -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: [strongSwan] had to manually up a connection
Hello Victor, You configured it to start, not to try to reinitiate. Use auto=route for the latter. It will try to reestablish when there's packets for it then though, not immediately. Kind regards Noel Am 05.03.20 um 12:03 schrieb Victor Sudakov: > Dear Colleagues, > > There was a power outage, the Mikrotik router at home was powered off > for several hours. Then it was powered on again but there was no IPSec > SA from work (Strongswan) to home (Mikrotik). > > I had to run "ipsec up home" at work to make things work again. Why did > the SA not start automatically when the Mikrotik became available again? > > This is the relevant Strongswan config (yes the Strongswan at work is > behind NAT). > > conn home > auto=start > authby=secret > dpddelay=10s > dpdaction=restart > esp=aes256-sha1-modp2048 > ike=aes256-sha1-modp2048 > ikelifetime=1h > lifetime=10m > keyexchange=ikev2 > type=transport > left=10.10.10.5 > right=y.y.y.y > leftprotoport=47 > rightprotoport=47 > > > > signature.asc Description: OpenPGP digital signature
