Hi Andrew,

I couldn’t find the bug in git, do you want me to create one? 


Here it is the log: 

Oct 18 09:52:07.299981: "tunnel8"[2] 6.149.27.119 #3: the peer proposed: 
192.168.20.0/24===192.168.20.100/32
Oct 18 09:52:07.299984: | find_v1_client_connection starting with tunnel8
Oct 18 09:52:07.299989: |   looking for 192.168.20.0/24===192.168.20.100/32
Oct 18 09:52:07.299994: |   concrete checking against sr#0 0.0.0.0/0 -> 
192.168.20.100/32
Oct 18 09:52:07.300001: | 
FOR_EACH_CONNECTION[local=82.100.127.28,remote=6.149.27.119].... in (fc_try() 
+2025 programs/pluto/ikev1_quick.c)
Oct 18 09:52:07.300005: |   found "tunnel8"[2] 6.149.27.119
Oct 18 09:52:07.300010: |   fc_try: looking at 0.0.0.0/0===192.168.20.100/32
Oct 18 09:52:07.300015: | match_id a=192.168.1.60
Oct 18 09:52:07.300019: |          b=192.168.1.60
Oct 18 09:52:07.300022: | results  matched wildcards=0
Oct 18 09:52:07.300025: | virt: is_virtual_spd_end() no spd=no config=no
Oct 18 09:52:07.300030: | virt: is_virtual_remote() no local/remote spd no/no; 
config no/no
Oct 18 09:52:07.300035: |   fc_try trying tunnel8:192.168.20.0/24:0/0 -> 
192.168.20.100/32:0/0 vs tunnel8:0.0.0.0/0:0/0 -> 192.168.20.100/32:0/0
Oct 18 09:52:07.300039: |    our client (0.0.0.0/0) not in local_net 
(192.168.20.0/24)
Oct 18 09:52:07.300042: |   matches: 1
Oct 18 09:52:07.300044: |   fc_try concluding with none [0]
Oct 18 09:52:07.300048: |   fc_try tunnel8 gives none
Oct 18 09:52:07.300051: | 
FOR_EACH_CONNECTION[local=82.100.127.28,remote=<unset-address>].... in 
(find_v1_client_connection() +2303 programs/pluto/ikev1_quick.c)
Oct 18 09:52:07.300055: |   found "tunnel8"
Oct 18 09:52:07.300058: |   checking hostpair 0.0.0.0/0 -> 192.168.20.100/32
Oct 18 09:52:07.300066: | 
FOR_EACH_CONNECTION[local=82.100.127.28,remote=<unset-address>].... in 
(fc_try() +2025 programs/pluto/ikev1_quick.c)
Oct 18 09:52:07.300070: |   found "tunnel8"
Oct 18 09:52:07.300074: |   fc_try: looking at 0.0.0.0/0===0.0.0.0/0
Oct 18 09:52:07.300078: | match_id a=192.168.1.60
Oct 18 09:52:07.300080: |          b=(none)
Oct 18 09:52:07.300084: | results  matched wildcards=15
Oct 18 09:52:07.300087: | virt: is_virtual_spd_end() no spd=no config=no
Oct 18 09:52:07.300091: | virt: is_virtual_remote() no local/remote spd no/no; 
config no/no
Oct 18 09:52:07.300095: |   fc_try trying tunnel8:192.168.20.0/24:0/0 -> 
192.168.20.100/32:0/0 vs tunnel8:0.0.0.0/0:0/0 -> 0.0.0.0/0:0/0
Oct 18 09:52:07.300100: |    our client (0.0.0.0/0) not in local_net 
(192.168.20.0/24)
Oct 18 09:52:07.300103: |   found "tunnel2"
Oct 18 09:52:07.300105: |   fc_try: looking at <unset-selectors>
Oct 18 09:52:07.300108: |   found "tunnel2-nat"
Oct 18 09:52:07.300111: |   fc_try: looking at <unset-selectors>
Oct 18 09:52:07.300114: |   matches: 3
Oct 18 09:52:07.300116: |   fc_try concluding with none [0]
Oct 18 09:52:07.300119: |   concluding with d = none
Oct 18 09:52:07.300122: | virt: is_virtual_remote() no local/remote spd no/no; 
config no/no
Oct 18 09:52:07.300127: | virt: is_virtual_spd_end() no spd=no config=no
Oct 18 09:52:07.300134: | virt: is_virtual_spd_end() no spd=no config=no
Oct 18 09:52:07.300137: "tunnel8"[2] 6.149.27.119 #3: cannot respond to IPsec 
SA request because no connection is known for 
192.168.20.0/24===82.100.127.28[@xauth.mad,MS+XS+S=C]...6.149.27.119[192.168.1.60,+MC+XC+S=C]===192.168.20.100/32
Oct 18 09:52:07.300140: | complete v1 state transition with 
INVALID_ID_INFORMATION





