Following my other topic I'm now changing the situation to be OPNSense and CHR, not CHR-CHR, but picking out how MT and OPNSense differ in terminology and what parameters must be set where is already proving to be a headache.
Does anyone have any experience/resources/howtos to share for doing IPSec between the two using digital-signature/certificate authentication method? I believe OPNSense call this EAP TLS.
The EAP suite is a whole different can of worms. What you're looking for is RSA. The general difference between the two IPsec implementations is that OPNsense creates a routable VTI. The terminology should be quite similar: local and remote identifiers and associated settings are identites, in connections general settings are phase1 settings (think profiles), local and remote auth correspond to I believe peers, and children are phase2 settings (think proposal and policies)
Thanks! However, RSA is not an authentication method in the available OPN options for its identities. There's PSK, Public Key, EAP TLS, EAP-MSCHAPv2, Xauh PAM, EAP RADIUS. Maybe Public Key then, if the public key is derived from the server and client certs while the private key is known to the OPN firewall since that's where the certs were generated, and the peer because exporting PKCS#12 with passphrase includes the private key, perhaps.
That's the one
That works, I can see installed SAs on both ends. The final bit is to validate IP connectivity. I have done the following:
10.45.45.2 (mimicking the config on the MT with a bridge to emulate loopback, for adding the local IPSec IP the MT uses)10.45.45.0/3010.45.45.2 and remote address 10.45.45.1 (the peer's local IPSec IP) and tunnel local 172.16.4.2, tunnel remote 172.16.4.1 (peer's local GRE IP) on /30netmaskBut pinging the OPN from the MT time's out OPN fw GRE IP times out. I was able to get pings working on the IPSec IP by allowing ICMP on the IPSec interface in firewall rule for OPNsense.
Maybe I don't have the GRE IP's the right way around? Or the GRE remote IP?
(note for others: some weird behaviour I've noticed is when making changes to IPSec connection settings/parameters on OPN, sometimes my peer will totally fail to create the tunnel even if I changes some settings, break it, then revert those changes. You'd think it would go back to how it was. But no. In these cases, restarting the OPN is the only solution for me, simply restarting the strongswan process on the OPN doesn't restore the connection. Odd.)
Solution: make sure phase 1 and phase 2 settings are exactly the same between both peers.
Keep in mind that the OPNsense is an implicitly denying firewall: to allow things, you need explicit rules
Would there be a need to enter manual NAT rules at both ends?
NAT-T, at least to my understanding, is only needed when both sides share the same IP addressing for their LANs. Otherwise, NAT-T isn't needed. So if both peers have different LAN networks that should be reachable from each side, then the responder can add a network tosplit-includeor static routes can be entered manually (on either side). Correct?
Not exactly, NAT-T is the coping mechanism of IPsec for every natted router, regardless if they share same IP addressing or not, because IPsec by default doesn't use ports and that confuses NAT. That's why packets get encapsulated in UDP and port 4500 is used if NAT is detected. I even believe that in IKEv2 it's hardcoded and cannot be influenced
As for NAT rules on both routers, Mikrotik's default masquerade works fine, in OPNsense not so sure how to configure it