Ping from VPN IPSec Site to Site

Hi everybody,

I have a problem that I can’t solve on my own and I hope you can help me.

I have two mikrotik connected by ipsec between them. They’re both connected and you can see each other. What’s the problem? I have a computer on a subnet of one of the mikrotiks that I can’t access from the other mikrotik.

The configuration of both mikrotik is as follows:

Mikrotik1

LAN: 192.168.0.28/30

Mikrotik2

LAN: 172.16.0.0/16

On the Mikrotik 1 LAN I have a computer with IP 192.168.0.30 without a gateway. This computer cannot have a gateway.

From the Mikrotik2 I can ping the IP 192.168.0.29 (IP of Mikrotik 1) but I cannot reach the computer with IP 192.168.0.30.

Could someone tell me how to get from the Mikrotik2 LAN to the computer with IP 192.168.0.30 without gateway, in the Mikrotik1?

Thank you all very much.

The most important question to me is, does the tunnel actually work?
Does it work but you cant reach that computer?
It does not work at all?

What should we begin with ?

“They see each other” is not enough. If you can reach one Mikrotik by its private IP from another one’s private IP, it means that the tunnel itself works, but firewall rules may prevent devices connected to the Mikrotiks from seeing each other although the Mikrotiks themselves do. So the first step should be to temporarily connect something else instead of that problematic computer, with same IP settings (192.168.0.30/30 and default gateway 192.168.0.29) and make sure it is remotely accessible via the VPN; only after this step you may proceed with dealing with the routing limitations.

Next, there may be many reasons why the “gateway cannot be set” on the problematic computer. Either it is really a limitation of its network stack, or it may be an issue that the interface you use is not the primary one an it is either not possible to set up a (non-default) route through it or you don’t know how to do it. Depending on that, the solution may vary from setting up a DHCP server which provides a routing table without a default route, through setting a proxy-arp mode on the LAN port (where nothing but the problematic device is connected anyway), down to setting a src-nat on that LAN port as the last resort (which means that the problematic device will see all traffic to come from 192.168.0.29 but this may not be an issue for you).

Hello,

Thank you for responding.

The tunnel is currently running. You can ping from one Mikrotik to the other, to the IP of each Mikrotik in the LAN. For example: Mikrotik1 can ping to IP 172.16.0.1 and Mikrotik2 can ping to IP 192.168.0.29.

From Mikrotik1 I can ping IP 192.168.0.30, but from Mikrotik2 (remote) I cannot ping that IP.

The device with IP 192.168.0.30 cannot have a gateway for certain reasons. The solution would be to put a gateway in the configuration of the equipment, but it is not what I want.

The proxy-arp is enabled on the Mikrotik1’s LAN.

What I need is to be able to ping from the Mikrotik2 to the IP 192.168.0.30 which is in the Mikrotik1.

Is there any possibility to establish a gateway on the mikrotik1 for the device with IP 192.168.0.30 or any route that will get me from the Mikrotik2 to that device?

Thank you very much for your help.

“can ping the own LAN address of the remote Mikrotik” and “can ping an address of a device in the LAN subnet of the remote Mikrotik” are two different things from the point of view of the firewall on the remote Mikrotik, because the former case is handled by filter chain input whilst the latter is handled by filter chain forward.


In that case, one way which doesn’t need anything to change on the device itself is to let the device see all requests from Mikrotik2’s LAN as if coming from the address of Mikrotik1 which is within the same subnet as its own IP on that interface, so packets towards that address do not need any gateway and can be sent directly. To achieve this, set up a src-nat rule on Mikrotik1:
/ip firewall nat add chain=srcnat dst-address=192.168.0.30 action=src-nat to-addresses=192.168.0.29


This could also be a way, but it would require that the mask on that device was shorter (possibly down to 0 if it doesn’t interfere with anything else, you don’t share the details of that device’s configuration) - at least as wide so that it would cover both 192.168.0.30 and 172.16.0.0/16 simultaneously, which would mean /1 (and it already covers half of the whole IP address range so it is probably not a good idea). This would be necessary so that the device would assume that the 172.16.x.x is on its LAN subnet and send an ARP request for it, which the Mikrotik1 would respond under certain circumstances.

