Hi there,
Following https://docs.opnsense.org/manual/how-tos/ipsec-s2s.html (https://docs.opnsense.org/manual/how-tos/ipsec-s2s.html) as reference.
Setup is fairly barebones - in a lab.
OPNsense FWs - cloned* - no VLANS, one linux VM in each Lan pinging each other, allow any out rules on Lan and IPSec.
* - this is an old VM deployed years ago, fully up to date on 23.1 - kept as a reference. IPSec was never used on it previously and no NAT changes ever happened on it.
The LANs are in the form of 192.168.AAA.0/24 and 192.168.BBB.0/24 - so nothing unusual there either.
WAN interfaces are on the same vlan, all the IPSec rules mentioned in the documentation are present and there's only one additional rule to manage the FWs through the WAN.
I exported the FW configs and did a side-by -side in WinMerge and everything looks as expected.
The tunnel is not coming up for some reason, and I don't see anything helpful in the Live Logs or the IPSec ones, however as soon as I disable pf it all comes to life, phase 2 appears in IPSec Status Overview and ping works - both with Mutual PSK and Mutual PKI.
It took me a few tries redoing the IPSec config on both ends - thinking I might have chosen dhgroups that may not be fully supported/working - until I did a config with the absolute defaults mentioned in the doc, and when that still failed I disabled pf as the last thing standing that I could think of.
Seeing how everything is completely open, the Winmerge side-by-side diff is clean with the IPSec things mirrored as expected and it all works with pf stopped - I figured I'd ask here first should there be something obscure I'm missing, otherwise this may be a bug after all ?
Thanks,
N
Attached a screenshot off the MutualPKI setup - working fine as soon as pf is stopped.
Hi,
If the tunnel works when you turn off the firewall, then this is not a bug but a missing firewall rule.
Regards,
atom
Yeah well that's the thing though, nothing comes up in the live log as blocked traffic, the expected wan rules are in place - and they're automatically created.
Could you share "Firewall: Rules: WAN" ?
Sure, I just added the last entries (mirrored off course) and rebooted the FWs to see if that changes anything and it's still not coming up, and I'm watching live log or anything that may trigger the last rule and nothing comes up.
LAN side only has the default rules.
I don't know why you defined IPsec out rules.
The IPsec In rule limits the WAN access to 192.168.69.35, which is an internal address and not a WAN address. Then you should add a rule for 4500/udp for NAT-T.
These are my rules.
Both WANs are in the same VLAN, one is .16 the other .35 so they can freely communicate with each other, and off course "block private networks" is unchecked on both WANs.
As written, 192.168.69.35 is not a WAN address. Leave the Source field empty for now.
And set Destination to "WAN address" .
I can take the rule out, or leave it empty as you say, it won't make a difference.
Also, to answer your other question, if you look closely on the let hand side of my screenshot you'll see I didn't manually define anything for IPsec - that magic wand shows they've been automatically created - and I don't know why for outbound as well.
Typically, one wants to establish a VPN tunnel between a remote computer and the local computer. The source can therefore never be a local address.
Sure, that would be the end goal, but I stumbled on this weird issue while testing the IPSec config in the lab environment and IPSec seems fine, FW rules as well, and yet it's not working with pf enabled.
Just tried with an allow rule allowing everything from wan net, rebooted the FWs and I'm in the same place.
Meanwhile he IPSec logs don't reveal anything out of the ordinary - simply unable to connect while pf is up.
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 ?
Seems fine to me :)
Where are the answer packets ?
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 \)
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.
Quote from: newsense on February 12, 2023, 08:29:05 PM
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.
Quotetcpdump -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
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 09[IKE] <con1|1> establishing IKE_SA failed, peer not responding
Can you run tcpdump again after new installation ?
Please share your phase 1 entries.
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. :)