Community discussions

MikroTik App
 
rlaalstn1055
just joined
Topic Author
Posts: 5
Joined: Thu Jul 11, 2024 5:37 am

VPN, Site to Site Tunneling, Vlan, Secondary IP

Thu Jul 11, 2024 8:41 am

Hello, I am currently having difficulties with Site to Site Tunneling, so I would like to write to ask for help.

Depending on the conditions, communication may or may not be possible with VLAN.

Currently, only one-way communication (ICMP) is possible, and two-way communication is not possible.

And when set to Secondary IP in IPSec - Policies,

One-to-one communication works normally, but when you add a connection,

When the existing connection is disconnected, the entire connection does not work.

Please guide me on whether to add the Secondary IP to Policies or if there is another way to set it up.

I am attaching a photo of the settings below.

Mikrotik Router : 192.168.88.1

meraki F/W : 192.168.128.1(Real IP)
Secondary IP : 192.168.129.0/24
192.168.130.0/24

S/W Vlan Interface : 192.168.128.2
You do not have the required permissions to view the files attached to this post.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 10860
Joined: Mon Dec 04, 2017 9:19 pm

Re: VPN, Site to Site Tunneling, Vlan, Secondary IP  [SOLVED]

Mon Jul 15, 2024 10:03 pm

Given that you bothered to hide the WAN addresses of both peers (Mikrotik and Meraki) on the screenshots, I figure they are both public. Therefore, the Phase 2 SA uses bare ESP, but your firewall filter rules (at least the ones that did fit into the screenshot) do not accept incoming ESP. So if the connection is intiated from the Meraki side after a long pause, the ESP packet sent by Meraki is not accepted by Mikrotik.

You also seem to be a bit lost in how the firewall configuration works, as you explicitly accept the IPsec-related traffic in the output chain, but there is no drop rule in that chain, so the rest of output traffic is accepted implicitly.

Instead of posting a ton of screenshots, use /export hide-sensitive file=somenicename on the command line, then download the file somenicename.rsc, remove the serial number and replace usernames for various services by xxxxx; for public IP addresses, replace their first three bytes systematically by distinct a.b.c patterns in such a way that the relationship between addreses and subnets remains unchanged, and post the redacted version between [code] and [/code] tags.

Please explain what you mean by Secondary address. Your description is hard to understand overall, could it be that you use some translator that blurs the idea? If so, can you reveal your native language?
 
rlaalstn1055
just joined
Topic Author
Posts: 5
Joined: Thu Jul 11, 2024 5:37 am

Re: VPN, Site to Site Tunneling, Vlan, Secondary IP

Tue Jul 16, 2024 7:27 am

First of all, thank you for your kind response and explanation.
I am from Repulic Of Korea, and I will write the content in its original form below.

지금 현재 상황에 대해 설명드리겠습니다.

192.168.88.1(Mikrotik) ↔ 192.168.128.1, 192.168.135.1(Merkai)와 통신 하려 합니다.

우리가 위의 사진과 같이 설정을 했는데 정책에서 두 개를 동시에 enable 하면

둘 중 하나는 통신이 되지 않습니다. (각각 다른 포트에 VLAN으로 세팅을 하였습니다.)

우선 추가적으로, 말씀하신 대로 방화벽 룰에 ipsec-esp(output)을 추가 하였습니다.

그리고 보조 주소라는 것은 "Secondary IP"로, 하나의 인터페이스 안에서

여러 개의 서브 인터페이스를 주는 기술을 의미하는 것이었습니다.

한 포트에서 여러가지 주소를 주어 대역을 나누는 것을 Secondary IP로 표현하였습니다.

이 부분도 위와 마찬가지로, 메인 IP(192.168.128.1)와 서브 IP(192.168.129.1)을 설정하게 되면,

통신이 끊기는 현상이 발생합니다. 이에 관련된 해결 방법도 있을까요?

그리고 마지막으로, 오랜 일시 중지 후에 연결이 시작되면 ESP 패킷이 허용되지 않는다고 하셨는데,

그 시간은 대략 어느 정도일까요?

말씀하신 파일은 첨부해 놓았습니다. 감사합니다..
You do not have the required permissions to view the files attached to this post.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 10860
Joined: Mon Dec 04, 2017 9:19 pm