—
Saludos / Regards / Cumprimentos
António Silva

> On 17 Oct 2024, at 19:10, Andrew Cagney <[email protected]> wrote:
> 
> António,
> 
> On Thu, 17 Oct 2024 at 11:29, antonio <[email protected]> wrote:
>> 
>> Hi Andrew,
>> 
>> Thanks for the detail info.
>> 
>> If it helps to reproduce and close the issue, my adicional setup is:
>> 
>> Debian: 11.11
>> Linux kernel:
>> 5.10.226
>> 
>> User in /etc/ipsec.d/passwd:
>> asilvapt@mad:$6$W27QzNXfRvCY$F.ea5ytgP/sdsdsds::192.168.20.2
> 
> Could you run the interop with plutodebug=all and then extract logs
> between (and including):
> 
>  the peer proposed: 192.168.20.0/24===192.168.20.2/32
>  cannot respond to IPsec SA request because no connection is known
> for 
> 192.168.20.0/24===82.100.127.28[@xauth.mad,MS+XS+S=C]...6.149.27.119[192.168.1.60,+MC+XC+S=C]===192.168.20.2/32
> 
> and put that in the bug.
> 
>> If you need more info, please let me know.
>> 
>> 
>> —
>> Saludos / Regards / Cumprimentos
>> António Silva
>> 
>> On 17 Oct 2024, at 16:09, Andrew Cagney <[email protected]> wrote:
>> 
>> 5.1 fixed this bug:
>> - fix Quick mode installing 0.0.0.0/0 when no MSG_CONFIG exchange
>> [Andrew, Tuomo]
>> It was exposed in 5.0 (kernel policy was set to 0.0.0.0/0) but 4.x was
>> also broken (it installed the peer's host address).
>> 
>> I suspect this is a similar problem.
>> 
>> 
>> left=82.100.127.28
>> right=%any
>> leftsubnet=0.0.0.0/0
>> rightaddresspool=192.168.20.100-192.168.20.254
>> 
>> 
>> Here's the start of quick mode.
>> 
>> Oct 17 10:16:02 sol1 pluto[882496]: "tunnel8"[4] 6.149.27.119 #5: the peer 
>> proposed: 192.168.20.0/24===192.168.20.2/32
>> Oct 17 10:16:02 sol1 pluto[882496]: |   checking hostpair 0.0.0.0/0 -> 
>> 192.168.20.2/32
>> 
>> 
>> It's looking for a host-pair matching 0.0.0.0/0 -> 192.168.20.2/32.
>> That's wrong -  192.168.20.2/32 is not the peer's host address.  Yet,
>> somehow, it stumbled on:
>> 
>> Oct 17 10:16:02 sol1 pluto[882496]: "tunnel8"[4] 6.149.27.119 #6: responding 
>> to Quick Mode proposal {msgid:ba263d12}
>> Oct 17 10:16:02 sol1 pluto[882496]: "tunnel8"[4] 6.149.27.119 #6:     us: 
>> 0.0.0.0/0===82.100.127.28[@xauth.mad,MS+XS+S=C]  them: 
>> 6.149.27.119[192.168.1.60,+MC+XC+S=C]===192.168.20.2/32
>> 
>> 
>> However, in 5.1:
>> 
>> Oct 17 10:15:01 sol1 pluto[855951]: "tunnel8"[6] 6.149.27.119 #5: the peer 
>> proposed: 192.168.20.0/24===192.168.20.2/32
>> Oct 17 10:15:01 sol1 pluto[855951]: |   checking hostpair 0.0.0.0/0 -> 
>> 192.168.20.2/32
>> Oct 17 10:15:01 sol1 pluto[855951]: "tunnel8"[6] 6.149.27.119 #5: cannot 
>> respond to IPsec SA request because no connection is known for 
>> 192.168.20.0/24===82.100.127.28[@xauth.mad,MS+XS+S=C]...6.149.27.119[192.168.1.60,+MC+XC+S=C]===192.168.20.2/32
>> 
>> 
>> that failed.
>> 
>> I'd file a bug.
>> 
>> 

_______________________________________________
Swan mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to