Community discussions

MikroTik App
 
JosipTopic
newbie
Topic Author
Posts: 43
Joined: Mon Apr 06, 2020 10:21 pm
Location: Zagreb

IPsec Site to SIte behind NAT

Tue May 04, 2021 10:58 pm

Hello!
Been trying to figure out how to accomplish this task of mine, but it's not going.

I have two sites, Site A and Site B let's say.
This is common case here in Croatia, because a lot of times internet operator is not capable/can't put his router in bridge, so this is one of the answers i'm looking,
for this kind of situations.

Site A Conf, Site B conf and topology are here, please help me to figure out why i cant ping from PC in Site_B to a PC in Site_A and vice versa.
I can ping from PC to a loopback adapter on the other side of tunnel, but can't make it to the PC.

Thanks in advance.

Josip.
You do not have the required permissions to view the files attached to this post.
 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 2098
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa, Krugersdorp (Home town of Brad Binder)
Contact:

Re: IPsec Site to SIte behind NAT

Wed May 05, 2021 12:15 pm

Look at PC firewall settings, Windows firewall by default drops packets for "new" connections not from local subnet
 
JosipTopic
newbie
Topic Author
Posts: 43
Joined: Mon Apr 06, 2020 10:21 pm
Location: Zagreb

Re: IPsec Site to SIte behind NAT

Wed May 05, 2021 12:32 pm

Hello CZFan!

I did check windows firewall, it's turned off.
But i can't even ping from Site A routers src adress 10.0.0.1 to 192.168.97.99.

Anyone else, or any other tip?

Josip.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IPsec Site to SIte behind NAT

Wed May 05, 2021 9:08 pm

I'd say it's simply a routing issue at Site A. I assume all the devices in 192.168.97.0/24 get their IP configuration via DHCP from the Huawei, so their default route's gateway is the Huawei itself, 192.168.97.254. Hence when a ping packet arrives to them from 10.0.0.1, i.e. from an address outside their own subnet, they send the response using the default route, i.e. to the Huawei, which also doesn't know that 10.0.0.1 is accessible via 192.168.97.78, so it drops the response.

The same happens to packets arriving via the tunnels from Site B.
 
JosipTopic
newbie
Topic Author
Posts: 43
Joined: Mon Apr 06, 2020 10:21 pm
Location: Zagreb

Re: IPsec Site to SIte behind NAT

Wed May 05, 2021 9:26 pm

Hello Sindy!
You are close.
Ip addresses are being delivered by DHCP on windows server 2019. So yes, default gateway is Huaweis address 192.168.97.254.
But i've changed default gateway on PC-192.168.97.99 to be 192.168.97.78. What do you think i could do?

By the way, from Site B PC192.168.79.109 I can ping 10.0.0.1, and from 10.0.0.1 i can ping 192.168.97.99,

I only can't ping from site B PC 192.168.79.109 to SIte B PC 192.168.97.99.

I made route on SIte B Pc 192.168.79.0 MASK 255.255.255.0 to 192.168.97.78

Thanks!
 
JosipTopic
newbie
Topic Author
Posts: 43
Joined: Mon Apr 06, 2020 10:21 pm
Location: Zagreb

Re: IPsec Site to SIte behind NAT

Wed May 05, 2021 10:14 pm

Hello, Thanks for help, what was wrong, is that i had wrong networks in Policies on both routers.
On router on SIte A
1. I had networks for tunnel which are 10.0.01 --> 10.0.0.2 and 192.168.97.0/24 --> public ip of Router on Site B , which i changed in to 192.168.79.0/24.

On router on Site B
2. I had networks for tunnel which are 10.0.0.2 --> 10.0.0.1 and 192.168.79.14 -->>192.168.97.0/24 which i changed to 192.168.79.0/24 --> 192.168.97.0/24

Now ping is working like it should.

Question -- Is it possible to have ddns name on Site B router so when ip changes that tunnel stays up, or no?
Another question - do i have to have a route on both Sites routers or it is enough that i have networks in policies of IPsec?

Thanks and good night.
 
JosipTopic
newbie
Topic Author
Posts: 43
Joined: Mon Apr 06, 2020 10:21 pm
Location: Zagreb

Re: IPsec Site to SIte behind NAT

Wed May 05, 2021 10:27 pm

One more thing, like you said Sindy,
ping works only for PC that has 192.168.97.78 Gateway, all other PC's aren't reachable.
So what could i do? How to make other PCs know to reach other side.

Should i put Site A Mikrotik router to be default gateway on windows DHCP, and in Mikrotik router put default route to be 192.168.97.254 and 192.168.79.0 to be 10.0.0.2?

Thanks.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IPsec Site to SIte behind NAT

Wed May 05, 2021 10:42 pm

