Community discussions

MikroTik App
 
User avatar
mdd
newbie
Topic Author
Posts: 49
Joined: Mon Oct 02, 2017 4:25 pm
Location: Klaipeda, Lithuania

IPSEC + overlaping subnet again

Wed Oct 12, 2022 11:49 am

Hi all have one question need some advise, as i have very unhelpful client (strong security requirements and no support staff) with ipsec overlapping local sub nets.
I have read lots of info and tried few setups, some king of them works half way but not fully (netmap). Does client needs to do any changes too to this work ? Or can this be done only on my side ? Also do i need to have this client's given subnet set up on any my interface or i can just use it ? Again needs help on this:

What i have:

My side (Mikrotik CCR1036):

10.0.0.0/24 - overlapping subnet, from this network I need to get connect to clients given IP 10.14.30.100/24 through IPSEC tunnel.
10.168.10.0/24 - client gave me this subnet to use in IPSEC policy, to avoid overlapping subnet

Client side (Fortigate FW)

10.14.0.0/16 - particular one IP I need access from this 10.14.30.100/24

Exports:
/ip ipsec profile
add dh-group=modp1024 enc-algorithm=3des name=profile_1
add dh-group=modp1024 enc-algorithm=3des name=profile_2
add dh-group=modp1536 enc-algorithm=aes-256 lifetime=2h10m name=Client1 Profile nat-traversal=no
/ip ipsec peer
add address=111.121.121.111/32 local-address=222.111.111.222 name=Client1 profile=Client1Profile send-initial-contact=no
add disabled=yes name=peer2 passive=yes profile=profile_2
add disabled=yes name=peer1 passive=yes profile=profile_1
/ip ipsec proposal
set [ find default=yes ] disabled=yes enc-algorithms=3des pfs-group=none
add enc-algorithms=aes-256-cbc lifetime=1h name=ClientProps pfs-group=modp1536
/ip ipsec identity
# Suggestion to use stronger pre-shared key or different authentication method
add generate-policy=port-override peer=peer1 remote-id=ignore
add generate-policy=port-override peer=peer2 remote-id=ignore
add peer=Client1
/ip ipsec policy
set 0 disabled=yes
add dst-address=10.14.0.0/16 peer=Client1 proposal=ClientProps src-address=10.168.10.0/24 tunnel=yes

Also question: do i need to have this client givent subnet set up on any interface ???

/ip address
add address=10.168.10.1/24 comment="Overlaping Client1" interface=ether6 network=10.168.10.0
 
User avatar
mdd
newbie
Topic Author
Posts: 49
Joined: Mon Oct 02, 2017 4:25 pm
Location: Klaipeda, Lithuania

Re: IPSEC + overlaping subnet again  [SOLVED]

Tue Oct 25, 2022 9:08 am

Not sure if i done right, but seems it works. Here if someone needs help about this too. I have added these rules before main outgoing masquerade rule.
/ip firewall nat
add action=accept chain=srcnat comment="Client" dst-address=10.168.10.0/24 src-address=10.14.0.0/16 to-addresses=10.168.10.0/24
add action=src-nat chain=srcnat comment="Client" dst-address=10.14.0.0/16 src-address=10.0.0.0/24 to-addresses=10.168.10.0/24
So far works.
 
Sob
Forum Guru
Forum Guru
Posts: 9188
Joined: Mon Apr 20, 2009 9:11 pm

Re: IPSEC + overlaping subnet again

Wed Oct 26, 2022 2:42 am

I don't think that the first rule does anything useful. If I understand it correctly, src/dst-address conditions match traffic from their subnet to your virtual subnet, so that covers incoming connections from them to you. But action=accept is saying that it should be excluded from further srcnat, which isn't good for anything (and to-addresses is just leftover that doesn't do anything with action=accept). The rule could have some use if it had action=dst-nat/netmap and to-addresses=10.0.0.0/24, then it would be possible to reach your devices from them.
 
User avatar
mdd
newbie
Topic Author
Posts: 49
Joined: Mon Oct 02, 2017 4:25 pm
Location: Klaipeda, Lithuania

Re: IPSEC + overlaping subnet again

Mon Dec 12, 2022 3:25 pm

Thanks Sob for correcting. How the rules be written ?
 
Sob
Forum Guru
Forum Guru
Posts: 9188
Joined: Mon Apr 20, 2009 9:11 pm

Re: IPSEC + overlaping subnet again

Sun Dec 18, 2022 2:19 am

Exactly as you have it, but only half of them. :) Second rule changes your 10.0.0.x to 10.168.10.x when connecting to their 10.14.x.x, that's what you want. First one matches if their 10.14.x.x tries to connect to your virtual 10.168.10.x, but it doesn't do anything useful with it. To handle such incoming connections and allow them to reach your devices, you'd need:
/ip firewall nat
add chain=dstnat src-address=10.14.0.0/16 dst-address=10.168.10.0/24 action=netmap to-addresses=10.0.0.0/24