Good day to all.
I'm trying to connect several RB4011s from 6.46 to CHR via IPSEC (without tunnels) which is in the DMZ.
Accordingly, the question arises how to configure IPSec modeconf \ NAT for traffic exchange between Internal networks?
IKEv2 Site-to-Site IPSec VPN for Branch Offices.
Last edited by Mrdude on Thu Nov 19, 2020 9:11 pm, edited 1 time in total.
Re: IKEv2 Site-to-Site IPSec VPN for Branch Offices. [SOLVED]
Since there is NAT at least at the CHR end, you cannot avoid tunnel mode of the SAs unless the DMZ (as in "1:1 dst-nat") can handle also ESP forwarding. If there is NAT also at at least some of the 4011 ends as your drawing suggests, I'm afraid there is no way to avoid tunnel mode of the SAs at all, so nat traversal support must be enabled on all the peers.
You only need to use mode-config if you want the CHR to assign addresses to the 4011s dynamically. If you don't, statically configured policies with policy-generate=no at the initiator (4011) ends and matching policy templates with policy-generate=port-strict at the responder (CHR) end are sufficient. Since late 6.45 or early 6.46, you don't need to specify sa-dst-address for the statically configured policy, you just link the policy to an initiator peer and it inherits the sa-dst-address from that peer.
If the above is not a sufficient answer or you want the SAs to work in transport mode (which may or may not be possible), provide more details about the overall setup and ask additional questions.
P.S.: I wonder how many people on this forum know that сервер means server and белый actually means public 🙂
You only need to use mode-config if you want the CHR to assign addresses to the 4011s dynamically. If you don't, statically configured policies with policy-generate=no at the initiator (4011) ends and matching policy templates with policy-generate=port-strict at the responder (CHR) end are sufficient. Since late 6.45 or early 6.46, you don't need to specify sa-dst-address for the statically configured policy, you just link the policy to an initiator peer and it inherits the sa-dst-address from that peer.
If the above is not a sufficient answer or you want the SAs to work in transport mode (which may or may not be possible), provide more details about the overall setup and ask additional questions.
P.S.: I wonder how many people on this forum know that сервер means server and белый actually means public 🙂
Re: IKEv2 Site-to-Site IPSec VPN for Branch Offices.
Since there is NAT at least at the CHR end, you cannot avoid tunnel mode of the SAs unless the DMZ (as in "1:1 dst-nat") can handle also ESP forwarding. If there is NAT also at at least some of the 4011 ends as your drawing suggests, I'm afraid there is no way to avoid tunnel mode of the SAs at all, so nat traversal support must be enabled on all the peers.
You only need to use mode-config if you want the CHR to assign addresses to the 4011s dynamically. If you don't, statically configured policies with policy-generate=no at the initiator (4011) ends and matching policy templates with policy-generate=port-strict at the responder (CHR) end are sufficient. Since late 6.45 or early 6.46, you don't need to specify sa-dst-address for the statically configured policy, you just link the policy to an initiator peer and it inherits the sa-dst-address from that peer.
If the above is not a sufficient answer or you want the SAs to work in transport mode (which may or may not be possible), provide more details about the overall setup and ask additional questions.
P.S.: I wonder how many people on this forum know that сервер means server and белый actually means public 🙂
Thank you very much, this answer is enough.