Is it possible to have ddns name on Site B router so when ip changes that tunnel stays up, or no?
RouterOS doesn't support IPsec MOBIKE yet, so the tunnel won't exactly stay up but it will re-establish. You can use the /ip cloud to update the dynamic DNS operated by Mikrotik (xxxxxxxx.sn.mynetname.net), and configure that fqdn as the address of the peer representing Site B at Site A. This way, the IPsec connection will be renegotiated each time the actual address changes.

Another question - do i have to have a route on both Sites routers or it is enough that i have networks in policies of IPsec?
In order that the traffic selectors of IPsec policies could match packets, the packets must first be routed by the regular routing. So you need some route to exist for these packets - the default one is usually sufficient.

Should i put Site A Mikrotik router to be default gateway on windows DHCP, and in Mikrotik router put default route to be 192.168.97.254 and 192.168.79.0 to be 10.0.0.2?
If all the PCs are Windows ones, you may make the Tik the DHCP server for 192.168.97.0/24 instead of the Huawei, and use DHCP Option 249 to push selective routes to the PCs. I.e. the default gateway will still be 192.168.97.254, but for several chosen destinations, you'll instruct the PCs to use 192.168.97.78.

If you just make 192.168.97.78 the default gateway for the PCs, and the Tik itself has a default route via 192.168.97.254, it will send ICMP redirect messages to the PCs whenever it receives a packet it has to route via the Huawei, informing them that 192.168.97.254 is a better gateway in 192.168.97.0/24 for other destinations than 192.168.79.0. But even this approach requires that the DHCP server is the Tik, as I don't believe you can configure Huawei to assign anything else than itself as a default gateway. Plus in this case you must have a dedicated route to 192.168.79.0/24 on the Tik, as otherwise it would send the ICMP redirects also for packets with destination addresses from 192.168.79.0/24. You can use e.g. the br-loopback as the gateway of such route.
 
JosipTopic
newbie
Topic Author
Posts: 43
Joined: Mon Apr 06, 2020 10:21 pm
Location: Zagreb

Re: IPsec Site to SIte behind NAT

Wed May 05, 2021 11:02 pm

[/quote]
. You can use e.g. the br-loopback as the gateway of such route.
[/quote]
I would like to try to make this second approach, because we have windows server 2019 that is DNS , and DHCP, i could try though to make him to deliver to PCs IP configuration with 192.168.97.78 as deault gateway and option 249 ( don't know if that is possible in Windows server), but i don't understand idea of route with br-loopback as the gateway.
Can you explain, please?

Thank you.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IPsec Site to SIte behind NAT

Thu May 06, 2021 8:59 am

don't know if that is possible in Windows server
It is. Option 249 is Microsoft's proprietary alternative to Option 121. The difference between the two is that Option 249 is used in addition to Option 3 (list of default gateways), whereas Option 121 replaces Option 3 (i.e. it contains the complete route list, including the default one).

i don't understand idea of route with br-loopback as the gateway.
First, you only need this if the Option 249 approach fails.

Second, an interface name can be set as a gateway parameter of a route. If it is a point-to-point interface, it always works; if it is a point-to-multipoint interface, it only works as such if the underlying network stack accepts ICMP router advertisements, so it learns a list of routers accessible through that interface. This doesn't seem to be the case of RouterOS for IPv4 (or at least it wasn't when I tried that last time years ago, and the manual explicitly states that it doesn't work). However, the fact that it doesn't work does not interfere with the possibility to specify a P-MP interface as a gateway of a route.

If it was a real Ethernet interface with a router connected to it, the packets would be dropped, but in your case, the IPsec traffic selector will match these packets before they actually reach the interface, and will divert them to the IPsec SA. So you can reuse br-loopback as a gateway of a route shadowing the default one for the destinations reachable via the SA. The default route points to a router in the same subnet from which the PCs send their traffic, and would thus cause the ICMP redirect messages to be sent to the PCs.

Another application of the same approach is a "killswitch" for IPsec VPNs - if you want to prevent traffic that should only ever be sent via a VPN from leaking through the default gateway when the VPN is down, setting a route for this traffic via a bridge with no physical interfaces does the trick. A type=blackhole route doesn't because blackholed packets are dropped before they reach the traffic selector matching phase.
 
JosipTopic
newbie
Topic Author
Posts: 43
Joined: Mon Apr 06, 2020 10:21 pm
Location: Zagreb

Re: IPsec Site to SIte behind NAT

Thu May 06, 2021 9:19 am

Thank you Sindy, I wish that i have a knowledge to understand this what you just wrote...:-)
Nevermind, i'll keep tryin...
The whole conception of what you're trying to tell me is to much for my head, if you could put it little simplier it would be great, or maybe even better, you could point me
what and where i could start reading, to upgrade this and to be able to connect everything in my head.I've been listening videos from Maher Hadad, and this is at the moment something i able to digest.

So, any let's say tip or advise would be great so i could be able to continue to develop my knowledge.

Josip.

Who is online

Users browsing this forum: GoogleOther [Bot], Kanzler and 78 guests