Hello,

I added the rule:

/ip firewall nat add chain=srcnat dst-address=192.168.0.30 action=src-nat to-addresses=192.168.0.29

I still can’t access the computer with IP 192.168.0.30 This IP is set on a subnetwork card, so no gateway can be set.

The tunnel still works, I can ping to IP 192.168.0.29, I can ping from Mikrotik1 to IP 192.168.0.30 but not from the remote Mikrotik… I don’t know how to continue.

Any other ideas?

Thank you very much.

Show me the whole output of /ip firewall nat print on Mikrotik1. As you say you can ping the 192.168.0.30 from Mikrotik1, the rule you’ve added must be shadowed by some other one, or you must have mistakenly added it to Mikrotik2 instead of Mikrotik1.

Do you have the routes?

In A you need to create a router with info about what is under B, and in B you need to create a router what is under A

Hello,

Mikrotik1 NAT:

Flags: X - disabled, I - invalid, D - dynamic 
 0    chain=srcnat action=accept src-address=192.168.0.28/30 dst-address=172.16.0.0/24 log=no log-prefix="" 

 1    chain=srcnat action=src-nat to-addresses=192.168.0.30 dst-address=192.168.0.30 log=no log-prefix="" 

 2    chain=srcnat action=masquerade out-interface=ether1 log=no log-prefix=""

Mikrotik2 NAT

Flags: X - disabled, I - invalid, D - dynamic 
 0    chain=srcnat action=accept src-address=172.16.0.0/24 
      dst-address=192.168.0.28/30 

 1    chain=srcnat action=masquerade out-interface=ether1 log=no log-prefix=""

The only issue is that the rule 1 on Mikrotik1 is wrong - to-addresses must be 192.168.0.29, not 192.168.0.30.

Sorry,

I have changed it but still doesn’t work.

Flags: X - disabled, I - invalid, D - dynamic 
 0    chain=srcnat action=accept src-address=192.168.0.28/30 dst-address=172.16.0.0/24 log=no log-prefix="" 

 1    chain=srcnat action=src-nat to-addresses=192.168.0.29 dst-address=192.168.0.30 log=no log-prefix="" 

 2    chain=srcnat action=masquerade out-interface=ether1 log=no log-prefix=""

I don’t know why I can ping to that computer from Mikrotik1 and I can’t from Mikrotik2.

Mikrotik1 Route

Mikrotik1 Route
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit 
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 A S  0.0.0.0/0                          192.168.8.1               1
 1 A S  172.16.0.0/24                     bridge1                   1
 2 ADC  192.168.0.28/30    192.168.0.29    bridge1                   0
 3 ADC  192.168.8.0/24     192.168.8.2     ether1                    0
 
 Mikrotik2 Route
 DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADS  0.0.0.0/0                          192.168.1.1               1
 1 ADC  172.16.0.0/24     172.22.62.1     bridge1                   0
 2 A S  192.168.0.28/30                    bridge1                   1
 3 ADC  192.168.1.0/24     192.168.1.45    ether1                    0

What do the /ip ipsec policy print detail say at both ends?

While you ping from Mikrotik2, what does /tool sniffer quick ip-address=192.168.0.30 show on Mikrotik1?

Hi,

IPSec Policy Mikrotik1

 1  A  peer1                  yes    192.168.0.28/30                                              172.16.0.0/24                                               all        encrypt require          1

IPSec Policy Mikrotik2

1  A  peer2                  yes    172.16.0.0/24                                               192.168.0.28/30                                              all        encrypt require          1

Sniffer Mikrotik 1

