Hello everyone,
I am out of ideas regarding this issue.
Router01 has 2 internet connections and Router02 only has one.
ipsec0 is working fine via router01’s main internet connection(eth2)
ipsec1 will not connect properly (the idea is to have the second tunnel formed on the second internet connection eth3)
I know that in v6 services are not vrf aware(including ipsec) but even with mangle rules or route rule it does not work
Torch on Router01 eth3 will sometimes show me Tx with ip from eth2
If on a router I use the same pre shared key in the identity of both peers(ipsec0 and ipsec1) phase I connects(even without vrf rules)
But on phase II of ipsec, policies will be invalid for the second peer(ipsec1)
I guess it is a peer identity issue before a vrf one. I even tried setting “My ID Type” and/or “Remote ID Type” but to no success (invalid credentials or unknown peer errors)
I did not understand the actual goal clearly. You mention one policy to be active and another one to be invalid, but neither of the configurations contains any actual policy. Maybe they were in another part of the export than the rest of the IPsec configuration?
So I can only assume you want a policy (or several ones) that links together the LAN subnets of the two routers. If so: you cannot use multiple policies with identical traffic selectors and different peers, but you can use a single policy and hook it to two peers (in another words, the peer parameter of a policy supports a list of at most two peers).
Normally you’d use this “dual-homed” policy on the “client” side, whereas the two “servers” would be actually two distinct devices, but it may work in your setup with two WANs of a single “server” too.
In the “usual” setup, the “client” establishes and maintains a Phase 1 SA with both peers, and only establishes Phase 2 to one of them at a time; in order that it worked in such “usual” case, the policy at the “server” side must be generated from a template, as the “server” where the policy is not active must be able to route packets for the “client” to the other “server”. A statically configured policy would prevent this from happening, as a statically configured policy intercepts matching packet even if no active SA is available for it, and it does so by design.
In your special scenario where the “server” is a single device, it may be possible to set up a “dual homed” policy at the “server” side as well, but I’ve never tried that so far. And I’ve got no idea whether the software is ready to deal with the situation when each device chooses another one of the twwo Phase 1 SAs to negotiate the Phase 2 SA. So configuring the dual-homed policy manually on one of the devices and let the other one generate it dynamically from template may be necessary.
In order to distinguish the two “client” connections from one another at “server” side, it is enough that you link each peer at the “server” side to another address. You can manually configure a matching local-id at one peer and remote-id on the other one but it should not be necessary, as the peer is taken into account when matching records in the identity list. So two identity rows that only differ in the peer field are not shadowing each other.
Additonal tricks have to be used if e.g. only router02 can be configured as a responder (i.e. if one or both WANs of router01 are behind a NAT without a port-forwarding possibility).
In my use case:
Router 01 has both connections under nat with no possibility to port forward
Router 02 has direct connection (no nat)
The goal is to have 2 tunnels up one for each of Router01’s WANs
In the config I do not have phase II configured because I cannot get a valid phase I active for the second connection.
Also the config is from 2 chr instances to rule out any other possible influences from the real networks(firewall, nat, vrf etc)
So with these 2 configs only 1 ipsec tunnel reaches phase I.
I suspect the issue is at Router01 as both peers try to connect to the same destination and the identity is not properly managed(that is maybe causing pachet on WAN2 with WAN1 ip as src)
Setting local id and remote id on the peer will not connect for me on the test instances(invalid password or unknown peer even with only one peer setup that connects with auto,auto)
Either this functionality was not intended or is bugged.
With a single responder peer at Router02, you can treat Router01 as two distinct active peers, but the dual-homed policy needs to be linked to two separate peers. So configure both peers on Router01 as initiators, link the dual-homed policy to them, and let Router02 generate the policy from a template upon request from Router01.
Since Router02 is a responder with a single peer, and the public IP addresses from behind which Router01 communicates via the WANs are unknown in advance, you have to configure local-id at Router01 and remote-id at Router02 manually. Also, the peer at Router01 has to be configured with send-initial-contact=no.
To be sure that each peer at Router01 uses the proper WAN, it should be enough to set the local-address of each of them to another own IP address of that router, and use routing rules matching on src-address and dst-address (without mangle) to choose a routing table.
Thank you sindy, your feedback pointed me in the right direction.
Setting just “My ID Type” on the initiator(Router01) and just “Remote ID Type” on the responder(Router02) got me past phase I for both peers.
Quick policy got phase II running instantly.
I find it strange and counter intuitive that for example
With one peer on Router01 and one peer on Router02
setting both “My ID Type” and “Remote ID Type” on identity will result in the following errors:
22:48:44 ipsec,error identity not found for peer: KEYID: router01
22:48:44 ipsec,info killing ike2 SA: 192.168.200.254[4500]-192.168.100.254[4500] spi:e2f4055a12c3731b:7d77377fed6d580b
22:48:45 ipsec,info new ike2 SA (I): 192.168.200.254[4500]-192.168.100.254[4500] spi:8f6ff40274b6b5bd:c72e8174564f0246
22:48:45 ipsec,error got fatal error: AUTHENTICATION_FAILED
22:48:45 ipsec,info killing ike2 SA: 192.168.200.254[4500]-192.168.100.254[4500] spi:8f6ff40274b6b5bd:c72e8174564f0246