Re: VPN, Site to Site Tunneling, Vlan, Secondary IP

Tue Jul 16, 2024 12:09 pm

The following translation was made by the free version of DeepL, and the fact that you have posted the original text in Korean has helped me understand the layout of your Original Post; more important, in this DeepL translation, I do not see any sentences that do not make much sense, like I did in the Original Post.
Let me explain what's happening right now.

We want to communicate with 192.168.88.1 (Mikrotik) ↔ 192.168.128.1, 192.168.135.1 (Meraki).

We have it set up like in the picture above, but if we enable both at the same time in the policy, one of them will not communicate (we have them set up as VLANs on different ports).

First of all, we added ipsec-esp (output) to the firewall rule as you said.

And by secondary address, I meant "Secondary IP", which is a technique to give multiple subinterfaces within one interface.

Secondary IP is a way to divide the bandwidth by giving different addresses on one port.

As above, if I set the main IP (192.168.128.1) and the sub IP (192.168.129.1), the communication is lost. Is there a workaround for this as well?

And finally, you mentioned that ESP packets are not accepted when the connection starts after a long pause, what is the approximate duration of that?

I have attached the file you are referring to, thank you...

Translated with DeepL.com (free version)Let me explain what's happening right now.

We want to communicate with 192.168.88.1 (Mikrotik) ↔ 192.168.128.1, 192.168.135.1 (Meraki).

We have it set up like in the picture above, but if we enable both at the same time in the policy, one of them will not communicate (we have them set up as VLANs on different ports).

First of all, we added ipsec-esp(output) to the firewall rule as you said.

And by secondary address, I meant "Secondary IP", which is a technique to give multiple subinterfaces within one interface.

Secondary IP is a way to divide the bandwidth by giving different addresses on one port.

As above, if I set the main IP (192.168.128.1) and the sub IP (192.168.129.1), the communication is lost. Is there a workaround for this as well?

And finally, you mentioned that ESP packets are not accepted when the connection starts after a long pause, what is the approximate duration of that?

I have attached the file you are referring to, thank you...
Please excuse my "western simplicity" and let me describe the issues in the most straightforward way.

Regarding secondary addresses and subinterfaces, this is my understanding:
  • a secondary address is another IP address attached to the same interface like the primary one directly, i.e. without any VLANs
  • a "sub-interface" is a Cisco name for a VLAN interface attached to a physical one, so an IP address attched to a sub-interface of interface X is not considered a secondary address of interface X
From the policies in the configuration export, I gather that you use two subnets at Meraki side. From the point of view IPsec, it does not matter whether they share the same (V)LAN or whether each of them is attached to a dedicated VLAN (sub)interface, as IPsec is interested solely in L3 and higer layers.

Regarding IPsec not working:
I am afraid you may attribute the symptoms you observe to different causes than the actual ones. The operation of IPsec interacts heavily with other parts of the configuration, and you have to take this into account and modify the configuration accordingly when adding IPsec to an existing configuration. Whereas most manufacturers take some assumptions and do a lot of adjustments "under the hood", Mikrotik "lets you feel the road" and requires that you do everything manually. This gives you the maximum possible flexibility; the price to pay is the complexity of the configuration.

An issue with NAT:
Matching the packets about to be sent against the traffic selectors of IPsec policies is the very last step of packet processing, which is taken even after src-nat. Since there is no other route to the Meraki subnets than the default one in your configuration, the regular routing sends packets from 192.168.88.0/24 to 192.168.128.0 or 192.168.129.0 via the default route to a.b.c.1, which means that the action=masquerade rule in /ip firewall nat changes their source address to a.b.c.54. And since the traffic selectors only look at the packet after NAT has been executed, they ignore it as it does not match them any more. The /ip firewall nat table is only consulted when handling the initial packet of each connection (like a TCP session or a UDP stream) and all subsequent packets belonging to that connection inherit the same NAT treatment, so this issue affects only connections initiated by hosts on the Mikrotik side. The simplest way to avoid it is to add a match condition dst-address=!192.168.0.0/16 to the action=masquerade rule, but there are several other ways how to achieve the same effect. The goal is always the same, to prevent NATing of the traffic that has to be delivered using IPsec. In some other cases, it is the other way round, you need the traffic to be NATed in order to match an IPsec policy, but that's not relevant for your case.

