Community discussions

MikroTik App
 
dot02
Member Candidate
Member Candidate
Topic Author
Posts: 108
Joined: Tue Jun 15, 2021 1:23 am

ikev2 VPN with one router behind CGN CG-NAT

Mon Jun 20, 2022 9:15 pm

Hi guys,

I'm struggeling setting up a VPN (MT to MT) between a main site (public DNS record and static IP) and a remote site (4G) which is behing CGN, and of course it has a dynamic IP in the 10.64.0.0/10 range. The should not be a problen since I have a script that updates the DNS record according to changing IP's.

However, the IPsec tunnel will not come up. Before I start posting the config here, I'd like some confirmation from you guys, just to make sure I didn't do any mistake.

For the distant (CGN) site, could you validate if my assumptions are right?
- under IPsec > Policies, the source IP shall be the real 10.100.x.x IP assigned to my public interface, not the official public IP on the other side of the CGN,
- under IPsec > peers, the local address shall also be the 10.100.x.x address
- under IPsec > identities, what shall I put under my ID / remote ID? I tried several configs, including fqdn on both sides, but without success.

I am always stuck with "no Phase 2" error

thanks for your help!
Cheers
Denis
 
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: ikev2 VPN with one router behind CGN CG-NAT

Tue Jun 21, 2022 11:05 am

No Phase 2 has nothing to do with DNS and CGNAT. As for your assumptions:
  • the local-address of the peer must be one of own ones of the router, or not specified at all (the router will choose one according to the routing table),
  • the src-address of a policy is only relevant for tunnel mode policies; the sa-src-address is inherited from the local address of the peer using which the policy has been currently negotiated. For tunnel mode policies, the src-address may not be necessarily related to any of the own addresses/subnets of the router, it depends on the application scenario
  • the identity settings must match each other, i.e. the remote-id of one peer must match my-id of the other peer. Moreover, the ID value must formally match the type, i.e. if type is fqdn, you cannot use just a random string as a value, it must conform to the requirements of a valid fqdn. Unfortunately, RouterOS allows you to configure a non-compliant string, but throws an error when it receives a non-compliant string from the other peer during the IKE negotiation. But any issue with IDs causes already Phase 1 to fail, so if your problem is only Phase 2, the root cause must be different.
 
dot02
Member Candidate
Member Candidate
Topic Author
Posts: 108
Joined: Tue Jun 15, 2021 1:23 am

Re: ikev2 VPN with one router behind CGN CG-NAT

Tue Jun 21, 2022 4:19 pm

Thanks for the feedback!
the identity settings must match each other, i.e. the remote-id of one peer must match my-id of the other peer
Sure. But can I put a different ID for each side, for instance:
Site A: my ID=fqdn ; remote ID=key_ID
Site B: my ID: key_ID ; remote ID=fqdn

I have valid fqdn's for both sites (site-a.company.com and site-b.company.com), so I don't see why it should not work. I don't need to put a dot "." at the end, right?

According to your comments, in my case, as I use tunnel mode and the 4G router is behing CGN, I guess I must assign the real public IP address to src-address as this is the IP the HQ router will "see" packets coming from.

Cheers
Denis
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: ikev2 VPN with one router behind CGN CG-NAT

Tue Jun 21, 2022 4:56 pm

I don't need to put a dot "." at the end, right?
Right, no need for a trailing dot.

as I use tunnel mode and the 4G router is behing CGN, I guess I must assign the real public IP address to src-address as this is the IP the HQ router will "see" packets coming from.
In tunnel mode, the src-address and dst-address are totally unrelated to the WAN addresses of the peers; sa-src-address and sa-dst-address are but they are set automatically through inheritance from the peer. So if the 4G initiator peer has a LAN subnet 192.168.1.0/24 and you want hosts in that subnet to connect anywhere to 192.168.0.0/16 via the wired responder peer, the tunnel policy at the 4G end will use src-address=192.168.1.0/24 dst-address=192.168.0.0/16; since this includes traffic between the 4G router itself and its LAN hosts, this policy has to be preceded by an src-address=192.168.1.0/24 dst-address=192.168.1.0/24 action=none one.
 
dot02
Member Candidate
Member Candidate
Topic Author
Posts: 108
Joined: Tue Jun 15, 2021 1:23 am

Re: ikev2 VPN with one router behind CGN CG-NAT

Tue Jun 21, 2022 5:43 pm

are you sure about the src-address/dst-address vs. sa-src-address/sa-dst-address? I'm pretty sure it is the other way around: the SA (as the name tells) deals with the security associations, so the addresses in the PRIVATE range. The src/dst-addresses however are used in the IPsec policies to CREATE the SA's, so these need the public addresses.

In my case it's gonna be even simpler since I will run a /30 GRE tunnel over it.

Let's take the real IP's I use.
Main site: 172.20.0.0/16
4G site: 172.18.0.0/16
GRE tunnel: 172.30.2.0/30 (main site: .1 ; 4G site: .2)

I should not need the encrypt=none policy precedence as the whole 172.30.0.0/16 IP range is exclusively reserved for GRE tunnels and there is no overlap with any existing subnets anywhere. So I guess the addresses I need should be:

main site:
src-address=HQ_public_IP
dst-address=4G_public_IP(real one, NOT in the 10.100.0.0/10 CGN range)

4G site:
src-address=?
dst-address=HQ_public_IP


Shall the NAT-Traversal option be set on both sides of the VPN, or only on the 4G side that is behind CGN?
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: ikev2 VPN with one router behind CGN CG-NAT

Tue Jun 21, 2022 8:49 pm

are you sure about the src-address/dst-address vs. sa-src-address/sa-dst-address?
I am. src-address and dst-address are part of the "traffic selector" (along with protocol, src-port, and dst-port), which is used to choose the payload packets to be delivered using the SA; sa-src-address and sa-dst-address are properties of the transport packets. They used to be writable many ROS versions ago, but since 6.45.something they are inherited from the active-peer's parameters.

With transport mode SAs, the xxx-address and sa-xxx-address are the same by definition.

In my case it's gonna be even simpler since I will run a /30 GRE tunnel over it.
A GRE tunnel also has addresses of the transport packets, and you can attach payload addresses to the tunnel interfaces; as you mention /30, it suggests you talk about addresses you attach to the tunnel interfaces, but these have nothing to do with the policy if you use GRE over IPsec where GRE transport is IPsec payload, as opposed to IPsec over GRE where IPsec transport is GRE payload. The latter would not work across any NAT as GRE has no notion of ports so most NAT devices cannot handle it, and those that can can handle at most one GRE tunnel to each remote address.

Let's take the real IP's I use.
Assuming that the own address of the HQ router in its LAN subnet is 172.20.x.y and the own address of the 4G router in its LAN subnet is 172.18.z.t, it will look as follows:

Main site:
peer: name=anyone address=0.0.0.0/0 passive=yes; if you use other exchange-mode than ike2, set nat-traversal in the profile used by the peer to yes, but it's the default anyway. For IKEv2, NAT traversal is a part of the standard that cannot be switched off. I suppose the public IP to which the 4G device is NATed is not a static one, so you must accept incoming connections from the whole world, and you cannot initiate any as you don't know the address of the remote peer. And even if you knew the public one and it was a static one, sending connection attempts to it would be pointless as the mobile operator doesn't know to which CGNAT address to forward them.
policy: peer=anyone src-address=172.20.x.y/16 dst-address=172.18.z.t/16
gre: name=gre-4G local-address=172.20.x.y remote-address=172.18.z.t
IP address: address=172.30.2.1/30 interface=gre-4G

4G site:
peer: name=HQ address=HQ_public_IP passive=no (and nat-traversal in profile must also be set to yes)
policy: peer=HQ src-address=172.18.z.t/16 dst-address=172.20.x.y/16
gre: name=gre-HQ local-address=172.18.z.t remote-address=172.20.x.y
IP address: address=172.30.2.2/30 interface=gre-HQ
 
dot02
Member Candidate
Member Candidate
Topic Author
Posts: 108
Joined: Tue Jun 15, 2021 1:23 am

Re: ikev2 VPN with one router behind CGN CG-NAT

Wed Jun 22, 2022 1:28 pm

I'm lost...

I tries that config yesterday but the ipsec tunnel still doesn't establish. I compared your config with another (ikev1) config I have on the HQ router (which is running rock-stable for weeks) and it is the other ways around:
/interface gre
add allow-fast-path=no mtu=1300 name=gre-tunnel1 remote-address=1.1.1.1

/ip ipsec profile
add dh-group=modp1536 dpd-interval=30s dpd-maximum-failures=100 enc-algorithm=aes-256 lifetime=1h name=Profile_SiteX \
nat-traversal=no proposal-check=strict

/ip ipsec peer
add address=1.1.1.1/32 comment="VPN to SiteX" local-address=2.2.2.2 name=Peer_SiteX profile=\
Profile_SiteX

/ip ipsec proposal
add enc-algorithms=aes-256-cbc lifetime=1h name=ipsec_SiteX pfs-group=modp1536

/ip ipsec identity
add comment=SiteX peer=Peer_SiteX

/ip ipsec policy
add dst-address=1.1.1.1/32 peer=Peer_SiteX proposal=ipsec_SiteX protocol=gre src-address=\
2.2.2.2/32 tunnel=yes
In your config, you specify the private IP addresses. How is the tunnel supposed to establish since these private IP's are not routable over the public WAN?
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: ikev2 VPN with one router behind CGN CG-NAT

Wed Jun 22, 2022 3:26 pm

I'm lost...

I tries that config yesterday but the ipsec tunnel still doesn't establish.

In your config, you specify the private IP addresses. How is the tunnel supposed to establish since these private IP's are not routable over the public WAN?
One more time. The SA consists of transport packets one IPsec peer sends to the other one. These transport packets contain encrypted versions of payload packets plus some additional information. So the sa-src-address is the same like the own address that the local router uses to send IKE traffic to the remote peer (in your example, 2.2.2.2), and the sa-dst-address is the same like the address of the remote peer (in your example, 1.1.1.1). These two addresses are not manually configured for the policy - they are dynamically inherited from the active-peer properties, because the address of the remote peer may be specified as an fqdn and resolved to an IP number, and because the local address is chosen depending on the route to that remote IP number - some systems use multiple WANs.

