[Solved] IPsec - tunnel down when pf is active

[atom]

It's not necessary to boot the firewall for rule changes.

If you monitor your traffic in "Firewall: Log Files: Live View", can you see that the packets are leaving the WAN interface ?

[newsense]

Seems fine to me :)

[atom]

Where are the answer packets ?

[atom]

Could you run a tcpdump ?

tcpdump -vvni <wan interface> host 192.168.69.16 and host 192.168.69.35 and \( esp or udp port 500 or udp port 4500 \)

[newsense]

They're not - which is what doesn't add up. Something should be logged but it's not showing up, apart from the retries seen in the IPSec log.

[newsense]

They're not - which is what doesn't add up. Something should be logged but it's not showing up, apart from the retries seen in the IPSec log.

tcpdump -vvni em0 host 192.168.69.16 and host 192.168.69.35 and \( esp or udp port 500 or udp port 4500 \)
tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:56:44.680503 IP (tos 0x0, ttl 64, id 4605, offset 0, flags [none], proto UDP (17), length 260)
    192.168.69.35.500 > 192.168.69.16.500: [udp sum ok] isakmp 2.0 msgid 00000000 cookie 4d9f34e2e1639ee3->0000000000000000: parent_sa ikev2_init:
    (sa: len=36
        (p: #1 protoid=isakmp transform=3 len=36
            (t: #1 type=encr id=#20 (type=keylen value=0100))
            (t: #2 type=prf id=#5 )
            (t: #3 type=dh id=#31 )))
    (v2ke: len=32 group=#31)
    (nonce: len=32 nonce=(827287beffc5103b98d9b644710a78b721b76bca083f9f69d2f58f94a78a41a3) )
    (n: prot_id=#0 type=16388(nat_detection_source_ip))
    (n: prot_id=#0 type=16389(nat_detection_destination_ip))
    (n: prot_id=#0 type=16430(status))
    (n: prot_id=#0 type=16431(status))
    (n: prot_id=#0 type=16406(status))
12:56:57.680202 IP (tos 0x0, ttl 64, id 5485, offset 0, flags [none], proto UDP (17), length 260)
    192.168.69.35.500 > 192.168.69.16.500: [udp sum ok] isakmp 2.0 msgid 00000000 cookie 4d9f34e2e1639ee3->0000000000000000: parent_sa ikev2_init:
    (sa: len=36
        (p: #1 protoid=isakmp transform=3 len=36
            (t: #1 type=encr id=#20 (type=keylen value=0100))
            (t: #2 type=prf id=#5 )
            (t: #3 type=dh id=#31 )))
    (v2ke: len=32 group=#31)
    (nonce: len=32 nonce=(827287beffc5103b98d9b644710a78b721b76bca083f9f69d2f58f94a78a41a3) )
    (n: prot_id=#0 type=16388(nat_detection_source_ip))
    (n: prot_id=#0 type=16389(nat_detection_destination_ip))
    (n: prot_id=#0 type=16430(status))
    (n: prot_id=#0 type=16431(status))
    (n: prot_id=#0 type=16406(status))
12:57:10.900754 IP (tos 0x0, ttl 64, id 47283, offset 0, flags [none], proto UDP (17), length 260)
    192.168.69.16.500 > 192.168.69.35.500: [udp sum ok] isakmp 2.0 msgid 00000000 cookie c577bf7c503bbfda->0000000000000000: parent_sa ikev2_init:
    (sa: len=36
        (p: #1 protoid=isakmp transform=3 len=36
            (t: #1 type=encr id=#20 (type=keylen value=0100))
            (t: #2 type=prf id=#5 )
            (t: #3 type=dh id=#31 )))
    (v2ke: len=32 group=#31)
    (nonce: len=32 nonce=(98b6543b90e8c16705c972bd37967c273fe1c561bcf130ca3457fdc89a080509) )
    (n: prot_id=#0 type=16388(nat_detection_source_ip))
    (n: prot_id=#0 type=16389(nat_detection_destination_ip))
    (n: prot_id=#0 type=16430(status))
    (n: prot_id=#0 type=16431(status))
    (n: prot_id=#0 type=16406(status))
^C
3 packets captured
1703 packets received by filter
0 packets dropped by kernel

[newsense]

So I decided to try on a fresh pair of VMs, downloaded 23.1 and installed, did only the minimum config on the lan side and the most basic ipsec config with mutual psk - with the same result.

Interestingly I saw a few NAT-T packets this time, and I added the respective rules - but in the end I still end up with

Code Select Expand

09[IKE] <con1|1> establishing IKE_SA failed, peer not responding

[atom]

Can you run tcpdump again after new installation ?
Please share your phase 1 entries.

[newsense]

Hi atom, thanks again for spending time with me last week on this issue.


Here's a breakdown of what was required  for it to work:

     Disabled reply-to on WAN and in IPSec settings disabled the automatic FW rule creation - which as seen in
     the previous post is incomplete.

     Rules on WAN are source:4500-dest:4500, source:500-dest:500 and the last piece of the puzzle was
     source:*-dest:500 for the Syn flag. Notably, the ESP rule in the documentation doesn't appear to be needed
     either (traffic is labeled "let anything out from firewall host itself")


In the end obviousl there was no bug, just a happy OPNsense user putting theory into practice while not foregetting how TCP/IP works. :)