An issue with fasttracking:
Fasttracking makes processing of packets faster by skipping some stages of packet processing for most packets; IPsec policy matching is one of the steps being skipped. So to quickly resolve this, re-enable the two rules action=accept ipsec-policy=... before the action=fasttrack-connection one in chain forward of /ip firewall filter. One of the purposes of these rules is to prevent connections that need to be forwarded using IPsec from getting fasttracked, see below.

Firewall filter:
Firewall rules can be seen as a programming script. Each packet passes them from the first (top) to last (bottom) one in a given chain (input, output, forward, prerouting, ...) in a given table until it either matches all conditions of that rule or it gets past the last rule without matching any of them. The default behavior of all chains is "accept" and on Mikrotik, it cannot be changed. So no rules in chain output of table filter mean that all packets in that chain will be accepted, so there is no need to add explicit action=accept rules.
Chain input handles packets whose destination is the router itself (so there is no out-interface for such packets); chain output handles packets sent by the router itself (so no in-interface exists for them); chain forward handles packets the router forwards from one external host to another external host. So there is no need to permit UDP ports 500 and 4500 and ESP in forward.
The firewall uses a connection tracking module to analyse the traffic and make it possible to implement a "stateful firewall". This allows you to put a single rule "accept packets belonging or related to already existing connections without further inspection" to the top (beginning) of each chain, and place all the selective permissive rules after (below) that one. So to save some CPU cycles, move the three IPsec-related rules in chain input below the action=fasttrack-connection rule. You can also put both 500 and 4500 as a list of ports to a single rule and remove the other rule.
The rule action=accept ipsec-policy=in,ipsec I have mentioned with regard to fasttracking also prevents payload packets that came encapsulated inside IPsec transport ones from getting dropped by the last rule in chain forward, which says "drop anything that came in via WAN unless it has been dst-nated". The thing is that IPsec does not use any virtual interfaces, so the payload packet inherits the in-interface attribute from the transport packet from which it has been decapsulated.

If it does not work after implementing the changes listed above, please post a fresh export of the config.
 
rlaalstn1055
just joined
Topic Author
Posts: 5
Joined: Thu Jul 11, 2024 5:37 am

Re: VPN, Site to Site Tunneling, Vlan, Secondary IP

Wed Jul 24, 2024 5:29 am

The following translation was made by the free version of DeepL, and the fact that you have posted the original text in Korean has helped me understand the layout of your Original Post; more important, in this DeepL translation, I do not see any sentences that do not make much sense, like I did in the Original Post.
Let me explain what's happening right now.

We want to communicate with 192.168.88.1 (Mikrotik) ↔ 192.168.128.1, 192.168.135.1 (Meraki).

We have it set up like in the picture above, but if we enable both at the same time in the policy, one of them will not communicate (we have them set up as VLANs on different ports).

First of all, we added ipsec-esp (output) to the firewall rule as you said.

And by secondary address, I meant "Secondary IP", which is a technique to give multiple subinterfaces within one interface.

Secondary IP is a way to divide the bandwidth by giving different addresses on one port.

As above, if I set the main IP (192.168.128.1) and the sub IP (192.168.129.1), the communication is lost. Is there a workaround for this as well?

And finally, you mentioned that ESP packets are not accepted when the connection starts after a long pause, what is the approximate duration of that?

I have attached the file you are referring to, thank you...

Translated with DeepL.com (free version)Let me explain what's happening right now.

We want to communicate with 192.168.88.1 (Mikrotik) ↔ 192.168.128.1, 192.168.135.1 (Meraki).

We have it set up like in the picture above, but if we enable both at the same time in the policy, one of them will not communicate (we have them set up as VLANs on different ports).

First of all, we added ipsec-esp(output) to the firewall rule as you said.

And by secondary address, I meant "Secondary IP", which is a technique to give multiple subinterfaces within one interface.

Secondary IP is a way to divide the bandwidth by giving different addresses on one port.

