Hosts can not ping remote hosts from ipip tunnel

RouterOS General
1

Hello All,

we have a CRS125-24G-1S in our factory and a hex in branch office. both locations have static ip address. The CRS (router-switch) has 24 ports which ehthernet1 is master for all other ports. The internet comes into the router via PPPoE and the factory ip range and the office branch are 192.168.1.0/24. I set up an ipip tunnel between routers and added a route towards branch office(192.168.1.18==>web server). we did not use 192.168.1.18 in our network in factory. I can ping it from CRS router but can not ping it from hosts in factory.also i can ping a web server in factory from hex router in branch office but not from hosts connected to it. would you please help me to solve this problem? Thank you in advance.

2

If both the branch and factory networks are 192.168.1.0/24 then you’ll either need to use proxy-arp (bad, bad, bad idea), change 1 network to a different range (best) or use twice nat to obfuscate the 2 networks from one another (complex but will work).

Maybe post a diagram so we can be sure we’re all on the same page.

3

Thank you idlemind,

why proxy-arp is a bad idea?

and would you please tell me how to do double nat step by step?

4

Double NAT, have a read through this post: http://forum.mikrotik.com/t/site-to-site-ipsec-tunnel/109591/11

I wrote it up for another user but should give you the idea of what’s needed.

Proxy-ARP is bad for a lot of reasons. Like anything it’s important to think about what it is actually doing. With it on the router will respond to ARP requests for any IP in it’s route-table. This means anyone would be able to interrogate a router with ARP to determine what is contained in it’s routing table. What people sometimes see as a reason to use it is a reason I prefer to turn it off. That is, by responding to ARP requests for anything in the routing table it can make traffic flow a way you shouldn’t think it should or cover up things like incorrect subnet masks or gateway IPs. This hiding of problems rear their head when you plan a network change that “shouldn’t” impact anything but it turns out it does because Proxy-ARP was acting as a band-aid and making hosts work. It can be incredibly difficult to uncover this behavior when you’re in the weeds troubleshooting.

I’m alright with using Proxy-ARP to fix an oops while you’re actively working on something but a solid design should not require Proxy-ARP to work.

5

Thanks,

which tunneling protocol do you recommend? ipip,eoip or GRE?

6

In factory side i created the followings:

dstnat
src address:10.20.2.0/24
dst address: 10.20.1.0/24
action: :
dstnat
to addresses: 192.168.1.0/24

srcnat
src address:192.168.1.0/24
dst address: 10.20.2.0/24
action:
srcnat
to addresses: 10.20.1.0/24

and route 10.20.2.0/24 via tunnel. I created vice versa in branch side but i can not ping hosts.

7

IPIP or GRE unless you need to stretch layer 2.

Are you pinging the 10.20.1 or 10.20.2 address?

8

No. I ping 192.168.1.18. Is my setup corect?

9

When you use double NAT to obfuscate your duplicate 192.168.1.0/24 networks you have to refer to them as what you are obfuscating them as. This can definitely be confusing, you’re using NAT to hide the fact that two networks have the same IP addresses. If at all possible it’s likely a lot less confusing to change the IP addressing on 1 side not to use 192.168.1.0/24.

Example:

SiteA - 192.168.1.0/24 = 10.20.1.0/24 to SiteB
SiteB - 192.168.1.0/24 = 10.20.2.0/24 to SiteA

For SiteB to ping a host at SiteA with the IP of 192.168.1.18/24 you need to ping 10.20.1.18.

For SiteA to ping a host at SiteB with the IP of 192.168.1.18/24 you need to ping 10.20.2.18.

Just for good measure, can you post a couple of exports:

/ip route export
/ip firewall export
10

Thanks again, here is my exports from factory side:

add action=dst-nat chain=dstnat dst-address=10.20.1.0/24 src-address=\
    10.20.2.0/24 to-addresses=192.168.1.0/24