INTERFACE                                 TIME    NUM DIR SRC-MAC           DST-MAC           VLAN   SRC-ADDRESS                         DST-ADDRESS                         PROTOCOL   SIZE CPU FP 
bridge1                                 26.694     53 ->  B8:69:F4:FE:0D:20 90:1B:0E:E9:7C:9A        172.16.0.1                         192.168.0.30                        ip:icmp      70   0 no 
ether2                                  26.694     54 ->  B8:69:F4:FE:0D:20 90:1B:0E:E9:7C:9A        172.16.0.1                         192.168.0.30                        ip:icmp      70   0 no 
ether1                                  27.704     55 <-  74:DA:88:E6:D2:14 B8:69:F4:FE:0D:1F        172.16.0.1                         192.168.0.30                        ip:icmp      70   0 no 
bridge1                                 27.704     56 ->  B8:69:F4:FE:0D:20 90:1B:0E:E9:7C:9A        172.16.0.1                         192.168.0.30                        ip:icmp      70   0 no 
ether2                                  27.704     57 ->  B8:69:F4:FE:0D:20 90:1B:0E:E9:7C:9A        172.16.0.1                         192.168.0.30                        ip:icmp      70   0 no 
ether1                                  28.718     58 <-  74:DA:88:E6:D2:14 B8:69:F4:FE:0D:1F        172.16.0.1                         192.168.0.30                        ip:icmp      70   0 no 
bridge1                                 28.718     59 ->  B8:69:F4:FE:0D:20 90:1B:0E:E9:7C:9A        172.16.0.1                         192.168.0.30                        ip:icmp      70   0 no 
ether2                                  28.718     60 ->  B8:69:F4:FE:0D:20 90:1B:0E:E9:7C:9A        172.16.0.1                         192.168.0.30                        ip:icmp      70   0 no 
ether1                                  29.726     61 <-  74:DA:88:E6:D2:14 B8:69:F4:FE:0D:1F        172.16.0.1                         192.168.0.30                        ip:icmp      70   0 no 
bridge1                                 29.726     62 ->  B8:69:F4:FE:0D:20 90:1B:0E:E9:7C:9A        172.16.0.1                         192.168.0.30                        ip:icmp      70   0 no 
ether2                                  29.726     63 ->  B8:69:F4:FE:0D:20 90:1B:0E:E9:7C:9A        172.16.0.1                         192.168.0.30                        ip:icmp      70   0 no 
ether1                                  30.736     64 <-  74:DA:88:E6:D2:14 B8:69:F4:FE:0D:1F        172.16.0.1                         192.168.0.30                        ip:icmp      70   0 no 
bridge1                                 30.736     65 ->  B8:69:F4:FE:0D:20 90:1B:0E:E9:7C:9A        172.16.0.1                         192.168.0.30                        ip:icmp      70   0 no 
ether2                                  30.736     66 ->  B8:69:F4:FE:0D:20 90:1B:0E:E9:7C:9A        172.16.0.1                         192.168.0.30                        ip:icmp      70   0 no 
ether1                                  31.746     67 <-  74:DA:88:E6:D2:14 B8:69:F4:FE:0D:1F        172.16.0.1                         192.168.0.30                        ip:icmp      70   0 no 
bridge1                                 31.746     68 ->  B8:69:F4:FE:0D:20 90:1B:0E:E9:7C:9A        172.16.0.1                         192.168.0.30                        ip:icmp      70   0 no 
ether2                                  31.746     69 ->  B8:69:F4:FE:0D:20 90:1B:0E:E9:7C:9A        172.16.0.1                         192.168.0.30                        ip:icmp      70   0 no 
ether1                                  32.753     70 <-  74:DA:88:E6:D2:14 B8:69:F4:FE:0D:1F        172.16.0.1                         192.168.0.30                        ip:icmp      70   0 no 
bridge1                                 32.753     71 ->  B8:69:F4:FE:0D:20 90:1B:0E:E9:7C:9A        172.16.0.1                         192.168.0.30                        ip:icmp      70   0 no 
ether2                                  32.753     72 ->  B8:69:F4:FE:0D:20 90:1B:0E:E9:7C:9A        172.16.0.1                         192.168.0.30                        ip:icmp      70   0 no

Either you have manually set somewhere in /ip firewall raw a rule with an action=notrack for the traffic from 172.16.0.0/24 to 192.168.0.28/30 (or more), or you have set notrack-chain=forward in /ip ipsec identity. Due to that, connection tracking is disabled for the tunneled traffic, and therefore NAT cannot work.

Hello everybody,

Solved! That was the key.

I had a no-track in /ip firewall raw. After delete it, everything is working now!

Thank you so much for the help, specially to sindy.