As above, if I set the main IP (192.168.128.1) and the sub IP (192.168.129.1), the communication is lost. Is there a workaround for this as well?

And finally, you mentioned that ESP packets are not accepted when the connection starts after a long pause, what is the approximate duration of that?

I have attached the file you are referring to, thank you...
Please excuse my "western simplicity" and let me describe the issues in the most straightforward way.

Regarding secondary addresses and subinterfaces, this is my understanding:
  • a secondary address is another IP address attached to the same interface like the primary one directly, i.e. without any VLANs
  • a "sub-interface" is a Cisco name for a VLAN interface attached to a physical one, so an IP address attched to a sub-interface of interface X is not considered a secondary address of interface X
From the policies in the configuration export, I gather that you use two subnets at Meraki side. From the point of view IPsec, it does not matter whether they share the same (V)LAN or whether each of them is attached to a dedicated VLAN (sub)interface, as IPsec is interested solely in L3 and higer layers.

Regarding IPsec not working:
I am afraid you may attribute the symptoms you observe to different causes than the actual ones. The operation of IPsec interacts heavily with other parts of the configuration, and you have to take this into account and modify the configuration accordingly when adding IPsec to an existing configuration. Whereas most manufacturers take some assumptions and do a lot of adjustments "under the hood", Mikrotik "lets you feel the road" and requires that you do everything manually. This gives you the maximum possible flexibility; the price to pay is the complexity of the configuration.

An issue with NAT:
Matching the packets about to be sent against the traffic selectors of IPsec policies is the very last step of packet processing, which is taken even after src-nat. Since there is no other route to the Meraki subnets than the default one in your configuration, the regular routing sends packets from 192.168.88.0/24 to 192.168.128.0 or 192.168.129.0 via the default route to a.b.c.1, which means that the action=masquerade rule in /ip firewall nat changes their source address to a.b.c.54. And since the traffic selectors only look at the packet after NAT has been executed, they ignore it as it does not match them any more. The /ip firewall nat table is only consulted when handling the initial packet of each connection (like a TCP session or a UDP stream) and all subsequent packets belonging to that connection inherit the same NAT treatment, so this issue affects only connections initiated by hosts on the Mikrotik side. The simplest way to avoid it is to add a match condition dst-address=!192.168.0.0/16 to the action=masquerade rule, but there are several other ways how to achieve the same effect. The goal is always the same, to prevent NATing of the traffic that has to be delivered using IPsec. In some other cases, it is the other way round, you need the traffic to be NATed in order to match an IPsec policy, but that's not relevant for your case.

An issue with fasttracking:
Fasttracking makes processing of packets faster by skipping some stages of packet processing for most packets; IPsec policy matching is one of the steps being skipped. So to quickly resolve this, re-enable the two rules action=accept ipsec-policy=... before the action=fasttrack-connection one in chain forward of /ip firewall filter. One of the purposes of these rules is to prevent connections that need to be forwarded using IPsec from getting fasttracked, see below.

Firewall filter:
Firewall rules can be seen as a programming script. Each packet passes them from the first (top) to last (bottom) one in a given chain (input, output, forward, prerouting, ...) in a given table until it either matches all conditions of that rule or it gets past the last rule without matching any of them. The default behavior of all chains is "accept" and on Mikrotik, it cannot be changed. So no rules in chain output of table filter mean that all packets in that chain will be accepted, so there is no need to add explicit action=accept rules.
Chain input handles packets whose destination is the router itself (so there is no out-interface for such packets); chain output handles packets sent by the router itself (so no in-interface exists for them); chain forward handles packets the router forwards from one external host to another external host. So there is no need to permit UDP ports 500 and 4500 and ESP in forward.
The firewall uses a connection tracking module to analyse the traffic and make it possible to implement a "stateful firewall". This allows you to put a single rule "accept packets belonging or related to already existing connections without further inspection" to the top (beginning) of each chain, and place all the selective permissive rules after (below) that one. So to save some CPU cycles, move the three IPsec-related rules in chain input below the action=fasttrack-connection rule. You can also put both 500 and 4500 as a list of ports to a single rule and remove the other rule.
The rule action=accept ipsec-policy=in,ipsec I have mentioned with regard to fasttracking also prevents payload packets that came encapsulated inside IPsec transport ones from getting dropped by the last rule in chain forward, which says "drop anything that came in via WAN unless it has been dst-nated". The thing is that IPsec does not use any virtual interfaces, so the payload packet inherits the in-interface attribute from the transport packet from which it has been decapsulated.