add action=src-nat chain=srcnat dst-address=10.20.2.0/24 src-address=\
    192.168.1.0/24 to-addresses=10.20.1.0/2




add distance=1 dst-address=10.20.2.0/24 gateway=eoip-tunnel1

’

Branch side

add action=dst-nat chain=dstnat dst-address=10.20.2.0/24 src-address=\
    10.20.1.0/24 to-addresses=192.168.1.0/24
add action=src-nat chain=srcnat dst-address=10.20.2.0/24 src-address=\
    192.168.1.0/24 to-addresses=10.20.1.0/24




add distance=1 dst-address=10.20.1.0/24 gateway=eoip-tunnel1
11

Change the gateway from interfaces to an actual IP.

If I understand it correctly RouterOS will ARP for the destination IP when you use the interface as a gateway. Even though you’re doing 1:1 NAT RouterOS won’t respond to the ARP request unless it actually has the IP in the route table. By directing it to send traffic to a specific IP it will then hit the router where it will go through normal packet processing and hit the 1:1 NAT rules. Also their isn’t a reason to not specify the IP. It is a statically assigned IP so it will not change like a dynamic one would or at least could.

Once you get this working you should look at changing your tunnel from EoIP to IPIP or GRE. It will save you at least 14 bytes worth of extra header data in MTU size. For the case of getting a ping to work it won’t matter though.

12

Thanks,

I’ll try and let you know the result.

13

Idelmind,

i did what you said but i can not ping the other side. i also changed eoip to ipip. should i enable proxy-arp for all 24 ports or not?

14

No proxy ARP shouldn’t be needed. You’re ping the 10.x.x.y/24 address right? You won’t be able to directly ping the 192.168.1.0/24 address from side to the other.

Also, re-reading your post … the branch side rule:

add action=src-nat chain=srcnat dst-address=10.20.2.0/24 src-address=
192.168.1.0/24 to-addresses=10.20.1.0/24

needs to be:

dst-address = 10.20.1.0/24
to-addressess=10.20.2.0/24

15

Should i change the factory side as well?

I did all the steps from the image you sent me.

16

Nope, just the branch. I just looked at the drawing. I’ll have to update that drawing. I must have copied and pasted on accident without editing it.

17

i did the way you said but still no success.

I changed the factory side from 10.20.1.0/24 to 192.168.10.0/24 and branch side from 10.20.2.0/24 to 192.168.20.0/24. I can’t ping 192.168.20.18 from factory to branch.
Factory:

add action=dst-nat chain=dstnat dst-address=192.168.10.0/24 src-address=\
    192.168.20.0/24 to-addresses=192.168.1.0/24
add action=src-nat chain=srcnat dst-address=192.168.20.0/24 src-address=\
    192.168.1.0/24 to-addresses=192.168.10.0/24




add distance=1 dst-address=192.168.20.0/24 gateway=2.2.2.2

Branch:

add action=dst-nat chain=dstnat dst-address=192.168.20.0/24 src-address=\
    192.168.10.0/24 to-addresses=192.168.1.0/24
add action=src-nat chain=srcnat dst-address=192.168.10.0/24 src-address=\
    192.168.1.0/24 to-addresses=192.168.20.0/24




add distance=1 dst-address=192.168.10.0/24 gateway=2.2.2.1
18

Now your rules are all messed up. I’m on my phone now so I won’t be able to post anything more until late tonight or tomorrow.
^^ Read the rules while getting coffee. After drinking said coffee. The NAT rules themselves look correct.

Lastly make sure these rules are above anything else that might affect them. Commonly the normal SRCNAT to the Internet interferes with them.

19

any idea?

20
  • Check the order of your NAT rules, they need to take effect before any other rules that may affect the traffic. A common mistake is they are placed below the general Internet access masquerade.
  • Ensure the gateway for your routes is the address of the far end of the IPIP tunnel. The values you gave appear to be bogus / obfuscated values so we can’t be sure.