Since you've decided to use tunnel mode of the policy, you had to specify the src-address and dst-address separately. It was your choice to configure the GRE tunnel to use the public addresses of both routers as local-address and remote-address, hence the src-address (matching the GRE's local-address) is the same like the sa-src-address and the dst-address (matching GRE's remote-address) is the same like the sa-dst-address, but it is only so because you have chosen GRE's local-address and remote-address this way. You had this option because both 1.1.1.1 and 2.2.2.2 in your example are public and static.

In the 4G case, you do not have this option, because the own WAN address of the 4G router is not public, and the public NAT address from behind which it talks to the HQ router is not static, or at least it is not known in advance, before the 4G router connects from that address.

So you have to let the HQ peer accept connections from anywhere, you have to make use of the fact that sa-dst-address is assigned dynamically, and as the GRE's remote-address and policy's dst-address you have to specify something else than the public IP from behind which the 4G router connects, because the 4G router itself does not know that public IP, so it cannot be set as the src-address of the policy on the 4G router.

If the CGNAT WAN address of the 4G router is static (which is however not common), you can use it for GRE's remote-address and policy's dst-address (from the point of view the HQ side); if it is not, you have to use some other own address of the 4G router, which is static. In both cases, the address you choose must not be in conflict with any address used at the HQ side.

So in my example, I've used private addresses for both GRE endpoints and the corresponding traffic selector of the policy, because in a generic case, even the WAN address of the HQ router may not be static.
 
dot02
Member Candidate
Member Candidate
Topic Author
Posts: 108
Joined: Tue Jun 15, 2021 1:23 am

Re: ikev2 VPN with one router behind CGN CG-NAT

Wed Jun 22, 2022 4:08 pm

Alright, now I think I get it! Thanks very much for the detailed explanation! At first I didn't realise that my current setup has to be considered as an exception due to the fact that BOTH gateways had public&static IP's. And frankly, after having configured dozens of IPsec tunnels over the years, I always thought I had to use the public IP's! But of course, all the gateways always had static&public IP's, that is why it worked.

I will give it another try this evening. and try to find out why I have this "no phase2" issue.

thanks again, I'll report here as to progress
 
dot02
Member Candidate
Member Candidate
Topic Author
Posts: 108
Joined: Tue Jun 15, 2021 1:23 am

Re: ikev2 VPN with one router behind CGN CG-NAT

Mon Jun 27, 2022 10:02 pm

I played a bit with the configs and it looks promising.
policy: peer=anyone src-address=172.20.x.y/16 dst-address=172.18.z.t/16
If I use lookback interfaces (bridge with no physical interface linked to it, and 172.20.0.1/32 on HQ side ; 172.18.0.1/32 on the 4G side), The IPsec policy should look like this, right?
policy: peer=anyone src-address=172.20.0.1/32 dst-address=172.18.0.1/32 (let's say I just want these 2 loopback to communicate)

at this point I'm not trying to have traffic sent over GRE, I'd be happy if I could get the IPsec SA's up and stable.

I get the following logs:
ipsec, info: new ike2 SA (I): Peer_siteA <GCN IP 10.110.229.36> - HQ_Public_IP...(...)
ipsec, info, account: peer authorized......(...)
ipsec, error: unable to apply address config
ipsec, info: killing ike2 SA (...)

the SA's are torn down immediately and it tried to establish a new one right away. Is there a way to get more detailed logs?
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: ikev2 VPN with one router behind CGN CG-NAT

Mon Jun 27, 2022 10:07 pm

ipsec, error: unable to apply address config
I'm not sure here but it sounds as if you had some mode-config configured on the /ip ipsec identity row?

Is there a way to get more detailed logs?
/system logging add topics=ipsec,!packet
But you have to run /log print follow-only file=ipsec-start where topics~"ipsec" in order to store the log into a file, as the normal log buffers get rewritten in no time.
 
dot02
Member Candidate
Member Candidate
Topic Author
Posts: 108
Joined: Tue Jun 15, 2021 1:23 am

Re: ikev2 VPN with one router behind CGN CG-NAT  [SOLVED]

Mon Jun 27, 2022 10:35 pm

niiiice, it was the mode config indeed!
now my IPSec SA's are up!

The GRE is up&running as well, I used the following parameters:

GRE interface config HQ router:
local address: Loopback address HQ (172.20.0.1)
remote-address: Loopback address 4G (172.18.0.1)

GRE interface config 4G router:
local address: Loopback address 4G (172.18.0.1)
remote-address: Loopback address HQ (172.20.0.1)

then of course the GRE L3 is configured as a /30 (172.30.2.0/30):
HQ IP: 172.30.2.1/30
4G IP: 172.30.2.2/30

works like a charm. thanks a lot for your help, Sindy!

Who is online

Users browsing this forum: No registered users and 88 guests