If it does not work after implementing the changes listed above, please post a fresh export of the config.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

안녕하세요? Cindy. 문의 주신 답변 잘 읽어보았습니다.

친절한 설명에도 불구하고, 이해가 안 가는 부분이 있어, 혹시 메일로 소통이 가능할까요?
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 10860
Joined: Mon Dec 04, 2017 9:19 pm

Re: VPN, Site to Site Tunneling, Vlan, Secondary IP

Wed Jul 24, 2024 8:38 am

Why not.
At least it will be more interactive.
The fact that notifications about new posts don't work again is annoying.

Please follow this post (and a few subsequent ones if needed).
 
User avatar
nichky
Forum Guru
Forum Guru
Posts: 1381
Joined: Tue Jun 23, 2015 2:35 pm

Re: VPN, Site to Site Tunneling, Vlan, Secondary IP

Wed Jul 24, 2024 2:29 pm

@sindy,

ako neshto mi treba da te kontaktiram , mogu da vidim tvoj key, sve ok , ali kako da ti poshaljem to?
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 10860
Joined: Mon Dec 04, 2017 9:19 pm

Re: VPN, Site to Site Tunneling, Vlan, Secondary IP

Wed Jul 24, 2024 2:40 pm

off topic - can be deleted
Last edited by sindy on Thu Jul 25, 2024 6:16 pm, edited 1 time in total.
 
User avatar
nichky
Forum Guru
Forum Guru
Posts: 1381
Joined: Tue Jun 23, 2015 2:35 pm

Re: VPN, Site to Site Tunneling, Vlan, Secondary IP

Wed Jul 24, 2024 2:43 pm

ukapirao sam . treba nov topik da otvorim za da ti to posaljem
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 10860
Joined: Mon Dec 04, 2017 9:19 pm

Re: VPN, Site to Site Tunneling, Vlan, Secondary IP

Wed Jul 24, 2024 3:06 pm

off topic - can be deleted
Last edited by sindy on Thu Jul 25, 2024 6:16 pm, edited 1 time in total.
 
rlaalstn1055
just joined
Topic Author
Posts: 5
Joined: Thu Jul 11, 2024 5:37 am

Re: VPN, Site to Site Tunneling, Vlan, Secondary IP

Thu Jul 25, 2024 4:50 am

Why not.
At least it will be more interactive.
The fact that notifications about new posts don't work again is annoying.

Please follow this post (and a few subsequent ones if needed).
어,, 죄송하지만 kim.ms@starion.co.kr 로 메일 하나만 보내주시겠어요???
 
User avatar
nichky
Forum Guru
Forum Guru
Posts: 1381
Joined: Tue Jun 23, 2015 2:35 pm

Re: VPN, Site to Site Tunneling, Vlan, Secondary IP

Thu Jul 25, 2024 7:26 am

removed
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 10860
Joined: Mon Dec 04, 2017 9:19 pm

Re: VPN, Site to Site Tunneling, Vlan, Secondary IP

Fri Jul 26, 2024 9:15 am

@rlaalstn1055, I have sent you an e-mail message yesterday. Have you received it?
 
rlaalstn1055
just joined
Topic Author
Posts: 5
Joined: Thu Jul 11, 2024 5:37 am

Re: VPN, Site to Site Tunneling, Vlan, Secondary IP

Mon Jul 29, 2024 1:46 am

@rlaalstn1055, I have sent you an e-mail message yesterday. Have you received it?
sorry. The email was not received. Or can you please contact rlaalstn1055@naver.com?
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 10860
Joined: Mon Dec 04, 2017 9:19 pm

Re: VPN, Site to Site Tunneling, Vlan, Secondary IP

Mon Jul 29, 2024 9:46 am

Or can you please contact ...?
Done.

Who is online

Users browsing this forum: Ahrefs [Bot], Bing [Bot] and 23 guests